What Belongs in an AI System Inventory

An AI system inventory needs nine fields per system: what it does, the model behind it and who provides it, whether the model is yours or a third party's, what data goes in, whether any of that data is customer or regulated data, where inference runs, what the system can do without a human approving it, whether its output influences a decision about a person, and a named owner. One row per system, and the definition of system has to be wide enough to include the tools nobody bought through procurement. This is not a nice-to-have artifact: the NIST AI RMF Playbook puts AI system inventories in GOVERN 1.6, one of the seven subcategories of the framework's first governance category, and the reason it sits that early is that nothing downstream works without it. The uncomfortable part is that the inventory is almost never wrong about the systems you built. It is wrong about the ones somebody signed up for with a company card, and those are usually the ones with the deepest access.

Below: the nine fields and what each one is actually for, how to find the systems nobody told you about, how to keep the thing from going stale, and when a spreadsheet is genuinely enough.

Key takeaways

• Nine fields, one row per system. The two that carry the most signal are autonomy (what it can do without approval) and whether output influences a decision about a person.
• The inventory is a named requirement, not a best practice. NIST AI RMF GOVERN 1.6 covers AI system inventories, and ISO/IEC 42001's Annex A includes a control objective on resources for AI systems.
• Scope by "processes our data or acts on our behalf", not by "we bought it". The gaps are in the second definition.
• Staleness is the failure mode, not incompleteness. An inventory built once and never revisited is worse than none, because it is trusted.
• Everything else in AI governance is downstream. Policy, questionnaire answers, vendor tiering and certification scope all read from this table.

Why this artifact and not another

Every AI governance framework assumes an inventory exists and then builds on top of it, which is why the companies that skip it end up doing the same discovery work three times.

The NIST AI Risk Management Framework, which NIST publishes for voluntary use, is organized around four functions that AI RMF 1.0 names as GOVERN, MAP, MEASURE and MANAGE. The Playbook places AI system inventories under GOVERN 1.6, alongside subcategories on legal and regulatory understanding, risk tolerance, monitoring and incident response, and safe decommissioning. Its MAP function then opens with MAP 1.1, which asks that intended purpose, potentially beneficial uses, and context-specific laws, norms and expectations are understood and documented. Both are per-system exercises, and you cannot run them over a population you have not enumerated.

ISO/IEC 42001 lands in the same place from a different direction. Its Annex A is a reference set of 38 controls across nine objectives, and one of those objectives, as Konfirmity's control guide describes it, covers resources for AI systems: the data, tooling, compute and human competence each system depends on. Konfirmity sells compliance software, so read its framing accordingly.

And the commercial version arrives before either. Enterprise security reviewers ask which model providers sit behind your product, and answering that from memory is where good-faith wrong answers come from. The inventory is what makes the AI questions on a security questionnaire answerable in an afternoon instead of a week.

The nine fields, and what each one is for

1. What it does, in one sentence a non-engineer understands. "Ranks inbound support tickets by urgency" beats "LLM-based triage pipeline". You are writing for a future auditor, a customer's reviewer, and yourself in eighteen months.

2. The model and the provider. Name the model and the company behind it, whatever the data is. Whether the provider also belongs on your sub-processor list is a second question with its own test: it belongs there when it processes personal data on your behalf as a downstream processor. An API that only ever sees public or internal non-personal data does not earn a sub-processor entry by being an API, and where you are not the party whose processing is being delegated the role can differ again. Apply the test rather than promoting every provider into a contractual or public disclosure by default, and where the test is met, keep the two documents from ever disagreeing.

3. Yours or theirs. Whether you train, fine-tune, host, or simply call. This field decides which obligations attach to you as a developer rather than as a deployer, and that distinction now has legal weight in more than one jurisdiction.

4. What data goes in. Both at training time and at inference time, because they are different questions and the answers frequently differ. A system trained on public data that receives customer prompts at inference is a customer-data system.

5. Whether that includes customer or regulated data. A yes here escalates the row into your existing data-handling regime rather than an AI-specific one, which is the correct outcome. This is the field that connects the inventory to the data classification tiers your AI acceptable use policy already references.

