The register is finished.
Three weeks after the workshop with the blocked calendars and the mandatory attendance, the spreadsheet is complete. Fourteen AI systems, each with a role in column D, each with documented reasoning, each with a reassessment trigger. You presented it to the general counsel. She nodded. In your world, that’s a standing ovation.
Then comes the quarterly all-hands. The product team is doing a demo. They’ve built something called Atlas: an internal assistant that answers customer-history questions for the support staff. It runs on a vendor’s model, fine-tuned on two years of support tickets. It has an internal brand name. It has a logo. Someone made a logo.
Atlas is not in the register.
That afternoon, you do something you should have done earlier. You search the expense system for AI subscriptions. Seventeen results. Team cards, individual expense claims, one recurring charge labeled only “productivity tool”. Four of them match the register. The other thirteen are new to you.
The register isn’t wrong. Everything on it is classified correctly. The problem is what’s missing from it. And what’s missing from it follows a pattern.
The Assumption Underneath the Decision Tree
The EU AI Act never tells you to build an AI inventory. No article requires one. What the AI Act does instead is attach every obligation to a specific system and to your role with respect to it.
Provider and deployer are defined system by system in Article 3. The role-transformation triggers in Article 25 fire per system. Deployer obligations under Article 26 attach to each high-risk system you operate. The fundamental rights impact assessment in Article 27 is per system. Even the AI literacy obligation in Article 4 assumes you know which systems your staff are operating.
The regulation assumes enumeration without ever mandating it. Every obligation is conditional on knowing a system exists and knowing what you are in relation to it. The inventory is the unstated premise of the whole compliance architecture, which is why build the inventory is step one of the practical process of role assignment.
Step one is also the step that so often fails.
Some Systems Get In, and Some Don’t
A register is built from what can be seen. What can be seen is what passed through procurement: a contract exists, legal reviewed it, the vendor wrote an intended purpose into the documentation. These are also the systems most likely to sit in a clean deployer posture, because a contract and a documented intended purpose are what keep you a deployer. The vendor assessed the use case. You operate inside the lines the vendor drew. Column D says deployer, and column D is right.
The systems that escape are a different population. The subscription on a team card. The API key a developer set up in an afternoon. The tool a business unit reconfigured after go-live, without anyone from legal knowing. These systems have no documented intended purpose, no contractual guardrails, and no review scheduled for later. Which is the exact environment where the Article 25 triggers live:
repurposing a system beyond what the vendor assessed (25(1)(c)),
modifying it in ways no conformity assessment foresaw (25(1)(b)),
putting your own name on it because it looked better that way (25(1)(a)).
The properties that keep a system out of your register are the properties that push it toward provider territory.
So the undercount isn’t even. The register misses the expensive category first. A procured chatbot used exactly as licensed can go missing too, but the tool that was fine-tuned on proprietary data, branded internally, and pointed at a use case its vendor never heard of? That one skipped procurement almost by definition.
Atlas was never getting into column D. Systems like Atlas never are.
Two Ways a Register Fails
The invisible system is the first failure mode. Shadow AI: the system isn’t in the register, you don’t know it exists, so you never classify it. A gap, at least, is honest about itself.
The second failure mode sits inside the register. The tool was procured properly. Legal reviewed the contract. The entry says deployed SaaS, vendor X, deployer. Then a business unit fine-tuned it on internal data, or pointed it at a use case the vendor never assessed, or put an internal brand on the interface. The entry was correct on the day it was written. It isn’t anymore.
A missing entry is a gap. A stale entry is false confidence, and false confidence costs more, because a signed-off register is the last place anyone looks for a problem. The classification happened. The box is ticked. The general counsel nodded.
Both modes map onto the decision tree on role-assignment. The first breaks step one: the classification never runs. The second breaks the “document and revisit” step: the classification ran once, and the system kept moving.
The regulation doesn’t distinguish between the two. Article 25 fires at the moment of the act. Rebranding is a marketing decision. Substantial modification can be a configuration choice. Repurposing is often plain usage drift. None of it requires a contract, a procurement event, or an approval. The legal event happens when the team does the thing, not when legal finds out.
Shadow AI Data Breach
Shadow AI became a security story before it became a compliance story, so the numbers come from the security world.
IBM’s 2025 Cost of a Data Breach report found that 20% of studied organizations experienced a breach linked to shadow AI: unsanctioned tools operating outside IT oversight. Those breaches cost an average of $670,000 more than the baseline. And 63% of the breached organizations had no governance policy for managing AI or detecting unauthorized use.
Reading it as a lawyer, the same numbers say something else. One in five organizations has already had unsanctioned AI surface in the most expensive way possible. The population of unregistered systems is large enough to show up in breach statistics. Every system in it has an AI Act role that has never been assigned.
The security industry measures shadow AI in exposed records and incident costs. The measurement still missing: how many of those invisible systems have crossed an Article 25 threshold. I haven’t found a published figure, and I doubt one exists yet.
I guess that the share is disproportionate.
The Questionnaire Coming Back Clean
My next question is how can an organization solve such situation. The instinctive fix is a survey. Email the business units, ask them to list their AI tools, compile the answers.
But what if the survey comes back clean, and it’s wrong anyway?
Self-reporting requires the respondent to know that what they did was legally significant. The team that fine-tuned a vendor model on support tickets did not experience that as a substantial modification within the meaning of Article 25(1)(b). They experienced it as making the tool better. The marketing team that put the company’s name on the interface wasn’t rebranding an AI system. They were fixing an ugly login page.
Article 25 triggers don’t feel like legal events to the people performing them. Ask people to self-report legal events, and you get a list of everything except the things you need.
The detection has to run on activity, not on memory:
Expense data. Recurring charges to AI vendors, individual subscription claims, the “productivity tool” line items. Finance has this already. Legal has never asked for it.
SSO and network logs. Which AI services people actually authenticate into. IT can pull the list in a day. It will be longer than your register.
API traffic. A live API key to a model provider is the tell for build activity, and build activity is where provider status gets created. If a team holds an OpenAI or Anthropic key, that team is at layer two of the GPAI stack, whether it knows it or not.
Procurement follow-up, not procurement records. The register captured what was bought. It didn’t capture what happened after. For every entry marked deployer, the question is not “did we license this” but “what has been done to it since”. Fine-tuning, configuration beyond vendor parameters, internal branding, new use cases. Each one is a potential Article 25 event that happened after the paperwork closed.
Then treat the register as a living document with named reassessment triggers: every modification, every retraining, every new use case, every contract renewal. I have already said this. What I didn’t say: the trigger list only works for systems already in the register. Everything else needs the detection layer, running continuously, because a system that skipped procurement will skip your triggers too.
One timing note. The Digital Omnibus pushed high-risk obligations for standalone Annex III systems to 2 December 2027. That reads like breathing room. For the visible register, it is. An Article 25 trigger doesn’t wait for 2027. The role shift happens when the act happens. The obligations land later.
The classification error exists now, sitting in systems you haven’t found yet.
The All-Hands Applause
The product team finishes the Atlas demo to applause. It’s a good tool. That was never the question.
You’re running the decision tree in your head. Fine-tuned on proprietary data: possible substantial modification. Internal name and logo: possible 25(1)(a). A purpose the vendor never assessed: possible 25(1)(c). Three potential triggers, one system, zero entries in the register. And thirteen subscriptions in the expense report you haven’t looked at yet.
The register you presented was accurate. Every system on it, correctly classified. It just wasn’t an inventory of your company’s AI. It was an inventory of your company’s procured AI. Those are different documents, and what separates them is not a random slice of what’s out there.
It’s the systems that never crossed legal’s desk, put to uses their vendors never assessed, carrying obligations that have never been assigned.
The decision tree still works. It will classify anything you feed it.
Feeding it is the part that has to be solved.
Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.
Thanks for this. The enumeration-without-mandate framing is exactly right, and there’s a number behind it: the cross-org data I track puts the share of companies that can’t produce a full list of the AI systems they run at 83%. Atlas is the median case.
Your two failure modes may share one cause. The same edge configuration — system prompts, RAG, a repurposed use case — that trips your Article 25(1)(b) and (c) triggers is also structurally what happens outside procurement’s line of sight, so the systems most likely to have silently changed role are disproportionately the ones that never made it onto the register in the first place.
Thank you for making the detection layer concrete. Self-reporting fails here for the same reason vendor security questionnaires fail: you are asking people to report legal events they never experienced as legal events. In third-party risk work, the honest witnesses were never the survey responses; they were the expense reports, the SSO logs, and the API keys, exactly as you lay out. My prediction is that the AI register converges with IT asset management within a few years, because the only inventories that stay true are the ones fed by systems that do not care how the answer looks.