You cannot govern AI systems you have not inventoried

An AI policy cannot reach a system that nobody has named. A risk committee cannot challenge an agent whose owner, data and actions are unknown. An incident team cannot contain a workflow it discovers for the first time in a log search.

That is why an AI inventory is not administrative housekeeping. It is the control surface that lets an organisation decide which systems require scrutiny, which changes require approval and who must act when evidence weakens. NIST’s AI Risk Management Framework makes the point explicit in Govern 1.6: mechanisms should be in place to inventory AI systems and should be resourced according to risk priorities.

The useful unit is an AI system in a context of use, not a model name. One model can support a low-consequence drafting assistant, a customer-support agent that changes accounts and an internal investigator that handles sensitive records. Those are three governance objects because their people, data, authority and failure consequences differ.

Set an inventory boundary that follows consequence

Start with a practical inclusion rule. Register a system when machine-generated inferences, recommendations, content or actions can materially affect one or more of the following:

• a decision about a person, customer, employee or supplier;
• access to data, money, systems or physical resources;
• an external communication or commitment;
• a regulated, safety-relevant or rights-relevant workflow;
• a control, security decision or operational response;
• the evidence used by someone making such a decision.

This catches embedded AI features and agentic workflows without forcing a debate about marketing terminology. It also avoids an inventory that lists every spell-checker while missing a workflow automation hidden inside a purchased platform.

The OECD classification framework is useful because it characterises applied systems across people and planet, economic context, data and input, model, and task and output. It specifically identifies inventories as one use of a common classification. The lesson is that discovery and classification belong together: an entry must contain enough context to decide what governance it needs.

Record the system, not only the supplier

A vendor register might say “hosted language model.” A governance inventory should say what the organisation has assembled around it. Retrieval sources, prompts, memory, tool interfaces, permission scopes, approval gates and human procedures can change the resulting behaviour even when the underlying model stays the same.

A minimum entry should answer these questions:

Inventory field	Decision it enables
Name and stable internal identifier	Can changes, evidence and incidents point to the same object?
Intended workflow and prohibited uses	What is the system allowed to help accomplish?
Business and technical owners	Who accepts consequence and who can change or stop it?
Users and affected people	Who operates it, and who can experience its effects?
Inputs, outputs and actions	What information enters, what leaves and what can change?
Data sources and retention points	Where can personal, confidential or licensed data persist?
Components and suppliers	Which models, indexes, tools and services does operation depend on?
Identity and authority	On whose behalf does it act, with which permissions?
Deployment and exposure	Is it experimental, restricted, internal or externally available?
Evidence and open findings	What has been evaluated, against which criteria, with what uncertainty?
Review triggers and last decision	What change or event will reopen the decision?

Do not copy secrets, raw personal data or complete technical configurations into the register. Link to protected records. The inventory is a navigational and accountability artefact, not a new concentration of sensitive material.

Discover what the declared list will miss

An intake form captures cooperative projects. It will not reliably capture experiments opened with a corporate card, AI features enabled by default, scripts created by a local team or a product whose inference behaviour was added in an update.

Reconcile the declared inventory against several independent signals:

1. Procurement and expense records: AI subscriptions, model APIs, data services and evaluation tools.
2. Identity and secrets systems: service accounts, OAuth grants, API keys and unusual permission scopes.
3. Cloud and network telemetry: calls to model endpoints, vector databases and external AI services.
4. Product and architecture records: features that classify, recommend, generate or act.
5. Data records: new processing purposes, pipelines, stores and transfers.
6. Support and incident channels: systems first revealed through complaints, errors or security events.

Discovery must be proportionate and transparent. Network traffic alone cannot tell you the workflow purpose; a purchase record cannot show whether a tool is still active. Use signals to start a conversation and validate the entry with people accountable for the work.

Classify for action, not decoration

An inventory becomes bureaucratic when it collects dozens of attributes but changes no decision. Keep classifications only when they determine review depth, controls, evidence or escalation.

For an agent, four dimensions are particularly actionable:

• Consequence: what credible harm or loss could follow an error or misuse?
• Authority: can it only propose, or can it read protected data, transact, communicate or change state?
• Exposure: who can instruct it, and can untrusted content influence it?
• Reversibility: can an action be detected, stopped and repaired within an acceptable interval?

Combine those dimensions with the people affected and applicable obligations. A system that drafts internal text from public sources may need lightweight registration and periodic review. A system that can retrieve employee records and send external messages should require named control owners, tested authorisation, privacy review, evaluation evidence and an incident path.

Avoid compressing that assessment into one colour too early. “Amber” cannot tell an engineer whether to narrow a permission, a product owner whether to add confirmation or a reviewer whether the evidence sample is inadequate. Preserve the reasons behind the tier.

Make ownership specific enough to operate

“AI team” is not an accountable owner. Record at least three roles where consequences warrant them:

• the business owner, who decides whether the workflow and residual risk are acceptable;
• the technical owner, who controls configuration, deployment and remediation;
• the control or evidence owner, who verifies that a safeguard or evaluation remains effective.

One person may hold more than one role in a small organisation, but the responsibilities should still be distinct. Supplier responsibility should also be explicit. A provider can supply documentation or controls; the deploying organisation still has to understand its own context, users and connected systems.

ISO/IEC 42001 describes an AI management system as interrelated elements that establish policies, objectives and processes for responsible AI development or use. An inventory supports such a system, but having a spreadsheet does not establish conformity with the standard. The operational test is whether an entry reaches the right owner and process when something changes.

Treat change as an inventory event

An entry that describes last quarter’s system can create false assurance. Define events that require an update and, where material, a fresh decision:

• a model, prompt, tool, retrieval source or policy change;
• new users, data categories, jurisdictions or affected groups;
• increased action authority or reduced human review;
• a new supplier or material supplier change;
• an incident, complaint, unexpected behaviour or control failure;
• evidence that no longer represents production conditions;
• retirement, suspension or transfer to another owner.

Connect deployment pipelines and change tickets to the inventory identifier where possible. The goal is not to route every prompt edit through a committee. It is to make materiality rules explicit and ensure consequential changes cannot silently inherit an old approval.

Give leaders an honest decision view

An executive view should not be a count of “AI projects.” It should show the portfolio decisions that need attention: systems without owners, high-consequence uses without current evidence, agents with broad action authority, overdue reviews, unresolved severe findings, material changes awaiting a decision and systems pending retirement.

That view also needs denominators. “Five systems reviewed” is not meaningful if the organisation cannot say whether five systems or fifty are operating. Track discovery coverage separately from review completion. A rising inventory count can mean improved visibility rather than increasing risk.

The NIST AI RMF treats governance as a cross-cutting function and risk management as continuous across the lifecycle. A living inventory makes that continuity possible. It lets policy meet a real system, gives evaluation a defined object, gives incidents an owner and gives retirement a verifiable end state.

Build the first version quickly around consequence and ownership. Then improve discovery, evidence links and change integration. The objective is not a perfect catalogue. It is to ensure that every consequential AI system can be found, understood and brought to a decision before it surprises the organisation.