How to Keep an Inventory of the AI in Your Company

Why the list comes before everything else

Every other AI control assumes an inventory. A usage policy has to say which tools are approved. A risk assessment has to know what is being assessed. A customer security questionnaire asks which subprocessors see their data. An incident needs a way to find every other system running the same model or prompt. Without a list, each of those is answered by asking around, and the answer is as good as whoever happened to be asked.

It is also the control that surfaces the problem nobody has scoped: the gap between what leadership believes is in use and what is actually running. That gap is almost always wider than expected, and it is not usually made of rule-breaking. It is made of features that arrived switched on.

Decide what counts before you start counting

Without a definition, the exercise either collects only the obvious chat tools or expands until it includes every product with a recommendation engine. A workable scope is anything where a model generates content, makes or materially influences a decision, or processes your data on a provider's infrastructure. That captures assistants, features built on an API, agents, and AI capability inside products you bought for other reasons.

Write the boundary down and note what you deliberately excluded, because the first challenge to the inventory will be someone arguing that their system does not qualify. A stated scope makes that a five-minute conversation instead of a debate, and it makes the count comparable when you repeat the exercise next quarter.

Find what is already running

AI use rarely arrives through procurement, so procurement records will not find it. Expense reports and corporate cards surface personal subscriptions. Identity and SSO logs show which services people sign into. Network egress to known provider domains catches both sanctioned integrations and ones nobody mentioned. A dependency scan across your repositories finds provider SDKs, and a search for API-key patterns in configuration finds the rest.

None of these is complete alone and together they still miss the largest category: AI features inside tools you already own, which appear in a release note rather than in any log you keep. Those need a pass through your existing vendor list, asking of each one whether it has shipped AI capability and whether it is enabled on your tenant. That question is worth putting into renewal conversations permanently.

Record the fields that make an entry useful

A name and an owner is not enough to act on. For each system record what it does, who owns it, which model and provider it uses, what data it can see, whether it faces customers or only staff, whether its output is acted on automatically or reviewed by a person, where the provider processes the data, and what the retention terms are.

Then add the field that keeps the whole thing honest: when the entry was last confirmed. Without it, a row written eighteen months ago is indistinguishable from one verified last week, and a reader has no way to know which parts of the list to trust. A visible confirmation date also makes staleness a fact rather than a suspicion.

Put it where your other records live

An inventory in a standalone spreadsheet decays because nothing else in the organisation points at it. Put the entries in whatever already holds your systems of record — a service catalogue, a CMDB, an asset register — so that an AI system is a system with extra attributes rather than an entry in a parallel universe maintained by one person who eventually changes role.

Make it a step in the paths that create AI use

Maintenance fails when updating the inventory is somebody's separate task. It works when it is a required field in the flows that introduce AI in the first place: procurement approval, architecture or design review, and the pull request that adds a provider SDK or a new retrieval source. Each of those already has a gate, and adding one question to an existing gate costs far less than running a discovery exercise twice a year.

Assume it decays and plan for that

The hardest part is not the first pass, it is the second year. Vendors add AI to existing products continuously, so a tool assessed as AI-free can gain a model-backed feature in a routine release with no purchase decision on your side and no signal to you. Systems are also retired without anyone telling the inventory, which is the less alarming failure but the one that erodes trust in the list fastest.

Set a review cadence weighted by risk rather than reviewing everything at once: the systems that touch customers, make decisions or see regulated data get confirmed often, the rest annually. Watch the ratio of entries created through the gates against entries found by discovery — when discovery keeps finding things the gates missed, the gates are in the wrong place, and that is more useful to know than the count itself.