Every AI governance framework begins with an inventory, and every published template starts from the same wrong assumption: that you can build one from the systems your organisation bought.
You cannot, because that is not how most AI arrived. It arrived when a caseworker opened a chatbot in a browser, when a vendor added a summarisation feature to software you had licensed for years, when a team wired an API into an internal tool over a weekend, and when someone pasted a spreadsheet into a free tool to reformat it.
None of that is in your contract list. Some of it is the highest-risk AI use in the organisation, precisely because nobody assessed it.
Amnesty first
The obstacle is not technical. It is that people will not tell you what they are using if telling you is an admission of wrongdoing.
If your first communication about AI is a policy with prohibitions, you will get a tidy inventory that is wrong, and use will continue where you cannot see it. That is a worse position than before you started, because now you have documentation asserting it does not happen.
So the sequence is amnesty, then inventory, then policy — in that order. Say plainly: we need to know what is being used, nobody is in trouble for having answered a work question with a tool, and we are asking so we can support it rather than stop it. You will learn more in a fortnight than an audit surfaces in a quarter.
This only works if it is true. If the amnesty is followed by disciplinary action, you have spent your credibility and will not get it back.
Ask about work, not about tools
The second reason inventories come back thin: people do not classify what they are using as AI.
Someone using a transcription service, an email tool that drafts replies, or a spreadsheet feature that predicts a column will answer "no" when asked whether they use AI. They are not being evasive — the question genuinely does not match their mental model of the tool.
Better questions:
- What repetitive part of your work has got faster in the last year, and what made it faster?
- Is there anything that drafts, summarises, translates, transcribes, ranks, scores or predicts for you?
- Has any system you already use added a feature that suggests or generates something?
- Is there anything you use for work that you signed up for yourself?
That last one surfaces the personal-account use that matters most, and it needs the amnesty to have been genuine.
Record few fields
The most common inventory failure is over-specification. A forty-field register is completed once, becomes stale within a quarter, and is quietly abandoned while still being cited in governance papers.
Ten fields is enough to be useful:
| Field | Why it earns its place |
|---|---|
| Name and what it does | In plain language, not the vendor's positioning. |
| Who uses it | Team or function. |
| Owner | A named person. Not a team. |
| Built or bought | Nearly every statute splits duties along this line. |
| Underlying model, if known | Matters when an upstream provider changes. |
| Data it touches | Personal, confidential, or neither. |
| Consequential decision? | Yes/no. The field that drives everything else. |
| Human review | What it actually consists of, not that it exists. |
| How it got here | Procured, added to existing software, or self-adopted. |
| Last reviewed | Without this the list cannot be trusted. |
Anything else can be attached to the entries that turn out to matter. Do not collect model cards for a meeting-notes summariser.
Classify by decision, not by technology
The useful question is not "does this use machine learning?" but "does this system take part in a decision that materially affects someone?" — employment, credit, housing, benefits, enforcement, pricing, access to services.
Two reasons this framing is better. It catches simple systems that matter: a scoring rule or a threshold model can carry real consequences without anyone calling it AI. And it matches how regulation is drafted — Colorado's replacement act regulates automated decision-making technology in consequential decisions, and US federal guidance tiers obligations around high-impact AI. Classifying by technology means re-doing the work when a statute arrives.
Three tiers is usually enough: takes part in consequential decisions; touches confidential or personal data but decides nothing; neither.
Keeping it true
This is the part that fails, and it fails quietly. An inventory decays from the moment it is complete, and a stale inventory is worse than none, because it is cited as though current.
Four mechanisms, in order of effectiveness:
- Attach it to something that already happens. A question in the procurement form, in the vendor renewal check, in the new-starter and leaver processes. Inventory maintenance that depends on someone remembering will not happen.
- Give every entry a review date, and let the dates fall due on a rolling basis rather than in one annual scramble.
- Make adding an entry trivially easy. If reporting a new tool takes a form and an approval, people will not do it. A single message to a named person is enough at the start.
- Re-run a light amnesty annually. Not an audit. A reminder that the list exists and that adding to it is welcome.
What the inventory is for
Worth stating, because an inventory built as an end in itself gets treated as paperwork:
- Scoping legal obligations. You cannot answer "which statutes reach us?" without knowing which decisions you automate and where the affected people are. See the compliance checklist.
- Proportionate review. Classification tells you which systems deserve real scrutiny and which need a line in a register.
- Incident response. When a model provider has an outage or a vulnerability, the inventory tells you what is affected. Without it, you are asking around during an incident.
- Vendor concentration. Five tools resting on one upstream model is a dependency worth seeing.
- Answering the question. Boards, insurers, auditors and regulators increasingly ask what AI you use. "We are compiling that" is a poor answer twice.
Common failure modes
- Building it from procurement records. Fast, tidy, and misses most of the estate.
- Leading with prohibitions. Produces a clean, false list.
- Too many fields. Completed once, then abandoned.
- Team ownership. "Owned by IT" means owned by nobody in particular.
- No refresh mechanism. Decays into fiction while still being cited.
- Treating it as the goal. The inventory exists so you can decide what deserves attention. If nothing changed as a result of building it, you built a document.
A first pass in two weeks
- Days 1–2. Write the amnesty message. Get it sent by someone senior enough that people believe it.
- Days 3–8. Ask the work-shaped questions, team by team. Conversations, not a survey, wherever practical.
- Days 8–10. Check what your existing software has added. Vendors frequently enable AI features by default.
- Days 10–12. Record the ten fields. Classify into three tiers.
- Days 12–14. Assign a named owner to everything in the top tier, and set review dates.
That produces something imperfect and real. It will be incomplete — every inventory is — but it will be closer to true than anything derived from your contract list, and it gives the rest of a governance programme something to stand on. For where it fits, see AI governance.