How Banks Should Record Excluded Generative AI and AI Agents in an SR 26-2 Model Inventory

What SR 26-2 says and what it leaves to the bank

SR 26-2, issued with OCC Bulletin 2026-13 on April 17, 2026, updates the agencies' model risk management guidance. It defines a model as a complex quantitative method, system or approach that applies statistical, economic or financial theories to process input data into quantitative estimates. Simple arithmetic and deterministic rule-based processes without such theories are outside that definition.

Footnote 3 addresses AI directly: generative and agentic AI models are novel and rapidly evolving, but the principles apply to traditional statistical and quantitative models and non-generative, non-agentic AI models. In a May 1, 2026 speech, Fed Governor Bowman said the amendment clarifies that the guidance does not apply to generative or agentic AI, and that the Fed expects other risk-management and governance practices to support their adoption. As of November 2026, the guidance is non-enforceable and non-compliance with it will not result in supervisory criticism.

On inventories, the guidance says maintaining comprehensive information on models is common industry practice, with detail varying by complexity and usage. An effective inventory holds enough information to understand model risks individually and in aggregate. It does not set fields or exclusion documentation for AI that falls outside scope. Anything beyond that is the bank's own design, and the page below treats it that way.

Treat the exclusion as a documented decision

A generative or agentic system may or may not satisfy the guidance's model definition. Because footnote 3 and the Governor's remarks place these systems outside scope regardless, the inventory should record the scope decision itself, not only a definitional analysis. An unrecorded system and a recorded exclusion look very different when someone asks what AI is in use and why it sits outside model risk management.

Keep excluded systems in a separate category or flag, with a cross-reference to the in-scope model inventory. That lets reporting show two clear populations: in scope, and excluded with rationale. It also prevents business lines from classifying similar systems differently, because each exclusion follows one bank-wide record structure.

Two supporting practices help. NIST AI 600-1 says to enumerate generative AI systems for the inventory and to define any inventory exemptions in policy, including for generative AI embedded in application software. The NIST Playbook also points to naming a person or team responsible for maintaining the inventory. Record the institution's own applicability too: the guidance is expected to be most relevant to banks with over $30 billion in total assets, and smaller banks' models typically fall under internal governance practices suited to their size and risk.

Inventory fields for an excluded generative AI system or agent

The fields below are a proposed schema, not an SR 26-2 requirement. They draw on the guidance's inventory purpose and on items NIST AI 600-1 suggests for generative AI entries. Adjust depth to risk, since the guidance itself accepts that inventory detail varies.

• System identity and use case: Name, description, business use case and the decision or process the output supports.
• Exclusion rationale and approval: The stated basis, such as footnote 3 or the model definition, plus approver, approval date and the policy that permits the exclusion.
• Ownership and oversight: Named business owner and the human oversight role and responsibilities for reviewing outputs or actions.
• Underlying model and provider: Foundation model, version, access mode and provider, with a note on how third-party version changes are tracked and escalated.
• Tools, data and system access: Every tool, data source and connected system the agent can reach, and any special rights over sensitive data or intellectual property.
• Compensating controls and review: Controls that replace model risk management activities, the governing framework, known issues, review date and reclassification status.

How agentic behavior complicates the exclusion

An exclusion that is easy to justify for a drafting assistant is harder for an agent that calls tools, acts with some autonomy and chains multiple steps. The scope decision may be unchanged, but the risk profile is not. The inventory should therefore record what the agent can do, not only what it is. Tool and data connections matter because they define the reachable impact of a bad output.

The bank should define reclassification triggers in its own policy, since no official triggers exist for moving an excluded system into scope. Candidate triggers a bank might adopt include an agent output being used as a quantitative estimate in a decision, a change in the underlying model or its behavior that alters the use case, expanded tool or data access, and a shift from human-reviewed outputs to autonomous action. Each trigger should name who reassesses the entry and how the change is recorded.

There is also a control continuity issue. When a system leaves the model inventory, it can also leave change control, documentation standards and performance evidence unless the bank substitutes equivalents. Recording compensating controls in the entry is how that substitution becomes visible and reviewable.

Compensating controls and the evidence behind them

Governor Bowman's statement implies other governance practices should cover these systems, but SR 26-2 does not list them. A bank can choose from practices already described elsewhere. FINRA's 2026 oversight report, which addresses broker-dealers and is not a bank requirement under SR 26-2, cites storing prompt and output logs, tracking which model version was used and when, human-in-the-loop review of outputs, and maintaining an inventory of third-party vendor services. NIST AI 600-1 is voluntary but offers similar inventory considerations.

Whatever the bank selects, the test is whether each recorded control can be substantiated. An entry that says outputs are reviewed by a human, or that an agent cannot reach certain data, is a claim. A review of a policy document shows the intent. Evidence that the control operated on actual interactions shows the behavior. Reviewers asking what governs the system at runtime are likely to look for that difference, so it is worth planning the evidence for each control when the entry is written, not after a question arrives.

Practical retention questions follow: which records are kept, for how long, where they reside, and how they are retrieved against a specific inventory entry. Answer them in the entry or in the policy it references.

Where runtime policy enforcement can support the record

Trussed is control, provenance and evidence infrastructure for consequential AI. It enforces policy in the execution path across models, agents, tools and MCP servers. Enforcement at the level of individual interactions and tool calls can allow, redact, block, rate limit or escalate an action for human approval. For an excluded agent, that gives a bank a way to implement several recorded compensating controls at runtime, not by review after the fact. Examples include limiting which tools an agent may call, redacting sensitive data before it reaches a model, and requiring human approval for defined actions.

The same enforcement generates continuous audit-ready evidence, mapped to frameworks including NIST. An inventory entry can then reference the policy applied and the evidence produced, so the control described in the record and the control observed in operation can be compared. Trussed's deepest experience is in insurance, another regulated sector, and it runs 100+ models under one policy plane. This page does not claim bank deployments.

This is a supporting layer, not a substitute for the inventory. The scope decision, rationale, ownership and reclassification triggers remain bank decisions recorded in the bank's own systems, and Trussed does not provide model lineage or end-to-end tracing of agentic workflows.