AI Model Risk Management in Banks Under SR 26-2: Reconnecting AI Spend to Oversight

What changed: SR 26-2 replaces SR 11-7

Many bank policies still cite SR 11-7 as the governing model risk guidance. That reference is out of date. The Federal Reserve, OCC and FDIC issued revised guidance on model risk management as SR 26-2, dated April 17, 2026. It supersedes SR 11-7 and SR 21-8, the interagency statement on model risk management for BSA/AML systems. As of October 2026, policy documents, tiering standards and examiner-facing materials should reference SR 26-2.

The agencies describe the revision as reflecting about fifteen years of supervisory experience and industry feedback. It clarifies principles and emphasizes a risk-based approach tailored to each bank's model risk profile, size and complexity. Practices are expected to vary with risk and model usage. For AI, this has a practical consequence: oversight effort should follow materiality and use, not the channel through which a tool was acquired.

Broader supervisory material on AI points the same way. Institutions are expected to manage AI risk through existing frameworks (model, operational, compliance and third-party risk) rather than a separate regime. Any control added for AI should therefore map to those frameworks.

Where spend decisions and model risk oversight diverge

Spend approval and model risk oversight run on different records. Procurement and budget processes track vendors, contracts and cost centers. Model risk management tracks inventory entries, validation status and tiers. A business line can buy a vendor model, call an LLM API from an internal application, enable a coding assistant or deploy an agent tool entirely within the first process, and the second process never sees it.

Three gaps follow. First, the inventory is incomplete, because AI embedded in vendor tools is rarely a separate purchase. Second, tiering is applied unevenly, because business lines judge materiality on their own. Third, approved-use boundaries exist only as approval documents, with nothing showing they held during operation.

The third gap matters most under examination. Approval documentation shows intent. Operating records show behavior. Guidance on model risk also names use beyond a model's intended purpose as a source of added uncertainty and risk, so a documented boundary that nobody enforces leaves that risk open.

This is a control-alignment problem, not a budgeting problem. Changing who approves spend does not help unless the approval creates or updates a record that model risk management also uses.

Five control points to reconnect the two processes

Each control point should have a named owner. Because AI risk is managed across several frameworks at once, accountability for the shared record needs to be explicit across model risk, procurement, technology and the business lines.

• 1. Shared inventory: Make an inventory entry a condition of spend approval. Include vendor models, LLM API usage, coding assistants, agent tools and AI embedded in third-party products. Existing guidance on third-party approaches supports this scope.
• 2. Risk tiering: Tier each entry by materiality and use. Higher-materiality uses warrant more rigorous oversight. Assess risk in aggregate as well, since common vendors, data or methods across business lines can affect several uses at once.
• 3. Approved-use policy: Define permitted behavior for each entry and tier: which data may be sent, which tools may be called, and which actions need human approval. Write these as rules that can be enforced, not only described.
• 4. Runtime enforcement: Apply the policy where the interaction happens, on model calls and tool calls, using one policy set for all business lines.
• 5. Evidence retention: Keep a queryable record of enforcement decisions, linked to inventory identifiers and tiers, under the bank's own retention and data-handling requirements.

Where runtime policy enforcement fits

Runtime enforcement sits in the execution path between an AI client and the model or tool it calls. For each interaction, it evaluates the request against policy and applies a decision: allow, redact, block, rate limit or escalate for human approval. Because the decision is made on the call itself, the same rules apply whether a business line bought, built or embedded the AI.

The design depends on identifiers. Each enforced policy should reference the inventory record and risk tier that model risk management already uses. When an examiner or internal auditor asks what a specific use was allowed to do and what it did, the answer then connects to the inventory instead of to a separate system with its own naming.

The records this produces are evidence of operation: which policy version applied, what decision was made, and when. Where the bank chooses, they can also capture prompt and output content and the model version used, subject to data-handling rules. FINRA's 2026 oversight report, written for broker-dealers, lists prompt and output logs, model-version tracking and human-in-the-loop review among GenAI practices, and these are the closest published analogues to interaction-level records.

Trussed provides this layer. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, and generates audit-ready evidence from enforcement. It is self-managed in the customer cloud, with configurable retention and data residency. Its production record is general: 18+ months of continuous production in a regulated enterprise, 99.95% uptime on live traffic, and 100+ models under one policy plane. Its deepest experience is in insurance, and it makes no claim of bank deployments.

What runtime enforcement does not cover

Runtime enforcement complements model risk management and does not substitute for any part of it. Conceptual soundness review and validation of AI approaches and third-party models stay with the validation function. Explainability work stays where it is today. Model lineage and training-data provenance are separate disciplines, and institutions have reported an incomplete understanding of where AI training data came from and how models were developed. Interaction-level enforcement does not address that. Transaction-level governance across tasks and agents is also outside what runtime enforcement of individual interactions and tool calls provides.

Effective challenge also remains independent. Guidance describes it as critical analysis by objective experts throughout the model lifecycle. Enforcement records can feed that review by showing how a tool behaved in operation, but they are inputs to challenge, not a replacement for it.

For banks with EU exposure, the AI Act requires a continuous, iterative risk management system for high-risk AI systems and a fundamental rights impact assessment for deployers of certain high-risk systems, such as banking entities. It also states that Union financial services governance and risk-management rules continue to apply. Scope and timing for specific use cases need legal confirmation.