Last updated: September 15, 2026
An AI system inventory is a maintained register of every AI model, AI-enabled feature, and AI-powered vendor tool your organization builds, buys, or uses, along with who owns each one, what it does, what data it touches, and how risky it is. It is the foundational control in every major AI governance framework: ISO 42001 requires you to document AI system resources and lifecycle information, the EU AI Act requires you to know which of your systems fall into its risk tiers, and the NIST AI RMF’s Govern function calls for a resourced inventory mechanism outright. You cannot classify, assess, or monitor what you have not counted.
This guide is part of our AI governance guide. It explains what belongs in an AI inventory, which fields to capture, how to discover systems you do not know about, and how to keep the register current once it exists.
Key takeaways
- An AI system inventory is step one of any governance program. Risk classification, impact assessments, and audit evidence all depend on it.
- Scope it broadly: in-house models, AI features inside SaaS products, API calls to foundation models, embedded vendor capabilities, and employee use of public tools.
- Capture a fixed set of fields per system: owner, purpose, users, data, model provenance, risk tier, controls, and review dates.
- Discovery is the hard part. Combine procurement records, SSO and expense data, code and API scanning, and a short survey to find shadow AI.
- Treat the inventory as a living record with a named owner, an intake process for new systems, and a review cadence, not a one-time spreadsheet.
Why does every AI governance framework start with an inventory?
Each of the three frameworks that dominate AI governance in 2026 assumes you know what AI you are running, even where it does not use the word “inventory.”
ISO 42001 requires you to determine the scope of your AI management system (clause 4.3) and, through its Annex A controls, to document the data, tooling, computing, and human resources behind each AI system (control A.4) and to keep documentation of AI system design and development (A.6.2). Certification auditors will expect a list of in-scope systems on day one. See our breakdown of ISO 42001 requirements for the full clause structure.
The EU AI Act imposes obligations by risk tier, so the first compliance question is which of your systems are prohibited, high-risk, limited-risk, or minimal-risk. Providers of high-risk systems must also register them in the EU database before placing them on the market (Article 49). Following the Digital Omnibus adopted in July 2026, the obligations for stand-alone high-risk systems listed in Annex III now apply from 2 December 2027, and those for AI embedded in regulated products from 2 August 2028, but the transparency obligations in Article 50 have applied since 2 August 2026 and the AI literacy duty in Article 4 since February 2025. Our EU AI Act compliance guide covers the full timeline, and this post on high-risk categories shows how to classify what you find.
The NIST AI RMF is the most explicit. Subcategory GOVERN 1.6 states that mechanisms should be in place to inventory AI systems and that the inventory should be resourced according to organizational risk priorities. The MAP function then builds on that record to establish context and categorize each system.
Beyond the frameworks, the inventory is what lets you answer the questions boards and enterprise customers actually ask: What AI are we using? Where is customer data going? Who signed off on it?
What counts as an AI system for inventory purposes?
The most common failure is scoping too narrowly. Teams inventory the models their data scientists trained and miss everything else. A defensible inventory covers five categories.
1. Models you build or fine-tune
Machine learning models trained or fine-tuned in-house, including classical models, deep learning, and fine-tuned foundation models. These are the easiest to find because someone in engineering owns them.
2. Foundation model APIs you call
Any application that sends prompts to an external model provider (OpenAI, Anthropic, Google, AWS Bedrock, Azure OpenAI, open-weight models on your own infrastructure). Each integration is an AI system with its own data flow, even if the underlying model is shared.
3. AI features inside software you buy
Your CRM, help desk, HR platform, meeting tool, and code editor almost certainly ship AI features now, often switched on by default. If that feature processes your data or influences a decision, it belongs in the register.
4. AI embedded in products you sell
Features your customers use that rely on AI. These carry the highest regulatory exposure under the EU AI Act because you may be the “provider” of the system, not just a deployer.
5. Employee use of general-purpose tools
Staff using ChatGPT, Claude, Copilot, or similar for daily work. You may track these at the tool level rather than per use case, but they need to be in scope for acceptable-use policy and data-leakage controls.
What fields should an AI system inventory capture?
Keep the schema small enough that people will fill it in and rich enough to drive classification and risk assessment. The table below is the minimum set we recommend. Add fields for your sector (for example, model card links for regulated financial models) rather than starting with fifty columns.
| Field | What to record | Why it matters |
|---|---|---|
| System name and ID | Unique identifier and plain-language name | Cross-referencing with risk register, vendor list, and audit evidence |
| Business owner | Accountable person, not a team | ISO 42001 leadership clauses; NIST AI RMF Govern; someone to answer auditor questions |
| Technical owner | Engineer or vendor contact | Change management and incident response |
| Purpose and intended use | What decisions or outputs it produces, for whom | Drives EU AI Act tier and impact assessment scope |
| Category | Built, API, embedded SaaS feature, product feature, general-purpose tool | Determines your role (provider vs deployer) and control set |
| Model provenance | Vendor, model name and version, training data summary if known | Supply chain risk; GPAI obligations; drift tracking |
| Data inputs and outputs | Data categories processed, including personal or sensitive data | Privacy, GDPR, cross-border transfer, retention |
| Users and affected people | Who operates it and who is affected by its outputs | Human oversight requirements; fairness and impact analysis |
| Autonomy level | Advisory, human-in-the-loop, human-on-the-loop, fully automated | Higher autonomy means stronger oversight controls |
| Risk tier | EU AI Act tier plus internal rating | Prioritizes assessment and control effort |
| Lifecycle status | Proposed, pilot, production, retired | Keeps the register current; supports decommissioning |
| Controls and assessments | Links to risk assessment, DPIA, model documentation, test results | Audit evidence for ISO 42001 and EU AI Act conformity |
| Review dates | Last reviewed, next review, trigger events | Proves ongoing monitoring |
How do you discover AI systems you do not know about?
A survey alone will miss half of what is in use. Combine several discovery sources and reconcile them.
Procurement and vendor records
Pull every active SaaS contract and ask each vendor, in writing, whether the product includes AI features, whether they are enabled, and whether your data is used to train models. Add the answers to your vendor risk records.
Identity, SSO, and expense data
Export app logins from your identity provider and search for AI vendors. Then search expense reports and corporate card statements for individual subscriptions to AI tools. This is where most shadow AI shows up.
Code, API keys, and network traffic
Scan repositories and secrets managers for model-provider SDKs and API keys. Ask your network or CASB team for egress to known model-provider domains. These two sources catch integrations engineering built without a formal project.
Cloud and MLOps platforms
List models deployed in SageMaker, Vertex, Azure ML, Databricks, or your model registry. Most teams find deployed endpoints nobody remembers.
A short, targeted survey
Ask every team lead three questions: which AI tools do you use, for what, and with what data? Keep it to five minutes and make it clear the goal is to enable safe use, not to punish anyone. Response rates collapse when the survey reads like an investigation.
How do you keep the inventory current?
An inventory that was accurate in January is a liability by June if nothing maintains it. Four mechanisms keep it alive.
Intake gate. Route new AI systems through a lightweight intake form before they reach production or before a vendor contract is signed. The form populates the inventory automatically. This is the single most effective control.
Named owner. Someone owns the register itself. Usually this sits with the GRC or privacy function, with engineering and procurement as contributing owners.
Review cadence tied to risk. High-risk systems reviewed quarterly, everything else annually, plus event-driven reviews when a model changes, a vendor changes terms, or a regulation shifts. Our AI risk assessment guide explains how to run the review itself.
Integration with existing registers. Link inventory records to your asset register, vendor register, and data map instead of duplicating them. ISO 27001 organizations already have most of this scaffolding.
What are the most common AI inventory mistakes?
The first is treating the inventory as a project rather than a process; it decays within months. The second is limiting scope to engineering-built models and ignoring SaaS features and employee tools, which is where regulators and customers increasingly look. The third is collecting too many fields, so nobody completes the record and the data is stale before it is finished. The fourth is failing to record the organization’s role for each system. Under the EU AI Act, being a provider carries far heavier obligations than being a deployer, and the inventory is where that distinction should live. Finally, teams often skip the “affected people” field, which is the one that matters most for fairness and impact assessment.
How does the inventory feed certification and compliance?
Once the register exists, everything downstream becomes tractable. The EU AI Act compliance checklist starts with classification, which is a filter on the inventory. ISO 42001’s risk assessment and AI impact assessment requirements (clauses 6.1.2 and 6.1.4) apply per system, so the inventory defines the scope of that work. And when an auditor asks for evidence of ongoing monitoring, a dated review history on each record is exactly what they want to see.
If you are pursuing ISO 42001 certification, expect the inventory to be one of the first artifacts requested during the Stage 1 audit. Building it well now shortens everything that follows.
Frequently asked questions
What is the difference between an AI inventory and an AI use case inventory?
An AI system inventory records the technical systems (models, integrations, tools). A use case inventory records the business purposes those systems serve. Public sector bodies such as US federal agencies are required to publish use case inventories. Most private organizations combine both by recording purpose as a field on each system, and listing multiple use cases where one system serves several.
Does the EU AI Act require an AI inventory?
Not by that name. But it requires providers and deployers to know which of their systems fall into each risk tier, to register high-risk systems in the EU database, and to maintain documentation and logs. Meeting those obligations without an inventory is not realistic. See who the EU AI Act applies to for the role definitions that drive scope.
Should employee use of ChatGPT be in the inventory?
Yes, at least at the tool level. Record the tool, the approved account type, the data classes permitted, and the policy that governs use. You do not need a record for every individual prompt or user.
Who should own the AI inventory?
The governance, risk, and compliance function typically owns the register, with engineering, procurement, and privacy contributing. What matters is that a named individual is accountable for its accuracy and that new systems cannot reach production without an entry.
How often should the inventory be reviewed?
Review high-risk systems at least quarterly and all others at least annually, with additional reviews triggered by model updates, vendor changes, incidents, or new regulation. Record every review with a date and reviewer.
Compyl gives you a single AI system inventory connected to vendor risk, risk assessments, and the control evidence you need for ISO 42001, the EU AI Act, and the NIST AI RMF. Intake forms populate the register automatically, reviews are scheduled and tracked, and every record links to the assessments and policies that govern it. Request a demo to see how it works on your own stack.
