AI model inventory

An AI model inventory is a centralized register of all AI models developed, deployed, or used within a company. It captures key information such as the model's purpose, owner, training data, risk level, deployment status, and compliance standing. Every other AI governance activity depends on having this visibility in place first.

Why it matters

Without an accurate inventory, AI risks go unnoticed. You cannot govern what you cannot see. The most common finding in AI governance gap analyses is that companies do not have a complete picture of the AI systems operating in their environment. Models deployed by individual teams, vendor-provided AI services, and experimental prototypes that quietly moved to production all create blind spots.

The EU AI Act makes the stakes concrete: providers must maintain technical documentation for high-risk AI systems, and deployers must keep operational logs. Both obligations assume — and in practice require — a well-maintained model inventory. ISO/IEC 42001 similarly requires companies to identify and document their AI systems as a foundation for the management system.

What to include in an AI model inventory

A complete inventory captures information across several dimensions for each AI system.

Core identification

Model name and version: A unique identifier plus version tracking to distinguish between iterations.
Purpose and use case: What the model does and why it was built.
Model type: The architecture category — classification, regression, generative, recommendation, and so on.
Owner and responsible party: The individual or team accountable for performance and governance.
Development status: Whether the model is in research, development, testing, production, or retired.

Data and training

Training data sources: All datasets used, including their origin, collection methods, and time periods.
Data sensitivity: Sensitivity classifications, noting whether personal data, protected characteristics, or proprietary information is involved.
Data quality assessment: Known quality issues, representativeness concerns, and any preprocessing applied.
Data retention and lineage: How long training data is retained and the full provenance chain from source to model input.

Risk and compliance

Risk classification: The model's risk level under applicable regulations, such as EU AI Act risk tiers or sector-specific classifications.
Regulatory mapping: Which regulations apply (EU AI Act, GDPR, sector-specific rules) and current compliance status.
Last review date: When the model was last formally reviewed for performance, fairness, and compliance.
Known limitations: Documented constraints, failure modes, and scenarios where the model should not be used.
Approval records: Who authorized deployment and under what conditions.

Operational details

Deployment environment: Where and how the model runs — cloud, on-premises, edge, or hybrid.
Integration points: Which systems consume the model's outputs, and how those outputs feed into decision-making.
Monitoring status: What performance metrics are tracked and what alerting exists.
Incident history: Any past issues, failures, or incidents involving the model.

Vendor and third-party information

Vendor or provider: For third-party models, the supplier name and contact information.
Contract terms: Contractual obligations including SLAs, audit rights, and data handling agreements.
Update and support status: Whether the vendor provides ongoing updates, security patches, and support.

The shadow AI problem

Shadow AI refers to models deployed outside official governance processes, and it is one of the most significant risks that model inventories address. Teams may adopt AI tools through individual subscriptions, embed open-source models into applications without review, or move experimental prototypes into production without formal approval.

Several discovery approaches can help:

Cloud and infrastructure scanning to monitor for AI service consumption, GPU provisioning, and model serving endpoints.
Procurement and vendor review to track AI-related purchases through finance processes.
API gateway monitoring to inspect traffic for calls to external AI services.
Employee surveys and education — asking teams directly about their AI tool usage while explaining why governance matters.
Network traffic analysis to identify connections to known AI API endpoints.

The goal is not to block innovation but to gain visibility. Easy registration processes and low governance friction for low-risk applications encourage teams to register models voluntarily rather than working around the system.

Tiered governance approach

Not every AI model warrants the same depth of documentation and oversight. A tiered approach matches governance effort to risk level.

Tier 1 — High-risk systems: Full documentation across all inventory dimensions. Formal risk assessment, bias testing, third-party validation, and ongoing monitoring are required. Examples include systems making decisions about employment, credit, healthcare, or law enforcement.

Tier 2 — Medium-risk systems: Thorough documentation with particular attention to data governance, performance monitoring, and user transparency. Internal review is typically sufficient, but documentation should be audit-ready.

Tier 3 — Low-risk systems: Lightweight documentation covering core identification, purpose, owner, and basic performance validation. Internal productivity tools, spam filters, and non-customer-facing automation fall here.

Tier 4 — Experimental and prototype: Minimal metadata — name, owner, data accessed, intended purpose. A full inventory entry should be required before any model moves from experimentation to production.

