How to Build an AI System Inventory 

AI Governance Guide · 01
NIST AI RMF · ISO/IEC 42001 · EU AI Act
AI System Inventory
Updated 13 Sep 2026

Learn · AI Inventory

What AI are we actually running?

Six words that stall most governance programs. How to build an AI system inventory that survives past the first quarter — where to look, what to record, and the one design decision that keeps it current.

Most AI governance programs stall in the same place. Someone senior asks a reasonable question — “what AI are we actually running?” — and nobody can answer it in under three weeks.

That question is the whole job compressed into six words. You cannot classify systems you have not found. You cannot assess risk on a list that does not exist. And when EU AI Act obligations land, or a customer sends a security questionnaire with eleven new AI clauses in it, the inventory is the first thing anyone asks to see.

This guide covers how to build one that survives past the first quarter: where to look, what to record, and the single design decision that determines whether it stays current or quietly rots in a SharePoint folder.

Sequence

Why the inventory comes first

Every framework you might be working toward assumes the inventory already exists.

NIST AI RMF’s MAP function is built around characterizing the systems in scope. ISO/IEC 42001 expects a defined set of AI systems inside the management system boundary. The EU AI Act’s obligations attach to specific systems in specific roles — you cannot determine whether you are a provider or a deployer of a high-risk system in the abstract. You determine it system by system.

So the inventory is not a preliminary step before the real work. It is the object the real work operates on.

It is also the artifact with the shortest path to value. A finished inventory tells you, usually within a day of completing it, which three or four systems are going to consume most of your governance attention for the next year. That is a genuinely useful answer, and you get it before writing a single policy.

Scope

The hard part: deciding what counts

Here is where most inventories go wrong in the first hour. Define “AI system” too narrowly — trained models your data science team deployed — and you produce a list of six things while missing the ninety that actually carry risk. Define it too broadly and every product with a machine learning feature qualifies, your list runs to four hundred rows, and it becomes unusable.

A working definition

Anything that produces an output your organization acts on, where the logic is learned rather than explicitly written, and where a person cannot fully predict the output in advance.

That definition captures the things people routinely forget:

  • The résumé screening feature bundled into your ATS
  • The fraud scoring inside your payments provider
  • Sales call transcription and summarization tools
  • The AI assistant embedded in your CRM
  • Anything a team is running against an LLM API, including internal prototypes
  • Third-party tools your vendors use to deliver services to you

It correctly excludes rules engines, deterministic automation, and the “AI-powered” label on a product that is doing regex matching. Ask the vendor what the logic is. If they cannot explain how the output is produced, treat it as in scope until proven otherwise.

Set the boundary in writing before you start collecting. Document your inclusion test in one paragraph. When someone challenges an entry six months from now — and they will — you want a written rule, not a recollection.

Discovery

Where the systems actually are

Asking department heads “what AI are you using?” produces an incomplete list. People do not think of the transcription feature in their meeting tool as AI. They think of it as the meeting tool.

Go to the systems of record instead, in roughly this order.

Source What to pull
01SSO / identity provider Every application with active sign-ins over the last ninety days. The single richest source, and it surfaces tools nobody remembers approving.
02Expense and card data Twelve months of transactions filtered for SaaS vendors under the approval threshold. Individual subscriptions on personal cards are where shadow AI lives.
03Procurement and contracts AI clauses, data processing agreements signed in the last two years, and any vendor whose product category changed after 2023.
04Existing vendor register Add an AI flag to the register you already maintain, then filter on it. Do not build a parallel list.
05Endpoint and MDM data Browser extensions and installed applications reveal a great deal.
06Code repos and cloud accounts API calls to model providers, deployed inference endpoints, model-serving infrastructure. Prototypes on someone’s cloud budget count.
07Then ask people Not “do you use AI?” Ask: which tools in your workflow generate text, summarize documents, score or rank anything, make recommendations, or transcribe? That phrasing gets three to four times the response rate.

Expect the true number to land somewhere between three and ten times what leadership estimates. That gap is normal, and worth reporting — it is the most persuasive argument for the program you are trying to fund.

Fields

What to record

Resist the urge to build a forty-column register. Every field you add is a field somebody has to maintain, and unmaintained fields make the whole inventory untrustworthy.

Twelve fields carry almost all the weight.

The twelve fields of an AI system inventory
Twelve fields that carry almost all the weight in a working AI system inventory.

The two fields people skip and later regret are your role and decision impact. Role determines the entire obligation set under the EU AI Act. Decision impact is the field that separates the systems needing real scrutiny from the ones needing a line in a policy.

Triage

Tiering without over-engineering

Once populated, sort the inventory. Three tiers is enough for most organizations.

Tier Criteria What it gets
1 — Elevated Outputs materially affect individuals’ rights, access or livelihood; or special category data is processed; or there is limited meaningful human oversight Full impact assessment, documented mitigations, named accountable owner, defined review cadence
2 — Standard Business impact without direct effect on individuals’ rights Baseline controls, vendor due diligence, annual review
3 — Minimal Productivity tools on non-sensitive data, with a person reviewing every output Covered by the acceptable use policy, nothing more

