What SR 26-2 means for a bank Head of AI: from model risk expectations to runtime policy enforcement and audit-ready evidence

What SR 26-2 establishes

The Federal Reserve published SR 26-2 on April 17, 2026. The OCC issued updated model risk management guidance the same day and stated that it rescinds, in part, prior model risk management guidance and other issuances. As of November 2026, no amendment, delay or repeal has been reported.

The guidance highlights sound principles for effective model risk management and recognizes that practices appropriately vary with a banking organization's risk profile and model usage. The OCC describes its coverage as the factors that influence model risk, features of effective model development and use, model validation and monitoring, and governance and controls. It also says practices should be risk-based, tailored and commensurate with size, complexity and extent of model use.

Two statements matter most for a Head of AI. First, each banking organization is ultimately responsible for adopting practices that are appropriate and effective for the specific risks it faces or is likely to face. Second, adequate documentation supports effective model risk management, including continuity of operations, tracking of recommendations, responses and exceptions, and management of model remediation. Both put the burden of design and proof on the bank.

What is stated and what is left to interpretation

The guidance states principles. It does not give a technical specification for runtime enforcement, a log format or a retention period. Whether a particular AI system is treated as a model, and at what tier, follows from the bank's own model definition and risk-based tiering. That classification decision should be documented and defensible, because it determines which practices apply to the system.

Once a system is in scope, the runtime layer is a matter of interpretation. The guidance expects ongoing monitoring that may include regular assessment of model limitations and procedures for responding to issues before and after approval for use. It expects governance supported by clear policies and effective controls. Policies define risk management expectations and set a framework for judging the magnitude of model risk and applying commensurate practices. Internal audit generally evaluates whether those practices are rigorous and effective and whether policies are implemented accordingly.

For generative and agentic systems, behavior is shaped by prompts, retrieved data and tool access at the time of each call. A policy that exists only in a document cannot show that it was applied to a specific interaction. That is the gap a runtime layer is meant to close, and the bank should state in its own framework why it believes the gap is relevant to its examiners.

Evidence gaps between model risk programs and production AI

Inventory, validation reports and model documentation describe a system as it was approved. They do not show what happened on a given day when an agent called a tool, or when a prompt carried customer information to a hosted model. Examiners who ask what an AI system was permitted to do, and what it did, are asking for operational records, not design documents.

Three gaps recur. The first is policy applicability: a written policy exists, but nothing ties it to the specific interaction or the version in force at that time. The second is exception handling: human approvals happen in chat threads or tickets that are not connected to the interaction they authorized. The third is third-party and vendor AI, where the bank cannot see inside the model but can still control and record what goes in, what comes out and which tools are reachable. Vendor arrangements should also be reviewed against the interagency third-party relationships guidance, and customer information handling against the interagency information security guidelines.

Place enforcement inside the bank's broader internal control framework. Internal control, as Federal Reserve supervisory material defines it, is a process providing reasonable assurance of effective operations, including safeguarding of assets, and compliance with applicable laws and regulations. Runtime enforcement should be owned and reviewable like any other control, not treated as an engineering feature.

Where Trussed fits

Trussed is one way to meet these control and evidence requirements. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions that include allow, redact, block, rate limit and escalate for human approval. Enforcement happens at runtime, not after the fact, and it operates on individual interactions and tool calls. The audit-ready evidence it generates comes from that enforcement. Trussed can be self-managed in the customer's cloud, with configurable retention and data residency.

On production record, Trussed has run continuously for more than 18 months in a regulated enterprise, reports 99.95% uptime on live production traffic, and operates 100+ models under one policy plane. It generates 30+ GB of audit evidence per day, and serves customers in insurance, pharma, healthcare and education. Insurance is the regulated financial sector where it is deepest. Trussed does not provide model lineage, dataset provenance or end-to-end tracing of agentic workflows, so those questions need other answers in the bank's model risk program.

A sensible next step is to pick one in-scope AI system, define the policy it should operate under, and test whether the resulting records would answer an examiner's question about a single interaction.