Real-world example

A healthcare company uses AI models to predict patient readmission risks, assist with diagnostics, and optimize scheduling. Its model inventory ensures that only validated models are used in clinical settings, every model complies with data privacy laws like HIPAA and the EU AI Act's high-risk requirements, and each model's performance is tracked against clinical benchmarks.

When external auditors request documentation, the company can immediately present an up-to-date record of all models — their training data, validation results, deployment status, and monitoring metrics. When a new regulation takes effect, the compliance team can quickly identify which models are affected and what changes are needed.

Tools and implementation

Spreadsheets vs. dedicated platforms

Many teams start with spreadsheets, and they work for small AI portfolios. They become difficult to maintain as the number of models grows: version control suffers, tracking changes over time gets messy, and there is no way to integrate with development and deployment pipelines.

Dedicated model registry and AI governance platforms offer automated data collection from ML pipelines, real-time status updates from deployment systems, built-in compliance mapping and reporting, role-based access control with audit trails, and dashboard views showing portfolio-level metrics.

Integration with MLOps

The most effective inventories tie into existing MLOps infrastructure. Model registries like MLflow, Weights & Biases, or Neptune can automatically populate inventory fields during development. Deployment pipelines can enforce inventory registration as a gate before production release. Monitoring systems can feed performance metrics back into inventory records.

Best practices

Single source of truth: Maintain one accessible list of all AI models across departments, including experimental, legacy, and vendor-provided models. Avoid departmental silos where each team keeps its own list.
Detailed metadata: Record model owner, purpose, input data, training history, deployment status, risk level, and compliance standing. Standardize field definitions so entries are comparable across teams.
Lifecycle tracking: Document each model's progression through development, testing, deployment, monitoring, retraining, and retirement. Keep version history and the reasons behind each update.
Compliance tagging: Label models by applicable regulation (EU AI Act risk tier, GDPR applicability, sector-specific requirements) so compliance teams can respond quickly when rules change.
Risk scoring: Assess and update risk scores regularly based on model behavior, use case sensitivity, the data involved, and impact scope. Let risk scores drive tiered governance requirements.
Regular audits: Run periodic discovery audits to find unregistered models and verify that inventory records match actual deployments. Cross-check against cloud infrastructure, API traffic, and procurement records.
Automation: Automate data collection from ML pipelines and deployment systems wherever possible. Manual data entry is error-prone and creates maintenance burden that leads to stale records.

FAQ

What information should be included in an AI model inventory?

A complete inventory should capture the model name, purpose, owner, input and training data, development status, deployment environment, regulatory requirements, risk classification, monitoring status, version information, last review date, approval records, known limitations, and links to detailed documentation. For vendor-provided models, include contract details, vendor contact, and SLA terms.

Who should be responsible for maintaining the AI model inventory?

Governance, risk, and compliance teams — or a dedicated AI governance officer — typically own the inventory process, but model owners and developers contribute updates. Define clear processes for adding new models, updating existing entries, and retiring deprecated ones. Automated integrations with development and deployment pipelines reduce the manual burden.

How often should the AI model inventory be updated?

Continuously, with reviews at key milestones: model deployment, significant retraining events, regulatory updates, or at minimum quarterly. Trigger-based updates ensure timely capture of changes. Automated synchronization with model registries and deployment systems helps keep records current.

Is an AI model inventory required by law?

The EU AI Act requires providers of high-risk AI systems to maintain technical documentation and deployers to keep operational logs. ISO 42001 requires companies to identify and document their AI systems. Neither prescribes a specific inventory format, but a well-maintained model inventory is the practical way to meet these obligations.

How do you discover AI models that are not in the inventory?

Run periodic discovery audits across cloud platforms, on-premises systems, and third-party integrations. Monitor procurement and vendor management processes for AI purchases. Review API traffic for connections to external AI services. Make registration easy to reduce incentives for bypassing governance. Establish clear policies requiring inventory registration before deployment.

Should the inventory include experimental and prototype models?

Yes, though with appropriate categorization and lighter documentation requirements. Even experimental models may access sensitive data or influence decisions during testing. Define clear criteria for when an experimental model needs full inventory treatment, and require a full entry before any model moves to production.

AI model inventory