Model inventory

Every governance obligation — risk assessment, regulatory classification, oversight, audit — presupposes one thing most organizations lack: a complete, current inventory of their AI systems. You cannot govern, classify, or defend what you don't know exists. The model inventory (or AI system registry) is the unglamorous foundation the whole program stands on, and building it is often the first real deliverable of a governance function.

The shadow-AI problem

The reason inventory is hard: AI adoption is decentralized and fast. A marketing team wires up a content generator, an analyst builds a spreadsheet assistant, an engineer embeds an API call in a feature — none of it announced to any central authority. This shadow AI is where ungoverned risk concentrates, precisely because nobody assessed it. A governance program's first act is usually a discovery exercise: find the AI you didn't know you had, because the unassessed HR tool is the one that becomes a headline.

What the inventory tracks

• Identity & ownership — name, purpose, the accountable owner (a named person, not 'the AI team'). No system on the inventory without an owner.
• Risk tier & regulatory classification — from your risk map and gap analysis. The inventory is where those assessments live and stay current.
• Models & providers — which foundation model(s), which vendor, self-hosted or API. This is your AI supply chain — a vendor's model change or incident is now your problem, so you must know your dependencies.
• Data — what data it uses and touches (feeds Module 3's data governance and lineage).
• Lifecycle status — in development / in production / deprecated, and last-reviewed date. A high-risk system not reviewed in a year is a flag.
• Controls & evidence pointers — links to its impact assessment, eval results, audit logs, human-oversight design. The inventory ties each system to the proof it's governed.

Vendor AI: governing what you bought

Most of Meridian's AI — like most enterprises' — is bought, not built, so vendor governance is model governance. Four disciplines: due diligence before purchase (the impact assessment runs on the vendor's tool before the contract is signed, not after); contract terms that preserve governance — audit rights and a model-change notification clause, because a silent vendor model swap changes your risk profile without your consent; assurance artifacts to request — a SOC 2 report, ISO/IEC 42001 certification, the provider's technical documentation — so your evidence chain doesn't stop at the vendor's front door; and an exit plan, because if the vendor fails an audit or a bias finding surfaces, you need a way to switch or stop that doesn't take the business down with it.

The inventory as the program's spine

Done well, the inventory becomes the single pane of glass for AI governance: a regulator asks 'what high-risk AI systems do you operate and can you show their conformity?' — you answer from the inventory. A model provider announces a deprecation — you query which of your systems depend on it. A new regulation arrives — you filter the inventory by tier to scope the work. It's the same 'you can't govern what you can't see' principle that Edova's Sentinel applies to access and Vigil applies to data health — here, applied to AI systems themselves.