AI system inventory work starts, almost always, with an uncomfortable meeting. Someone asks a simple question — which AI tools are we actually using? — and the room produces four different answers, none of them complete. IT names the two products it bought. Legal names the one it reviewed. Marketing mentions a transcription service nobody else had heard of. Nobody mentions the AI features that switched themselves on inside software the business already pays for.
This guide closes that gap. It sets out what an AI system inventory is, where shadow AI genuinely hides, a template you can fill in field by field, seven discovery methods that surface tools nobody declared, a two-week sweep plan, a triage scale for what you find, the governance decisions that follow, and how the finished register maps onto ISO/IEC 42001, the NIST AI RMF and the EU AI Act.
None of it requires a governance function or new software. A competent IT lead with access to expense data, your identity provider and a survey form can build a credible first-pass register in a fortnight. If you are assembling the wider programme, this pairs with our AI strategy work and sits directly upstream of your AI acceptable use policy — the policy tells staff what is allowed, the register tells you what is actually happening.
Table of contents
- What an AI System Inventory Is — and Why Shadow AI Makes It Urgent
- Shadow AI: Where an AI System Inventory Finds It Hiding
- The AI System Inventory Template, Field by Field
- How to Find Shadow AI: Seven Discovery Methods for Your AI System Inventory
- Running the AI System Inventory Sweep: A Two-Week Plan
- Scoring and Triaging What the AI System Inventory Finds
- From AI System Inventory to Governance: Approve, Migrate, Retire
- Keeping the AI System Inventory Current
- Mapping the AI System Inventory to ISO 42001, NIST AI RMF and the EU AI Act
- AI System Inventory Mistakes That Waste the Exercise
- Frequently Asked Questions About AI System Inventory
- References
What an AI System Inventory Is — and Why Shadow AI Makes It Urgent
The phrase gets used for at least three different artefacts, which is why so many organisations maintain two of them badly instead of one of them well. Precision about scope is what keeps the register short enough to survive.
An AI system inventory is a register of use, not a list of licences
An AI system inventory records every place where an AI capability influences work: what it does, who owns it, what data reaches it, what happens to the output, and how much human review sits in between. A licence list answers a procurement question. The register answers a risk question, and the two overlap far less than people expect.
The distinction matters most for free tools, which carry no licence, no invoice and no procurement record — and which make up the bulk of what a first sweep uncovers.
Shadow AI is the majority of what you will find
Shadow AI is any AI capability in use without the knowledge or approval of whoever is accountable for it. It is rarely malicious. It is a marketing assistant pasting a customer list into a free summariser because the deadline was yesterday, or a developer accepting completions from an extension nobody reviewed.
Because it grows from convenience rather than intent, it grows fast and it grows quietly. Treat it as a discovery problem to solve, not a discipline problem to punish, or the second sweep will return nothing at all.
The AI system inventory is the prerequisite for every AI framework
ISO/IEC 42001 expects you to know the scope of your AI management system. The NIST AI RMF expects you to map context before you measure anything. The EU AI Act expects you to classify systems by risk. Every one of those obligations begins with a list you do not have yet.
That is the practical argument for doing this first. An AI system inventory is not a compliance deliverable in its own right; it is the input every other deliverable silently assumes you already possess.
| Record | Question it answers | Unit | Typical owner |
|---|---|---|---|
| AI system inventory | Where is AI influencing our work, and who owns each instance? | Use case | IT or AI lead |
| Software asset register | What have we bought and what does it cost? | Licence | Procurement |
| CMDB | What is deployed and how does it connect? | Configuration item | IT operations |
| Record of processing (ROPA) | What personal data do we process and why? | Processing activity | Data protection lead |
| Vendor register | Who are our suppliers and how were they checked? | Supplier | Procurement |
Each of those feeds the AI system inventory rather than replacing it. The register borrows the supplier from the vendor list, the data categories from the ROPA and the hostname from the CMDB — but the row exists because a use case exists, and no other record is organised that way.
Shadow AI: Where an AI System Inventory Finds It Hiding
Discovery gets easier once you stop looking for rogue subscriptions and start looking in the five places shadow AI genuinely accumulates. Ranked by how often they turn up first, here is what a sweep finds.
AI features switched on inside tools you already own
This is now the largest single category and the least visible, because nothing was bought and nothing was installed. A meeting platform enables automatic summaries. A CRM adds a drafting assistant. A support desk starts suggesting replies. Each one is a new AI system processing your data under terms somebody accepted years ago for a different product.
Nobody experiences these as adoption decisions, which is precisely why they never reach a register. Check the release notes and admin consoles of your ten largest platforms and expect to add several rows.
Free tiers signed up with a work email
The classic case: a free summariser, image generator or transcription service, registered with a work address, used on real documents. There is no invoice to find and no procurement trail, so expense data will never surface it. Identity and network telemetry will.
Browser extensions and IDE plugins
Extensions sit inside the browser session, which means they can often read whatever the page shows — including systems you consider internal. Code assistants raise the same question in the development environment, where the material is source and secrets rather than prose.
Personal accounts and personal devices
Work moved to a personal account is the hardest category to see and the one an amnesty survey is genuinely better at finding than any tool. Telemetry stops at the boundary of your estate; a question asked without threat of punishment does not.
Embedded AI inside supplier products
Your suppliers are adopting AI too, and their models may process your data as part of delivering the service. This is a contractual discovery exercise rather than a technical one, and it belongs in the same AI system inventory as everything else — with a note recording which supplier, which service and which notice clause applies.
The AI System Inventory Template, Field by Field
Here is the structure that survives contact with a real organisation. Five blocks, roughly fifteen fields, one row per use case. Resist every request to add a sixteenth field — the register fails through abandonment, not through insufficient detail.
Block 1: Identity and ownership
Give every entry a stable reference, a plain-English name and one named accountable owner. Not a department: a person. Record the business unit, the date added and who added it. Ownership is the field most often left blank and the one that makes every later question answerable.
Block 2: Purpose and data
One sentence on what the system does and what decision or output it feeds. Then the data: categories in, whether personal or special-category data is involved, categories out, and who sees the output. If output leaves the organisation, say so explicitly — that single flag drives most of your triage.
Block 3: Technical and contractual
Record the vendor, the underlying model or service where you know it, the hosting region, whether your data trains the provider’s models, the retention period and the contract or terms reference. Half of these come straight from the supplier’s trust page; the other half are worth an email.
Block 4: Risk and control
Capture the risk tier, the human review arrangement, the controls in place today and the residual score. Keep this block short and link out to the fuller AI risk assessment for anything scored medium or above. The register points at the assessment; it does not try to be one.
Block 5: Lifecycle and status
Status (discovered, under review, approved, migrating, retired), the review date, the re-assessment triggers and the exit route. An AI system inventory without a status field becomes a graveyard within two quarters, because nothing ever visibly leaves it.
| Field | What to capture | Why it earns its place |
|---|---|---|
| Reference and name | Stable ID, plain-English name | Lets two teams discuss the same row |
| Accountable owner | One named person, not a team | Every other question has somebody to ask |
| Use case | One sentence, plus the decision it feeds | Distinguishes low risk from high inside one product |
| Data in | Categories, personal data flag, source | Drives the data protection questions |
| Data out and audience | What is produced, who sees it, does it leave | Separates internal drafting from customer impact |
| Vendor and model | Supplier, service, model where known | Links the row to vendor due diligence |
| Training use | Does your data train their models | The term most likely to change without notice |
| Hosting and retention | Processing region, retention period | Answers transfer and deletion questions |
| Human review | Who checks output, before or after use | The single biggest control on the row |
| Autonomy and volume | Outputs per week, how far they travel unreviewed | Turns a modest score into a real priority |
| Risk tier | Tier 1–4 from the scale below | Decides who has to approve it |
| Discovery source | How this row was found | Tells you which method to repeat |
| Status | Discovered, review, approved, migrating, retired | Stops the register becoming a graveyard |
| Review date and triggers | Next review, what invalidates it early | Keeps the row honest between reviews |
| Exit route | How to switch it off, who can, what breaks | Converts a description into a control |
How to Find Shadow AI: Seven Discovery Methods for Your AI System Inventory
No single method finds everything, and the two cheapest ones find the most. Run them in this order — the automated pulls first, so the survey can ask better questions.
1. Expense, card and invoice data
Search the last twelve months of card statements and accounts payable for the obvious vendor names and for small recurring charges under your approval threshold. Individual AI subscriptions are deliberately priced below the level that triggers procurement, which is exactly why they hide there.
2. Identity provider and SSO sign-in logs
Your identity provider knows every service anybody signed into with a work account, including the free ones. Export the application list, filter for anything added in the last two years, and read it with fresh eyes. This is the highest-yield hour in the entire exercise.
3. OAuth grants and third-party app consents
Separately from sign-in, look at what staff have granted access to their mailbox, calendar and files. An AI assistant with permanent read access to a mailbox is a materially different risk from one somebody logs into occasionally, and only the grant list shows you the difference.
4. Network, DNS and egress logs
Filter outbound traffic for known AI service domains and for unfamiliar high-volume destinations. This catches tools nobody signed into with a corporate identity. It stops at the network edge, so it finds nothing on personal devices — a limitation to state openly rather than work around.
5. Endpoint and browser extension inventory
Your device management platform can list installed browser extensions and IDE plugins. Most organisations have never pulled that report. When they do, the extension count is the number that surprises people most.
6. The amnesty survey
Ask every team what they use, promise explicitly that nothing disclosed will be held against anybody, and give them a two-minute form rather than a policy document. Name the tools you already know about so the question feels safe to answer honestly.
7. Supplier and contract review
Ask your material suppliers a single written question: does any AI process our data in delivering this service, and if so, which and where? File the answers — and the non-answers, which are themselves findings — against the relevant rows of your AI system inventory.
| Method | What it finds | Effort | Blind spot |
|---|---|---|---|
| Expense and card data | Paid subscriptions below threshold | 2–3 hours | Everything free |
| Identity provider logs | Anything signed into with a work account | 1 hour | Personal-email signups |
| OAuth grant review | Standing access to mail, files, calendar | 1–2 hours | Non-integrated web tools |
| Network and DNS logs | Traffic to AI services from the estate | Half a day | Personal and remote devices |
| Endpoint extension report | Browser extensions, IDE plugins | 2 hours | Unmanaged devices |
| Amnesty survey | Personal accounts, intent, workarounds | 1–2 weeks elapsed | Whatever people forget |
| Supplier questionnaire | AI embedded in services you buy | 2–4 weeks elapsed | Sub-processors two tiers down |
The pattern is consistent: telemetry is fast and incomplete, people are slow and comprehensive. Run both, and treat any tool that appears in only one of them as the most interesting row in your AI system inventory.
Running the AI System Inventory Sweep: A Two-Week Plan
Two weeks is enough for a first-pass register covering a few hundred staff. Longer than that and the exercise loses its sponsor.
Days 1 to 2: pull everything you already have
Export the identity provider application list, the OAuth grants, twelve months of card data and the endpoint extension report. Do not analyse yet — collect. Four exports, one folder, one afternoon.
Days 3 to 5: launch the amnesty
Send the survey with a named sponsor, an explicit no-blame statement and a closing date. Seed it with the tools your exports already revealed, so the first question staff see is recognisably honest rather than a trap.
Days 6 to 8: reconcile into one AI system inventory
Deduplicate by use case, not by product name. One tool used three ways is three rows; the same tool named differently by two teams is one. This reconciliation is where the AI system inventory actually gets built, and it is slower than everyone estimates.
Days 9 to 10: triage, and report the shape
Score every row, then report the distribution rather than the list. Leadership needs to know how many high-tier systems exist and who owns them — not the name of every summarising tool in the marketing team.
Scoring and Triaging What the AI System Inventory Finds
A register with three hundred unranked rows is a list, not a control. Triage turns it into a work queue, and it needs to be crude enough that one person can apply it consistently in an afternoon.
The four-question screen
For each row, ask: does personal or confidential data reach it; does output reach anyone outside the organisation without review; does it influence a decision about someone’s money, job or access; and could nobody notice if it were wrong? Each yes moves the row up a tier.
Tier the AI system inventory by data sensitivity and autonomy
Autonomy is the factor generic risk scoring misses. The same flawed model behaves very differently at ten reviewed outputs a week and ten thousand unreviewed ones. Score volume and reach alongside sensitivity, or your AI system inventory will rank a chatty pilot above a silent automation.
Set escalation thresholds before you score
Decide in advance which tier requires which approval. Doing it afterwards invites the tier to be negotiated down to match the approval somebody already wanted.
| Tier | Typical profile | Action | Approval |
|---|---|---|---|
| 1 – Minimal | Internal drafting on data the author already holds | Record and move on | Use case owner |
| 2 – Moderate | Confidential data in, reviewed output | Confirm terms and retention | Department head |
| 3 – Elevated | Personal data, or unreviewed external output | Full risk assessment | IT and data protection lead |
| 4 – High | Automated decisions on people, or safety relevance | Assess, control, or stop | Board or equivalent |
From AI System Inventory to Governance: Approve, Migrate, Retire
Discovery without a decision is surveillance. Every row leaves triage with one of three outcomes and a date, and the register records which.
Approve, with the conditions written down
Most rows are fine. Say so explicitly, record the conditions — reviewed output, no client data, this owner — and set a review date. An approved row with conditions is a far better outcome than an unanswered one.
Migrate to a sanctioned equivalent
Where you already pay for a capability somebody is using elsewhere for free, migration is the cheapest fix available. It removes the risk without removing the benefit, which is the only kind of control people cooperate with.
Retire, and say why
Some rows should stop. Explain the reason in one sentence, offer the alternative, and confirm the account is closed and the data deleted. A retirement with no replacement and no explanation is how the next generation of shadow AI gets created.
Never punish the disclosure
The organisations that end up with an accurate register are the ones where volunteering a tool produced help rather than a disciplinary conversation. This is a cultural control and it outperforms every technical one you can buy.
Keeping the AI System Inventory Current
A register is accurate on the day it is finished and decays from there. Three habits keep it alive without a standing committee.
Attach the AI system inventory to processes that already run
Add one line to procurement: does this involve AI, and who owns it? Add one line to the joiners, movers and leavers checklist. Reuse the supplier cyber-risk assessment checklist you already run rather than inventing a parallel AI questionnaire.
Re-run the cheap pulls quarterly
The identity provider export, the OAuth grants and the extension report take three hours between them. Quarterly is frequent enough to catch drift and rare enough that somebody actually does it.
Write down what invalidates a row
A model version change, a new data source, removal of human review, a supplier acquisition or a change in terms — any of these makes the entry stale regardless of the review date. The terms change is the one nobody notices, and it is the one that most often moves a row up a tier.
Mapping the AI System Inventory to ISO 42001, NIST AI RMF and the EU AI Act
The same register satisfies the first requirement of all three frameworks, provided you record a handful of extra fields while you are already there.
ISO/IEC 42001
Clause-level scoping and the Annex A controls both assume a defined set of AI systems with owners and lifecycle status. Your status and owner fields are doing that work already.
NIST AI RMF
The Map function is context and inventory: what the system is for, who it affects, what data it uses. If you complete blocks 1 and 2 of the template properly, most of Map is documented as a by-product.
The EU AI Act
Classification is by risk and by role — provider or deployer. Add two fields to the register and you can answer both, which is considerably cheaper than reconstructing the answer under time pressure later.
| Framework expectation | Field that satisfies it | Extra field to add |
|---|---|---|
| ISO 42001 – scope of the AI management system | Status, business unit | In scope yes or no |
| ISO 42001 – roles and responsibilities | Accountable owner | None |
| NIST AI RMF – Map | Use case, data in and out, audience | Affected groups |
| NIST AI RMF – Measure | Human review, residual score | Evaluation evidence link |
| EU AI Act – risk classification | Risk tier, decision impact | Act risk category |
| EU AI Act – provider or deployer role | Vendor and model | Our role for this system |
Two extra columns and a risk category are the entire compliance delta. That is the argument for building the register before anyone asks for a certificate, rather than during the audit that requires one — a point worth making when the ISO 42001 implementation conversation starts.
AI System Inventory Mistakes That Waste the Exercise
Five failure modes account for almost every abandoned register. All of them are cheap to avoid at the start and expensive to correct later.
Filling the AI system inventory with products instead of use cases
“We have Copilot” is not a row. Drafting internal notes and drafting customer contract summaries are two use cases with different data, different review and different exposure, and collapsing them hides the one that matters.
Building the AI system inventory where nobody owns it
A spreadsheet in one person’s drive dies when that person changes role. Put the register somewhere with an owner, version history and access for the people who need to update it.
Treating discovery as a one-off project
Adoption did not stop when your sweep finished. Without the quarterly pulls, an accurate register is out of date within two quarters and misleading within three, which is worse than not having one.
Turning the AI system inventory into a blocklist
The moment staff believe that declaring a tool gets it banned, disclosure stops and the shadow estate grows back invisibly. Approve generously and control narrowly; the register’s value is accuracy, not restriction.
Recording discovery but never a decision
Rows that sit at status “discovered” for six months tell you the exercise had no teeth. Every row needs an outcome and a date, even if the outcome is simply “approved, low risk, review in twelve months”.
Frequently Asked Questions About AI System Inventory
How long does a first AI system inventory take?
About two weeks of elapsed time and three to five days of actual effort for a few hundred staff, most of it spent reconciling duplicates rather than discovering tools. Larger or more federated organisations should run it business unit by business unit instead of attempting one sweep.
Do we need a dedicated tool for this?
No. A well-structured spreadsheet or a table in your existing service management platform handles the first two hundred rows comfortably. Buy tooling when the manual reconciliation becomes the bottleneck, which for most mid-sized organisations is later than vendors suggest.
Should the register include AI features inside products we already pay for?
Yes, and they are usually the largest category. The fact that no separate purchase occurred does not change the data flow, and these entries are the ones auditors and clients ask about most often.
What if a team refuses to disclose what they use?
Treat it as a finding rather than a confrontation. Record the gap, note the reason, and cover the team with telemetry-based discovery instead. Persistent refusal is itself a governance issue and belongs in front of whoever owns the relationship.
How does this relate to our risk register?
Directly. The AI system inventory holds one row per use case; the residual scores from tier 3 and tier 4 rows are what belong in your cybersecurity risk register. Keeping them separate stops the risk register filling with low-tier drafting tools.
Who should own the register in a small business?
Whoever owns IT decisions, with a named deputy. It does not need a governance function to be credible. What it needs is one person who keeps the index, chases review dates and runs the quarterly pulls, because these registers fail through drift rather than bad judgement.
Can any of the discovery be automated?
The telemetry can, and should — identity, OAuth, network and endpoint pulls all script cleanly and can run to a schedule. The reconciliation into use cases cannot, because deciding whether two entries are the same use case is a judgement call about how the work is actually done.
References
NIST AI Risk Management Framework
ISO/IEC 42001:2023 Artificial Intelligence Management System
European Commission: Regulatory Framework for Artificial Intelligence
Regulation (EU) 2024/1689 Artificial Intelligence Act
ICO Guidance on AI and Data Protection
NCSC Guidelines for Secure AI System Development
NCSC Asset Management Collection
OWASP Top 10 for Large Language Model Applications
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.
