- A joint statement of the European Supervisory Authorities puts an inventory first, saying prevention relies on comprehensive and continuously updated inventories of all IT assets including infrastructure, applications, data repositories, APIs, and AI or machine learning components.
- An application inventory is not an AI inventory. The behaviour of an AI system is determined by the model version, the prompt and configuration set, the retrieval corpus and the tool permissions, and none of those appear in a conventional asset register.
- Scope is drawn from the inventory, so the inventory decides what a certificate means. Incomplete produces a certificate narrower than readers assume; inaccurate produces one wider than the evidence supports.
- Discovery is the hard half. Six trace-based routes find most undeclared AI: vendor spend, identity grants, network egress, code search, procurement records and browser extensions. Asking people is a good seventh step and a poor first one.
- One inventory serves the supervisory dialogue, the assessment, the underwriting submission and the incident response. Four partial lists cost more and agree with each other less.
Why this is being written now
A joint statement of the European Supervisory Authorities, published through their Joint Committee under the title Toward a consistent and risk-based approach for ICT risks from frontier AI models, sets out three mitigation strategies for financial entities. The first is prevention, and the first sentence of prevention is about an inventory. It says prevention relies on comprehensive and continuously updated inventories of all IT assets, including infrastructure, applications, data repositories, APIs, and AI or machine learning components, because that is what enables entities to classify assets based on criticality and exposure. It goes on to say that assessing the risk arising from dependencies among IT assets is essential for consistently prioritising preventive measures.
Two things are notable about that placement. It is first, ahead of architecture, monitoring and patching, which is the correct engineering order and an unusual thing for a supervisory document to get right. And it names AI and machine learning components explicitly as assets in their own right, rather than folding them into applications, which is the distinction the rest of this article is about. The full regulatory reading of the statement is at agentliability.eu, on the supervisory answer arriving through operational resilience law.
This framework reached the same conclusion from the opposite direction, by repeatedly failing to start assessments on time. The pattern is consistent enough to state as a finding: assessments do not usually stall on a control that is missing. They stall in week one, on the question of what is in scope, because there is no agreed list. What follows is a description of the artefact that removes that failure.
An application inventory is not an AI inventory
Most organisations of any size already maintain an asset register. It records systems, owners, hosting arrangements, data classifications and business criticality, and it is genuinely useful. It is also close to silent on everything that determines how an AI system behaves.
The reason is structural rather than a failure of diligence. In conventional software, behaviour is determined by the code, and the code is the thing the register points at. In an AI system, behaviour is determined by a combination of things that a conventional register has no column for: which model is being called and at what version, what instructions it is given, what material it retrieves before answering, what actions it is permitted to take on other systems, and what a human is required to do before an output has effect. Two deployments of the same application, identical in every field of an ordinary asset register, can differ in all five and behave nothing alike.
That is why the unit of inventory has to be the deployed system rather than the tool. A company using one commercial assistant across four business functions, with four different configurations and four different permission sets, has four rows and not one. The alternative, a single row naming a vendor, is the shape that produces certificates nobody should rely on and submissions that describe an organisation nobody would recognise.
What belongs in a row
Twelve fields. Fewer than twelve is a starting point rather than an inventory, and more than twelve tends to be a taxonomy project that never finishes.
1. System name and identifier. A name a person would use, plus a stable identifier that survives renaming.
2. Business owner, by name. Not a team, not a function. Ownership that dissolves under scrutiny is the single most common weakness in an otherwise good register, and it is the field an assessor tests first because it is the cheapest to test.
3. Purpose and affected population. What the system is for, and who is on the receiving end. This field determines the regulatory position and most of the risk analysis, and it should be written in language the affected population would recognise.
4. Model dependency and version. Which model, from which provider, at which version, and whether the version is pinned or floating. A floating version is not a defect, but it is a fact that changes what every test result means, and it belongs on the row rather than in somebody's head. The dependency question in full is at certifying agents built on general-purpose models.
5. Instruction set and where it is versioned. Prompts, system messages, configuration. If these are edited in a console with no history, that is the finding, and it is worth recording as one. Change control for this surface is at prompt change control as certification evidence.
6. Retrieval sources. What the system reads before it answers, who can add to it, and how removals propagate. A corpus that anybody can write to is an input control question, and it is treated at certifying retrieval and knowledge bases.
7. Tool permissions and effect. The most important field and the most often missing. What can this system do, as opposed to say? Send mail, write to a record, move money, book, cancel, escalate, call another system. The distinction between advisory and effectual is where autonomy actually lives, and we treat the scaling of it at the autonomy envelope.
8. Human oversight arrangement. Who reviews, at what point, with what authority to stop, and whether the review is a decision or a formality. An oversight arrangement that cannot in practice reject an output is not oversight, and recording it honestly is more useful than recording it favourably.
9. Data categories. What goes in, what is retained, what leaves the organisation, and where.
10. Criticality and exposure. The classification the supervisory statement asks for. Any defensible scale is acceptable; what is not acceptable is a blank, or a scale where everything is medium.
11. Dependencies. What this system needs in order to work, including the ones nobody chose: the model provider, the hosting region, the identity provider, the search or vector service, the interface a partner exposes. The supervisory statement asks specifically for dependencies to be identified, monitored, assessed for criticality and mitigated, naming software dependencies such as open-source libraries and third-party interfaces, infrastructure dependencies such as cloud and name resolution services, and operational dependencies such as outsourced monitoring.
12. Last reviewed, and last tested. Two dates, not one. Reviewed is a governance act. Tested is an evidence act. Conflating them is how a register comes to look current while every test result behind it is a year old.
Discovery is the hard half
Describing systems you know about is a week of work. Finding the ones nobody declared is the part that determines whether the inventory is worth anything, and it cannot be done by circulating a questionnaire, for a reason worth stating: people do not report what they do not classify as AI. A team that has enabled a summarisation feature inside a tool the company already licenses has not, in its own mind, deployed an AI system. It has ticked a box in software it was already using. That is the single largest source of undeclared exposure and no survey will surface it.
Traces work better than questions. Six routes, in rough order of yield.
Vendor spend. Somebody is paying. Card statements, expense claims and the accounts payable ledger will name providers that no register mentions. This route is unglamorous and it is consistently the highest yield.
Identity and authorisation grants. The list of applications granted access to corporate identity, mail, calendars, files and repositories is a precise record of what has been connected, including things connected once by somebody who has since left.
Network egress. Outbound traffic to model interfaces shows what is calling out, from where, and how often. It also surfaces systems that were built rather than bought, which the spend route misses entirely.
Code search. Provider libraries, client packages and interface key patterns across repositories. Two hours with a search across the estate typically finds more than a month of asking.
Procurement and contract records. Not only new purchases. The higher-yield search is for features added to tools already bought, which arrive with no procurement event and no review.
Managed device inventories. Browser extensions and installed applications, which is where individual experimentation lives before it becomes a business process.
Asking people is the seventh step and it works well once the first six have produced a draft, because the conversation changes from an open question to a specific one. Showing a team a list of six things and asking which of them they use produces better information than asking what they use.
The word doing the work is continuously
The supervisory phrasing is comprehensive and continuously updated, and the second half is where the cost sits.
Every other class of asset holds reasonably still between reviews. An AI system does not, and it does not for reasons outside the organisation's control. A model provider can change what is behind an interface on its own timetable. A retrieval corpus drifts as documents are added and removed by people who are not thinking about the agent that reads them. A permission granted for one workflow persists into another. Behaviour moves while the configuration file stays identical.
An annual inventory of a moving object is a photograph, and it will be out of date on the day it is signed. The practical answer is not continuous automation, which few organisations can build. It is a small set of triggers, each of which obliges somebody to update a row: a model or version change, a change to instructions or configuration, a change to tool permissions, a change to retrieval sources, a change of owner, and decommissioning. Six triggers, each attached to a process that already exists. Our treatment of the obligation between assessments is at maintaining certification after the assessment, and the end-of-life case, where a row must be closed rather than deleted, is at decommissioning and the evidence that outlives the system.
What a weak inventory does to a certificate
This is the part that matters to anybody who will hold, issue or read a certification result, and it is worth being blunt about.
A certificate is a statement about a defined scope. That scope is drawn from the inventory, because there is nowhere else to draw it from. Two failure modes follow, and they are opposites.
An incomplete inventory produces a certificate that is narrower than its reader will assume. The assessment was honest, the scope statement was accurate, and the buyer reading the badge concludes that the organisation's AI has been assessed. The gap is not created by the assessor and it is not closed by the assessor either. It is closed by a scope statement written in language a non-specialist reads correctly, which is a discipline this framework applies to itself.
An inaccurate inventory produces a certificate that is wider than the evidence supports. A row that describes an advisory system which in fact holds write permissions has been assessed against the wrong risk profile. Nothing in the assessment will catch that if the assessor was never told, which is exactly why field seven is field seven.
The practical consequence for anyone preparing for an assessment is that time spent on the inventory is not preparation for the work. It is the work, and it is the portion of it that cannot be compressed. The full sequence is at preparing for an assessment, and the mapping of the resulting evidence to the Act's obligations is at the seven dimensions against EU AI Act obligations.
One artefact, four audiences
The argument for doing this properly rather than adequately is that the same rows answer four different parties, none of whom will accept a summary produced for one of the others.
The supervisor wants criticality, exposure and dependencies, and asks about the ones you do not control. The assessor wants scope, ownership, configuration and test history. The underwriter wants to know what the system can do, who is accountable, and what happens if a dependency fails, which is the reading set out at agentinsured.eu, on the same statement read from the coverage side. The incident responder wants one thing, at speed, in the middle of the night: which systems touch the affected component.
Four partial lists, each built for one audience, will disagree with each other within a quarter, and the disagreement will be discovered at the worst possible moment by the fourth audience. The financial services version of this argument, where the perimeter is defined by regulation rather than by choice, is at DORA and AI agent certification.
Where to start on Monday
A minimum viable inventory is one sheet and eight columns: system name, business owner by name, purpose and affected population, model and version, permitted actions, who reviews and with what authority, criticality, and date last reviewed. Accept that the first version will be wrong.
Then run two of the six discovery routes, and pick the two your organisation can do this week rather than the two with the highest theoretical yield. Add what they find. Circulate the result to the teams involved and ask them to correct it, which is a far more productive conversation than asking them to build it.
Then attach the six triggers to processes that already exist, so that the sheet does not begin decaying the day it is finished. Precision in the fields can be added later without redoing anything. Completeness cannot: everything built on an incomplete list has to be built again once the list changes.
Questions
What is an AI asset inventory and how is it different from an application inventory?
An application inventory lists software. An AI asset inventory lists deployed systems together with the components that determine their behaviour, because in an AI system the behaviour is not fixed by the application. A row therefore has to carry the model and its version, the prompt or configuration set and where it is versioned, any retrieval corpus and how it is updated, the tool permissions describing what the system can actually do rather than only say, the human oversight arrangement, the data categories in play, and a criticality and exposure classification. An application inventory that records a name, an owner and a hosting location tells an assessor almost nothing about an agent.
Why is an inventory the first thing a certification assessment looks at?
Because scope is drawn from it, and scope decides what the certificate means. An assessment can only speak about systems that were identified, in the configuration they were in. If the inventory is incomplete the certificate is narrower than the reader will assume, and if it is inaccurate the certificate is wider than the evidence supports. Most assessments that stall do not stall on a control failure. They stall because nobody can produce an agreed list of what is deployed, and two weeks disappear into building one before any assessment work begins.
What does continuously updated mean in practice for an AI inventory?
It means the inventory is maintained by a process attached to change rather than by an annual exercise. This matters more for AI than for other assets because the object moves without anyone in the organisation touching it: a provider can update the underlying model on its own timetable, a retrieval corpus drifts as documents are added and removed, and a tool integration changes what a system is able to do. An inventory refreshed once a year describes a state that has already passed. The practical form is a small number of triggers, each of which requires a row to be updated: a model or version change, a change to prompts or configuration, a change to tool permissions, a change to the corpus, a change of owner, and decommissioning.
How do you find AI systems nobody told you about?
By looking at traces rather than by asking. Six routes find most of it. Vendor spend and expense claims, because somebody is paying for it. Single sign-on and authorisation grants, which show what has been connected to corporate identity. Network egress to model interfaces, which shows what is calling out. Code search for provider libraries and interface keys across repositories. Procurement and contract records, including features added to tools already bought. And browser extension inventories on managed devices. Asking teams what they use is a useful seventh step and a poor first one, because the honest answer usually omits anything the respondent does not consider to be AI.
Is one inventory enough for compliance, certification and insurance?
One inventory, held to the highest of the demands placed on it, serves all three, and this is the strongest argument for doing the work properly once. A supervisory dialogue wants criticality, exposure and dependencies. A certification assessment wants scope, ownership, configuration and test history. An underwriting submission wants what the system can do, who is accountable and what would happen if a dependency failed. An incident response wants to know, at three in the morning, which systems touch the affected component. Those are different questions about the same rows, and maintaining four partial lists is more expensive and less accurate than maintaining one good one.
What is the minimum viable AI inventory if we are starting from nothing?
Start with a single sheet and eight columns, and accept that the first version will be wrong. System name. Business owner by name, not by team. What it does and who is affected by it. The model and version it depends on. What actions it is permitted to take. Who reviews its output and with what authority. Criticality, on any scale you can defend. Date last reviewed. That is enough to begin an assessment conversation, enough to answer a supervisor's first question, and enough to reveal the systems nobody had thought about. Precision can be added afterwards. Completeness cannot be added afterwards without redoing everything built on top of it.