Most organizations land with under ten percent in Tier 1. If half your inventory is landing in Tier 1, your criteria are too loose and you have built a program nobody can staff.

A tiering decision you cannot reconstruct in twelve months is a tiering decision an auditor will not accept.

The design decision

What keeps it current

An inventory built as a one-time project is obsolete within a quarter. Not because anyone neglected it — because procurement kept working while you were building it.

The fix is not a better reminder schedule. It is attaching the inventory to a process that already runs without your involvement. Pick one existing gate and add three questions to it.

Gate What it catches
Procurement intake or purchase requisition Anything new, flagged at the point of purchase
Vendor security review You already assess new vendors — add the AI questions to the questionnaire
Change management or architecture review Internally built systems that never touch procurement

The three questions

  1. Does this tool generate content, make recommendations, score or rank anything, or transcribe?
  2. What data will it process?
  3. Will any output affect a decision about a person?

Three questions on a form somebody already fills in will keep an inventory more current than a quarterly all-hands email ever will. That is the difference between a governance program that runs and one that requires you to push it.

Pair it with a light quarterly reconciliation: re-pull the SSO application list, diff it against the register, investigate anything new. Thirty minutes, four times a year.

Test

What good looks like

A working inventory should let you answer these in under five minutes:

  • How many AI systems process personal data, and which ones?
  • Which systems would be high-risk under the EU AI Act, and what is our role for each?
  • Who owns the three systems with the greatest decision impact?
  • What changed since last quarter?

If any of those takes longer than five minutes, the problem is usually structure rather than effort — most often too many fields, or ownership assigned to departments instead of people.

Pitfalls

Five failure patterns worth avoiding

  1. Building it in a tool nobody opens. A maintained spreadsheet beats an abandoned GRC platform. Buy tooling once the process works manually, not before.
  2. Assigning ownership to a department. “Marketing” does not answer emails. Name a person.
  3. Treating pilots as out of scope. Pilots process real data and become production quietly. Include them, flag the status.
  4. Recording the vendor and stopping. The vendor is not the system. One vendor may supply three AI features with three different risk profiles.
  5. Waiting for completeness before starting the analysis. An eighty percent inventory you act on beats a hundred percent inventory delivered six months late. Publish, act, refine.

Next

Where this leads

The inventory is stage one. Once it exists, classification becomes a defined task rather than an open-ended one, and the policy set you write afterward has something concrete to point at.

The next guide in this path covers classifying those systems against EU AI Act risk tiers and confirming your role in the value chain.

FAQ

Common questions

How long should a first inventory take?

Two to four weeks for most mid-sized organizations, with the bulk of that spent waiting on exports rather than doing analysis. Pull the SSO list first — it alone usually gets you to seventy percent.

Do we include AI our vendors use to serve us?

Yes, where their outputs affect your decisions or your data. You may not be able to assess those systems directly, but you need to know they exist, and your vendor questionnaire is the mechanism for finding out.

Spreadsheet or GRC platform?

Spreadsheet, until the process works manually. Tooling amplifies a functioning process and disguises a broken one. The organizations that buy a platform first usually end up maintaining two lists.

What if we find something that should never have been deployed?

Expect it, and decide in advance how you will handle it. If the first discovery triggers a disciplinary process, the second discovery will not be reported to you. Amnesty during the initial sweep produces a far better inventory.

Does this satisfy ISO/IEC 42001 or the EU AI Act?

It is the foundation for both, not the whole of either. The inventory is what classification, impact assessment and conformity work operate on — without it, neither can be completed or evidenced.

See where you stand before you start

Our free assessment scores your AI governance against the EU AI Act, ISO/IEC 42001 and the NIST AI RMF, and shows which gaps to close first. Twenty to thirty questions, about ten minutes, no signup.

Take the assessment  ·  Browse governance documents

Get the template

Our AI System Inventory template ships with the twelve fields above, the tiering criteria, and the three intake questions formatted for a procurement form. It is included in the AI Governance Starter Kit, tailored to your sector and size. Working through this and want a second opinion on scope? Book a free 30-minute call — no slides, and you leave with the two or three things worth doing first whether or not you hire us.

References

Primary sources for this guide

  • NIST AI Risk Management Framework 1.0 — MAP function
  • ISO/IEC 42001:2023 — AI management system requirements
  • Regulation (EU) 2024/1689 (EU AI Act) — provider and deployer obligations

This guide reflects published guidance as of 13 September 2026. Framework requirements and regulatory timelines change — verify current NIST, ISO and EU AI Act text before relying on them. Advisory content, not legal advice.

Nabiha Sofia Herradi

Nabiha Sofia Herradi
PRINCIPAL · AI GRC ADVISORY

Nabiha advises regulated organizations on AI governance, risk and compliance — EU AI Act readiness, ISO/IEC 42001, and NIST AI RMF programs built to produce evidence rather than documents. She holds a law degree along with CISM, CISA, CIPP/E, CIPP/US and CMMC-CCP, and 15+ years in GRC.

AI GRC Advisory · Learn · AI Governance Guide 01 · 13 Sep 2026