SR 26-2 Proportionality and AI Tools: Scoping, Tiering and Evidence

What SR 26-2 says about proportionality

The Federal Reserve, with the OCC and FDIC, issued revised model risk management guidance as SR 26-2 on April 17, 2026. The guidance states that model risk management should be tailored commensurately to the size, complexity and model risk profile of a banking organization. It says the relevance of model risk depends on the nature, scale and use of models in relation to the associated business risks.

Two further points matter for tiering. The guidance says practices that are appropriate for one organization may be ineffective for another with a different risk profile or model purpose, and each bank is responsible for adopting practices suited to the risks it faces. It also says the rigor of effective testing is commensurate with model complexity and materiality.

The guidance does not hand banks a list of low-risk criteria. It asks policies to define expectations and to establish a framework for assessing the magnitude of model risk and applying practices commensurate with it. Proportionality is therefore a method the bank must write down and apply consistently, not a category it can assert.

Scope comes before tier: the generative and agentic AI carve-out

A Federal Reserve speech dated May 1, 2026 states that the agencies amended the model risk management guidance to clarify that it does not apply to generative or agentic AI. The speech also says supervisors had expanded the previous guidance beyond its original purpose. This changes the starting question. It is no longer how to tier every AI tool under SR 26-2, but which tools fall inside model risk management at all.

A bank should make and record a scope determination for each AI tool. Where a tool is inside scope, proportionality governs how much validation and monitoring it receives. Where a tool is generative or agentic, the bank should document why it sits outside SR 26-2 and which other framework governs it, such as third-party risk or information security. The guidance material does not prescribe how excluded tools should be governed, so that choice is the bank's own to justify.

The practical consequence is that the scope record and the tiering record are separate artifacts. An examiner reading either one should be able to see the reasoning without inferring it.

Candidate criteria for a low-risk tier

SR 26-2 frames proportionality around nature, scale and use, and around complexity and materiality. It does not list AI-specific tiering factors. The dimensions below are internal design choices that many risk teams use to make those concepts operational. They are not guidance text, and each should be defined in policy with thresholds the bank can defend.

A tool qualifies as low risk when it scores low on every dimension, not on average. One high-scoring dimension, such as access to sensitive customer data, should move the tool out of the lightest tier regardless of how modest the others look.

• Materiality: The size of the business risk if the tool is wrong or misused, relative to the bank's overall exposure.
• Data sensitivity: The classes of data the tool can read, retain or transmit, including customer and confidential information.
• Decision impact: Whether outputs inform a human working draft or feed a decision that affects customers or financial reporting.
• Degree of autonomy: Whether a person reviews outputs before action, or the tool can act through connected systems on its own.
• Customer exposure: Whether outputs reach customers directly or stay internal.
• Complexity: How difficult the tool is to understand, test and explain, which drives testing rigor.

What stays expected at lower tiers

Lighter treatment reduces the depth of validation. It does not remove documentation or oversight. The guidance states that adequate documentation supports effective model risk management, and it describes internal audit as evaluating whether practices are rigorous and effective and whether policies are implemented accordingly. A low-risk file should therefore be complete enough for audit to test.

At minimum, each low-risk tool should have an inventory entry, a written rationale for the tier tied to the bank's criteria, and a defined approved use with explicit limits. The bank should document why lighter testing is justified by the tool's complexity and materiality. Ongoing monitoring should still assess the tool's limitations over time and include a procedure for responding to issues before and after approval for use.

Effective challenge applies as well. The guidance describes it as critical analysis by objective, independent experts with appropriate standing. Decide who challenges low-risk tier assignments, how often tiers are revisited, and what triggers reassessment, such as a change in data access, a new connected system or a wider user population.

An evidence standard for low-risk AI tools, and where Trussed fits

A workable standard has three parts. The static file holds the scope determination, tiering rationale, approved use and challenge record. The operational record holds per-interaction and per-tool-call outcomes, so the bank can show what the tool was allowed to do and what it did. The periodic review compares those records against the tier criteria and feeds reassessment. If blocks or escalations rise, or redactions show data the tier should never see, the low-risk designation deserves a second look.

Trussed enforces policy in the execution path on individual interactions and tool calls, with outcomes including allow, redact, block, rate limit and escalate for human approval. That enforcement produces audit-ready evidence, retained with configurable retention and data residency in a self-managed deployment in the customer cloud. Insurance, a regulated financial sector, is where Trussed is deepest. Trussed does not provide model lineage or end-to-end tracing of agentic workflows, so the scope determination, tiering rationale and challenge record remain the bank's own artifacts.

To outline an approach this quarter, start with a scope determination for every AI tool, write the tiering criteria into policy, and decide which per-interaction records you would want to hand an examiner. Then test whether your current controls can produce them.