SR 26-2 Model Risk Management: Examiner Expectations and the Evidence AI Systems Need

What changed with the April 2026 guidance

On April 17, 2026, the Federal Reserve, the OCC and the FDIC issued revised interagency model risk management guidance. The Fed published it as SR 26-2 and the OCC as Bulletin 2026-13. The Fed states that the agencies updated the guidance based on supervisory experience and industry feedback since SR 11-7. The update clarifies principles and emphasizes an approach tailored to the institution's model risk profile and to the size and complexity of its operations.

The guidance addresses the factors that influence model risk, features of effective model development and use, model validation and monitoring, and governance and controls. The OCC bulletin also covers vendor and other third-party products. As of November 2026, the OCC has rescinded its Comptroller's Handbook booklet on model risk management and Bulletins 1997-24, 2011-12 and 2021-19. The FDIC has rescinded FIL-22-2017, which had adopted SR 11-7 and OCC 2011-12, and FIL-27-2021.

Two practical points follow. Policies and procedures that cite the rescinded OCC and FDIC issuances need review. Applicability also needs confirming with the primary supervisor: the FDIC states that the guidance generally does not apply to models at banking organizations with total assets of $30 billion or less, to the extent they lack significant model risk exposure. The OCC describes generative AI and agentic AI models as novel and rapidly evolving, which signals that these systems are within the supervisory conversation.

Where examiners are likely to probe AI in production

Public statements on generative and agentic AI are brief, so institutions should expect examiners to apply the guidance's general principles to these systems. Those principles point to a few predictable areas.

Ongoing monitoring is the first. Monitoring evaluates whether a model performs as expected given changes in products, exposures, activities, clients, data relevance or market conditions. For a generative model or an agent, an examiner can reasonably ask what was monitored, how often, and what happened when behavior drifted.

Governance and documentation come next. Governance should rest on clear policies and effective controls, with responsibility assigned across the model lifecycle, and adequate documentation supports all of it. Where internal audit is part of the program, its role is to evaluate whether practices are rigorous and effective and whether policies are implemented, not to duplicate development or validation.

The gap for AI is that an inventory, a pre-deployment validation report and a periodic review show what a system was approved to do. They do not show what it was permitted to do on a given day, or what it did. That is the question an examiner reaches when testing control effectiveness, change management and documented limits on use.

Relating SR 26-2 to the NIST AI RMF

SR 26-2 and the NIST AI Risk Management Framework are separate instruments, and any mapping between them is an institutional choice rather than part of the guidance text. Many institutions still use the framework's four functions, Govern, Map, Measure and Manage, as a shared vocabulary.

Under that vocabulary, policies, assigned responsibilities and documentation sit mainly with Govern. Inventory and use-and-limits documentation align with Map. Ongoing monitoring and control-effectiveness evidence align with Measure. Controls that act on system behavior, and the records of how they acted, align with Manage and feed Measure.

Runtime enforcement at the interaction and tool-call level fits in that last position. It acts on what a system attempts to do and records the outcome. It does not evaluate model performance, validate conceptual soundness or establish where a model came from. Those tasks stay with validation and governance, and the examination record should show both layers working together.

Runtime policy enforcement as one part of the record

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each interaction or tool call is allowed, redacted, blocked, rate limited or escalated for human approval. Policy is enforced at runtime, not reviewed after the fact, and the enforcement itself generates audit-ready evidence: what policy applied, what decision was made, and who approved any escalation. Evidence is mapped to frameworks including NIST, and deployment is self-managed in the customer cloud with configurable retention and data residency.

The scope is deliberate. Trussed does not provide model development, validation, model lineage or transaction-level governance, and it does not discharge the institution's governance obligations. It supplies the interaction-level and tool-call-level part of the examination record that inventories and periodic reviews cannot.

Trussed is deepest in insurance, a regulated financial sector, and has customers in four regulated verticals: insurance, pharma, healthcare and education. It has run 18+ months in continuous production in a regulated enterprise, with 99.95% uptime on live production traffic, 100+ models under one policy plane, and 30+ GB of audit evidence generated per day.