An AI inventory that survives an audit
Most AI inventories are lists of names. An auditor will ask questions a list of names cannot answer. Here is the minimum a record has to carry.
Every organisation building an AI governance capability starts with an inventory. Most of those inventories will fail their first real test, for the same reason: they record what exists, not what would be needed to answer a question about it.
A list of system names tells you nothing when a regulator asks whether any of your systems fall under a prohibited practice, or when an auditor asks who approved the last model change, or when an incident requires you to identify every system depending on a compromised vendor model.
What a record has to carry
The test I apply is simple. For each entry, could someone who has never met the system answer these questions from the record alone?
What does it decide, and about whom? Not the system’s name or its vendor, but the decision it participates in and the population affected. This is what makes a prohibition assessment possible, and it is what determines whether the system is high-risk under any regime.
Where is the human, and what can they actually do? “Human in the loop” is recorded far more often than it is true. The useful field is what the human can change and what happens if they do nothing — because a human who can only approve is not oversight.
What is it built on? Base model, version, hosting location, and whether the weights are yours. Cross-border transfer questions and vendor concentration questions both resolve here.
What data trained it, and what data does it see at inference? These are different questions with different consequences, and inventories routinely collapse them into one.
Who owns it, in the sense of being accountable for its behaviour? A named individual in a named function. Not a team.
When was it last assessed, against what, and what was the outcome? Including the open findings. An inventory that hides the open findings is a marketing document.
Why the shape matters more than the tool
Organisations spend a long time choosing where the inventory lives — a GRC platform, a CMDB extension, a spreadsheet. That choice matters far less than the field list, because the field list is what determines whether the inventory can answer a question you have not thought of yet.
The failure mode is always the same. Someone asks a question the inventory was not designed for, the answer requires going back to system owners individually, and by the time the answers arrive the question has changed. At that point the inventory has become a record of past effort rather than an instrument.
The discipline that keeps it alive
An inventory decays the moment it stops being a precondition for something. The mechanism that works is to make it a gate: no production deployment without a record, no material model change without an update to that record, and no exception without a named owner and a date.
That is not a documentation policy. It is an assurance control, and it should be tested like one.
Adapted from material in AI Cybersecurity Governance, second edition.