AI Use Case Register: What It Is and How to Build One

An AI use case register is the structured record in which a company lists every use of artificial intelligence: what task it performs, in which department, with which tool, on what data, under whose responsibility and at what risk level. It is where spend control, adoption and compliance meet, because it answers a question all three functions ask: what are we actually using?

Why do you need an AI use case register?

Many companies know the tools they have bought, but not the ways those tools are used. The two are different. The same tool can be used to rephrase an internal text or to process customers' personal data, and the risk changes radically.

A use case register solves three problems:

• Visibility. It gives a single map of uses, including those that arose spontaneously in departments.
• Priority. It lets you focus controls and training where risk or value is greatest.
• Consistency. It gives IT, the DPO, the CISO, HR and finance a shared basis, instead of different lists in each function.

The key step is shifting the unit of analysis from the tool to the use case. The tool is a means; the use case is what generates value, cost and risk.

Which fields do you need: the minimum set

A register that is too ambitious does not get filled in. It is better to start with seven fields, the ones needed to make decisions.

1. Use case. A short, concrete description of the task (for example "summaries of meeting minutes"), not the name of the tool.
2. Department. The organizational unit that performs it. Record the department or role, not individuals.
3. Tool. The service or model used, including whether it is an approved company tool or an unofficial service.
4. Data processed. The type of information that enters the tool: public, internal, confidential, personal data, special categories of data.
5. Owner. The person accountable for the use case, who knows its purpose and can speak to its outcome.
6. Status. For example: proposed, pilot, in production, suspended, retired.
7. Risk level. An internal classification (for example low, medium, high), to be refined with the categories set by the regulations.

Once the register works, you can add fields such as number of users, review date, expected benefit and impact measure. But every extra field lowers the completion rate: add one only if someone will use it to decide.

How do you assign the risk level?

The risk level is the most delicate field, because it needs a criterion. A reasonable approach combines two factors: the sensitivity of the data and the consequences of an error in the output.

Some examples of criteria:

• if personal data enters, the use case falls within the scope of the GDPR and may require a legal basis (article 6), privacy notices (articles 13 and 14) and, in high-risk cases, an impact assessment (article 35);
• if the output influences decisions about people (recruitment, evaluation, access to services), the risk rises and may approach the categories of the EU AI Act;
• if the use falls among the practices prohibited by article 5 of the EU AI Act, it must be stopped: the prohibitions have applied since 2 February 2025;
• if the tool is a critical supplier for essential services, the supply chain risk management provided for by the NIS2 Directive comes into play.

The EU AI Act (Regulation (EU) 2024/1689) classifies systems by risk level and provides, for high-risk systems, specific obligations for those who use them (deployers), as well as transparency obligations in some cases. The application timetable for the other obligations should be checked in official updates. This guidance is informational and is not legal advice.

How do you populate the register?

The biggest risk is a register filled in once and never updated. To avoid it, combine several sources.

1. Start from known tools. License and contract lists give a first core of use cases to confirm with departments.
2. Interview department heads. A short structured conversation brings out uses that appear in no contract.
3. Run a questionnaire. An aggregated survey helps surface use of unapproved tools as well. This is the path described in shadow AI risks and how to manage it.
4. Verify with usage data. Vendor consoles expose, to varying degrees, activity data that confirms or contradicts what was declared.
5. Open a channel for new requests. Anyone who wants to start a new use registers it before starting, through a lightweight approval process.
6. Set a periodic review. For example quarterly, with deadlines for each owner.

A useful principle: make declaring easy, not punitive. If registering a use exposes people to internal sanctions, they will stop declaring it. This is also why data on people should be handled in aggregate by role or department.

How do you link the register to spend?

The register becomes powerful when it cross-references costs. By associating each use case with the tools and seats that serve it, you get three answers that are otherwise missing:

• which tools serve the same use case (overlaps);
• which licenses are not linked to any registered use case (candidates for revocation);
• how much each use case costs, in essence.

This reading is the basis for a reasoned consolidation, described in how to reduce AI license spend, and for understanding whether the cost is proportionate to the benefit.

How do you link the register to compliance?

For compliance, the register is the starting point of almost every requirement. Each row lets you ask the right questions:

• GDPR: which use cases process personal data, on what legal basis, which vendors act as data processors (article 28), whether there are transfers outside the EU (Chapter V).
• EU AI Act: which risk category the use case belongs to, whether transparency or deployer obligations apply, whether the training required by article 4 on AI literacy is needed, applicable since 2 February 2025 (see AI literacy and training).
• NIS2: which AI vendors are part of the supply chain to be assessed.

A mapping of this kind helps clarify obligations and gaps, but it is not legal advice: conclusions should be validated with the DPO and advisers.

What are the common mistakes?

• Recording tools instead of use cases. The link to risk and value is lost.
• Too many fields at the start. Completion stalls and the register goes stale.
• No owner. Without a name, nobody updates it or answers for it.
• Assessing risk only once. Data, tools and rules change: the classification must be reviewed.
• A register separate from spend and compliance. If it lives in an isolated spreadsheet, it drives no decision.

Where Delphis fits

Delphis is a vendor-independent platform that connects spend, adoption, impact and regulatory obligations. The use case register is one of its elements: it inventories use cases and tools, links them to costs and observed usage, and maps GDPR, NIS2 and EU AI Act obligations with a gap checklist. The mapping guides the work, but it is not legal advice. More details on the Compliance page.

Sources

• GDPR, Regulation (EU) 2016/679
• AI Act, Regulation (EU) 2024/1689
• NIS2, Directive (EU) 2022/2555