Imagine a member of the executive board asking a seemingly straightforward question:
“How many AI systems are currently influencing our customers, employees or business decisions?”
In a large organisation, the answer may depend entirely on whom you ask.
IT may point to centrally developed models and approved applications. Procurement may produce a list of third-party platforms that include AI capabilities. Data science teams may have additional models running in experimental environments. Meanwhile, business units may already be using AI to classify customer messages, summarise conversations, generate content or support operational decisions.
Information security, Legal, Compliance, Model Risk and Internal Audit may each see a different part of the picture.
The result is not necessarily the absence of an AI inventory. It is often the presence of several partial versions of reality.
And that is where a fundamental AI governance problem begins.
One system in the register may represent many different uses
Corporate AI inventories are often built around technical assets:
- Model or application name
- Provider
- System owner
- Deployment environment
- General risk classification
These are necessary data points. But the source of AI risk is not merely the model being used.
The same underlying model might help employees improve internal emails in one use case, classify customer complaints in another, summarise information for a credit process in a third, and communicate directly with customers in a fourth.
The technical component may be the same. The purpose, affected individuals, data, degree of human oversight and consequences of an incorrect output are not.
An inventory that answers only “Which models do we have?” may therefore create a false sense of control.
A more meaningful question is:
Which AI-enabled use cases are operating in which processes, and what outcomes can they influence?
The distinction matters. Recording a SaaS platform as one inventory item does not mean the organisation understands the many AI-enabled use cases taking place within it. Conversely, using the same foundation model across several applications does not make those applications a single risk object.
An inventory of technologies is not automatically an inventory of organisational AI use.
Knowing the system does not mean knowing the version
Traditional asset management tends to treat systems as relatively stable objects. AI systems can change without appearing to become different systems.
A provider may update the underlying model. System instructions may be revised. New documents may be added to a retrieval knowledge base. A decision threshold may be adjusted. The system may gain access to a new tool or data source. An output that previously served as a recommendation may begin flowing automatically into an operational process.
The application name remains unchanged, so the inventory record may remain unchanged as well.
But the organisation may no longer be using the same system in any meaningful governance sense.
Versioning an AI system is therefore not limited to recording a model number. The real challenge is identifying changes that can alter the system’s behaviour, exposure or risk profile.
This leads to a deceptively difficult question:
Is the system running in production today still the system that was evaluated and approved?
If the organisation cannot answer this, an earlier risk assessment, performance test or approval decision may say far less about the current system than governance stakeholders assume.
An incomplete inventory is not merely a documentation issue
At first sight, gaps in an AI inventory may look like an administrative weakness. Their implications are much broader.
An organisation cannot classify a system it does not know exists. It cannot assign accountable ownership, assess the suitability of its data, monitor deterioration in performance or determine whether appropriate human oversight is in place.
When an incident or complaint occurs, it may be unable to reconstruct which configuration contributed to the outcome.
The AI inventory is therefore not simply one document among many in an AI governance framework. It is the foundation on which the other controls depend.
Risk assessment, data governance, performance monitoring, human oversight, third-party management, incident response and regulatory classification only become meaningful when the population of relevant systems is known.
The most serious consequence of an incomplete inventory is not that several rows are missing. It is that the organisation may believe it is governing AI while governing only the portion it can currently see.
Regulation will not discover an organisation’s AI estate for it
The EU AI Act introduces requirements relating to areas such as risk management, technical documentation, record-keeping and oversight, particularly for high-risk AI systems. The NIST AI Risk Management Framework similarly emphasises the need to understand AI systems as their context, capabilities, impacts and risks evolve.
These frameworks provide direction. They do not automatically discover fragmented AI use across an organisation.
Before determining which regulatory category applies to a system, the organisation must know that the system exists. Before requesting documentation from a provider, it must understand where the provider’s AI functionality is being used. Before deciding whether a change is significant, it must have a reliable record of the previous state.
An AI inventory is therefore not simply an output of compliance work. It is a prerequisite for meaningful compliance analysis.
This is not a theoretical concern in the Netherlands. DNB and AFM have observed that Dutch financial institutions already use AI across areas including fraud prevention, financial-crime controls, creditworthiness assessments, identity verification and employee productivity—and expect its use to grow further. As adoption expands, creating a single and reliable view of organisational AI activity becomes progressively more difficult. (DNB and AFM, EU AI Act, NIST AI RMF)
Is the inventory a living governance capability?
The maturity of an AI inventory cannot be assessed simply by counting its fields. More revealing questions include:
How does the central inventory become aware when a business unit activates a new AI capability?
What happens when a provider changes the underlying model or materially alters system behaviour?
Are different uses of the same AI component recognised as distinct risk contexts?
Can the organisation demonstrate the relationship between the approved version and the version currently operating in production?
When a system is retired, is it merely removed from the active inventory, or are its decision history, data dependencies and record-retention requirements also managed?
If answering these questions requires several meetings, manually reconciling multiple spreadsheets or locating the few individuals who hold the relevant knowledge, the organisation may have an AI inventory.
It may not yet have an AI inventory management capability.
The first governance question
Discussions about AI governance quickly move towards ethical principles, explainability, model performance, human oversight and regulatory classification. All of these matter.
But they depend on a more basic question:
Does the organisation actually know the AI systems it claims to govern?
A credible answer cannot be derived from the existence of a spreadsheet alone. It requires shared definitions, clear ownership, reliable change signals, version history and a working flow of information between business units, technology teams and control functions.
The AI inventory may not be the most visible or sophisticated component of AI governance.
But when it is incomplete, the scope of almost every control built on top of it becomes uncertain.
The next step is not simply to add more rows.
It is to design a way for the inventory to remain complete, current and governable as the organisation—and its AI—continues to change.
Leave a Reply