An AI model inventory is a complete, maintained register of every model and AI system an organization runs, including large language models and the applications built on them. For each entry it records the purpose, the data sources it reads, the owners accountable for it, the controls that constrain it, and the evidence that those controls actually operate. It is the foundation of model risk governance: you cannot validate, monitor, or attest to what you have never catalogued.
The term comes from banking supervision, where a model risk management program begins with a firm-wide inventory. But the idea now reaches well beyond statistical credit and market-risk models. A retrieval-augmented assistant that answers questions over customer records, an AI system used in a regulated workflow, or an agent that drafts customer-facing language all carry model risk, and all belong in the same register. The inventory is where governance, validation, and audit converge, which is precisely why it is scrutinized first.
01Why an incomplete inventory is the most common finding
Across model risk examinations, the single most frequently cited weakness is an inventory that is incomplete, stale, or missing models entirely. The reason is structural. The inventory is the map of everything else a program does, so when it is wrong, every downstream control is suspect. A validation standard cannot apply to a model no one recorded. A monitoring threshold cannot fire for a pipeline governance never saw.
Inventories drift because the business moves faster than the register. Teams stand up a new LLM feature in a sprint, swap a model provider to cut cost, or add a retrieval source to improve answers, and the inventory is updated weeks later, if at all. The result is shadow AI: systems in production that the governance function cannot name. Examiners look for exactly this gap between what is running and what is documented, because it reveals whether the control environment is real or only on paper.
For AI systems the drift is worse, because the surface area is larger and less familiar. A single assistant may read from several data sources, call more than one model, and change behavior when a prompt template is edited. Keeping that current demands a discipline most inventories were not built for, which is why AI entries are so often the weakest part of the register.
02What belongs in an inventory for LLMs and AI systems
A traditional model inventory captures owner, purpose, methodology, and validation status. An AI system needs the same backbone plus detail about the data it reads and the controls around that data, because the dominant risks are no longer only statistical. They are about what the system can see and what it might disclose. Five categories carry most of the weight.
- Purpose and decision context. What the system does, what decisions rely on its output, and how consequential those decisions are. This sets the level of scrutiny everything else should match.
- Data sources. Every system the model reads from, the sensitivity of those records, and the fields involved. For an LLM this includes retrieval indexes, databases, and document stores feeding the prompt, not just the training corpus.
- Owners and accountability. A named business owner, a technical owner, and the validation and governance contacts. Accountability that maps to a person is what makes the entry actionable.
- Controls. The access, redaction, and policy controls that constrain what the system can read and return. For an AI system on sensitive data this is the heart of the entry: who can see which fields, enforced how, and where.
- Evidence. Proof that the controls operate as described. An assertion that access is restricted by role is only credible if there is a record showing that restriction was applied to real requests.
The first four are familiar. The fifth is where most AI entries are thin, and where the strongest entries are built, because evidence is what turns a documented control into a demonstrated one. This is closely tied to the broader practice of AI data governance, which the inventory both depends on and feeds.
03The 2026 model risk context
The regulatory backdrop shifted in 2026, and it is worth being precise about what changed and what did not. SR 11-7, the interagency guidance that defined model risk management for more than a decade, was replaced in April 2026 by SR 26-2, issued as OCC Bulletin 2026-13. Notably, SR 26-2 excludes generative AI from its formal scope.
That exclusion is easy to misread. It does not mean generative AI is unsupervised or that an inventory is optional. The model risk principles that SR 11-7 established, sound development, independent validation, and ongoing governance, continue to apply, and supervisors still expect institutions to identify, catalogue, and govern consequential models and AI systems. A generative system that informs a real decision sits within the firm's broader risk and control obligations whether or not it falls inside one bulletin's formal definition. The expectation that you know what AI you run, and can govern it, has not weakened.
For practitioners the takeaway is steady: maintain a complete inventory that includes LLMs and AI systems, govern them in proportion to their consequence, and do not treat a narrowed formal scope as a reason to stop cataloguing. The cost of an unknown model in production is the same as it has always been, and so is the first question an examiner asks. For the detail on how the change interacts with LLM governance, see our note on SR 11-7 and LLMs.
04Making an AI inventory entry defensible
An inventory entry is only as credible as the evidence behind it. For an AI system that reads sensitive records, the controls and evidence fields are where defensibility is won or lost. It is one thing to write "access is restricted by role" in the register. It is another to show, for any past request, exactly what an actor was permitted to see. Runtime controls and signed evidence close that gap.
Custosa is a runtime data-control plane for enterprise AI. Its data plane runs inside the customer's environment and inspects every record and field at runtime, before the model, so records never leave the boundary. A deterministic formal policy engine, built on Cedar rather than a model, evaluates each field against the actor's role using a five-level clearance lattice and issues a per-field PASS or REDACT verdict, withholding prohibited fields before the prompt is built. Because the engine is deterministic and fail-closed, the same inputs always produce the same decision, and an unresolved decision blocks rather than leaks. The control plane receives only content-free verdict evidence.
The part that matters for the inventory is the evidence. Every access decision is signed with HMAC-SHA256 and hash-chained into an append-only, tamper-evident, content-free evidence ledger that is verifiable offline. That converts a claim about field-level data control into something an examiner can inspect: which policy applied, which fields were passed or redacted, for which role, without storing the underlying record content. The inventory entry stops being an assertion and becomes a pointer to proof.
- Purpose recorded, with the decisions that rely on the system and how consequential they are.
- Every data source the model reads, with the sensitivity and fields involved.
- A named business owner, technical owner, and validation contact.
- The access, redaction, and policy controls that constrain what the system can see and return.
- Evidence that those controls operate: signed, content-free records of real access decisions.
- Provider, version, and prompt-template changes tracked so the entry does not drift out of date.
- A defensible position on scope under SR 26-2, governing consequential AI in proportion to its risk.
The table below maps the core inventory fields to why each one matters for an AI system, and what good looks like.
| Inventory field | Why it matters |
|---|---|
| Purpose and decision context | Sets the level of scrutiny. A system informing a consequential decision warrants stronger validation and controls than a low-stakes helper. |
| Data sources | Defines the data risk surface. You cannot assess disclosure risk without knowing every record and field the model can read. |
| Owners and accountability | Makes the entry actionable. A named owner is who answers when a control fails or a model changes. |
| Controls | States how access and disclosure are constrained. For sensitive data, field-level, role-aware control is the substance of the entry. |
| Evidence | Turns an assertion into proof. Signed, content-free, tamper-evident records show the control operated on real requests. |
| Provider and version | Keeps the entry current. Model swaps and prompt changes alter behavior, so they must be tracked to stay defensible. |
| Validation status | Shows the control environment is real. An entry no one has reviewed signals a program that exists only on paper. |
Custosa is early-stage and in production with design partners. It does not build or maintain your inventory for you. What it provides is the runtime control and the signed evidence that make the data-control fields of an AI entry defensible rather than aspirational.
Make your AI inventory entries provable
Custosa inspects every record and field at runtime, redacts by role inside your environment, and signs content-free evidence of each decision into a tamper-evident ledger. That is the proof behind a defensible inventory entry.
05Frequently asked questions
What is an AI model inventory?
An AI model inventory is a complete, maintained register of every model and AI system in use across an organization, including large language models and the applications built on them. For each entry it records purpose, the data sources it reads, the owners accountable for it, the controls that constrain it, and the evidence that those controls operate. It is the backbone of model risk governance: you cannot govern, validate, or attest to what you have not catalogued.
Why is an incomplete model inventory the most common examination finding?
Examiners and auditors start with the inventory because it is the map of everything else. When the inventory is incomplete, stale, or missing shadow models, every downstream control is suspect, since a control cannot apply to a model no one has recorded. Inventories drift quickly: teams stand up new LLM features, swap providers, and add retrieval pipelines faster than governance updates the register. That gap between what is running and what is documented is the single most frequently cited weakness in model risk reviews.
Do LLMs and AI systems belong in a model inventory?
Yes, when they inform consequential decisions or touch sensitive data. A retrieval-augmented assistant that surfaces customer records, an agent that drafts adverse-action language, or a model that scores risk all carry model risk regardless of whether they fit a traditional statistical definition. Leading practice is to inventory any AI system whose output a person relies on, and to record the same fields you would for any model: purpose, data sources, owners, controls, and evidence.
Does SR 11-7 still require a model inventory in 2026?
The specific guidance changed. SR 11-7 was replaced in April 2026 by SR 26-2, issued as OCC Bulletin 2026-13, which excludes generative AI from its formal scope. But the underlying expectation did not disappear. Supervisors still expect institutions to identify, catalogue, and govern consequential models and AI systems, and the model risk principles of sound development, validation, and governance continue to apply. A defensible inventory remains foundational whether the system is a regression or a large language model.
What evidence supports a defensible AI inventory entry?
An entry is only as credible as the evidence behind it. For an AI system that reads sensitive data, the strongest evidence shows what each actor was actually permitted to see at runtime: which fields were passed, which were redacted, for which role, and under which policy. Custosa produces exactly this. Every access decision is signed with HMAC-SHA256 and hash-chained into an append-only, tamper-evident, content-free evidence ledger that is verifiable offline, turning an inventory claim about data controls into demonstrable proof.