6. Where inference runs. Region, and whether requests can fail over to another region under load. "In the cloud" is not an entry. Residency commitments live or die on this field.

7. Autonomy: what it can do without a human approving it. This is the field most inventories do not have and the one that changes decisions. A system that drafts is a different risk from a system that sends, refunds, provisions, deletes or escalates. Record the actions and the credentials it holds to take them.

8. Whether output influences a decision about a person. Hiring, discipline, credit, pricing, access, eligibility. A yes here is what pulls the row into automated-decision regimes such as Colorado's SB 26-189 and into the human-review tier of your policy.

9. A named owner. A person, not a team. The owner answers when a reviewer asks about this row, and notices when the row stops being true.

Nine fields fit in a spreadsheet and take about ten minutes per system for someone who knows it. Resist a tenth until you have run the first review cycle, because every field you add is a field that goes stale.

Finding the systems nobody registered

The inventory you build from a product roadmap will be accurate and incomplete. The gaps are in three predictable places.

Employee-adopted tools. Microsoft and LinkedIn's 2024 Work Trend Index, a survey of 31,000 people across 31 countries, found 78 percent of AI users bringing their own tools to work. That figure is from 2024 and Microsoft sells AI products, so treat it as directional, but it names a real category. The practical search: expense reports, corporate card statements, SSO application lists, browser extension inventories from your device management, and OAuth grants against your Google or Microsoft tenant. The OAuth list in particular tends to surprise people, because it shows what has been given access rather than what has been paid for.

AI features inside tools you already own. Your support desk, your CRM, your code host and your document suite have all shipped AI features, often enabled by default, often processing exactly the data you were careful about elsewhere. These do not appear in any procurement record because you did not procure them. Go through your top twenty SaaS vendors and ask what AI features are on and what data they touch.

Embedded models inside products you built. A recommendation model somebody added two years ago, a classifier that fires in a data pipeline, a fraud score from a vendor library. These are AI systems by every definition that matters and they predate the vocabulary, so nobody thinks to list them.

The scoping rule that catches all three: include anything that processes your data or acts on your behalf using a model, regardless of whether you bought it, built it, or inherited it. "We bought it" is the definition that produces the gaps.

Keeping it true, which is the whole difficulty

Building the first version takes a week. Keeping it accurate is the actual project, and the failure is specific: an inventory built once and never revisited becomes worse than no inventory, because people start trusting it. The Stage 2 audit finding and the botched questionnaire answer both come from the same place, which is a table that stopped matching production and nobody noticed.

Three mechanisms, in order of how much work they are.

A review cadence with a name attached. Quarterly, owned by the person who owns AI governance, with a fifteen-minute pass per system and a longer look at anything whose owner has changed jobs. This is the minimum and it is enough for most companies under a couple of hundred people.

A trigger in an existing process. Add one question to whatever gate you already have: does this change introduce or modify an AI system, and if so, has the inventory row been updated? Vendor intake, architecture review and the change process are all reasonable places. A trigger in a process people already follow beats a new process people have to remember.

Detection, where the volume justifies it. OAuth grant monitoring, egress to known model-provider endpoints, and expense keyword rules. Worth building once you are large enough that the review cadence keeps finding things it should already have known, and overhead before that point.

The honest test of whether the inventory is alive: pick a row at random and ask its owner whether it is still accurate. If the answer takes longer than a minute, the table is documentation rather than a control.

What the inventory makes possible

Your acceptable use policy's approved-tool list is a filtered view of this table. Your answers to enterprise security questionnaires read straight off it. Your vendor tiering gets its two most useful axes, data sensitivity and autonomy, from fields five and seven, which is the model a serious AI vendor review works from. Your ISO 42001 scope is a decision about which rows are in it, and that decision is unmakeable without the rows. Your automated-decision obligations under state law attach to the rows where field eight is yes.

One table, five downstream uses. That ratio is why it goes first.

When a spreadsheet is enough, and when this is not your problem

A spreadsheet is enough up to roughly fifty systems and a couple of hundred people. Below that, a purchased AI governance platform mostly moves the same neglect into a nicer interface. What makes an inventory work is a named owner and a cadence, and no tool supplies either.

