What an AI use-case register actually looks like

The EU AI Act has a way of turning into an abstraction. Risk tiers, conformity assessments, Annex III, penalties reaching into the tens of millions. All true, all important, and all completely useless to the product manager sitting in a room on a Tuesday afternoon while an engineer explains why the new feature needs to ship this sprint.

I spent a good part of last year building the AI governance register for an enterprise ITSM portfolio. Not the policy document — the working system that decides, case by case, what gets built, what gets flagged, and what quietly gets stopped. This is what I actually learned, stripped of the compliance-webinar language.

The Act came into force on 1 August 2024 and applies in phases. Prohibited practices and AI-literacy obligations have applied since 2 February 2025, and general-purpose AI model obligations since 2 August 2025. The Article 50 transparency obligations apply from 2 August 2026. Penalties for prohibited practices reach €35 million or 7% of global annual turnover, whichever is higher.

The high-risk timeline moved. The Digital Omnibus on AI — proposed in November 2025, agreed politically on 7 May 2026 and given final approval by the Council on 29 June 2026 — deferred the Annex III stand-alone high-risk obligations from 2 August 2026 to 2 December 2027, and the Annex I obligations for AI embedded in regulated products from 2 August 2027 to 2 August 2028. A further tranche lands on 2 December 2026, covering transparency for systems already on the market and a new prohibition on AI-generated non-consensual intimate imagery.

If you built your compliance calendar before May 2026, part of it is now wrong — and the relief is narrower than the headlines suggested. Transparency did not move. High-risk did. That is sixteen extra months on the hardest part of the Act, and precisely nothing on the part that arrives in a fortnight.

The register is not a list. It’s a gate.

The first mistake people make is treating an AI use-case register as an inventory — a spreadsheet you fill in after the fact so you can wave it at an auditor. That version is worse than useless, because it creates the paperwork of governance without any of the effect. By the time a use case reaches the list, it has already been built.

A register that does anything sits at intake. Before a line of code, someone proposes an AI use case, and it has to pass through the register to proceed. The register asks a small number of unglamorous questions, and the answers determine what happens next. That’s it. The value isn’t the document. It’s that nothing gets to skip the questions.

The most useful question isn’t about risk. It’s “is this even AI?”

Here is the finding that surprised me most, and the one I now lead with whenever anyone asks. A meaningful share of what gets submitted as AI isn’t. A rules engine with good marketing. A set of if-statements someone wanted to call machine learning. A report the dashboard already produced.

This matters more than it sounds. The Act’s obligations attach to AI systems. Wave everything through, and you spend your entire governance budget assessing things that were never AI to begin with. Catching the non-AI at intake — before it’s classified, assessed, documented — isn’t pedantry. It’s what stops the whole system collapsing under its own weight.

The question sounds trivial and is anything but: does this system infer, or does it just execute rules a human wrote? Most of the disagreements I mediated came down to that line, and most people had never been asked to draw it.

Risk classification is a conversation, not a lookup

The Act gives you tiers: prohibited, high-risk, limited, minimal. The temptation is to treat classification as a lookup — find your use case in Annex III, read off the tier, move on. Real cases don’t cooperate. The same underlying model does something minimal-risk in one workflow and something that brushes against high-risk in another, depending entirely on what decision it influences and who is affected by it.

So classification became a structured conversation at intake, not a checkbox. Who is affected by this system’s output? What happens when it’s wrong? Is a human making the final call, or is the system’s output the decision? Can the person affected tell that AI was involved at all? None of those have clean answers on a form. All of them have clean-enough answers in a ten-minute conversation with the person who wants to build the thing — if you know to ask before they build it.

Human oversight is a design constraint, not a disclaimer

“There’s a human in the loop” is the sentence everyone reaches for, and most of the time it’s a fig leaf. A human who rubber-stamps a hundred AI decisions an hour isn’t oversight; they’re a liability-transfer mechanism.

The requirement for meaningful human oversight forces a harder question at design time: is the human actually positioned to catch and override a wrong output, or are they there to absorb blame? That’s a product decision, and it belongs in the register because it changes what you build — the interface, the workflow, whether the human sees the reasoning or just the answer, how much time they have to act. Bolt oversight on at the end and it’s theatre. Design it in from intake and it’s a real control — I’ve written about what that actually requires separately. I wrote about what that looked like in practice in the AI change assistant case study.

What I’d tell a team starting now

With transparency obligations live from August 2026 and the high-risk provisions now landing in December 2027, a lot of teams are about to build one of these — some under time pressure, some with sixteen months they did not expect and will spend anyway. Four things I wish someone had told me:

• Put it at intake, or don’t bother. A register that documents decisions after they’re made is compliance theatre. One that gates them is governance. The entire difference is timing.
• Make “is this AI?” the first question. You’ll filter out more noise than you expect, and every non-AI case you catch early is budget you get to spend on the cases that matter.
• Keep the friction proportional. If every use case gets the full high-risk treatment, people route around you — and a register everyone avoids governs nothing. Minimal-risk cases should pass in minutes.
• Write down the rejections. The cases you stop are the register’s most valuable output and the easiest to lose. “We considered this and chose not to build it, here’s why” is the most useful artifact you can hand a regulator, a nervous executive, or the next PM who inherits the system.

None of this is the version you’ll read in the compliance briefing. That version is about tiers and penalties. This version is about the Tuesday afternoon, the intake meeting, the person who wants to ship — and the small set of questions that decide whether what they ship is something you’ll be comfortable defending later.

If you build in financial services, DORA asks a parallel set of questions that arrive earlier and have nothing to do with risk tiers. The Act is the reason the register exists. What it actually does, day to day, is simpler and more human than the legislation makes it sound. It makes people answer four or five honest questions before they build. Most of the time, that’s enough.