Model Inventory

AI governance frameworks specify controls proportionate to risk: evaluation, bias testing, human review, explainability, monitoring, contestation routes. Every one of them presupposes knowing which models exist.

Most organisations cannot enumerate their deployed models. They accumulate through experiments that became production, features shipped by individual teams, third-party services embedded in products, and models inherited through acquisitions — and the inventory is the unglamorous prerequisite that determines whether any of the rest is real.

Why it matters

An uninventoried model is an ungoverned one by definition. It has no tier, so no controls attach; no owner, so nobody is accountable; no review date, so its performance is never re-examined.

The specific finding that recurs is retirement: a model with no owner, still serving production traffic three years after the team that built it dispersed, with no monitoring and no record of what it was evaluated against. It is a common and serious governance failure, and it is invisible without an inventory.

The second reason is regulatory. Emerging AI regulation requires organisations to identify their high-risk systems and demonstrate controls over them, and "we do not know what we have" is not an available answer.

Implementation patterns

• Registration as a precondition of deployment, enforced by the platform, so an unregistered model cannot reach production — the same mechanism as required ownership metadata on a service, and it works for the same reason: generated compliance beats checked compliance.
• Per-model records: purpose, owner, risk tier, training data provenance, evaluation methodology and results, known limitations, fallback behaviour, and the date of last review.
• Third-party and embedded models included, since a model called via an API is still a model making decisions in your product — and this is the category most often omitted.
• Risk tier assigned by consequence and autonomy, not by technique, and recorded so the applicable controls follow automatically.
• A mandatory review date, with review meaning re-evaluation against current data rather than a documentation check.
• Linked production monitoring: drift, quality and — for higher tiers — fairness across relevant groups, since a model fair at launch may not be fair a year later and nothing detects that without measurement.
• A retirement process, so decommissioning is a defined act rather than an omission.
• Discovery scanning to find models that were deployed without registration, because the register otherwise describes only the compliant teams.

Industry example

Model risk management has a long history in financial services, where regulators have required inventories, independent validation and periodic review of models used in credit, capital and pricing decisions for many years. The practices being adopted across the wider industry for machine learning and generative AI are substantially the same ones, extended to a much larger and faster-moving population of models.

The difference in scale is what makes automation essential. A bank with two hundred models can maintain a register by process; an organisation with two thousand models and a self-service ML platform cannot — which is why registration enforced at deployment, rather than requested afterwards, is the pattern that works.

Failure scenarios

• No inventory, making every other control unenforceable.
• Registration requested rather than enforced, so the register covers the conscientious.
• Third-party and embedded models excluded, missing a large and growing category.
• Tier assigned by technique rather than by consequence and autonomy.
• Review dates passing unnoticed, with no consequence.
• Review as a documentation exercise rather than re-evaluation against current data.
• No retirement process, leaving unowned models serving traffic indefinitely.
• The inventory maintained separately from deployment, so it is accurate on the day it is compiled and stale within a quarter.

Trade-offs

Mandatory registration adds friction to shipping a model, which is precisely the population — experimental, fast-moving, low-consequence work — where friction is least welcome and least warranted. A register that imposes high-tier process on every experiment will be circumvented, and the circumvention is the failure.

Proportionality is therefore the design constraint: registration must be near-instant and lightweight for low-tier models, with substantive process attaching only where the tier justifies it. A framework that is genuinely light at the bottom is what earns the credibility to be heavy at the top.

The trade is deployment friction against the ability to govern anything at all. Given that the alternative is a population of unowned, unmonitored models whose existence nobody can establish, the inventory is not the expensive part of AI governance — it is the part without which the expensive parts are theatre.

Interview question

"A regulator asks for a list of every model that makes decisions affecting customers, with its owner and last review date. Tell me how you would answer that today, what you would have needed to build, and how you would stop the register going stale within six months."