A model risk inventory entry for an AI agent records the agent in the bank's model inventory with the fields model risk management expects (owner, purpose, tier, validation status, limitations, monitoring) plus the fields an agent adds: the models it uses, the actions it takes, the depth of each, and the controls that limit the impact of a model error.
Why does an agent belong in the model inventory?
Supervisors expect banks to know which models they use and how much they rely on them. In the US, interagency guidance SR 11-7 expects a comprehensive inventory. In the UK, the PRA's SS1/23 sets model risk management principles for banks, including a model inventory. In Canada, OSFI Guideline E-23 covers model risk management. Each takes a broad view of what counts as a model. How these regimes map to agent controls is set out in AI agent regulation, mapped to controls.
An agent uses models to produce outputs that drive actions, so it falls within that view. The questions are how to record it and how to tier it. More detail in SR 11-7 model inventory for AI agents and PRA SS1/23 model inventory: recording AI agents.
When should you use it?
Create the entry when the agent is proposed, before development, so model risk can set expectations early. Update it at each validation, at each change of underlying model, and at each change of capability or depth.
The model inventory is not the only list an agent belongs on. The AI agent inventory register records every agent for governance purposes; this entry adds what model risk needs. The difference between the two kinds of list is explained in what an AI inventory is.
How do you fill in each field?
- Models used lists every model the agent calls, with version and provider. A change of model is a change to the entry.
- Use and reliance describes what decisions or actions depend on the outputs. This drives tiering more than the model's complexity.
- Actions and depth lists what the agent does with outputs. A model error that leads to a draft a person reviews is less material than one that leads to an executed payment.
- Impact limits records the bounds that cap harm from a model error: depth, limits, holds, refusals.
- Tier uses your existing model tiering. Consider materiality, reliance and the depth at which outputs are acted on.
- Validation covers both the model's outputs and the agent's behaviour: does it stay within scope, refuse correctly, hold where it should.
- Limitations records known weaknesses, such as case types it handles poorly.
- Monitoring names the measures and thresholds that trigger review.
The template
| Field | Guidance |
|---|---|
| Inventory ID | Model risk reference |
| Agent name and agent inventory ID | Link to governance inventory |
| Owner | Named model owner |
| Business use | Purpose and process |
| Models used | Model, version, provider, role in the agent |
| Inputs and sources | Data and systems, with provenance |
| Outputs | What the agent produces |
| Actions and depth | The agent's certified depth, and the depth each action needs |
| Reliance | Who relies on outputs and how |
| Impact limits | Bounds that cap harm |
| Tier | Per your tiering method, with reasoning |
| Validation status | Date, scope, findings, next due |
| Known limitations | Listed |
| Monitoring | Measures, thresholds, frequency |
| Change triggers | Events that require revalidation |
| Approved for use by | Named approver and date |
A filled example
A hypothetical regional bank's commercial lending agent.
| Field | Entry |
|---|---|
| Business use | Prepares credit memos for commercial loan applications from financial statements and account history |
| Models used | General-purpose language model (provider and version recorded) for extraction and drafting; in-house cash flow scoring model for indicative rating |
| Inputs and sources | Financial statements uploaded by applicant (external); account history from core banking (sealed); bureau data (signed) |
| Actions and depth | Extract figures: 1. Calculate ratios: 3. Draft credit memo: 2. No action on credit decisions |
| Reliance | Credit analysts review and edit memos; credit committee decides |
| Impact limits | Memo is a draft; ratio calculations re-run independently by the scoring model; figures from external statements flagged for analyst check |
| Tier | Tier 2: material input to credit decisions, but every output reviewed by a person before use |
| Validation status | Initial validation complete; findings: extraction errors on scanned statements; next due in 12 months |
| Known limitations | Poor extraction from low-quality scans; does not handle consolidated group accounts |
| Monitoring | Analyst edit rate on extracted figures; ratio mismatches with scoring model; monthly |
| Change triggers | Change of language model version; new statement formats; any rise in depth |
Notice the tier reasoning. The agent supports material decisions, but its depth is capped at drafting for anything that matters, which limits the impact of a model error. If the bank later let the agent's ratings feed approvals directly, the tier would rise and revalidation would be needed.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Is the underlying language model the model, or is the agent?
Both, in practice. Record the agent as the inventory item, because that is what the business relies on, and list each underlying model within it with its own version.
Does a vendor model need validation?
Yes, proportionate to its tier. You may not see the vendor's internals, so validation focuses on outputs in your use, conceptual soundness from the vendor's documentation, and ongoing monitoring.
What triggers revalidation for an agent?
A change of model version, a new capability, a rise in depth, a new data source, or monitoring results outside thresholds.