What SR 26-2 means for internal audit's review of bank AI

What SR 26-2 says that matters to audit

SR 26-2, titled Revised Guidance on Model Risk Management, was issued April 17, 2026. The OCC's companion release states that the update serves in part to rescind prior model risk management guidance and other issuances, and that practices should be risk-based, tailored and commensurate with a bank's size, complexity and extent of model use. The guidance covers factors that influence model risk, model development and use, validation and monitoring, and governance and controls.

Two features shape audit work. First, the guidance is supervisory guidance. It states that it does not set enforceable standards or prescriptive requirements, and that non-compliance will not result in supervisory criticism. As of November 2026, audit reports should therefore measure AI controls against the bank's own policies and risk-based practices rather than present SR 26-2 as a mandatory checklist. Second, it describes internal audit's role narrowly. Where internal audit is part of model risk management, it would generally not duplicate model development or validation. It evaluates whether practices are rigorous and effective and whether policies are implemented accordingly.

That second point is the practical center of an AI audit. The question is less whether a model is accurate and more whether the controls the bank says it operates are actually operating.

Setting audit scope for AI

Scope begins with the inventory. The interagency safety and soundness standards describe an internal audit system appropriate to an institution's size and the nature and scope of its activities. For a covered bank, they call for a complete and current inventory of material processes, product lines, services and functions, with risks assessed, including emerging risks, as the basis for the audit plan. AI use belongs in that inventory wherever it supports a material process.

The first scoping decision is classification. Confirm in the bank's model inventory and policy whether generative and agentic AI systems are treated as models, and on what basis. The same question applies to rule-based components such as a policy engine that sits in front of a model: the bank must decide whether it is a model or a control, and the audit approach differs. Do not assume the guidance includes or excludes a given system. Audit the bank's documented decision and its rationale.

Then scale depth to the bank's size, complexity and extent of model use. A bank with a handful of low-impact AI uses needs less than one running AI against customer data or connecting models to internal tools. Keep a clear line between validation evidence, governance evidence and runtime control evidence so that audit tests the controls and does not redo validation.

Which AI controls are actually testable

The guidance pairs clear policies with effective controls. A policy that says sensitive data must not leave the bank, or that high-risk actions require human approval, is not testable until it is implemented in a way that produces observable outcomes. Auditors can test design (is the control specified and enforceable?) and operating effectiveness (did it work on a sample?).

The federal internal control framework gives a useful structure: control environment, risk assessment, control activities, information and communication, and monitoring activities. Most AI policy statements sit in the control environment. The testable layer is control activities, where a rule applies to a specific interaction or tool call and produces a decision. A control that operates only through after-the-fact review is harder to test, because the auditor can see what was reviewed but not what was prevented.

A control is testable when four things are true: it operates on each interaction in scope, it cannot readily be bypassed, it records the decision it made, and that record can be retrieved without relying on the control owner's recollection.

Criteria for evaluating runtime controls

Runtime policy enforcement means a rule is applied inside the execution path, before a model response is returned or a tool call proceeds. These criteria are an auditor's own, not regulatory requirements, but they connect directly to the guidance's emphasis on policies that are implemented and documented.

Enforcement location: does the control sit in the path, or beside it? If a call can reach a model or tool without passing the control, sampling the control's records proves little. Coverage: does it apply to every interaction in scope, including agents, tools and coding assistants? Evidence durability: are records generated by the enforcement itself, tamper-resistant in practice and complete, or reconstructed later from other systems? Retention and residency: can the bank set retention to match its own policy and keep evidence in its chosen region? Deployment: where the bank requires evidence to stay in its own environment, a self-managed deployment is relevant. Independence: can audit query evidence without going through the team that owns the control?

Tradeoffs exist. Enforcement in the path adds a component that must itself be governed, changed under change control and tested. It also does not replace validation of the underlying model, governance of the model inventory or business-line accountability. It makes one class of controls testable.

Where runtime enforcement fits, and what it does not cover

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with decisions to allow, redact, block, rate limit or escalate for human approval on individual interactions and tool calls. Enforcement generates continuous audit-ready evidence, and deployment can be self-managed in the customer's cloud with configurable retention and data residency. The platform has run in continuous production in a regulated enterprise for more than 18 months, and insurance is where Trussed is deepest.

The boundaries matter for audit scoping. Trussed does not provide model lineage, dataset provenance or end-to-end tracing of agentic workflows, so those questions need other evidence. It also does not substitute for model validation or the bank's model risk governance. For an internal audit function, its value is narrower and concrete: a control that is enforced at runtime, not reviewed after the fact, and that leaves records an auditor can sample.

Findings from this work should reach the audit committee or board, which review the effectiveness of the internal audit system. Keep audit testing separate from control ownership and from validation so that independence is preserved.