I already know the objection, because I raise it myself every time I hear the word inventory. Another register. Another document someone fills in diligently in January and that by March is already archaeology, because in the meantime the team has swapped two dependencies, a supplier has updated its contract terms, and somebody has shipped to production a model that doesn’t exist in the register. If that’s the promise, the inventory is just the same old bureaucracy with a more technical name, and whoever proposes it is selling the problem dressed up as the solution.
The objection is right. And it’s exactly why this piece is worth writing, because it describes perfectly one particular way of doing inventory, the hand-compiled one, which is dead on arrival. But mistaking that way for the idea of inventory itself means missing what’s happening in European regulation, where five different legal texts, written by different directorates-general, for different sectors, are converging on the same demand without ever having agreed on it.
Five Laws, One Sentence
The AI Act asks for a register of systems, a risk classification, traceability of training data and decisions. The Cyber Resilience Act asks for a bill of materials for software, the famous SBOM, and the ability to say quickly which products contain a vulnerable component. NIS2 asks you to know your supply chain and to govern incidents with notification windows that assume you already know where to look. DORA, which speaks to the financial world but confirms the pattern, asks for a register of dependencies on critical ICT providers. The Product Liability Directive, in its revised version, shifts the burden of proof in such a way that a producer who cannot reconstruct what was inside its software on a given date starts out losing. I told the story of how we got here, starting from a 1932 bottle of ginger beer, in Mrs Donoghue’s Last Bottle.
They are different languages. Register, SBOM, mapping, technical file. But the underlying sentence is one and the same: prove you know what you have in the house. Which models, which components, which suppliers, which data, which responsibilities, which changes.
Non-Compliant or Ungovernable
And here comes the point that I think gets systematically misunderstood. An organization that can’t answer these questions is not a non-compliant organization. Non-compliant is the one that knows its own system and has chosen not to bring it into line, a position you can defend, negotiate, remedy. The one that doesn’t know its own system is in a different and worse condition: it is ungovernable. It can’t decide to comply even if it wants to, because it doesn’t know what to apply the decision to.
The Waiting Strategy
Meanwhile, the most common strategy I run into is waiting. We’ll comply when the final guidance comes out, when the national authority clarifies, when the harmonised standard arrives, when the Digital Omnibus stabilises the calendar. I wrote about it a few weeks ago: postponed deadlines are not an amnesty, and whoever reads them that way is mistaking an extension for an absolution. But there’s a deeper error in waiting, and it’s the idea that compliance is content someone will sooner or later dictate to us, and that our job is merely to transcribe it. Guidance will say how to describe the system. It will never be able to describe it in our place. And the hard part, the one that takes months and cuts across team boundaries, is not the transcription. It’s knowing what to write.
The Map That Doesn’t Exist
I see it in everyday work. When we enter a project in healthcare or public administration, the first question we ask is never about the rule. It’s about the map. Which applications are in production, who owns them, which libraries they depend on, where the data lives, which processing operations have been assessed, which contracts cover which suppliers, what has changed in the last six months. The honest answer, almost everywhere, is that the map doesn’t exist. Fragments exist: an IT spreadsheet last updated a year ago, a record of processing activities frozen at the version handed to the consultant, the memory of two people who, if they change jobs tomorrow, take half the architecture with them. None of these fragments talks to the others, and none is updated by the events that should feed it.
The Dead Register and the Living Inventory
Here the initial objection returns, and here it dissolves. The register that ages in a drawer and the map European compliance requires are not the same thing done with more or less diligence. They are two objects of a different nature. The first is a document, the second is a by-product of processes. An SBOM is not compiled: it is generated by the build pipeline, at every build, and if the pipeline doesn’t generate it the problem is the pipeline, not people’s willpower. A register of AI systems is not updated from memory: it gets updated because the process for putting a model into production runs through it, and a model that isn’t in the register simply doesn’t reach production. A change log is not a ritual: it’s the trace that allows you, when a vulnerability report or an authority’s request arrives, to reconstruct what was there and when. The living inventory doesn’t ask people to remember to document. It asks the architecture of your processes to produce documentation as a side effect of normal work. It’s a difference of engineering, not of discipline, and it’s the same idea I once called compliance as architecture.
The Function With No Name
There is, though, a problem engineering alone doesn’t solve, and it’s that this map crosses territories that inside organizations have different owners. The SBOM lives with whoever does DevOps. The record of processing activities lives with the DPO. Supplier contracts live with procurement or with management. Incidents live with whoever does security, when someone does security. The AI register, where it exists, lives with whoever had the misfortune of raising a hand in the wrong meeting. Each of these pieces has an owner, but the coherence between the pieces has none. It’s not a role to hire for, and I distrust anyone who presents it as yet another acronym to add to the org chart. It’s a function that today has no name and that falls into the gaps between the DPO, who looks at personal data, the CISO, who looks at threats, and the CTO, who looks at the product. Someone has to hold together the software bill of materials, the register of AI systems, the impact assessments, the contracts, the change log and the incident history, not to fill them in but to guarantee they tell the story of the same system. In small organizations it will be one more hat on a head already wearing several. In large ones it will become a trade, and I’ve already described its rise. In both cases, whoever does it well will hold something worth more than compliance: the operational description of the company.
The Specification of the Organization
And here I close the circle with something I wrote about software development. In specification-driven development, the code becomes a derivative and the specification becomes the asset: it’s the spec that gets maintained, versioned, debated, while the code gets regenerated. European regulation, without knowing it, is saying the same thing one level up. The binder is the derivative. The living inventory is the specification of the organization, the maintained, versioned description from which compliance documents can be regenerated every time a rule, an authority or a customer asks for them in a new format. Whoever has the specification produces the binder in days. Whoever has only binders can’t even produce the specification, and accumulates, without seeing it, specification debt at company scale.
What 2026 Will Reward
That’s why I believe 2026 won’t reward whoever fills in forms best. Deadlines slip, guidance arrives late, harmonised standards are still largely on paper, and all this calendar noise hides the real selection under way. 2026 will reward whoever can describe their own system better than others describe theirs, to the customers who ask for it in tender documents, to the authorities who will ask for it in inspections, and before that to themselves, when they have to decide quickly what to change. Compliance is just the bureaucratic name for this capability. The inventory is its instrument. And no extension has ever made governable a system its owner cannot narrate.
Key takeaways
Five European regulations, written by different directorates-general for different sectors, are converging on the same demand without ever having agreed on it: the AI Act, the CRA, NIS2, DORA and the PLD all ask, in different words, that you prove you know what you have in the house.
Non-compliant is the organization that knows its own system and has chosen not to bring it into line: a position you can defend, negotiate, remedy. The organization that doesn’t know its own system is ungovernable, which is worse: it can’t decide to comply even if it wants to.
Waiting for guidance and harmonised standards mistakes compliance for content to transcribe. Guidance will say how to describe the system, it will never describe it in our place. The hard part isn’t the transcription, it’s knowing what to write.
The register that ages in a drawer and the living inventory are objects of a different nature: the first is a document, the second a by-product of processes. An SBOM isn’t compiled, it’s generated by the pipeline at every build. That’s a difference of engineering, not of discipline.
The coherence between the SBOM, the AI register, the impact assessments, the contracts and the change log has no owner: it falls into the gaps between the DPO, the CISO and the CTO. Whoever takes charge of that function will hold something worth more than compliance: the operational description of the company.
Questions & answers
Why does European compliance require an inventory?
Because five different legal texts converge on the same demand. The AI Act asks for a register of systems, a risk classification and traceability of training data. The Cyber Resilience Act asks for the SBOM and the ability to say quickly which products contain a vulnerable component. NIS2 asks you to know your supply chain and to notify incidents within windows that assume you already know where to look. DORA asks for a register of dependencies on critical ICT providers. The revised PLD shifts the burden of proof so that a producer who can’t reconstruct what was inside its software on a given date starts out losing. They are different languages, but the underlying sentence is one and the same: prove you know what you have in the house.
What's the difference between being non-compliant and being ungovernable?
Non-compliant is the organization that knows its own system and has chosen not to bring it into line: a position you can defend, negotiate, remedy. The organization that doesn’t know its own system is in a different and worse condition: it is ungovernable. It can’t decide to comply even if it wants to, because it doesn’t know what to apply the decision to. The distinction matters because most organizations that believe they are behind on compliance aren’t actually behind on an obligation: they lack the map any obligation would have to be applied to.
What is a living inventory and how does it differ from a traditional register?
They are objects of a different nature, not the same object done with more or less diligence. The traditional register is a document: someone fills it in, then the system changes and the document ages. The living inventory is a by-product of processes: the SBOM is generated by the build pipeline at every build, the register of AI systems gets updated because putting a model into production runs through it, the change log is the trace that lets you reconstruct what was there and when. It doesn’t ask people to remember to document: it asks the architecture of your processes to produce documentation as a side effect of normal work.
Who should own the inventory inside a company?
Every piece already has an owner: the SBOM lives with whoever does DevOps, the record of processing activities with the DPO, the contracts with procurement, the incidents with whoever does security. What has no owner is the coherence between the pieces, that is, the guarantee that they all tell the story of the same system. It’s not necessarily a role to hire for: in small organizations it will be one more hat on a head already wearing several, in large ones it will become a trade. It’s a function that today falls into the gaps between the DPO, who looks at personal data, the CISO, who looks at threats, and the CTO, who looks at the product.
Is it wise to wait for the final guidance before complying?
No, for two reasons. The first is that postponed deadlines are not an amnesty: the Digital Omnibus moved a few dates and confirmed everything else. The second is deeper: waiting assumes compliance is content someone will sooner or later dictate to us, and that our job is merely to transcribe it. Guidance will say how to describe the system, it will never describe it in our place. The part that takes months and cuts across team boundaries isn’t the transcription: it’s knowing what to write. And that part has no deadline, gets no extension, and doesn’t get easier with time.
The author
