Building an AI Inventory That Stays Current

Why does everything else depend on the inventory?

Risk assessment, policy scope, regulatory classification, monitoring and incident response all start from a list of what exists. ISO/IEC 42001 readiness, NIST AI RMF mapping and EU AI Act role analysis each ask, in different words, what AI you have and who is responsible. An inventory answers those questions once.

What should it include?

Scope it wider than the data science team:

• Models and applications built in-house, including prototypes that reached real users.
• Vendor AI products and APIs, and the foundation models behind them.
• AI features embedded in existing software, such as summarization or scoring.
• Agents and retrieval systems that act on data or systems.
• Tools adopted without approval, found through shadow AI discovery.

Which fields matter?

Field group	Examples
Identity	Name, version, status, business unit, vendor or internal
Accountability	Business owner, technical owner, risk reviewer, approval date
Purpose	Intended use, users, affected people, decisions supported
Data	Sources, sensitivity, personal data, permitted purposes, link to lineage
Risk	Tier, key risks, applicable regulations, human oversight arrangement
Controls	Tests run, monitoring in place, last review, open exceptions

Start with fewer fields and complete them reliably. A short register that is accurate beats a long one that is stale.

How do you keep it current?

Treat the inventory as a by-product of processes people already follow:

• Intake: no AI project starts building or buying without a register entry.
• Procurement: vendor onboarding asks whether the product contains AI, and renewals re-ask.
• Change control: a model retraining, new data source or new use triggers an entry review.
• Automated signals: model registries, cloud accounts and identity logs flag candidates not yet registered.
• Attestation: owners confirm entries on a schedule, and unconfirmed entries escalate.
• Retirement: decommissioned systems are marked, with data disposition recorded.

A hypothetical walk-through

A utility with a small data science team starts its register. This example is hypothetical.

1. Intake forms and a procurement scan list eleven systems, including a vendor load-forecasting service and an AI feature in a customer-service platform.
2. Each gets an owner and a provisional tier. Two touch customer data and move to full assessment.
3. A cloud-account scan reveals a prototype still running with real meter data; the team registers it and decides to retire it.
4. Procurement adds an AI question to onboarding, so new systems arrive pre-registered.

What goes wrong?

• One-time census. The list is accurate for a month, then drifts.
• No owner per entry. Nobody can answer questions about a system.
• Too many fields. People stop filling them in.
• Data ignored. The register names models but not the sources behind them, so questions about lineage cannot be answered.

How do you tier entries?

Tiering turns a list into a plan. A simple scheme uses three or four levels based on a few factors: whether the system affects individuals' rights, money or safety; whether it processes personal or regulated data; how much autonomy it has; and whether it faces customers or only staff. Each tier carries a standard set of controls, from a light review for internal productivity tools to full assessment, testing and monitoring for high-impact systems. Write the criteria down so two reviewers reach the same answer. Revisit the tier when the use changes, since a pilot that becomes a production service has a different risk profile.

What is a sensible first milestone?

Within the first cycle, aim for a register that covers the systems with the highest exposure, with a named owner and tier on every entry, and a defined process for adding new ones. Completeness can follow. The point is to establish the routine, because the routine is what keeps the register true.

Who uses the inventory?

Many groups: risk teams for assessment, legal for regulatory classification, security for threat exposure, procurement for vendor decisions, and audit for sampling. Ask each what they need to see, then give them views of one register instead of separate lists. Duplicate lists drift apart, and the disagreement between them is where gaps hide.

Where a team resists, start from the benefit to them: a registered system is easier to get approved, easier to support, and less likely to be stopped at the last minute. Show one team how an entry saved time in an assessment, and the habit tends to spread faster than a mandate would.

Review quality as well as coverage. Sample a few entries each quarter, compare them with the system as it runs, and correct what has drifted.

Where aerais fits

aerais designs the inventory, wires it into intake, procurement and delivery workflows, and operates it as part of the governance function. It is the first deliverable in many engagements, because policies, controls and monitoring all attach to it. See the AI governance practice, our method, and the framework that maps register fields to standards.

This article is for general information only and is not legal advice.