SR 26-2 Bank Board and Senior Management Expectations for AI and Model Risk

What changed with SR 26-2

SR 26-2, Revised Guidance on Model Risk Management, was issued on April 17, 2026. It supersedes and replaces SR 11-7 (April 2011) and SR 21-8 (April 2021). In connection with the release, the FDIC is rescinding FIL-22-2017 and FIL-27-2021. The agencies say they updated the guidance based on supervisory experience and industry feedback since SR 11-7, clarifying principles and emphasizing a risk-based approach tailored to a bank's model risk profile and the size and complexity of its operations. The Fed letter says the guidance is expected to be most relevant to banking organizations with over $30 billion in total assets that the Federal Reserve regulates.

Two features shape how boards and senior management should read it. The guidance does not set forth enforceable standards or prescriptive requirements, and non-compliance with it will not result in supervisory criticism. It also states that each bank is ultimately responsible for adopting model risk management practices that are appropriate and effective for the specific risks it faces or is likely to face.

A reasonable reading is that the question for oversight shifts from whether a bank followed a checklist to whether its risk management works. That is an interpretation, not a statement in the guidance, but it explains why documented policy alone is a weak answer to an examiner's question.

Where AI systems sit relative to the guidance

In a May 1, 2026 speech, Governor Bowman said the agencies amended the model risk guidance to clarify that it does not apply to generative or agentic AI. She said supervisors had expanded the previous guidance beyond its original purpose, and that other risk-management and governance practices are expected to support adoption of these technologies. The guidance itself says a bank's risk management and governance practices should guide the controls for any tools, processes or systems it does not cover.

This means SR 26-2 does not prescribe controls for generative or agentic AI, and it does not prescribe any particular technology. It does leave accountability with the bank. Materiality still matters: the guidance is generally most useful for models supporting significant business lines, operations, services and functions, and higher-materiality models warrant more comprehensive and rigorous oversight. Vendor-provided AI adds a further question. Governor Bowman said the Fed is working to update its third-party risk-management guidance and raised questions about expectations for vendor-provided AI tools.

A practical first step is to sort the AI inventory into three groups.

• Models in scope: Quantitative methods and systems the bank treats as models under SR 26-2, tiered by materiality.
• AI outside the guidance: Generative and agentic AI, which the Fed has said falls outside the revised guidance.
• Bank-governed systems: Tools and systems controlled under the bank's own risk and governance framework, including vendor-supplied components.

Dividing oversight and execution

SR 26-2 is risk-based and leaves structure to each bank, so the division below is a practical reading rather than a restatement of the guidance. Examination procedures in the FDIC's manual point to the same themes. They assess whether management has established policies commensurate with risk, complexity and materiality, whether duties across model developers, owners, users, validators, auditors, committees and the board are detailed, and whether the risk information presented to the board is sufficient for oversight. The voluntary NIST AI RMF Govern playbook similarly suggests policies that define AI risk roles for boards or advisory committees and senior management, with management declaring risk tolerances.

• Board or committee: direction and challenge: Sets risk appetite and policy direction, receives risk reporting on AI-enabled systems, and can show that it questioned what it was told. Evidence: minutes, reporting packs, approved policies and risk limits.
• Senior management: implementation: Maintains the inventory, assigns materiality tiers, defines roles and escalation paths, and keeps internal policies aligned to SR 26-2. Evidence: inventory, tiering rationale, role definitions, approval records for policy changes.
• Model owners, users and validators: execution: Operate, use and independently review the systems within defined duties. Evidence: documentation, validation results, issue tracking.
• Production runtime: behavior: What each system was actually permitted to do, and what it did. Evidence: per-interaction records of the policy applied and the action taken.

Policy defined in advance versus policy enforced at runtime

Most banks can produce policy documents. Fewer can show how a policy applied to a single interaction or tool call in production. The distinction matters most for generative and agentic systems, which act through prompts, retrieved data and tool calls rather than a fixed, validated calculation.

A policy defined in advance states what should happen. Review after the fact samples what did happen, usually weeks later and usually incompletely. Enforcement in the execution path is different: a policy decision is made as the interaction occurs, with outcomes such as allow, redact, block or escalate for human approval. The decision and the policy that produced it can be recorded at the same moment.

No supplied guidance requires or endorses this approach, and SR 26-2 does not prescribe technology. It is a design choice a bank may make under its own framework. The reasoning is straightforward: if boards set risk limits, those limits are only as credible as the mechanism that applies them in production. Per-interaction records of the policy applied and the action taken could also serve as evidence of what a system was permitted to do. The same logic extends to vendor-supplied AI, where evidence collection would need to cover components the bank does not build.

Where Trussed fits

Trussed addresses the last item above, not the guidance as a whole. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. Actions include allow, redact, block, rate limit and escalate for human approval. Enforcement produces continuous audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Trussed's deepest experience is in insurance, a regulated financial sector, and its customers span four regulated verticals: insurance, pharma, healthcare and education. Approved operating proof includes 18+ months of continuous production in a regulated enterprise, 99.95% uptime on live production traffic, 100+ models under one policy plane, and 30+ GB of audit evidence generated per day. SR 26-2 does not require any specific technology, and runtime enforcement is one way a bank could support the evidence its oversight needs.