AI Model Inventory Template: Fields, Model Cards and an Example

An AI model inventory is the system of record for every AI system and model your organization builds, buys or uses: what each one is for, which models and providers sit behind it, what data it touches, how risky it is, who answers for it and when it was last reviewed. It is the first control nearly every AI framework asks for, because nothing else in AI governance works until you know what you have. This template gives you the fields, a short model card template, an illustrative entry and the practices that keep the inventory accurate, including for vendor and embedded AI.

Inventory, model card and agent registry: how they differ

Three records get confused. They answer different questions, and each points to the others.

Record	Scope	Question it answers	Depth
AI model inventory	Every AI system and model in use: built, bought, embedded or called through an API	What AI do we have, who owns it, and how risky is it?	One short record per system
Model card	One model	What was this model built for, how was it evaluated and where does it fail?	A few pages per model
Agent registry	AI systems that take actions with tools	What can this agent do right now, as whom, within what limits, and how do we stop it?	A full operational record per agent

The inventory is the parent list. A model card hangs off an inventory entry when your organization builds, tunes or materially adapts a model. An agent is an inventory entry with extra fields, which our AI agent registry template sets out in full. Keep all three in one system, or at least linked by one ID, so there is a single place to start.

The word “model” causes some trouble. Most enterprises now use far more models than they build, and most of the risk sits in how a model is used, not in the model alone. Inventory the AI system (the use case, its model, its data and its users) and record the models underneath it. A single hosted model serving five use cases gives you five entries that share one model reference.

Why the inventory is the first control

Every major framework assumes an inventory exists, even when it does not use the word.

• NIST AI RMF 1.0. The Map function asks you to establish the context of each AI system: purpose, users, affected people, data and dependencies. Govern includes keeping track of the AI systems in use. The inventory is where both live. Our NIST AI RMF implementation guide calls it the hardest part of the first quarter.
• ISO/IEC 42001:2023. An AI management system needs a defined scope and documented information about the AI systems inside it. An auditor will ask to see the list and test whether it is complete. See our ISO 42001 readiness guide.
• EU AI Act. Obligations depend on whether you are a provider or a deployer and on the risk category of each system. You cannot classify systems you have not listed. Timelines for the high-risk obligations have been subject to change, so confirm current dates with counsel.
• Model risk management in banking. SR 11-7, the 2011 supervisory guidance on model risk management from the Federal Reserve and the OCC, expects banks to keep an inventory of models in use, under development and recently retired, including vendor models. Many banks extend that inventory to generative AI rather than starting a second list. Check current supervisory guidance, which can change.

The inventory is also what makes the rest of the program cheap. Risk tiering, review routing, incident response and vendor reviews all start with a lookup. Our AI governance framework lists it as the third of eight components, right after policy and roles.

The fields, grouped by owner

The template has ten field groups. Each has a natural owner, which matters more than the field names: an inventory fails when one team is expected to know everything.

Group	What it answers	Usually maintained by
1. Identity	What is this and where does it run?	AI platform or governance team
2. Purpose and use case	What is it for, and who uses it?	Business owner
3. Models and providers	Which models sit behind it, at which versions?	Engineering, filled by the pipeline; procurement for vendor AI
4. Data	What data goes in and comes out, at what classification?	Data owner, with privacy
5. Risk	How much harm could a wrong output cause?	Risk, with the architecture review board
6. Owners	Who answers for it?	Business owner
7. Evaluation evidence	How do we know it works?	Engineering, with model risk where it applies
8. Deployment and access	Who can reach it, through what?	Platform and security teams
9. Monitoring	What is watched after launch?	Platform team and system owner
10. Lifecycle	What state is it in, and when is the next review?	Governance team

Mark each field as required or optional for your organization. A short required list that is always filled beats a long one that is half empty.

The template

Copy the block below into your inventory system as a schema, or use it as a YAML record per system in a repository. Replace the bracketed parts.

# AI model inventory entry
identity:
  id: [stable unique ID, used in logs and gateway routes]
  name: [plain-language name]
  description: [one sentence a non-specialist understands]
  type: [built in-house | configured platform | vendor feature | third-party model API]
  runtime: [cloud account, platform or vendor product]

