It's worth starting with what the law doesn't say, because this is an area where invented obligations are common.
The word "inventory" doesn't appear once in Regulation (EU) 2024/1689. There's no article that says "keep a list of your AI systems." Anyone who claims otherwise is describing good practice as if it were a legal duty — the same mistake as attributing obligations to whoever doesn't actually bear them, applied here to something that isn't even someone else's: it simply doesn't exist.
There is a registration obligation, yes, but it's narrow: Article 49(3) requires registering in the EU database before putting into service or using an Annex III system — and it reaches deployers "that are public authorities, Union institutions, bodies, offices or agencies or persons acting on their behalf". A private company isn't in that group.
That said, here comes the uncomfortable part.
How the obligations that do exist are written
Read them one after another and a pattern emerges that isn't a matter of interpretation: they're drafted per system, not per organisation.
They are those of Article 26, which reaches only deployers of high-risk systems and applies from 2 December 2027 for those of Annex III. Article 26(1) requires using "such systems in accordance with the instructions for use accompanying the systems". Article 26(2), assigning human oversight of that system to specific people. Article 26(5), to "monitor the operation" of it. Article 26(6), to keep "the logs automatically generated by that high-risk AI system".
Each one names an identified system, with its instructions, its supervisor and its logs. None of them can be applied to a fleet nobody knows about, and not because I say so: because that's how they're written.
That's the exact relationship between the inventory and the law. It isn't an obligation. It's the condition without which the obligations have no subject to attach to.
The register that actually is mandatory is a different one, and the two shouldn't be confused
There's a mix-up that happens constantly here, and it deserves precision.
The GDPR does impose a registration duty: Article 30(1) requires every controller to maintain "a record of processing activities under its responsibility", with the purposes, the categories of data subjects and of data, the recipients, the time limits and the security measures.
But its object is personal data processing activities, not AI systems. They overlap when the system processes personal data, and they don't coincide: an agent that doesn't touch personal data falls outside Article 30 and stays inside Article 26.
A nuance that's often misquoted: Article 30(5) says those obligations "shall not apply" to organisations with fewer than 250 persons — but the cut-off collapses "unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data". Processing built into day-to-day operations isn't occasional. The exemption is considerably narrower than the headline suggests.
What makes an agent worse
A system that suggests and isn't in the inventory is a risk of omission: someone is using a tool the organisation never assessed. Annoying, and generally reversible.
An agent that isn't in the inventory is another matter, and the difference is the one from the previous article in this series: it acts. A team may have deployed it without going through anyone, with whatever credentials were at hand, to solve something specific. There's no screen for anyone to open and no output for anyone to read. There's a process executing actions nobody authorised.
That shifts what "shadow AI" means. It isn't someone using a conversational assistant on their own — that happens too, and it's a different problem. It's a process running with real permissions over real systems, one the organisation doesn't even know exists, and which therefore has nobody designated who can stop it. Which is exactly what Article 26(2) requires having.
Technical controls don't apply to what isn't on the list
This is the practical consequence, and it's drier than it looks.
Article 26(1) calls for technical and organisational measures. A technical measure — restricting permissions, limiting the scope of an action, requiring confirmation for anything irreversible, being able to interrupt execution — applies to a specific system. There's no way to apply a control to something that hasn't been listed.
So the sequence is unavoidable and has no shortcut: first know what's there, then decide what each one is allowed to do. It can't be done the other way round, and an organisation that starts with the controls will find it has applied them to the part of its fleet it already knew about — which is precisely the part that had the least problem to begin with.
What a list needs to have to be worth anything
It isn't a template, and none of these fields comes from an article.
What it does, not what it's called. "Operations assistant" says nothing. "Answers customer queries and updates order status" does, because it describes actions — and actions are what gets assessed.
Whether it suggests or executes. It's the line that changes everything else, and the one almost no inventory captures.
What it has access to. An agent reaches as far as its permissions go, not as far as its description says.
Who put it there and who can stop it. Two people, who sometimes aren't the same one — and if the second doesn't exist, that's exactly what the list has to make visible.
When it was last checked. Because the list ages on its own: tools get expanded, permissions get granted, and nobody sends a notice.
None of those five fields is required by the Regulation. All five are what's needed to be able to answer when someone asks about the measures that were adopted and why those ones — and that question does have an article behind it.
Content in accordance with Articles 26 and 49 of Regulation (EU) 2024/1689 and Article 30 of Regulation (EU) 2016/679, cited from the text published in OJ L 119 of 4.5.2016 and verified against the consolidated version.
This article is for informational purposes only and does not constitute legal advice.