What is an AI inventory?

A maintained register of every AI system your organisation builds, buys or embeds, recorded by use case rather than by model. Each entry describes what the system decides or produces, who is affected, what data it consumes, who owns it internally, and what risk tier it falls into. It is the artefact that every other AI governance obligation refers back to.

Why is the inventory the first thing an auditor asks for?

Because every downstream obligation is scoped by it. Risk classification, impact assessments, disclosure duties, human oversight, monitoring and vendor diligence all apply per system, so none of them can be evidenced until the population of systems is defined. An organisation that cannot produce the list cannot demonstrate that any control covers everything it should.

Should we inventory models or use cases?

Use cases. The same general-purpose model can be low risk in a drafting assistant and consequential in a screening workflow, and the obligations attach to the consequence, not the weights. Inventorying by model produces a short list that hides all the risk; inventorying by use case produces a longer list that is actually decision-useful.

What is shadow AI and why does it break the register?

Shadow AI is any AI use that entered through a corporate card, a free tier, or a feature toggle in software you already own, without passing procurement. It breaks the inventory because the register only ever contains what someone chose to declare, while the exposure is created by what nobody declared. Discovery has to come from expense data, network and SSO logs and vendor release notes, not from a survey.

How often does the inventory need reviewing?

Continuously at the entry point and at least annually in full. A register refreshed once a year is roughly a year out of date at its worst moment, and the entries that changed silently — a vendor adding an AI feature to an existing product — are exactly the ones that matter. The realistic pattern is an intake gate that creates entries, plus a scheduled review that re-validates them.

Do we need a tool for this?

Not at first. Below a few dozen use cases a well-structured shared sheet with an owner and a change log is adequate, and it is what most organisations at this size can actually maintain. Buy tooling when the failure is volume or evidence collection, not when the failure is that nobody has been made responsible for the register.

AI Inventory Requirements 2026: The Register Every Framework Asks For First

Why the List Is Load-Bearing

Compliance obligations in this space are almost all per-system. A duty to assess impact applies to a system. A duty to disclose applies to an interaction. A duty to keep a human in the loop applies to a decision. None of them can be evidenced in the abstract — the question is always "for which systems, and how do you know that is all of them."

That structure makes the inventory unusually consequential for a document that looks like housekeeping. If it is wrong, nothing built on top of it is reliable. An impact assessment programme covering nine of your fourteen consequential systems is not seventy percent compliant; it is an organisation that does not know how many systems it has, which is a finding on its own.

It is also the cheapest artefact to produce and the one most often deferred, because it produces no visible improvement on the day it is finished. The value arrives later, all at once, when someone external asks a question that can only be answered from it.

What a Compliance-Grade Entry Contains

A list of tool names is not an inventory. The register has to support the decisions that hang off it, which means each entry needs enough to classify risk without reopening the investigation:

Use case, stated as an outcome. Not "GPT integration" but "ranks inbound applicants for recruiter review." The sentence should make the risk obvious to a reader who knows nothing about the stack.
Who is affected. Employees, applicants, customers, the general public, or nobody outside the team. This field does more work in classification than any other.
Decision role. Does the system inform a human, substantially influence a decision, or decide autonomously? The middle case is the one organisations consistently under-record, and the one regulators are most interested in.
Data in and data out. Categories, not schemas. Flag personal data, special categories, biometric and children's data explicitly, because those flags change which regimes apply.
Provider and deployment mode. Built in-house, hosted API, embedded feature of a purchased product, or open weights self-hosted. Vendor obligations differ by mode.
Named accountable owner. A person, not a team inbox. Unowned entries are how registers rot.
Risk tier and the reasoning. Record why the tier was chosen. A conclusion without reasoning cannot be defended or revisited when the use case shifts.
Linked artefacts. Assessment, disclosure copy, oversight procedure, vendor terms, monitoring dashboard. The register becomes the index to the evidence, which is what makes an audit tractable.
Status and dates. Piloting, live, deprecated; first deployed, last reviewed. Deprecated entries stay in the register — a decommissioned system that made decisions last year is still in scope for claims about last year.

Shadow AI Is the Whole Difficulty

