The AI Use Case Register: Where EU AI Act Compliance Actually Begins
An AI use case register is step one of EU AI Act compliance: the exact fields it needs, how it maps each use to Article 6, and why it precedes everything else.
One large language model inside your company can be three different compliance problems at once. The same model used to screen CVs is high-risk under the EU AI Act; used to draft marketing copy it is minimal-risk; used to power a customer chatbot it carries transparency duties. Classification attaches to what you are doing, not the model you bought — which is why the first artefact you build is a register of uses, not a list of tools.
An AI use case register is the governance ledger of every distinct business use of AI in your organisation: one row per intended purpose, not one row per licence. It is deliberately upstream of, and lighter than, a full technical-documentation file — its job is to feed classification, not to be the evidence pack itself.
This page sets out exactly what a use case register is, why it is step one of compliance under Regulation (EU) 2024/1689, the fields it must hold, how each row flows into the Article 6 classification chain, and what it costs to get wrong.
What an AI Use Case Register Actually Is
Use case, not the model or the licence
The unit of analysis is the use case — a single intended purpose to which AI is put — not the tool that delivers it. Legal classification under the EU AI Act attaches to the intended purpose as defined in Article 3(12): the use for which an AI system is intended, including the specific context and conditions of use. That definition is the hook the entire classification chain hangs from, and it points at the use, not the underlying model.
This matters because one foundation model or vendor tool routinely generates several distinct use cases that classify differently. The same general-purpose model can sit behind CV-screening (high-risk), marketing-copy drafting (minimal), and a support chatbot (limited-risk transparency). Counting that as "one AI tool" hides three different obligation profiles. Counting it as three use cases surfaces them.
Why "register" is a governance artefact, not a software inventory
Distinguish the use case register sharply from the warehouse-stock sense of an AI inventory — the exercise of counting deployed models, SaaS seats, and API keys. The inventory asks what do we have running? The use case register asks what are we using AI to do, and to whom does it apply? That second question is the one the statute answers against.
The register is the input that feeds classification, risk assessment, and registration. It is intentionally lean: a governance control, not a 40-page documentation file. Keep it as the index that points downstream, not the place you duplicate downstream evidence.
The one-row-per-use-case rule
The governing discipline is simple: one row per distinct intended purpose. If a single tool serves two genuinely different purposes — scoring candidates and drafting offer letters — it earns two rows, because each will be classified separately. If two different tools serve the same purpose, that is a sourcing question for the row, not two rows. The register tracks uses; the tools are an attribute of each use.
Why the Use Case Register Is Step One of EU AI Act Compliance
You cannot classify what you have not catalogued
Every downstream obligation presupposes that you have already enumerated your use cases. High-risk classification under Article 6, the risk-management system under Article 9, technical documentation under Article 11, and EU-database registration under Article 49 all assume a known set of uses to act on. You cannot classify, risk-assess, or register a use case you have never written down. The register is how the set becomes known.
It scopes the entire compliance programme
The register sizes the problem before you spend a euro solving it. It tells you how many of your use cases touch an Annex III area — and therefore how large your high-risk obligations actually are. Without that count, organisations default to one of two errors: over-scoping, treating everything as high-risk and burning effort on minimal-risk uses; or under-scoping, missing an Annex III use case entirely and walking into a real breach. A populated register replaces guesswork with a prioritised workload.
It is also the evidence you were diligent
Article 4 AI literacy duties have applied since 2 February 2025, and a use case register is precisely how an organisation demonstrates it knows what AI it is responsible for and has equipped its people accordingly. Beyond literacy, a maintained register is itself evidence of good-faith diligence when a market surveillance authority asks. The absence of one signals the opposite: that you did not know your own estate. The register is both the planning tool and the proof you used it.
The Fields a Use Case Register Must Hold
Each field carries an Article reference because each field does regulatory work. Here is the field-by-field specification — column, what it captures, and why the EU AI Act needs it.
| Field | What it captures | Why the Act needs it |
|---|---|---|
| Use case ID | A stable identifier for the use | Lets every downstream artefact (risk register, documentation) reference one canonical row |
| Use case name / description | Plain-language statement of the use | The thing being classified; an auditor reads this first |
| Delivering system / tool | The AI system or product behind the use | Links the use to the technology and to its provider |
| Vendor / provider name | Who supplies the underlying system | Determines whether GPAI / upstream provider duties apply |
| Business function | Department or process owning the use | Routes the use to the right accountable area |
| Role: provider or deployer | Whether you act as provider or deployer for this use (Article 25 / Article 26) | The single most consequential field — it decides which obligations apply |
| Intended purpose | The Article 3(12) purpose, in operational language | Classification is performed against this exact wording |
| Annex III mapping | Which Annex III heading applies, or "none" with reason | Decides whether the high-risk path is even open |
| Risk tier | Prohibited / high-risk / limited / minimal, plus rationale | The classification conclusion and the basis for it |
| Accountable owner | A named human responsible for the use | Someone an authority can escalate to; not a team |
| Review date and status | Live / piloted / retired, plus last-reviewed date | Keeps the register a living document, not a snapshot |
| Pointer to deeper artefacts | One line linking to the risk register / documentation | Keeps the register lean instead of duplicating evidence |
Core identification and ownership fields
The identification block is the spine: use case ID, name and description, the system or tool delivering it, the vendor or provider, and the business function. The accountable owner must be a named individual — "the data team" is not an owner; "Head of People Ops" is. That person certifies the row's accuracy and triggers its reviews.
The classification fields that drive everything downstream
Three fields do the heavy lifting. The role field — provider or deployer — is the most consequential single column on the register. Most companies using third-party tools are deployers, whose duties sit in Article 26; but under Article 25, substantially modifying a system, rebranding it as your own, or changing its intended purpose makes you the provider. The same tool can make you a deployer for one use case and a provider for another. The intended purpose field, stated in plain operational language, is what classification runs against. And the Annex III mapping field records which heading applies — for example employment under Annex III point 4 or education under Annex III point 3 — or "none", with the reason recorded so the conclusion is defensible.
Status, review, and audit-trail fields
The risk tier field records the resulting classification — prohibited under Article 5, high-risk under Article 6, limited/transparency under Article 50, or minimal — plus a short rationale and any Article 6(3) derogation claim. The review date and status fields (live, piloted, retired) keep the register current. And a single-line pointer to deeper artefacts — the risk register, the technical-documentation file — keeps the register lean rather than turning it into a duplicate of everything downstream.
How the Register Feeds the Classification Chain
Each row is not an end point; it is a feeder. Once captured, every use case is run through the same classification logic in a fixed order.
From use case to Article 6 high-risk decision
Screen each row in sequence. First, against the Article 5 prohibitions — is this use one of the banned practices? Then against Annex III plus the Article 6 significance filter — does it fall under a high-risk heading? Then against Article 50 transparency triggers. The Annex III mapping field decides which Article 6 path applies: Article 6(1) covers AI that is, or is a safety component of, a product covered by Annex I harmonisation legislation; Article 6(2) covers stand-alone use cases that fall under an Annex III heading. The register's Annex III field is what routes a row down one path or the other.
The Article 6(3) carve-out lets certain Annex III use cases escape high-risk status where they do not pose a significant risk — narrow procedural tasks, for instance. But profiling of natural persons always stays high-risk, with no exemption available. Record the rationale for any Article 6(3) claim in the register row, because that rationale is the artefact you hand an authority if the tier is challenged.
The transparency cases you must not forget
Limited-risk use cases are the ones organisations wrongly file under "nothing to do". A chatbot, or a feature that generates synthetic content, still carries Article 50 transparency duties — disclosing that a person is interacting with AI, or marking AI-generated content. The register flags these explicitly so a "not high-risk" verdict is not mistaken for "no obligation". Note that the Article 50 content-marking and watermarking duties carry their own deadline of 2 December 2026.
Handing off to the risk register and registration
High-risk rows graduate. They flow into the Article 9 AI risk register — the risk-management system that runs across the system's lifecycle — and ultimately into the Article 49 EU-database registration that providers must complete before placing a high-risk system on the market. The use case register is the feeder for both. Get the use case fields clean and the downstream artefacts cost far less rework.
Worked Example: Meridian Logistics, a 120-Person Freight Forwarder
A register is abstract until it is populated. Take Meridian Logistics, a 120-person freight-forwarding company in Rotterdam. Its leadership says "we use AI" — an undifferentiated claim that tells a regulator nothing. Building the register turns four words into four rows.
| Use case | Delivering system | Role | Annex III mapping | Risk tier |
|---|---|---|---|---|
| Route-optimisation engine (internal logistics) | SaaS planning tool | Deployer | None — no effect on persons | Minimal |
| CV-screening assistant (6-person HR team) | Third-party SaaS | Deployer (Art 26) | Point 4 (employment) | High-risk |
| Customer tracking chatbot | Vendor chatbot | Deployer | None | Limited (Art 50) |
| Demand-forecasting model (fine-tuned in-house) | Internally modified model | Provider (Art 25) | None | Minimal, but provider duties |
Classifying each row
Use case 1 — route optimisation. It schedules trucks; it does not affect natural persons. Screened against Article 5 (clear), Annex III (no heading applies), Article 50 (no transparency trigger). Tier: minimal. Meridian is the deployer. The register notes "no Annex III heading" with the reason, so the minimal verdict is documented rather than assumed.
Use case 2 — CV-screening assistant, used by the six-person HR team. This falls squarely under Annex III point 4 (employment, recruitment, selection). Tier: high-risk. Meridian is the deployer; the SaaS vendor is the provider. This single row triggers the Article 26 deployer obligations and is the one use case that graduates into the Article 9 risk register.
Use case 3 — customer-facing tracking chatbot. Limited risk, but not nothing: Article 50 requires Meridian to disclose that customers are interacting with AI. The register flags the transparency duty so it is not lost.
Use case 4 — demand-forecasting model, which Meridian fine-tuned in-house and now badges as its own internal product. This is the Article 25 trap: by substantially modifying the model and presenting it under its own name, Meridian's role flips from deployer to provider, pulling in far heavier obligations than it expected from an internal forecasting tool. The register is exactly the artefact that surfaces this flip before an auditor does.
What the populated register reveals
Of four AI use cases, only one is high-risk — and a different one quietly turns Meridian into a provider. Without the register, Meridian would either have treated all four as high-risk (wasting effort) or, worse, missed the recruitment use case and the role flip entirely. The register converted "we use AI" into a precise, prioritised, defensible workload. Full stop.
Keeping the Register Live and What Non-Compliance Costs
Change triggers and review cadence
The register is a living document, not a one-time exercise. Each of these triggers a fresh classification of the affected row: a new use case appearing; a vendor or tool change; a substantial modification that flips a role under Article 25; and any change to the intended purpose. On top of event triggers, set a fixed periodic review — quarterly is the practical minimum — and stamp each row with a last-reviewed date. A passed review date with no update is a documented gap, worse than no date, because it proves you knew.
The penalty tiers behind getting it wrong
| Tier | Maximum fine | What it covers |
|---|---|---|
| Article 99(3) | €35 million or 7% of total worldwide annual turnover, whichever is higher | Article 5 prohibited-practice breaches |
| Article 99(4) | €15 million or 3% of total worldwide annual turnover, whichever is higher | Non-compliance with most high-risk and other obligations |
| Article 99(5) | €7.5 million or 1% of total worldwide annual turnover, whichever is higher | Supplying incorrect or misleading information to authorities |
The lowest tier is 1%, never 1.5%. And under Article 99(6), fines for SMEs and start-ups are capped at the lower of the percentage or the fixed amount — not the higher — so smaller companies should not read the headline figures unchanged. Where the register bites: an inaccurate or absent register is precisely the kind of incorrect information that engages the Article 99(5) tier when shared with an authority, while undermining the evidence base behind the larger Article 99(4) exposure.
The high-risk timeline as of June 2026
Not everything is on the same clock, and not everything is delayed. Article 5 prohibitions and Article 4 AI literacy have applied since 2 February 2025. GPAI obligations under Articles 51–55 have applied since 2 August 2025. A new fixed deadline of 2 December 2026 adds the CSAM / 'nudifier' prohibition and the Article 50 content-marking duties.
For stand-alone high-risk Annex III use cases (Article 6(2)), the statute legally still reads 2 August 2026. The Digital Omnibus reached provisional political agreement on 6–7 May 2026 (COREPER confirmed the text around 13 May 2026) to defer that date to 2 December 2027, and to defer the product-embedded Annex I track (Article 6(1)) from 2 August 2027 to 2 August 2028. But as of June 2026 this is not yet law — it still needs a European Parliament plenary vote, formal Council adoption, and publication in the Official Journal. Until then the statute still reads 2 August 2026 for stand-alone high-risk Annex III. Plan against 2 August 2026 until the deferral is enacted. These are fixed calendar dates; the standards-contingent 'stop the clock' variant was rejected.
How Confir Helps
Confir builds and maintains your AI use case register as you describe what your organisation does with AI. You answer plain-English scenarios about each use — what it does, to whom, on whose behalf — and Confir's deterministic, rule-based engine derives the role (provider under Article 25 / deployer under Article 26) and the risk tier (prohibited / high / limited / minimal), with the Annex III mapping and a cited rationale recorded against each row.
The logic is reproducible: the same inputs always produce the same tier and the same cited reasoning — no model inference, no hallucination. That reproducibility is what makes a register defensible when a competent authority asks how a use was classified. High-risk rows then feed straight into the Article 9 AI risk register and the Article 49 registration data, kept in one source so they cannot drift, with every field change written to a timestamped audit log.
Frequently Asked Questions
What is an AI use case register?
An AI use case register is a governance ledger that lists every distinct business use of AI in an organisation, one row per intended purpose rather than one row per tool. Each entry records the use case, the system delivering it, whether you act as provider or deployer, its Annex III mapping, and its resulting risk tier under the EU AI Act. It exists to drive classification and is deliberately lighter than a full technical-documentation file.
How is a use case register different from an AI inventory?
An AI inventory in the warehouse-stock sense counts what you have deployed: models, SaaS seats, and API keys. A use case register asks what you are using AI to do and to whom it applies. The distinction matters because EU AI Act classification attaches to the intended purpose under Article 3(12), not the underlying model. One foundation model can support several use cases that classify differently, so the use case, not the tool, is the unit of analysis.
Why is the use case register step one of EU AI Act compliance?
Because every downstream obligation presupposes it. You cannot classify under Article 6, build the Article 9 risk-management system, draft Article 11 documentation, or register under Article 49 until you have enumerated your use cases. The register also sizes the problem, telling you how many use cases touch Annex III before you invest in controls. A maintained register is itself evidence of diligence if a market surveillance authority asks what AI you are responsible for.
What fields should an AI use case register contain?
At minimum: a use case ID and description, the delivering system and vendor, the business function, and an accountable named owner. The classification fields are the ones that drive everything else: your role (provider or deployer), the intended purpose, the Annex III mapping, the resulting risk tier, and a short classification rationale. Add status and review-date fields so the register stays a living document, plus a pointer to deeper artefacts rather than duplicating them.
Does a use case register only cover high-risk AI?
No. It should cover every use case, because you cannot know which are high-risk until you have classified them all. Minimal-risk uses still belong on the register so their classification is documented and revisited if the purpose changes. Limited-risk uses such as chatbots carry Article 50 transparency duties and must be flagged, not ignored. The register is the place where each use case is screened against Article 5, Article 6, and Article 50 in turn.
When do the EU AI Act high-risk obligations apply?
Article 5 prohibitions and Article 4 AI literacy have applied since 2 February 2025, and GPAI obligations under Articles 51-55 since 2 August 2025. For stand-alone high-risk Annex III systems, the statute legally still reads 2 August 2026. A deferral to 2 December 2027 reached provisional political agreement via the Digital Omnibus in May 2026, but as of June 2026 it is not yet law and still needs a Parliament vote, Council adoption, and publication. Plan against 2 August 2026 until enacted.
What are the penalties for failing to manage AI use cases under the EU AI Act?
Fines scale with the breach. Prohibited practices under Article 5 can reach EUR 35M or 7% of worldwide annual turnover (Article 99(3)). Most high-risk and obligation breaches reach EUR 15M or 3% (Article 99(4)). Supplying incorrect or misleading information to authorities reaches EUR 7.5M or 1% (Article 99(5)). For SMEs and start-ups, Article 99(6) sets each cap at the lower of the fixed amount or the percentage, not the higher.
Related guides
- the AI inventory that counts your deployed systems
- a copy-paste AI system register template
- how Article 6 classifies high-risk AI systems
- build an Article 9 AI risk register
- the wider EU AI Act governance operating model
Last reviewed June 2026. Cites Regulation (EU) 2024/1689 (EU AI Act).
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →