AI System Inventory

An AI system inventory is the maintained list of every place AI is used in an organisation — features built in-house, models called through an API, and third-party products whose AI capability is switched on. It is the artefact every other governance control depends on, because a policy, a risk grading and an audit all need to know what they apply to. A useful entry records more than a name. What the system does, who owns it, which model and provider it uses, what data it sees, whether it touches customers or only staff, whether its output is acted on automatically, and when it was last reviewed. That last field is what keeps the inventory honest: without a review date, an entry written eighteen months ago looks identical to one confirmed last week. Building it is harder than it sounds, because most AI use does not arrive through procurement. It arrives as a feature toggled on inside a tool the company already pays for, or as a personal account expensed by one person, or as a library call added in a pull request. Expense reports, SSO and identity logs, egress to known provider domains, and a dependency scan across repositories each surface a different slice, and none of them is complete on its own. The common mistake is treating it as a one-off compliance exercise. An inventory compiled once and filed decays quickly, because vendors add AI features to existing products continuously — a tool that was AI-free at the time of assessment can gain a model-backed feature in a routine release without any purchase decision on your side. That is why maintenance matters more than the completeness of the first pass. Keep it wherever the organisation already keeps its systems of record — a service catalogue, a CMDB, an asset register — rather than in a separate spreadsheet, and make it a step in the paths that create AI use: procurement, architecture review, and pull requests that add a provider SDK. An inventory nobody is required to update is a snapshot, and a snapshot answers questions about the past.