AI Inventory and Model Registry
Knowing what AI your organisation actually runs — including the tools nobody declared and the features vendors switched on — kept current by discovery rather than by a survey that is stale before it is finished.
Every governance requirement begins with the same assumption: that you know what AI you have. Almost no organisation does. The inventory produced by asking teams to declare their AI systems is reliably incomplete, because people do not think of the transcription tool, the vendor feature enabled last quarter, or the script somebody wrote that calls an API.
An AI inventory is the authoritative record of every AI system an organisation builds, buys or embeds — with its owner, purpose, risk classification, data, lifecycle stage and documentation. A model registry is the technical counterpart holding model versions, lineage and approval state.
Why surveys produce incomplete inventories
| Category | Why it is missed | How we find it |
|---|---|---|
| Vendor features enabled quietly | Nobody sees it as adopting AI | Vendor contracts, release notes, admin settings |
| Tools bought on expenses | Below procurement thresholds | Expense and card data by merchant |
| Direct API use in code | A script, not a system | Repository scanning for provider endpoints |
| Departmental automations | Built in a low-code tool by a business team | Platform admin consoles and connector lists |
| Pilots that quietly became production | Never formally launched | Traffic, spend and support tickets |
| Embedded models in products | Part of a product, not an AI system | Engineering interviews and architecture review |
The first two rows account for most of what a survey misses. Discovery through procurement, expense and engineering records typically finds substantially more AI than the declared inventory contains, and that gap is usually the most useful thing an executive learns from this engagement.
What the inventory has to hold
Ownership, as a person
Every entry has a named accountable owner. Entries owned by a team or a function are entries nobody will answer for, and they are the first thing an auditor probes.
Purpose, and what it decides
What the system does and what happens downstream of its output, in language a non-technical reviewer can assess. Risk classification depends on this being written honestly rather than minimally.
Risk classification and its basis
The tier under your framework, and the classification under any regulation that applies, with the reasoning recorded. See EU AI Act compliance where the Act is in scope.
Data, including what leaves
What the system processes, whether personal or sensitive data is involved, and which third parties receive it. This is the join between the AI inventory and your privacy records, and keeping them consistent avoids two registers that disagree.
Lifecycle stage, including retirement
Proposed, in development, in production, deprecated or retired. Registries that only record live systems lose the history an auditor asks for and quietly accumulate entries for things switched off two years ago.
Links to the documentation that exists
Model card, risk assessment, evaluation results, approval record. The inventory is the index; the documents live where they are produced. See risk assessment and model cards.
A registry maintained by annual survey is wrong by March
The inventory has to be fed by the processes that create AI systems — procurement, engineering release, vendor management — rather than by asking people once a year. Automated discovery reruns catch what the process misses. Without both, you have a snapshot of last January.
Inventory and model registry are different things
- The AI inventory is a governance record. Systems, owners, purposes, risk classifications and documentation, readable by risk, legal and audit functions.
- The model registry is an engineering artefact. Model versions, training data references, metrics, lineage and approval state, used by the deployment pipeline.
- They must be linked and are not the same. An inventory that lists model versions is unreadable to its audience; a registry that carries governance metadata drifts from the pipeline that uses it.
Where an MLOps registry already exists, we link to it rather than duplicating it, so engineering keeps one source of truth and governance gets the view it needs.
How the engagement runs
Discovery runs against procurement, expense and engineering records rather than relying on declarations.
Discovery
Procurement, expense, vendor contracts, repositories and low-code platforms searched for undeclared AI.
Consolidation
Discovered and declared systems reconciled; the gap reported to the executive owner.
Enrichment
Owners assigned, purposes documented, risk classified, data and third parties recorded.
Build and integrate
Inventory implemented, linked to any existing model registry, and fed by procurement and release processes.
Maintenance and handover
Discovery reruns scheduled, ownership review cadence set, handover to the owning function.
What you receive
A complete inventory, fed by process rather than by survey, with a named owner per entry.
Discovery report
Undeclared AI found through procurement, expense, repository and platform searches, with the gap quantified.
Consolidated inventory
Built, bought and embedded AI with owners, purposes, risk classification and data recorded.
Model registry linkage
Connected to your engineering registry rather than duplicating it.
Process integration
Fed by procurement, engineering release and vendor management so it stays current.
Scheduled discovery
Reruns that catch what the processes miss.
Maintenance model
Ownership review cadence, retirement handling and a named owning function.
Is this the right engagement?
Worth being direct. AI Inventory and Model Registry is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Nobody can say with confidence what AI the organisation runs.
- A governance framework, certification or regulation requires a complete inventory.
- An auditor or customer has asked for a list and the existing one is doubted.
- AI is arriving through vendor features and departmental tools.
- An existing inventory was built by survey and is now stale.
Choose something else if
- The organisation runs three AI systems and everyone knows what they are.
- The requirement is the engineering registry. See MLOps implementation.
- Procurement and engineering records cannot be accessed, which makes discovery guesswork.
- No function will own the inventory after handover.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
Why not just ask teams what AI they use?
Because the answer is reliably incomplete. People do not think of the transcription tool, the vendor feature enabled last quarter, the script calling an API, or the pilot that quietly became production. Discovery through procurement, expense and engineering records typically finds substantially more than the declared inventory, and that gap is the point of the exercise.
What is the difference between an AI inventory and a model registry?
The inventory is a governance record — systems, owners, purposes, risk classifications and documentation — readable by risk, legal and audit. The model registry is an engineering artefact holding model versions, lineage and approval state for the deployment pipeline. They should be linked, and they serve different readers.
How do we keep it current?
By feeding it from the processes that create AI systems — procurement, engineering release, vendor management — rather than by asking annually, and by rerunning discovery on a schedule to catch what those processes miss. An inventory maintained by survey is wrong within a quarter.
Does this include AI inside software we bought?
It must, and that is usually the majority of the exposure. Vendor features switched on inside existing products are the single largest category of undeclared AI we find, because nobody in the organisation experienced it as adopting AI — it arrived in a release note.
Who should own the inventory?
A function with visibility across procurement and engineering — often risk, security or a central governance team — with a named accountable owner per entry rather than a team name. Entries owned by a function are entries nobody will answer for when an auditor asks.
Often paired with this
Most clients combine two or three engagements from the AI Governance, Security and Compliance pillar. These are the ones that most often run immediately before or after.
AI Governance Framework Design
Proportionate risk tiers, named accountability and decision rights — a framework people follow rather than route around.
Read more →AI Audit and Third-Party Assurance
Independent assessment against a stated standard, with evidence tested rather than taken on assertion.
Read more →AI Policy and Acceptable-Use Documentation
Specific rules with named tools and worked examples, plus an approval route fast enough that people use it.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.