AI Inventory: What Regulators Expect to Find in It

Key takeaways

• An AI inventory is the internal register of every AI system, model, agent and AI-enabled service an organisation builds, buys or uses, with an owner, a purpose and a risk tier for each.
• No major framework uses the phrase as a chapter title, yet NIST AI RMF GOVERN 1.6, ISO/IEC 42001 Annex A.4, OMB M-25-21 and SR 26-2 all require one in substance.
• The EU AI Act database registration (Articles 49 and 71) is a public filing, not an inventory, but you cannot file correctly without one.
• The value of an AI inventory sits in its links: to assessments, owners, vendors and evidence.
• A spreadsheet built once for an audit decays within a quarter; intake gates and change triggers keep the register true.

An AI inventory is the one governance artefact every AI rule quietly assumes you already have. Regulators rarely ask “do you have an AI inventory?” in those words. They ask which systems are high-risk, who approved them, which vendor supplies the model, and when each was last reviewed. Every one of those questions is a query against the AI inventory, and if the register does not exist, the answers are guesses. This guide answers a question that circulates in governance training almost word for word: how does maintaining an AI inventory support responsible governance? It then goes further than the definitional pages that rank for it, tracing each column of the register to the clause that compels it.

What an AI inventory is, and what it is not

An AI inventory is a maintained record of the AI an organisation develops, procures or uses, described at the level of the use, not only the tool. The same large language model licence can support a customer chatbot, a contract review assistant and a CV screening pilot. Those are three entries, because they carry three different risk profiles, three owners and, under the EU AI Act, potentially three different legal classifications. Five objects are routinely confused with it: <table header-row=”true”> <tr> <td>Object</td> <td>What it is</td> <td>Who keeps it</td> <td>Legal status</td> </tr> <tr> <td>AI inventory</td> <td>Internal register of AI systems and uses, with owners, purposes, risk tiers and links to assessments</td> <td>The organisation (governance, risk or compliance function)</td> <td>Required in substance by NIST AI RMF, ISO/IEC 42001, OMB M-25-21, SR 26-2</td> </tr> <tr> <td>EU database registration</td> <td>Public (or restricted) filing for specific high-risk and Article 6(3) systems</td> <td>Provider or public-authority deployer, filed with the European Commission</td> <td>Mandatory under EU AI Act Articles 49 and 71</td> </tr> <tr> <td>Model registry</td> <td>Technical catalogue of model versions, artefacts and metrics</td> <td>ML engineering, often in an MLOps platform</td> <td>No legal status on its own</td> </tr> <tr> <td>AI bill of materials (AI-BOM)</td> <td>Machine-readable list of models, datasets and dependencies inside one system</td> <td>Engineering or security</td> <td>Emerging practice (SPDX 3.0, CycloneDX ML-BOM)</td> </tr> <tr> <td>Risk register</td> <td>List of risks, owners and treatments</td> <td>Risk management</td> <td>Required by most management-system standards</td> </tr> </table> The practical rule: the AI inventory is the parent record. The model registry and the AI-BOM describe what is inside a system; the risk register describes what can go wrong; the EU database entry is what you disclose to the regulator. A mature AI registry links all four to the same system identifier, so an auditor can move from a use case to its risks, its models and its filing without changing tools. The closest legal precedent is the record of processing activities under GDPR Article 30. Privacy teams that already maintain one will recognise the pattern: a structured row per activity, an accountable owner, and a record that the supervisory authority can request.

How an AI inventory supports responsible governance

The short answer found on homework sites (“it provides visibility”) is true but thin. An AI inventory supports responsible governance through five distinct mechanisms, and each one fails if the register is incomplete.

1. It fixes the scope of every other control. Impact assessments, bias testing, human oversight design and monitoring all start from a list of systems. A system missing from the AI inventory is a system that no control ever reaches. This is also why shadow AI matters: an unregistered tool is not a policy breach in isolation, it is a hole in the scope of the entire programme.
2. It drives risk tiering and legal classification. Tiering needs structured facts: purpose, affected persons, decision impact, data categories. When those facts sit in the AI inventory, classification against the EU AI Act high-risk categories becomes repeatable instead of a one-off legal memo.
3. It names an accountable owner per system. Accountability frameworks assign duties to roles; the inventory assigns roles to people. Without a named business owner and technical owner, escalation paths described by an AI governance committee have nobody at the end of them.
4. It detects change. Most AI risk enters through change: a new purpose, a model upgrade, a vendor swap, a new market. A register with change triggers turns those events into review tasks. A register without them records a past that no longer exists.
5. It is the evidence an auditor samples from. Certification auditors and supervisors do not test everything. They sample. The AI inventory is the population they sample from, and the completeness of that population is often the first thing they test.

