AI use case register template
A practical way to record where AI is already running in the business, who owns each use and which obligations attach, in a form that survives a board question or a customer questionnaire.
“Most organisations discover their AI obligations backwards. They read about the regulation first and only then start asking which systems they actually run. The register is the work that should have come first.”
Tejas Dhabalia, Co-founder, DS Consulting
What you get
The template is built for teams that need to answer the question of where AI is used before they can answer any question about compliance, procurement or customer assurance.
One row per use, with the fields that matter. What it does, which system runs it, whether you are the provider or the deployer and whether output reaches EU users.
A guide tab covering the EU AI Act tiers and the four Article 50 triggers, so classification follows the purpose rather than the vendor.
Prompts to assign a business owner and a technical owner separately, because the person who runs the system is rarely the person accountable for it.
The current compliance timetable built in as a lookup, so each row shows when its obligation becomes live rather than requiring a separate check.
Right for you if
You have been asked where AI is used across the business and the honest answer is that nobody has a complete list.
AI has arrived as features inside tools you already bought, rather than as a project anyone approved.
A customer or an insurer has sent you an AI questionnaire and you are assembling the answer from memory.
You know the EU AI Act applies to you somewhere but not to which systems.
Find what is already running
Separate what was bought from what arrived.
Approved AI projects are the easy half. The harder half is AI that appeared inside software you already licensed, where nobody made a decision because nobody was asked.
Ask procurement, not just IT.
Expense reports and card statements surface tools that never went through a technical review. This is usually where the marketing and sales use cases are found.
Record shadow use rather than punishing it.
People using a public model to draft copy or summarise calls are a use case, not a disciplinary matter. A register that people are afraid to complete is worse than no register.
Include what is planned, not only what is live.
A use case logged at pilot stage can be classified before it is embedded. One logged after go live is a remediation project.
Establish your role for each use
Decide whether you are the provider or the deployer.
The provider develops the system or places it on the market. The deployer uses it. Most organisations are deployers, and deployers carry obligations in their own right.
Do not assume the vendor's compliance covers you.
Responsibility does not transfer automatically. Marking generated output is the provider's duty, but disclosing a deepfake or labelling AI written text on matters of public interest falls on whoever puts it in front of the reader.
Record where the output lands, not where the team sits.
Scope follows the output. A team outside the EU running a campaign aimed at European audiences is in scope. This is the field most often filled in wrongly.
Note when a system was placed on the market.
Systems already on the market before 2 August 2026 have until 2 December 2026 for the Article 50(2) marking duties. That distinction only matters if you recorded the date.
Classify by purpose, not by tool
The same model can sit in two tiers.
A general purpose model summarising internal documents is minimal risk. The same model ranking job candidates is high risk. Classification follows what the system is used for.
Check the Article 50 triggers separately from the risk tier.
Transparency duties apply regardless of tier. An organisation with no high risk AI at all can still have significant obligations because it runs a chatbot or publishes generated content.
Log the reasoning, not just the answer.
A classification with no recorded basis cannot be defended when someone asks in a year why a use case was judged minimal risk.
Flag anything you are unsure about rather than guessing.
An honest unsure field is a work item. A confident wrong classification is a control failure that nobody will look at again.
Make it a control rather than a list
Assign a business owner for every row.
Not a reviewer and not the IT contact. The person accountable when the obligation lands. A row with no named owner is the commonest failure in an AI register.
Record where the evidence lives.
Disclosure wording, vendor documentation, the classification rationale, human oversight arrangements. A register that points at nothing is a list.
Set a review cadence per row.
Not every use case needs quarterly review, but each one needs an intentional rhythm. Vendors add AI features to existing products without asking, so a classification ages whether or not the use case changes.
Connect it to procurement.
The register only stays current if new tools are added when they are bought rather than at the next audit.
Why this matters
The regulatory timetable has moved more than once, and it will probably move again. That makes the register more useful, not less. Whatever the dates turn out to be, the work of knowing which systems you run, what they are used for and who owns them is the same work, and it is the input to every obligation that follows.
There is also a commercial reason that has nothing to do with regulators. Customer questionnaires, insurance renewals and procurement reviews have all started asking where AI touches a supplier's process. An organisation that can answer in a week looks different from one that needs a month, and the difference is usually whether somebody kept a register.
Turning the register from a completed spreadsheet into a control with named owners, a review rhythm and a path into procurement is AI governance and adoption work.
Frequently asked questions
Do we need a register if we are not using high risk AI?
Yes, for two reasons. The Article 50 transparency obligations apply regardless of risk tier, so an organisation running a chatbot or publishing generated content has duties without any high risk AI at all. And the AI literacy duty under Article 4 applies across the board. A register is also how you demonstrate that you assessed the question rather than assumed the answer.
Who should own the register?
Someone in operations, technology or risk usually coordinates it, but every row should carry a named business owner. A register maintained entirely by one function becomes a document that describes the business rather than a control that governs it.
How is this different from an asset or software inventory?
An asset inventory records what you have licensed. A use case register records what those systems are used for, which is what determines obligations. One vendor tool can generate several use cases in different risk tiers, and an inventory organised by vendor cannot show that.
Get the template
Receive the AI use case register with fields for role, classification, Article 50 trigger, owner, evidence and review cadence, plus a classification guide and the current obligation dates.
Former IBM mainframe engineer turned operator across Tata and Tata-Tesco. Works at the seam between systems, governance and commercial execution.
LinkedIn profile →