How to build an AI inventory

Every AI governance conversation opens with the same question, whether it comes from an auditor, a customer or a board member: what AI are you running? Most organisations cannot answer it, and the ones that think they can are usually describing the official list rather than the real one.

This is the unglamorous foundation. Risk classification, oversight design, policy and certification all depend on it, and none of them can start until it exists. The good news is that a useful first version takes days rather than months.

The real list is bigger than the official one

If you ask the technology function what AI the organisation uses, you will get a list of the deliberate projects: the pilot, the vendor platform, maybe a model somebody built internally. That list is real but incomplete, often badly.

The gap is everything that arrived without a procurement decision. AI features switched on inside software you already pay for. Assistants bundled into the office suite. Summarisation in the service desk tool. Scoring inside a recruitment or finance platform. Browser extensions somebody installed because it saved them an hour a week.

If it drafts a customer response, scores an application or influences a decision, it belongs on the list, whether or not anyone bought it as AI.

That framing is the useful one. The question is not "did we procure an AI system?" but "is a machine judgement affecting an outcome here?" Answering the second question honestly produces a noticeably longer list, which is uncomfortable the first time and exactly the point.

What to record

Resist the temptation to design an elaborate register. A long template guarantees the inventory is filled in once and never maintained. These fields are enough to support real decisions.

• What it is and what it does. One sentence in plain language. If it takes a paragraph, you do not understand it well enough yet.
• Named owner. A person, not a team. This single field does more work than any other, because it converts a general concern into somebody's actual responsibility.
• What data it touches. Particularly whether it sees personal data, commercially sensitive material or anything safety related.
• What it is allowed to decide alone. Define the autonomous envelope positively. Most registers only record what needs review, leaving everything else ambiguous by default.
• Where the human checkpoint is. If there is one, where does it sit and is the approval recorded anywhere? "Someone reads it" is not a checkpoint.
• Who supplies it. Including which underlying model, if you can establish that. Increasingly you are governing somebody else's system.
• Risk rating. Three bands is plenty. More precision than that is false precision.

How to actually find things

A survey asking "do you use AI?" will under-report, partly because people forget and partly because some will worry they are confessing to something. A few approaches work better in combination.

• Start from spend. Go through software subscriptions and expenses. AI tooling is often bought on a card by a team, below any procurement threshold.
• Ask about tasks, not tools. "What in your week is now done or drafted by software that was not two years ago?" gets far better answers than asking whether people use AI.
• Read your vendors' release notes. Much of your AI exposure arrived as a feature in a product you already had, switched on by default and announced in a changelog nobody read.
• Check the identity logs. Sign-in and OAuth consent records show which third party applications have been connected to your tenant and what they were granted access to.

Run this as a stocktake rather than an investigation. If people think the exercise is about catching them out, the list gets shorter and less accurate, which is the opposite of what you need.

Rating risk without over-engineering it

Two questions get you most of the way, and both are about consequence rather than technology.

First, what happens if it is wrong? A system that drafts internal meeting notes and a system that screens job applicants may use identical technology and sit in completely different risk bands. The model does not determine the rating. The consequence does.

Second, can a person catch it before it matters? A wrong output that a human reviews before anything happens is a different proposition from one that updates a record automatically. If the answer is no, that system needs attention regardless of how impressive its accuracy numbers look.

High risk means consequential and lightly supervised. That is where your effort goes. Everything else gets recorded and reviewed periodically, which is proportionate.

Keeping it current

Most inventories are accurate for about a month. The initial push happens, the spreadsheet is circulated, and then AI keeps arriving while the document does not keep up.

Two habits prevent the decay, and neither needs a tool.

• Attach it to something that already happens. Add an AI question to whatever change or procurement process you already run. A question inside an existing workflow survives. A separate process that depends on people remembering does not.
• Review on a fixed cadence with a named owner. Quarterly is usually right. Put it in a diary, give it to a person and keep it short.

A modest inventory that is genuinely current beats an elaborate one that was accurate last March. Auditors can tell the difference immediately, and so can anyone trying to make a decision with it.

What it unlocks

Once the inventory exists, the questions that previously felt unanswerable become ordinary. Which systems need oversight design. Where certification effort should land. Whether anything falls into scope of a particular regulation. What to say in a customer questionnaire without guessing.

It is also the thing most organisations skip, because it is administrative and produces no demo. That is precisely why having one is such a clear signal that AI is being managed rather than improvised.