Put differently, an AI inventory does not make AI responsible by itself. It makes every other governance activity possible to scope, assign, repeat and prove.

Which rules make an AI inventory mandatory

No major framework has an article titled “AI inventory”. The obligation arrives indirectly, through duties that cannot be met without one. The table below maps the main regimes as of September 2026. <table header-row=”true”> <tr> <td>Regime</td> <td>Clause</td> <td>Who</td> <td>What it demands</td> <td>Status (September 2026)</td> </tr> <tr> <td>EU AI Act</td> <td>Art. 6(4), 26(8), 49, 71</td> <td>Providers of Annex III systems; public-authority deployers</td> <td>Registration in the EU database, documented Article 6(3) assessments</td> <td>Registration duty kept by the Digital Omnibus; Annex III obligations from 2 December 2027</td> </tr> <tr> <td>NIST AI RMF 1.0</td> <td>GOVERN 1.6</td> <td>Any organisation adopting the framework</td> <td>Mechanisms to inventory AI systems, resourced by risk priority</td> <td>Voluntary, widely referenced in US contracts</td> </tr> <tr> <td>ISO/IEC 42001:2023</td> <td>Annex A.4 (A.4.2)</td> <td>Organisations certifying an AI management system</td> <td>Documented resources per AI system</td> <td>Certifiable standard</td> </tr> <tr> <td>OMB M-25-21</td> <td>Section on AI use case inventories</td> <td>US federal agencies</td> <td>Annual public AI use case inventory</td> <td>2025 inventory published April 2026</td> </tr> <tr> <td>SR 26-2</td> <td>Model inventory expectations</td> <td>US banks supervised by the Fed, OCC, FDIC</td> <td>Complete, tiered model inventory</td> <td>Issued 17 April 2026, replaced SR 11-7</td> </tr> <tr> <td>UK ATRS</td> <td>Algorithmic Transparency Recording Standard</td> <td>UK central government and arm’s-length bodies</td> <td>Public records of algorithmic tools</td> <td>Mandatory since 2025</td> </tr> </table>

EU AI Act: registration presupposes an AI inventory

The EU AI Act creates a public EU database managed by the Commission under Article 71. Under Article 49, providers must register Annex III high-risk systems before placing them on the market or putting them into service. A provider that concludes under Article 6(3) that an Annex III system is not high-risk must document that assessment (Article 6(4)) and still register the system under Article 49(2). Deployers that are public authorities register their use (Articles 26(8) and 49(3)), and law enforcement and migration entries go into a restricted section (Article 49(4)). None of these filings is possible without knowing which systems you have and which role you hold for each. The Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, deferred Annex III obligations to 2 December 2027 and Annex I obligations to 2 August 2028, but kept the registration duty, including for Article 6(3) exemptions. The deadline moved; the need for an AI inventory did not.

NIST AI RMF: GOVERN 1.6

The NIST AI RMF Playbook is the most explicit text: GOVERN 1.6 states that “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.” The suggested actions go beyond a list of names, extending inventory requirements to data provenance, known issues, human oversight roles and responsibilities, and underlying foundation models. Organisations mapping to the NIST AI RMF should treat GOVERN 1.6 as the anchor control for their register.

ISO/IEC 42001: Annex A.4 resource documentation

ISO/IEC 42001 does not use the word inventory in its control titles, but Annex A.4 requires the organisation to identify and document, for each AI system, the resources it depends on: data, tooling, system and computing resources, and the people involved. In practice, an AI inventory with resource fields is the most direct evidence an auditor can sample for A.4.2. See our ISO 42001 certification guide for how the audit itself runs.

US federal agencies: OMB M-25-21

US federal agencies publish their registers. The 2025 Federal Agency AI Use Case Inventory, released by OMB in April 2026 under Executive Order 13960, the Advancing American AI Act and OMB Memorandum M-25-21, lists 3,611 individually reported use cases from 56 agency submissions, 445 of them classified as high-impact. That is more than double the 1,757 reported for 2024. The federal AI inventory is the largest public example of the discipline at scale, and its growth rate is a fair proxy for what happens inside large enterprises.