Some companies do not need this yet. If your entire AI exposure is a marketing team using a public chatbot on public copy, the correct artifact is a paragraph in your acceptable use policy. If you have one AI feature calling one provider and everyone can name both, writing it down takes ten minutes and does not need a project.

And a caution that cuts against the discipline generally: an inventory built to be shown rather than used is a real cost with no return. If the answer to a tool with too much autonomy is going to be to note it and move on, you are not ready to govern this yet and the table is theater. Ownership first.

Where Top Floor fits

We build this as a bounded exercise rather than a program: the discovery pass across procurement, SSO, OAuth and your existing SaaS estate, the nine fields filled in with the people who actually know, and the review cadence handed to a named owner. It usually takes less time than the meetings about whether to do it. That work sits inside our NIST AI RMF engagements, where the inventory is the first deliverable and the alignment statement is built on top of it.

Where the destination is certification, the inventory is also the scoping instrument for ISO 42001: you cannot draw an auditable boundary around a population you have not listed, and a scope drawn before the discovery pass is a scope that changes in month four.

Where the difficulty is the cadence rather than the build, because everyone agrees it matters and nobody has the hours, compliance as a service covers keeping it current. That is the part that decays, and it decays quietly.

How to decide this week

• Pull three lists: SSO applications, OAuth grants against your identity tenant, and twelve months of expense lines containing AI vendor names.
• Ask your top twenty SaaS vendors which AI features are enabled on your account and what data they touch. Most will answer in a day.
• Open a nine-column sheet and fill one row properly, end to end, before you fill twenty badly.
• Fill the autonomy column first for every system you already know about. It is the fastest way to find the row that should worry you.
• Name the owner and put the quarterly review in their calendar before you finish the first pass, because the review is what makes the pass worth doing.

Frequently asked questions

What should an AI system inventory contain?

Nine fields per system: a plain-language description, the model and its provider, whether the model is yours or a third party's, what data goes in at training and at inference, whether that data includes customer or regulated data, where inference runs, what the system can do without a human approving it, whether its output influences a decision about a person, and a named owner. The autonomy field and the decision-about-a-person field carry the most signal and are the two most often missing. Nine fields fit in a spreadsheet and can be completed for a typical system in about ten minutes by someone who knows it.

Is an AI inventory actually required by any framework?

Named in both, required by neither in the way that word is usually meant. The NIST AI RMF Playbook puts AI system inventories at GOVERN 1.6, one of the seven subcategories of the framework's first governance category, and NIST publishes the framework for voluntary use, so GOVERN 1.6 is an outcome you align to rather than a rule you are held to. ISO/IEC 42001 reaches the inventory through Annex A, whose 38 reference controls across nine objectives include an objective covering resources for AI systems: the data, tooling, compute and competence each system depends on. Annex A is a reference set, and applicability is decided in your Statement of Applicability against your risk and impact assessments rather than by adopting every control. What holds in both is practical rather than formal: the per-system work each framework asks for is impossible over a population that has not been enumerated, which is why the inventory tends to be the first thing a scope needs whether or not a clause names it.

How do we find AI tools nobody told us about?

Three searches catch most of them. Look at what employees adopted directly, through expense reports, corporate card statements, SSO application lists, browser extensions reported by device management, and OAuth grants against your identity tenant. Look at AI features switched on inside SaaS you already pay for, which appear in no procurement record because you did not procure them. And look for models embedded in products you built before the current vocabulary existed, such as classifiers and scoring models in data pipelines. The scoping rule that catches all three is to include anything that processes your data or acts on your behalf using a model, regardless of who bought it.

How often should the inventory be reviewed?

Quarterly, by a named owner, with a fifteen-minute pass per system. Add one question to a gate you already run, asking whether a change introduces or modifies an AI system and whether the row has been updated, because a trigger inside an existing process outperforms a new process people have to remember. Automated detection through OAuth monitoring and egress rules is worth building only once the quarterly review keeps finding things it should already have known. The test of whether the inventory is alive is to pick a row at random and ask its owner if it is still accurate; if that takes more than a minute, it is documentation rather than a control.