purpose:
  intended_use: [two or three sentences]
  out_of_scope: [uses that are not approved]
  users: [employees | customers | partners | none]
  affected_people: [who an output can affect, if not the users]
  business_process: [process name and its owner]

models:
  - provider: [vendor or internal team]
    model: [name]
    version: [exact version or dated deployment]
    hosting: [managed API | cloud endpoint | self-hosted | inside vendor product]
    model_card: [link, or "vendor documentation" with link]
    contract_terms: [link to data use and retention terms]

data:
  inputs: [sources, with classification]
  outputs: [where outputs go and who sees them]
  training_or_tuning: [none | dataset links]
  highest_classification: [public | internal | confidential | restricted]
  personal_data: [yes | no, with categories]
  residency: [regions where data is processed]

risk:
  tier: [Low | Moderate | High, from the governance framework]
  decisions_about_people: [yes | no]
  autonomy: [advises | decides | acts; if acts, link the agent registry entry]
  regulatory_notes: [frameworks that apply, with date last checked]

owners:
  business_owner: [named person]
  technical_owner: [named person or team; vendor contact for vendor AI]
  risk_reviewer: [named person, for moderate and high tier]

evaluation:
  suite: [link to evaluation set and harness]
  last_result: [link to the run]
  thresholds: [pass marks for release and continued use]
  independent_validation: [date and reviewer, where required]

deployment:
  access_path: [gateway route, application, vendor tenant]
  user_access: [groups or roles allowed]
  approval_record: [link to review decision or ADR]

monitoring:
  metrics: [quality, safety, cost, drift]
  dashboard: [link]
  incidents: [links]

lifecycle:
  status: [proposed | pilot | production | suspended | retired]
  last_review: [date, reviewer, outcome]
  next_review: [date]
  review_triggers: [model change, new data, new users, vendor release]

Three fields deserve a note.

Type. This one field decides how the rest is filled. A built system gets its model fields from the pipeline. A vendor feature gets them from procurement and the vendor’s documentation, and its version field may simply say “vendor managed” with a link to release notes. Both are legitimate entries.

Model card. Link it; do not paste it. The inventory stays short and scannable, and the card carries the detail.

Autonomy. If the answer is “acts”, the system needs a full agent registry entry as well. The inventory records that it is an agent and links to the registry, which holds identity, tools, limits and the kill switch.

Model cards: the detail behind an entry

The model card format comes from Margaret Mitchell and colleagues’ 2019 paper “Model Cards for Model Reporting”, presented at the ACM Conference on Fairness, Accountability, and Transparency (FAT* 2019). They proposed a short document to accompany each trained model, covering its details, intended use, the factors and metrics used to evaluate it, the evaluation and training data, quantitative results, ethical considerations, and caveats and recommendations. Model hubs and many vendors now publish cards in a similar shape.

Write a model card when you train, tune or materially adapt a model, or when you build a system whose behavior a reviewer needs to understand beyond the inventory fields. For models you consume as-is, link the provider’s card or documentation and add a short enterprise addendum covering how you use it.

# Model card: [model or system name], [version]

## Model details
Owner, provider, version, date, model type, license, base model if tuned.

## Intended use
Primary uses and users. Uses that are out of scope.

## Factors
Groups, conditions or input types where performance may differ.

## Metrics
What is measured, why, and the pass thresholds.

## Evaluation data
Datasets used, how they were chosen, known gaps.