Ask every department to list the AI they use and you will get an honest, badly incomplete answer. Not because people conceal it, but because the category boundary is invisible from the inside. The support lead who turned on an AI reply-suggestion toggle in an existing helpdesk product does not experience that as adopting an AI system. The recruiter using a scoring feature that appeared in this quarter's release of the ATS does not either.

So discovery cannot be survey-first. The sources that actually find things:

Expense and card data. Every recurring charge under a few hundred a month, checked against the register. This finds more than any questionnaire.
SSO and identity logs. Applications people have signed into with a work account, whether or not anyone approved them.
Existing vendor release notes. The highest-risk additions arrive inside software you already bought and already trust. Nobody procures these; they simply appear.
Browser extension and integration audits. Anything with access to a mailbox, a CRM or a document store deserves an entry.
Your own codebase. API keys and SDK imports are a definitive list of what engineering integrated, including experiments that shipped quietly.

Run this once and the register roughly doubles. That is the normal result, and it is the point of doing it.

Classification Is a Decision, Not a Lookup

Risk tiering fails when it is treated as a table lookup. The same recommendation engine is unremarkable suggesting related articles and consequential deciding which candidates a recruiter ever sees. What determines the tier is the consequence to the affected person and how hard that consequence is to reverse — not the technique.

A workable three-question test for a small team: Does the output affect someone's access to employment, credit, housing, education, healthcare or an essential service? Would a wrong output be hard for that person to detect or contest? Is a human genuinely able to override, with the time and information to do it? Two uncomfortable answers move an entry up a tier regardless of how simple the model is.

Keeping It Alive

Most registers are accurate for about six weeks. The fix is not discipline; it is putting the register somewhere in a path people already walk. Practical hooks:

Make it a gate in procurement. No new software purchase completes without an AI question answered and, if yes, an entry created.
Add a line to the change process. Any release that adds a model call, changes what a model decides, or expands who it affects, updates the entry. One checkbox, reviewed like any other.
Attach re-review to renewal. Vendor renewal dates are already tracked and already forced. Re-validating the entry then costs nothing extra.
Give it one owner. Not a committee. Somebody whose name is on the accuracy of the list.
Keep history. What changed, when and why. In any dispute, the question is what the system did at the time, and a register that only shows the present cannot answer it.

The Commercial Reason to Do It Now

Set the regulators aside for a moment. Enterprise security questionnaires have already added AI sections, and one of the first items is a request to describe the AI systems involved in delivering the service, including subprocessors. Teams without a register answer that from memory, in a hurry, in a document that becomes a contractual representation. Teams with one answer it by export.

That is the honest business case. The compliance value is real but deferred; the sales value shows up on the next deal that goes through a procurement review.

Common Questions

Does a two-person company need an AI inventory?

It needs the list, not the ceremony. Ten lines in a shared document naming each use case, who it affects and which vendor sits behind it will answer nearly every question you get asked at that size. The formality should scale with the consequence of the decisions, not with headcount.

Do internal-only tools count?

Yes, and employee-facing systems are frequently the higher-risk half of the register. Anything touching hiring, scheduling, performance, monitoring or termination affects people who did not choose to be subject to it, which is precisely the pattern the accountability laws target.

Where do embedded vendor features go?

Their own entry, with the parent product named as provider. Bundling them into one line for the vendor hides the fact that obligations attach to each use, and it is the reason release-note-driven features go ungoverned for years.

How granular is too granular?

Split when the risk answer differs. If two uses of the same model affect different populations, produce different consequences, or would receive different tiers, they are two entries. If they would be classified identically, one entry with a note is enough.

Should the inventory be public?

Generally no, though a summary can be a strong trust signal on a public page, and public bodies increasingly publish one by obligation. The working register contains vendor and architecture detail that belongs behind a diligence process, not on the website.

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

Record it, tier it, and fix it on a dated plan. Deliberately leaving a known system off the register to avoid documenting the gap converts a compliance shortfall into something much worse, because the omission is itself evidence.

Your Public Pages Are Part of the Record

What your site says about AI features, data handling and human review is read as your stated position — by enterprise buyers, by anyone assessing you, and increasingly by AI assistants summarising you to a prospect before a human ever visits.

Run a free scan of your site to see what is currently published about how you use AI.