A practical AI model inventory: what to record for every system in production
A field-by-field guide to building an AI model inventory that supports risk reviews, incident response, and audits without becoming shelfware.
- Published
- Updated
- Reading time
- 4 min read
Key takeaways
- An AI inventory should answer four questions fast: incident contacts, people-affecting systems, vendor exposure, and audit evidence.
- Ten fields per system are enough to start: owner, purpose, model, data inputs, oversight, risk tier, and review dates.
- Risk tiers only matter when each tier maps to concrete minimum controls and review cadence.
- Store records as version-controlled, machine-readable files so CI can flag overdue reviews.
On this page
Ask a large organization how many AI systems it runs and you will usually get a range, not a number. Models are embedded in vendor products, called through APIs from a dozen services, and fine-tuned in notebooks that quietly became production dependencies.
You cannot govern what you cannot list. Frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001 both assume you know which AI systems you operate, who owns them, and what they are used for. An inventory is where that knowledge lives.
The challenge is keeping it useful. Inventories fail in two ways: they capture too little to support real decisions, or they ask for so much that nobody keeps them current.
Start with the decision, not the spreadsheet
Before choosing fields, decide which questions the inventory must answer quickly. In our experience, four cover most of the value:
- During an incident: which systems use this model, vendor, or dataset, and who do we call?
- During a risk review: which systems make or influence decisions about people, and how are they monitored?
- During procurement: where is a given vendor's AI already in use?
- During an audit: can we show that each system had a documented owner, assessment, and review?
Every field in the inventory should help answer at least one of these. If it does not, leave it out.
The core record
The schema below is deliberately small. It fits on one screen and can be filled in by an engineer in under fifteen minutes.
| Field | Example | Why it matters |
|---|---|---|
| System name | Support reply drafting | A stable, human-readable identifier |
| Business owner | Head of Customer Support | Accountable for use and outcomes |
| Technical owner | Platform AI team | Accountable for operation and changes |
| Purpose | Drafts replies for agent review | Defines intended use and its limits |
| Model and provider | Hosted LLM via vendor API | Needed when a vendor issue or deprecation lands |
| Data inputs | Ticket text, order history | Drives privacy and security review scope |
| Affects people? | Indirectly, via agent review | Determines review depth |
| Human oversight | Agent approves every reply | Shows where errors are caught |
| Risk tier | Medium | Sets review cadence and controls |
| Last review / next review | 2026-07 / 2026-10 | Proves governance is ongoing |
Tie risk tiers to concrete controls
A tier is only meaningful if it changes what happens. Write down the minimum controls for each tier and link them from the inventory record.
- Low: owner assigned, purpose documented, annual review.
- Medium: everything in low, plus pre-launch security and privacy review, output monitoring, and a review every six months.
- High: everything in medium, plus documented evaluation results, a named human oversight process, incident runbook, and quarterly review.
For systems where models can take actions, the controls should include authorization on every tool call. We cover that design in detail in Prompt injection is an access-control problem.
Make it machine-readable
A spreadsheet is a fine start, but store the inventory somewhere other systems can read. A version-controlled YAML file per system works well for engineering-heavy organizations, because changes get reviewed like code and history is preserved.
id: support-reply-drafting
owner:
business: head-of-support
technical: platform-ai
purpose: Draft replies to customer tickets for agent review.
model:
provider: external-llm-vendor
access: api
data_inputs: [ticket_text, order_history]
affects_people: indirect
human_oversight: agent-approves-every-reply
risk_tier: medium
reviews:
last: 2026-07-14
next: 2026-10-14
With records in this form, you can fail a CI check when a review date passes, or generate the inventory report for an audit instead of assembling it by hand.
Find what is already running
The first version of an inventory always misses things. A few sources help close the gap:
- Egress and billing data. API calls and invoices for model providers reveal integrations that never went through review.
- Procurement records. Vendor contracts increasingly disclose AI features; flag them at renewal.
- Code search. Search repositories for SDK imports and model endpoints.
- A short survey. Ask team leads one question: what AI features do you use or ship? Keep it to that.
Keep it alive
An inventory decays from the moment it is complete. Three habits keep it current: make registration part of the launch checklist, assign review dates that someone is notified about, and treat a stale record as a finding in its own right.
Done well, the inventory stops being a compliance artifact and becomes the place engineers go first when something breaks. It is also the natural home for the logging and retention decisions we discuss in logging LLM applications without creating a privacy problem.
