AI Model Inventory Template: Track Every Model Your Organization Runs in Production

Regulators don't accept "we use AI" as a governance posture. They want a list — every model, its version, its owner, its risk level, who validated it, and when it was last reviewed. If you can't produce that list on demand, you have a compliance gap.

This article gives you the complete template. Copy it, adapt the field names to your tooling, and start filling it in today.

Why Regulators Require Model Inventories

Three major frameworks have converged on the same requirement: you must maintain a formal register of every AI system you operate.

SR 11-7 (Federal Reserve / OCC) requires banks and their holding companies to maintain comprehensive documentation of all models used in business decisions. "Model" is defined broadly — any quantitative method that produces estimates or decisions. That includes credit scoring, fraud detection, chatbots used in loan origination, and any LLM-assisted workflow that touches a regulated outcome.

EU AI Act Article 11 requires technical documentation for high-risk AI systems before they are placed on the market or put into service. That documentation must be kept up to date throughout the system's lifecycle. For deployers (organizations using high-risk systems), Article 26 requires maintaining logs and conducting human oversight — which is only possible if you know what systems you're running.

ISO/IEC 42001 (AI Management System standard) requires organizations to establish an AI system register as part of their AI management system. Clause 6.1.2 explicitly requires identifying AI systems and their associated risks.

An inventory isn't optional for organizations subject to any of these frameworks. It's the foundation everything else is built on.

What a Model Inventory Is (and What It Isn't)

A model inventory is a structured register of every AI/ML system your organization operates in production. It includes:

• Models you built internally
• Models from vendors (including API-accessed models like GPT-4, Claude, Gemini)
• Fine-tuned models, even if the base was a vendor's
• Models running on-premises and in the cloud
• Models embedded in third-party software you deploy

It is not just a list of APIs you call. If a vendor's model makes or influences a business decision, it belongs in your inventory — including the version pinned, the date it was last changed, and who owns the outcome if it fails.

Shadow AI — models deployed by individual teams outside the formal procurement process — is the most common gap. Your inventory is only useful if it's honest about what's actually running.

The Model Inventory Template

Use one row per model deployment. If the same model version is deployed in two separate production contexts (e.g., one for customer service, one for internal ops), create two rows.

Populated Example Row

Model Change Log Template

Every change to a model in production — version updates, retraining, threshold adjustments — must be logged. This is separate from your main inventory table; the inventory shows current state, the change log shows history.

Change Type options: Version update / Threshold adjustment / Input feature change / Training data update / Infrastructure migration / Emergency rollback

How to Populate Each Field

Risk Tier is the field most organizations get wrong. Don't assign it based on technical complexity. Assign it based on consequences of failure. A simple logistic regression that affects credit decisions is High Risk. A sophisticated transformer model that suggests internal meeting summaries is Low Risk. The question is: if this model outputs something wrong, who is harmed, and how badly?

Human Oversight Level needs to match reality, not aspiration. If your policy says HITL but reviewers rubber-stamp 98% of outputs in under 10 seconds, document that honestly — the gap between policy and practice is itself a finding.

Version for third-party API models requires you to pin model versions, not use "latest" aliases. If you're calling gpt-4 instead of gpt-4-0613, you don't know what model you're actually running. Pin versions. Log them.

Regulatory Scope should be populated by your legal or compliance team, not by engineers. Engineers know what the model does; legal knows which regulations attach to that activity.

Maintaining the Inventory

A model inventory that isn't maintained is worse than no inventory — it creates false confidence and will actively mislead auditors.

Minimum review cadence:

• High-Risk systems: quarterly
• Medium-Risk systems: semi-annually
• Low-Risk systems: annually
• After any production incident: within 5 business days

Triggers for a new inventory entry (not just an update to an existing row):

• New model deployed to production
• Existing model applied to a new business purpose or new data type
• Model moved from one deployment environment to another (staging → production)

Triggers for an update to an existing row:

• Version change
• Owner change
• Validation status change
• Retirement

Common Mistakes

Treating the inventory as a one-time project. Organizations stand up an inventory for an audit, then let it go stale. Regulators check for recent updates. An inventory last touched 18 months ago is evidence of a governance gap, not governance.

Under-reporting shadow AI. Individual teams spin up AI tools — Copilot integrations, vendor-specific AI features, custom API integrations — without going through formal procurement. Survey business units directly, not just IT. Ask: "Are there any AI tools your team uses that aren't managed by central IT?" The answer is almost always yes.

Conflating the model with the use case. The same model version (e.g., GPT-4o) deployed in two different contexts — customer-facing support chat vs. internal legal document summarization — represents two different inventory entries with potentially different risk tiers, oversight requirements, and regulatory scope.

Not tracking API-accessed models by version. "We use OpenAI" is not an inventory entry. The specific model ID, the date it was pinned, and any subsequent updates are all required information.

Connecting to Your Data Pipeline

The Model Change Log columns — particularly Change Type, Changed By, and Validation Completed — map directly to the output of a well-instrumented data processing pipeline. If your training data pipeline tracks every transformation with operator attribution and timestamps, you already have the raw material for the change log. The gap is usually connecting that operational log to the governance register.

Ertas Data Suite generates a complete, immutable audit trail of every data transformation step — who ran it, when, what changed — which feeds directly into the Model Change Log without manual entry.

Book a discovery call with Ertas →

Next Steps

1. Export a list of all models currently running in your environment (work with ML Ops and IT)
2. Assign a risk tier to each using your classification policy (or adopt the three-tier framework above)
3. Identify owners for each model — if no one is accountable, that's your first governance finding
4. Schedule the first formal review for all High-Risk systems within 90 days
5. Implement a change notification process so the inventory stays current

The inventory is the foundation. Model cards, validation documentation, audit trails, and incident response all reference it. Build it well, and the rest of your governance program has something to stand on.