What Is an AI Inventory? Knowing What You Actually Run

Almost every organisation attempting AI governance starts with a committee and a policy, and discovers a year later that neither covers most of the AI actually running. The inventory is the unglamorous foundation that makes the rest work, and building one is usually the most informative month a governance function has. This explainer covers how. It complements what is ai risk tiering and ai governance framework, and reflects FISTA Solutions' approach in AI enablement delivery. This article is general guidance, not legal advice.

Why is it foundational?

Because every other control operates on a list. Risk classification needs systems to classify. Impact assessments need to know what requires one. Monitoring needs to know what to monitor. Incident response needs to know what exists. Regulatory disclosure needs a register.

Without the inventory, governance addresses whatever reaches it through goodwill, which correlates poorly with what carries the most risk.

Entry field	Purpose
Purpose and description	Understand what it does
Named owner	Accountability
Data categories	Privacy and residency scope
Affects individuals	Determines obligations
Model and provider	Dependency and contract tracking
Risk tier	Drives proportionate controls
Evaluation evidence	Shows it was tested
Oversight arrangements	Who reviews, how often

What does discovery find?

More than expected, consistently. Teams using assistants for production work without registering them. Product features built with model APIs by engineers who did not consider it a governance event. Automations wired to providers through low-code platforms.

The largest category is usually AI embedded in purchased software. A vendor adds AI features to a tool the organisation already uses, and nobody classifies it as an AI deployment because no one made a decision to deploy it.

What should an entry record?

Enough to answer a question without a fresh investigation. Purpose, owner, data categories, whether it affects individuals, model and provider, deployment status, risk tier, evaluation evidence, and oversight arrangements.

The named owner is the field that matters most and the one most often left as a team name. Accountability that belongs to a team belongs to nobody in particular, which becomes apparent during an incident.

Why classify by risk?

Because uniform controls fail in both directions. Applying full assessment and review to an internal summarisation tool wastes effort; applying light-touch treatment to an eligibility system is inadequate.

Tiering lets scrutiny follow impact. It also makes governance sustainable: teams accept proportionate process and route around uniform process, so tiering is what keeps the inventory populated voluntarily. See what is ai risk tiering.

How is it kept current?

By making registration part of deployment rather than a periodic survey. A gate in the release process, a required field in a service catalogue, or a check at procurement — anything that catches systems at the moment they appear.

Annual surveys produce inventories that are out of date within weeks and that the governance function nonetheless relies on for a year.

What about procurement?

It is the highest-leverage capture point for embedded AI. Adding a question to vendor assessment — does this product use AI, for what, on what data — catches the category that discovery finds hardest, and it catches it before deployment rather than afterwards.

What should you do first?

Ask three teams what AI they are using and compare the answers to your register. The gap is your discovery problem, and its size usually determines whether the next step is a discovery exercise or a registration mechanism.

What about AI in the supply chain?

Suppliers increasingly use AI in services they provide, and that use affects your data and your outcomes without appearing anywhere in your estate. Asking about it in vendor assessment, and recording the answer, extends the inventory to the part of the picture that governance most often cannot see.

The question is simple — does this service use AI, on what data, with what human oversight — and the answers vary enough to be worth having.

Who maintains it?

A named owner with the authority to require registration, usually in risk or technology governance. An inventory maintained by whoever has time is an inventory that stops being maintained during a busy quarter, and the gap is invisible until something is missing from it during an incident.

What does the first version look like?

Incomplete, and useful anyway. An inventory listing the twenty systems governance already knows about, with owners and risk tiers attached, is immediately more useful than a perfect register that takes six months to compile. Discovery then adds to it continuously rather than delaying it.

The common failure is treating completeness as a precondition. It is an outcome, and a partial register that people actually use converges toward completeness faster than a comprehensive exercise that delivers once.

How FISTA Solutions helps

FISTA Solutions builds AI inventories with named individual owners and risk tiers, runs discovery that covers embedded vendor AI as well as built systems, integrates registration into deployment and procurement paths rather than relying on surveys, and keeps entries detailed enough to answer regulatory questions directly, through AI enablement, AI agents, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies across 12+ countries.

To find out what AI you are actually running, message FISTA on WhatsApp, or read ai governance framework.