AI governance
AI inventory management: what to record and how to build one
What an AI inventory is, what each record needs, which frameworks point to one, and six steps to build it, with a field template.
An AI inventory is a maintained list of every AI system your organisation builds, buys or lets people use, with an owner, a purpose, the models and data involved, and a risk tier for each. Build it by discovering, classifying, assigning an owner, setting a risk tier, setting a review cadence and connecting it to change control. NIST names an inventory in the AI RMF. The EU AI Act text we read does not state a general inventory duty.
Last verified 2026-10-07. Sources are listed at the end of the page.
What is an AI inventory?
It is a register of AI systems, which is wider than a list of models. One record can be a model you host, an agent built on a provider's model, an AI feature inside a product you buy, a tool server an agent can call, or a chat tool staff use. The test is whether it makes or shapes an output that someone relies on.
A spreadsheet is a valid start. What matters is that each row has an accountable owner, and that the list is reviewed on a schedule instead of being a one-off exercise.
Why keep an AI inventory, and which rules point to one?
Read the source before you cite any of these. The last column is deliberate: only one of them states an inventory in so many words.
| Source | What the text says | Literal inventory duty? |
|---|---|---|
| NIST AI RMF, GOVERN 1.6 | The subcategory reads "Mechanisms are in place to inventory AI systems" and says they are resourced according to risk priorities. The framework is voluntary. | Yes in the framework text, but voluntary. |
| EU AI Act, Article 26 | Sets deployer duties for high-risk systems: use per instructions, human oversight, monitoring, logs of at least six months, and informing workers. | No inventory duty in the text we read. You still need to know which systems are high-risk to apply it. |
| EU AI Act, Article 49 | Providers of Annex III high-risk systems must register themselves and the system in the EU database. Public authority deployers must register their use. | A registration duty, not an internal inventory. |
| ISO/IEC 42001 | A management system standard for AI. The ISO page could not be opened by our tooling on 2026-10-07, so this page states nothing about its clauses. | Not stated here. Read the standard. |
| Basic security practice | You cannot patch, review or revoke access for something you do not know exists. This is this page's reasoning, not a quoted rule. | Not a legal point. |
What fields does each AI inventory record need?
A template. Start with these and drop what you will not keep current. A field nobody updates is worse than no field.
| Field | What to record | Why it matters |
|---|---|---|
| System name and ID | A unique name and a stable identifier. | Links logs, tickets and reviews to one record. |
| Type | Model, agent, embedded feature, tool server or chat tool. | Different types need different reviews. |
| Accountable owner | A named person and their team, not a mailbox. | Someone must answer for it and approve changes. |
| Purpose and users | The task it performs and who uses or is affected. | Frames risk, as MAP 1.1 asks for intended purposes and settings. |
| Models and versions | Each model and provider it calls, with versions. | Supports third-party review and rollback. |
| Data classes | The kinds of data it reads or sends. | Drives approval and retention rules. |
| Data residency | Where data is processed and stored. | Needed for transfer and sovereignty questions. |
| Reachable systems and actions | What it can read, write, send or delete, and what it may not. | Sets the risk tier for agents. |
| Identity and credentials | The service account or key it uses, and who owns it. | Unowned credentials are a security gap. |
| Risk tier | Your tier, with the reasoning and date. | Decides the review cadence and approvals. |
| Human oversight rule | When a person must approve or review. | Shows how oversight is meant to work. |
| Status and review date | Pilot, live, paused or retired, with next review. | Stale records mislead. GOVERN 1.7 covers decommissioning. |
| Evidence links | Where logs, test results and approvals are kept. | Lets a reviewer check without asking around. |
How do you build an AI inventory?
1. Discover
Collect from procurement, identity and single sign-on logs, cloud accounts, code repositories, gateway logs and a short staff survey. Expect to find more than anyone listed. See how to detect shadow AI.
2. Classify
Give each item a type, a purpose and the data classes it touches. Merge duplicates. Mark anything you cannot explain as unknown, not as fine.
3. Assign an owner
Every record gets one accountable person. If nobody accepts a system, treat that as a finding and decide whether to retire it.
4. Set a risk tier
Tier by what the system can reach and do, and by who is affected, using your own scale. For EU AI Act classification, which depends on role and use case, take legal advice. See the AI Act high-risk checklist.
5. Set a review cadence
Match the review interval to the tier, for example more often for agents with write access. NIST GOVERN 1.5 asks that periodic review is planned and its frequency determined.
6. Connect it to change control
A new model, prompt template, tool permission or data source should trigger an inventory update and, for higher tiers, a review. If changes bypass the inventory it will drift within weeks.
How does shadow AI discovery feed the inventory?
Shadow AI is AI use nobody approved or recorded. The inventory is where the output of discovery lands: each finding becomes a draft record with a source, a time and an unknown owner, and the owner then decides to sanction, replace, restrict or retire it. See shadow AI for the concept and shadow AI discovery for the workflow.
Discovery is continuous, because the estate changes. A one-off scan produces a list that is out of date within a quarter, so schedule it with the review cadence and compare each run to the last.
Where Swfte fits
The Trust Profile is the platform's design for an inventory record. Its example fields are identity, owner, risk level, approved models, data classification, residency, permitted systems, allowed and restricted actions, human approval rule, retention, audit and policy set. It is design intent. Today the controls it names are separate parts of the platform, and fields such as owner and risk level are not yet stored together on an agent.
Related parts exist: the policy engine and run ledger, and Nexus for non-human identity, described on non-human identity. The shadow AI discovery page describes the workflow Swfte is designed for, and which sources run depends on the connectors you have.
You do not need Swfte to start. A spreadsheet with the fields above and a monthly review is a real inventory. Swfte provides the technical controls, governance mechanisms and evidence you need to deploy AI within your applicable regulatory, security and policy requirements. The exact posture depends on your use case, jurisdiction, deployment and configuration.
Sources and last verified
Every dated or technical fact on this page was read from the pages below on 2026-10-07. Anything that could not be confirmed is left out or marked as not verified.
- NIST AI 100-1: AI Risk Management Framework (AI RMF 1.0). GOVERN 1.5, 1.6 and 1.7 and MAP 1.1, read in the framework text.
- NIST AI Resource Centre: AI RMF Playbook. That the Playbook is voluntary and not a checklist. The page did not display the inventory subcategory text, so the quote comes from the PDF.
- AI Act Service Desk: Article 26, deployer obligations. Deployer duties for high-risk systems and the public authority registration reference.
- AI Act Service Desk: Article 49, registration. Registration of Annex III high-risk systems and of public authority deployer use.
- European Commission: understanding standardisation under the AI Act (FAQ). The statement on ISO/IEC 42001 and the AI Act quality management system. Dated 10 March 2026.
Frequently asked questions
What should be in an AI inventory?
At least the system name, type, accountable owner, purpose and users, models and versions, data classes, residency, reachable systems and actions, credentials, risk tier, human oversight rule, status and review date, and links to evidence. Start with fewer fields if you will not keep them current.
Does the EU AI Act require an AI inventory?
The Article 26 and Article 49 text we read does not state a general inventory duty. Article 49 requires registration of Annex III high-risk systems in the EU database by providers, and by public authority deployers. Whether those apply depends on your role and use case, so take legal advice.
What does the NIST AI RMF say about inventories?
Subcategory GOVERN 1.6 reads "Mechanisms are in place to inventory AI systems" and adds that they are resourced according to risk priorities. The AI RMF is voluntary, so this is a recommended outcome, not a legal requirement. NIST says the Playbook is not a checklist.
Do I need to inventory AI features inside software I buy?
Yes where the feature touches your data or shapes decisions. Record the product, the feature, the vendor and the data it receives. You will not own the model, but you still own the use, so the record needs an owner and a risk tier like any other.
How often should the inventory be reviewed?
Match the interval to the risk tier and to how fast the system changes. NIST GOVERN 1.5 asks that periodic review is planned, with roles defined and the frequency determined. Review immediately when a model, prompt, tool permission or data source changes.
Is the Swfte Trust Profile an AI inventory product?
It is a design for one. The Trust Profile page shows the record fields, and the platform has a policy engine, approvals and a run ledger as separate parts. It does not yet keep one Trust Profile record per agent, so treat it as design intent.