Building an AI inventory you can actually trust
Ask any organisation how many AI systems it uses and the answer will be wrong, usually by a large multiple, and usually in the direction of undercounting. This is not carelessness. AI arrived in most companies as features inside software bought for other reasons, purchased by teams who were not buying AI and would not describe it that way. An inventory built by asking people what AI they use finds the projects and misses the estate, which is why the first honest inventory is always uncomfortable.
Why can't most organisations list their AI?
Because most of it was never procured as AI. A recruitment platform added candidate ranking, a service desk tool added ticket classification, a marketing suite added copy generation and a security product added anomaly scoring, and in each case the buyer signed a renewal for a product they already had. No procurement process was triggered, no architecture review happened, and nothing about the purchase record indicates that the organisation now operates an AI system.
The second cause is definitional. Ask a team whether they use AI and you get answers filtered through whatever they think the word means. Some will say no while running a statistical scoring model that has decided things about customers for years. Others will say yes because they used a chatbot once. Any inventory built on self-identification inherits that noise.
The third is that individual use leaves no trace in any system a governance team looks at. Someone pasting customer records into a consumer AI tool through a browser generates no purchase order, no contract and no ticket. It is the category that generates the most data protection exposure per unit of usage and the least visibility, and it will not appear in an inventory built from procurement records alone.
What counts as AI for the inventory?
Use a functional definition and accept that it will over-include. The EU AI Act defines an AI system as a machine-based system that operates with varying levels of autonomy, may adapt after deployment, and infers from its input how to generate outputs such as predictions, content, recommendations or decisions that influence real or virtual environments. That is deliberately broad, and it is a better inventory boundary than any technical one because it tracks effect rather than method.
For practical purposes, run a second and simpler screen alongside it: does this thing produce an output that a person or a process acts on, without a human having specified the rule that produced it. That catches machine learning, statistical scoring and generative tools, and it usefully catches the borderline cases that matter, such as an optimisation engine that allocates shifts.
Then include the systems that do not meet either definition but carry identical risk, and mark them as such. A hard-coded rule set that screens job applicants creates the same legal exposure as a model doing the same job, and excluding it because it is not technically AI produces a governance regime that can be evaded by writing simpler software. Scope by consequence and the boundary stops moving every time the technology does.
Where do you actually find them?
Six sources, and none of them is sufficient alone. Running two or three in parallel finds most of the estate in a couple of weeks; running the survey alone finds perhaps the projects and none of the features. The general rule is that self-reported sources find things people are proud of and technical sources find things people forgot.
| Source | Finds | Misses | Effort |
|---|---|---|---|
| Accounts payable and procurement records | Paid vendors, including features inside renewals, with owner and spend attached | Free tools, trials, anything on a personal card | Low, one export and a read-through |
| Identity provider application list | Every SaaS application anyone has signed into with a work account | Tools used without single sign-on, and features inside approved apps | Low |
| Network egress or proxy logs | Traffic to model provider endpoints, including from tools nobody declared | Anything on unmanaged devices or personal networks | Medium, needs a security team |
| Code repository search | Model SDK imports, API keys, calls to inference endpoints in your own software | AI reached through a third-party product rather than directly | Low if you can grep the estate |
| Vendor release notes and contract review | AI features added to products you already own, and changed data terms | Anything the vendor did not announce | Medium and ongoing |
| Structured survey of team leads | Purpose, ownership and context that no log can supply | Anything the respondent does not think of as AI | Medium, and best run last |
What does an inventory entry need?
Twelve fields, and resisting the urge to add more is what keeps the inventory alive. What it is in one sentence a non-specialist understands. The business owner, by name, not by team. The technical owner. Whether it affects people, and if so how: a decision, a recommendation to a decision-maker, or content shown to them. The supplier and the model or product version. What data is sent to it. Where that data goes, including region and any subprocessors. The risk tier and the date it was assigned. A link to the evidence supporting that tier. The review trigger. The date the entry was last verified. And whether it is still in use.
The last field is the one everybody omits and the one that determines whether the inventory is trustworthy after a year. Systems get quietly retired, replaced or left running with nobody using them, and an inventory that only ever grows becomes a list of things that used to be true.
Notice what is not on the list: architecture, accuracy figures, detailed data flows, model documentation. Those belong in the record for the system, linked from the inventory. An inventory that tries to hold everything becomes a document maintained by one person until they leave.
How do you stop it decaying?
By attaching updates to events that already happen rather than to a review cycle nobody owns. Three hooks cover most of it. New supplier onboarding asks a single mandatory question about whether the product processes data using AI, with the answer routed to the inventory. Contract renewal triggers a check of whether the product's AI features or data terms changed since last time. And any change deployed to a system already on the inventory updates its entry as part of the change, not afterwards.
The fourth hook is the one that catches individual use, and it is cultural rather than technical: a route for someone to declare a tool they want to use that is faster than the route to use it undeclared. If registering a tool takes two weeks and using it quietly takes two minutes, the inventory will always be behind, and no amount of policy changes that arithmetic. Make the declared route same-day for low-risk tools and the shadow estate shrinks on its own.
Set an expiry on entries rather than a review date. An entry unverified for twelve months is marked stale automatically and its owner is asked one question: is this still running. That produces a list where the freshness of every entry is visible, which is far more useful than a list that claims uniform accuracy it does not have.
What does the first pass actually get you?
Three findings, and they are consistent enough to predict. You will find AI systems affecting people that nobody classified, usually in recruitment, customer service triage or fraud and risk scoring. You will find data leaving the organisation under terms nobody read, typically a default in a product where content submitted may be used for service improvement. And you will find at least one system whose owner has left, which is the entry that should worry you most because nobody is watching it and nobody will notice if it degrades.
You will also find duplication, which is the finding that pays for the exercise. Multiple teams commonly hold separate subscriptions to overlapping tools, and consolidating them tends to recover more than the inventory cost while reducing the number of places your data sits.
A reasonable first pass is two weeks: pull the payments export and the identity provider list, run a repository search, cross-reference them, and interview the owners of anything that touches people. Do not attempt to classify everything at once. Sort into three buckets, being systems affecting people, systems handling confidential data, and everything else, and put real effort only into the first two.
Common questions
- What is an AI inventory?
- A maintained list of the AI systems an organisation uses, with a named owner, a stated purpose, the data involved, the risk classification and the evidence behind it for each entry. It is the prerequisite for every other governance activity, because controls, testing and incident response all attach to specific systems and cannot be applied to systems nobody has recorded.
- Why don't organisations know what AI they are using?
- Because most AI arrived as features inside software bought for other purposes, so no procurement or architecture review was triggered and nothing in the purchase record identifies it. Self-identification compounds the problem, since teams filter the question through their own idea of what counts as AI. Individual use through a browser leaves no procurement trace at all, and generates high exposure with almost no visibility.
- How do you discover shadow AI in an organisation?
- Combine sources rather than relying on a survey. Accounts payable records reveal paid vendors and features inside renewals. The identity provider application list reveals every SaaS tool anyone signed into with a work account. Network or proxy logs reveal traffic to model provider endpoints. A code repository search reveals model SDK imports and inference calls in your own software. Surveys are useful last, for purpose and ownership that logs cannot supply.
- What fields should an AI inventory record contain?
- A plain-language description, the named business owner, the technical owner, whether and how it affects people, the supplier and version, what data is sent to it, where that data goes including region and subprocessors, the risk tier with the date assigned, a link to supporting evidence, the review trigger, the date last verified and whether it is still in use. That final field is the one most often omitted and the one that keeps the list honest.
- Should rule-based systems be in an AI inventory?
- Yes, where they carry the same consequences. A hard-coded rule set that screens job applicants creates the same legal exposure as a model doing the same work, and excluding it because it is not technically AI produces a governance regime avoidable by writing simpler software. Scoping the inventory by what a system decides or influences about people, rather than by the technique it uses, keeps the boundary stable.
- How do you keep an AI inventory up to date?
- Attach updates to events that already happen: supplier onboarding asks whether the product uses AI, contract renewal checks whether features or data terms changed, and any deployment to a listed system updates its entry as part of the change. Add an expiry so entries unverified for a year are marked stale automatically. And make the route to declare a tool faster than the route to use it undeclared, or the shadow estate will keep growing.
