What is an AI system inventory?

What goes in it

Each entry describes one system well enough that someone outside the team could understand what it does and why it matters. Link each entry to its impact assessment, to its risks in the risk register, and to the suppliers involved.

• Identity. Name, version, a short description, and whether you built it, bought it or call it through an API.
• Purpose. What it is used for, which decisions it informs, and who uses it.
• Data. Training, input and output data, and whether any of it is personal or confidential.
• Owner. A named person accountable for the system and for keeping its entry current.
• Classification. Your internal risk tier and, where the EU AI Act applies, its risk category and your role as provider or deployer.

Why everything starts from it

ISO 42001 has no clause titled “inventory”, but its scope (clause 4.3), AI risk assessment (6.1.2) and AI system impact assessment (6.1.4) all depend on knowing which systems are in play. Its Annex A also asks for the resources behind each system, such as data, tooling and computing, to be documented.

The EU AI Act sets obligations by role and risk category: banned practices under Article 5, high-risk systems under Article 6 and Annex III, and transparency duties under Article 50. Each system has to be classified before you know which apply. The NIST AI RMF asks for the same thing in Govern 1.6, which calls for mechanisms to inventory AI systems.

Finding what is in use

Models your own team built are easy to list. The gaps are usually AI features switched on inside existing SaaS tools, AI APIs called from code, and tools staff signed up to on their own. Procurement and expense records, supplier reviews, the list of apps in your single sign-on, a search of code for AI libraries and keys, and a short survey of each team will find most of them.

To keep the inventory current, make adding an entry part of procurement and change approval, and check it in full at planned intervals, such as before each management review.

Related terms

AI impact assessment

An assessment, for each AI system, of who is affected, what could go wrong, how likely and how severe it is, and what is done about it. ISO 42001 requires one, and the EU AI Act requires its own forms for high-risk systems.

Risk register

The list of identified risks with an owner, likelihood, impact, treatment and review date, linked to the controls that treat each one. Usually the first document an auditor asks to see.

Management review

A recorded review in which leadership looks at how the management system is performing: audit results, risks, incidents, objectives and resources. Required by ISO management system standards.

Control

A specific safeguard or activity that reduces a risk, such as requiring MFA on privileged accounts or reviewing access every quarter. Frameworks are, in large part, lists of controls.