AI Inventory

The control every other control depends on

Every AI governance framework starts in the same place. ISO/IEC 42001 asks the organisation to determine which AI systems are in scope of its management system. The NIST AI RMF's Map function begins with establishing context and cataloguing systems. The PRA's SS1/23 makes model identification its first principle. The EU AI Act cannot be complied with at all until an organisation knows which of its systems fall into which risk category. All of them are saying the same thing: the inventory comes first, because appetite, assessment, oversight and monitoring all attach to a named system with a named owner, and without the list there is nothing to attach them to.

It is also the control most often found incomplete. The reason is not neglect. It is that AI arrives in three ways, and only one of them looks like a project.

What belongs in it

Three populations, and most inventories capture only the first.

Systems the organisation built or commissioned. The credit model, the chatbot, the document classifier. These have project names, budgets and owners, and they are usually already listed.

Third-party systems and models the organisation uses directly. A foundation model reached through an API, an AI vendor's product, a model downloaded from a public hub. These belong in the inventory as models in their own right, with the provider, the version the organisation depends on, and the contract terms about updates and data use; see third-party risk.

AI features inside software that was approved for something else. The summariser in the mail client, the assistant in the CRM, the transcription in the meeting tool. Nobody adopted these; a vendor switched them on. They are the largest and least visible population, and the one shadow AI is mostly made of.

For each entry, the minimum useful record: what it is, what it is used for and by whom, who owns it, what data it sees, what decisions it influences, which risk tier it sits in, what its regulatory classification is (EU AI Act category, whether it is a model under SS1/23), and its lifecycle status. Model-level detail belongs on a model card; the inventory points to it.

Keeping it true

An inventory that was accurate on the day it was built is a historical document a month later. Three mechanisms keep it current.

• A gate. Nothing gets a production credential, a data connection or a budget line without an inventory entry. This catches the first population completely and the second mostly.
• Discovery. Web gateway and identity logs show which AI services staff are reaching; procurement and vendor reviews ask every supplier which AI features are on. This is how the third population gets found, and it is the same evidence base that reveals shadow AI.
• Review on a schedule. Every entry re-confirmed by its owner at a fixed interval, with the tier and classification re-checked against whatever has changed in the system, the use or the law.

The model versioning entry covers the harder problem underneath: a third-party model that changes without a version number the organisation controls.

Why regulators ask for it first

When a supervisor or an auditor arrives, the inventory is the first document requested, because it is the index to everything else. A firm that can produce it with owners, tiers and dates has demonstrated that it knows what it is running; the rest of the review is a sample of entries. A firm that cannot has demonstrated the opposite, and no quality of policy document recovers that. The EU AI Act makes this concrete: an organisation that cannot list its systems cannot show it has classified them, and classification is the obligation everything else in the Act hangs from.

Where it sits in the register

AI not mapped to important business services is the operational-resilience form of the gap, and unclear AI ownership and accountability is what an entry without an owner amounts to. No documented AI policy is why the third population goes unlisted. The controls are the ownership and accountability framework, which gives the inventory a keeper, and important business service impact tolerance mapping, which is what the inventory feeds on the resilience side.