Banks: SR 26-2 model inventory

For US banks, SR 26-2, issued on 17 April 2026 by the Federal Reserve with the OCC and FDIC, replaced SR 11-7. It narrows the definition of a model and ties oversight to materiality, while keeping a complete model inventory as the foundation. Commentators note that many generative AI tools and agents fall outside the narrowed model definition, which is exactly why banks need an AI inventory that sits above the model inventory rather than inside it. Our guide to model risk management covers the overlap.

Public sector transparency registers

The UK made its Algorithmic Transparency Recording Standard mandatory for central government departments and arm’s-length bodies in 2025, with records published on GOV.UK. Several EU cities and member states run comparable algorithm registers. For public bodies, the AI inventory is no longer internal at all: part of it is published.

The fields an AI inventory needs

The question is not how many columns to add but which question each column answers for a reviewer. The table below lists the fields that recur across the regimes above. <table header-row=”true”> <tr> <td>Field</td> <td>Why it matters</td> <td>Regime that asks for it</td> </tr> <tr> <td>Unique ID and name</td> <td>Links the entry to assessments, incidents and filings</td> <td>All</td> </tr> <tr> <td>Business purpose and use case</td> <td>Drives classification; one tool can have several uses</td> <td>EU AI Act Annex III, OMB M-25-21</td> </tr> <tr> <td>Role (provider, deployer, importer, distributor)</td> <td>Determines which obligations apply</td> <td>EU AI Act Art. 3, 16, 26</td> </tr> <tr> <td>Lifecycle status</td> <td>Separates pilots, production and retired systems</td> <td>NIST AI RMF, SR 26-2</td> </tr> <tr> <td>Business owner and technical owner</td> <td>Accountability and escalation</td> <td>ISO/IEC 42001, NIST GOVERN 2</td> </tr> <tr> <td>Vendor and model provenance, incl. foundation model</td> <td>Supply chain risk and contractual flow-down</td> <td>NIST GOVERN 1.6 actions, vendor due diligence</td> </tr> <tr> <td>Data categories, incl. personal and special-category data</td> <td>Links to GDPR and data governance duties</td> <td>GDPR Art. 30, ISO/IEC 42001 A.4</td> </tr> <tr> <td>Affected persons and decision impact</td> <td>Tests for high-impact or high-risk status</td> <td>OMB M-25-21, EU AI Act Art. 6</td> </tr> <tr> <td>Risk classification (legal tier and internal tier)</td> <td>Sets the intensity of controls</td> <td>EU AI Act, SR 26-2 materiality</td> </tr> <tr> <td>Linked assessments (DPIA, FRIA, AI impact assessment, conformity assessment)</td> <td>Shows the entry has been reviewed, not just listed</td> <td>EU AI Act Art. 27 and 43, GDPR Art. 35</td> </tr> <tr> <td>Human oversight arrangement</td> <td>Evidence for oversight duties</td> <td>EU AI Act Art. 14 and 26</td> </tr> <tr> <td>EU database registration number</td> <td>Proves the filing matches the internal record</td> <td>EU AI Act Art. 49</td> </tr> <tr> <td>Review date and change log</td> <td>Shows the register is alive</td> <td>ISO/IEC 42001 clause 9, NIST GOVERN 1.6</td> </tr> </table> Resist the temptation to capture technical metrics in the AI inventory itself. Accuracy scores and model hashes belong in the model registry or AI-BOM; the inventory should hold a link to them. Machine-readable formats such as the SPDX 3.0 AI profile and the CycloneDX ML-BOM make that link practical.

How to build and maintain an AI inventory

Building the first version is a discovery exercise. Keeping it true is an operating process. The steps below cover both.

