Tracking and Remediating AI Findings Outside SR 26-2 Model Risk Processes

Where SR 26-2 stops and other governance starts

SR 26-2 was issued on April 17, 2026 by the Federal Reserve, OCC and FDIC. It rescinds prior model risk management guidance and asks for practices that are risk-based, tailored, and commensurate with size, complexity and extent of model use. Its principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. Footnote 3 states that generative AI and agentic AI models are novel and rapidly evolving and are not within the scope of the guidance.

For tools, processes or systems the guidance does not cover, it says a banking organization's own risk management and governance practices should determine the appropriate governance and controls. In a May 2026 speech, Governor Bowman said the guidance now applies narrowly to traditional models and basic AI applications, and that supervisors expect other risk management and governance practices to support generative and agentic AI adoption.

The boundary therefore turns on system type, not finding type. A policy violation in a single interaction, an unsafe tool call, sensitive data exposure and coding assistant output with unclear provenance typically arise in generative or agentic systems. SR 26-2 does not name these categories, so their out-of-scope status is an inference from the system type. A traditional or non-generative model that deviates from expected performance stays within validation, outcomes analysis and monitoring. The term "basic AI applications" is not defined, so a bank should document its determination and rationale for borderline systems.

No supervisory text prescribes how to manage issues for non-model AI findings. The workflow below is a design recommendation, not an examiner requirement.

Routing findings across the boundary

Apply the boundary test at intake and record the result. The routes below show how common findings are likely to split.

• Policy violation in a generative AI interaction: Non-model AI workflow. The system is generative, so SR 26-2 does not apply.
• Unsafe tool call by an agent: Non-model AI workflow. Agentic systems are excluded from scope.
• Sensitive data exposure in a prompt or output: Non-model AI workflow. Also notify the privacy and compliance functions that already own data handling.
• Coding assistant output with unclear provenance: Non-model AI workflow. Record origin, licence and security context as part of the finding.
• Traditional or non-generative model outside performance thresholds: Model risk management. Validation, outcomes analysis and monitoring apply.
• Non-model finding that implicates an in-scope model: Both. Keep the finding open in the non-model workflow and hand off to model validation.

How runtime enforcement closes findings and produces evidence

Many recurring findings are best fixed where the interaction happens. When a policy decision sits in the execution path, a remediation such as a redact or block rule becomes a testable control instead of documented intent. Each decision (allow, redact, block, rate limit or escalate for human approval) can record what was evaluated, the policy identifier and version, the action taken and, for escalations, the approver. This is a design pattern, and a bank should confirm with its own risk and audit functions that the records meet its closure standard.

Consider a recurring finding of sensitive data appearing in prompts to a generative assistant. The remediation is a redact rule. Closure verification then means showing enforcement records for matching events after the rule's effective date, each tied to the rule version, along with the finding ID. The verifier checks the records, not the owner's assertion. Escalation for human approval works similarly for higher-risk tool calls: the approval record becomes part of the trail.

There are tradeoffs. Blocking adds friction for users, human escalation adds latency and reviewer workload, and rate limits can mask a problem rather than fix it. Severity should drive which action a rule takes, and the choice should be recorded with the finding.

Trussed 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. It also provides code provenance covering the origin, licence and security context of code, which is relevant to coding assistant findings. Enforcement generates audit-ready evidence mapped to NIST, among other frameworks, and deployment is self-managed in the customer cloud with configurable retention and data residency.

Connecting the workflow to existing functions

Document the non-model workflow as part of the bank's risk management and governance practices, since that is where SR 26-2 directs out-of-scope systems. Avoid building a parallel structure. The register should sit in the existing issue management system, use its severity scale where possible, and report through the same committees as operational, compliance and third-party findings. Frameworks the bank already uses for AI risk, including ones that predate SR 26-2, remain relevant.

Define handoffs in both directions. A finding that reveals a performance problem in a traditional or non-generative model should reach validation and monitoring, and model risk should know how to refer generative or agentic findings back to the non-model path. Findings involving third-party AI services should also reach third-party risk owners.

The boundary may move. The agencies plan a request for information on model risk management and bank use of AI, including generative and agentic AI, and the Fed is updating its third-party risk management guidance. Schedule a review of the workflow when those materials are issued.

A practical start is to list AI systems by type, mark each as in or out of model inventory scope, and migrate open findings into one register with the fields above. Then pick the one or two recurring finding types where an enforcement rule can be tested and closed with evidence.