## Training or tuning data
Sources, classification, consent and licensing (or "provider's base
model, see provider documentation").

## Results
Performance overall and by factor. Link to the evaluation run.

## Limitations and risks
Known failure modes, including bias, confabulation and misuse.

## Caveats and recommendations
Conditions for safe use, required human review, monitoring.

An illustrative entry

The entry below is illustrative. The company, system and vendors are invented to show how the fields read when filled in.

Field	Example value
ID	ai-fin-0031
Name	Invoice exception summarizer
Type	Built in-house on a third-party model API
Intended use	Summarize why a supplier invoice failed matching and suggest the likely fix for an accounts payable clerk
Out of scope	Approving, rejecting or paying invoices; changing supplier bank details
Users	Accounts payable team (employees)
Models	One hosted model through the LLM gateway, dated version pinned in configuration; provider card linked
Data	Invoice and purchase order records (confidential); no personal data beyond supplier contact names
Residency	Primary cloud region only
Risk tier	Moderate (material business impact, a person decides)
Autonomy	Advises; no agent registry entry needed
Business owner	Controller (named person)
Technical owner	Finance applications team
Evaluation	Graded set of past exceptions; pass marks for correct cause and no invented amounts; link to last run
Access path	Gateway route for the finance workspace; AP group only
Approval record	Delegated review decision and ADR linked
Monitoring	Clerk feedback rate, cost per summary, refusal rate
Status	Production
Next review	Six months from last review, or on any model version change

Notice what the record makes visible. The out-of-scope line rules out the riskiest misuse in plain words. The tier is Moderate because a person makes every decision; if the system were later allowed to release payments, its autonomy would change to “acts”, it would need an agent registry entry, and the review would reopen.

Finding shadow and embedded AI

An inventory built only from self-declaration will miss most of what is in use. Draw from several sources and reconcile them.

• Procurement and contract records. Search new and renewing contracts for AI features, model providers and data use clauses. Add an AI question to vendor intake so new purchases arrive pre-registered.
• Expense and card data. Look for subscriptions to AI tools bought on corporate cards outside procurement.
• Single sign-on and SaaS management. Your identity provider and SaaS discovery tools show which AI applications people sign in to, and which existing applications have switched on AI features.
• Gateway and egress logs. Traffic to model provider endpoints that does not pass through your LLM gateway is, by definition, unregistered. Our LLM gateway architecture guide covers making the gateway the default path.
• Cloud billing. Charges for model services in accounts that have no inventory entry.
• Code repositories. Scans for model SDK imports and API keys.
• Vendor questionnaires. Ask existing suppliers whether their product uses AI on your data, which models, where it runs and whether your data is used to train them. Repeat at renewal.

Treat findings as registrations, not violations. The aim is a complete list, and people stop declaring things when declaring gets them in trouble.

Keeping it accurate

A stale inventory is worse than none, because people trust it. Make accuracy a side effect of how systems are built and bought, the same way the agent registry does.

1. Registration gates deployment and purchase. The release pipeline refuses to promote a system without an approved entry, and procurement will not sign an AI-capable contract without one.
2. The gateway refuses unknown IDs. Every route through the LLM gateway carries an inventory ID. No ID, no traffic.
3. The pipeline fills technical fields. Model versions, evaluation results and approval links are written on each release, not typed in.
4. Reconcile regularly. Compare the inventory with gateway logs, cloud billing and procurement records. Every difference is a finding to resolve.
5. Entries expire. An entry past its review date drops to suspended unless the owner renews it.
6. Low tier gets a fast path. A short form for low-risk productivity tools brings them into view. A slow process drives them underground.

Common mistakes

• Inventorying models instead of uses. One model listed once hides five use cases with five different risk tiers.
• Leaving out vendor AI. Embedded features and third-party models are often the largest part of the estate.
• Team names as owners. Name a person for the business and a person or team for the technical side.
• Hand-typed versions. They drift within weeks. Pull them from configuration.
• Deleting retired systems. Retire the entry and keep it; auditors and incident reviews ask about systems that are gone.
• A list nobody queries. If the AI architecture review board and security do not use it, it decays.

Where to start

1. Agree the required fields: groups 1 to 6 and the next review date are enough for a first pass.
2. Pull candidate systems from procurement, expense, SSO, gateway and billing data.
3. Fill entries with each business owner in short working sessions.
4. Tier every entry and route moderate and high tier systems to review.
5. Wire the pipeline and gateway to write and check the technical fields.
6. Write model cards for the systems you build or tune, starting with the high tier ones.
7. Run the first reconciliation and set its cadence.

How we help

We design the AI model inventory as part of the platform, so registration, model versions and evaluation evidence are captured by the systems that deploy and route AI rather than by survey. That work sits within our AI governance and risk service and the AI operating model we help teams run. To build an inventory that will stand up to an audit, talk to an architect.