1. Discover from several sources at once. Declarations from business units miss embedded AI. Combine them with procurement records and vendor contracts, SSO and CASB logs for unsanctioned tools, cloud and API billing lines from model providers, code repositories and ML platforms, and the SaaS catalogue (many existing tools have quietly added AI features).
2. Install an intake gate. Nothing goes into production, and no AI-enabled purchase is approved, without an entry in the AI inventory. The gate is the single most effective control against drift, and it turns the register from a survey into a workflow.
3. Triage and tier. Apply a short screening questionnaire to each new entry: purpose, affected persons, decision impact, data categories, role. Route the few systems that look high-risk to a full classification and the rest to a lighter track.
4. Assign owners. Every entry gets a business owner who answers for the use and a technical owner who answers for the system. Owners attest to their entries on a fixed cycle.
5. Define change triggers. A new purpose, a model version change, a new vendor, a serious incident, a new jurisdiction or a new category of affected person reopens the entry for review.
6. Inventory agents and tools, not only models. Autonomous agents, the tools they can call and the MCP servers they connect to are inventory objects with their own permissions and owners. The rise of agentic AI is why registries now track agents as first-class entries.
7. Record decommissioning. Retiring a system is an event: record the date, the reason, data retention and whether any EU database entry needs updating.

Attestation cadence should follow risk: quarterly for high-risk and high-impact entries, annually for the long tail. The point is not the frequency but that someone signs.

Where AI inventories fail

Most failed registers were built correctly and then left alone. The recurring failure modes are predictable.

• Spreadsheet decay. A spreadsheet built for a certification audit is accurate on the day of the audit. Without an intake gate and owners, it is outdated within a quarter.
• Counting tools instead of uses. One entry per vendor hides the fact that the same model supports a harmless use and a high-risk one.
• Missing embedded AI. Features added to existing SaaS platforms rarely trigger procurement, so they rarely reach the register.
• No owner, or a committee as owner. A committee can approve, but only a person can answer.
• No link to assessments. An entry without its DPIA, impact assessment or human oversight design is a list, not a governance record.
• Built once for an audit. Supervisors increasingly ask for the history of the register, not only its current state. A change log is evidence that governance runs continuously.

FAQ

Is an AI inventory mandatory under the EU AI Act? Not under that name. The EU AI Act does not contain an article titled “AI inventory”. It does require providers to register Annex III high-risk systems and Article 6(3) exemptions in the EU database, public-authority deployers to register their use, and every operator to know its role for each system. None of that can be done reliably without an internal AI inventory, which is why supervisors and auditors treat the register as the first document to request. What is the difference between an AI inventory and the EU database? The AI inventory is internal and covers every AI system and use in the organisation, whatever its risk level. The EU database, set up by the Commission under Article 71, holds filings only for specific high-risk systems, Article 6(3) exemptions and certain public-sector uses. Think of the database entry as a public extract of a few rows of the inventory, which is why the registration number belongs in the inventory entry. Who should own the AI inventory? The register as a whole is usually owned by the AI governance, risk or compliance function, which sets the fields, runs the intake gate and reports to the governance committee. Individual entries are owned by the business owner of each use and a technical owner. Splitting ownership this way keeps the central team from becoming a bottleneck while keeping accountability personal. How often should the AI inventory be updated? Continuously for events and periodically for attestation. Any change trigger (new purpose, new model version, new vendor, incident, new jurisdiction) should reopen the entry immediately. On top of that, owners should attest to their entries on a cycle that follows risk: quarterly for high-risk and high-impact systems, annually for low-risk tools. An annual clean-up alone is not enough. Does a spreadsheet count as an AI inventory? Legally, yes: no regime prescribes a tool. Practically, a spreadsheet struggles once the register passes a few dozen entries, because it cannot enforce an intake gate, keep a change log, notify owners or link each row to its assessments and evidence. Most organisations start in a spreadsheet and move to a dedicated AI registry once audits begin sampling from it. Should AI agents be included in the AI inventory? Yes. An autonomous agent is an AI system with its own purpose, permissions and potential impact, and the tools or MCP servers it can call extend what it can do. Record each agent with its owner, the systems and data it can reach, its human oversight arrangement and the foundation model it relies on. NIST’s GOVERN 1.6 actions already point to foundation models as an inventory field.

Conclusion

An AI inventory is not paperwork that sits beside governance; it is the structure governance runs on. The EU AI Act registration duties, NIST AI RMF GOVERN 1.6, ISO/IEC 42001 Annex A.4, OMB M-25-21 and SR 26-2 all assume that an organisation can say, at any moment, which AI it uses, for what, under whose responsibility and with which assessments behind it. The Digital Omnibus pushed back the Annex III deadline to 2 December 2027, which buys time to build the register properly rather than a reason to wait. Start with discovery, install the intake gate, name the owners and link every entry to its evidence. An AI registry built this way turns the question “what AI do we have?” from an investigation into a query.