SR 26-2 Gap Assessment Template for Bank AI Platform Owners: Scope Generative and Agentic AI First

Scope comes first: what changed in 2026

The Federal Reserve issued SR 26-2, Revised Guidance on Model Risk Management, on April 17, 2026. The OCC issued updated model risk management guidance the same day and said it serves in part to rescind prior model risk management guidance and other issuances. The guidance is risk-based and tailored, with practices commensurate with a bank's size, complexity, and extent of model use. The OCC describes its coverage as the factors that influence model risk, model development and use, model validation and monitoring, and governance and controls.

A May 1, 2026 speech by a Federal Reserve Board speaker added a scope point that matters for platform owners. It said the Fed, together with the OCC and FDIC, recently amended the guidance to clarify that it does not apply to generative or agentic AI. As of November 2026, that means a template built on the assumption that SR 26-2 is a binding examiner standard for every AI system is starting from the wrong premise.

The practical response is to treat the template as an internal-policy mapping. It can still borrow SR 26-2 concepts such as documentation, monitoring, and governance, because they are sound ways to organize evidence. Each bank remains responsible for adopting model risk management practices that are appropriate and effective for its own risks, and the scope row should record that decision per system.

How to structure the template

Organize rows by the SR 26-2 areas: development and use, validation and monitoring, and governance and controls. Put a scoping row ahead of them and an exceptions row after them. Every row carries the same columns: expectation, control description, evidence source, gap rating, owner, and remediation action. Add two fields that make the assessment more useful: the policy basis for the row, and a flag for whether the gap is addressable at runtime.

• Scope determination: Record the AI system, model type, whether it is generative or agentic, whether it is treated as in scope of SR 26-2 or governed only by internal policy, the basis for that call, the approver, and the date.
• Development and use: Record documented intended use, use restrictions, and access limits, and whether each is enforced in the execution path or exists only as written policy.
• Validation and monitoring: Record who evaluates reliability and limitations, how model limitations are reassessed over time, and how issues are handled before and after approval for use.
• Governance and controls: Record the policy that sets the risk management framework, the control owner, and the separate role of internal audit.
• Documentation: Record whether documentation supports continuity of operations and durable tracking of recommendations, responses, and exceptions.
• Exceptions and remediation: Record each open gap, its priority, its owner, a target date, and the rationale for the rating.

Where runtime enforcement fits and where it does not

Validation, as described in the guidance, evaluates whether models perform as expected, including reliability and limitations. Validating conceptual soundness means assessing and documenting design, construction, and developmental testing, including data selection. These activities belong to development and validation teams. No runtime control closes a gap in them, so mark those rows as outside runtime control.

Runtime enforcement addresses a narrower question: what was this AI interaction or tool call permitted to do, and what happened? Policy enforced in the execution path can allow, redact, block, rate limit, or escalate an individual interaction for human approval. The enforcement decision itself produces the evidence. A policy that says a model may not return certain data, or that an agent needs approval before a sensitive tool call, is only a documented intent until something enforces it and retains a record of the outcome.

Two cautions. First, the guidance describes ongoing monitoring as assessing model limitations over time and responding to issues. Mapping that to per-interaction enforcement and its records is a framing choice for your template, not a statement in the guidance, so label it that way. Second, evidence of what an AI system was allowed to do and actually did is a design requirement your bank defines. Runtime evidence does not cover model lineage, dataset provenance, or end-to-end tracing of agentic workflows, so rows on those topics need other owners and other artifacts.

Sorting gaps by owner

After rating each row, assign it to the group that can actually close it. This keeps the platform owner from carrying gaps that sit in validation, development, or governance, and it keeps runtime gaps from being buried in a general remediation list.

• Policy written, not enforced per interaction: Runtime-addressable. Owner: platform owner. Remediation: enforce the policy in the execution path and retain the decision record.
• Tool call permissions not evidenced: Runtime-addressable. Owner: platform owner. Remediation: record what each tool call was permitted to do and what occurred.
• Human approval exists only as procedure: Runtime-addressable. Owner: platform owner with business owner. Remediation: escalate for approval in the path and retain the approval record.
• Conceptual soundness and design documentation: Validation and development. Owner: model validation or development lead. Not addressed by runtime controls.
• Data selection and developmental testing: Development and validation. Owner: model developer and validator. Not addressed by runtime controls.
• Policy framework, inventory, internal audit role: Governance. Owner: model risk management function. Internal audit evaluates whether practices are rigorous and effective and does not own the controls.

Recording evidence, ratings, and priority

The evidence source column is where most assessments are thin. For each artifact, record the system that holds it, what it actually shows, whether coverage is complete or partial, the retention period, and who can retrieve it and how quickly. Retention periods and completeness criteria are your bank's decisions, so write them down rather than assuming a default. A control with no retrievable artifact should be rated as a gap even if the policy is well written, because the question under scrutiny is what you can show, not what you intended.

Let ratings follow the risk-based principle in the guidance. A low-volume internal assistant and a customer-facing agent with tool access should not get the same priority, and the rationale column should say why they differ in terms of size, complexity, and extent of model use. Track every exception and remediation action durably, since the guidance notes that documentation supports tracking recommendations, responses, and exceptions.

For crosswalks, add optional columns rather than restructuring the template. The five internal control components (control environment, risk assessment, control activities, information and communication, monitoring activities) work as a cross-reference. If your team maintains a crosswalk to prior model risk management guidance, which the OCC says is rescinded in part, add a column for it. A NIST AI RMF column, for example GOVERN 1.1 on legal and regulatory requirements being understood, managed, and documented, should be marked supplementary. The framework itself says its actions are not a checklist or an ordered set of steps.