SR 26-2 AI Scope Determination: How Banks Classify AI Use Cases

What the current guidance changes for AI scoping

Many scoping procedures were written on the assumption that copilots, document summarization and agent-assisted workflows would be inventoried as models. SR 26-2 changes that starting point. Two comment letters on the Federal Reserve's site quote footnote 3 as stating that generative and agentic AI models are not within the scope of the guidance. A commenter also reports that deterministic rule-based processes are excluded from the model definition.

Those are characterizations of the text, so a scoping procedure should not rest on them. The model risk policy should quote the SR 26-2 definition, the scope language and footnote 3 directly, and state how generative and agentic AI are treated. Every scope decision then cites the same exact wording.

Out of scope does not mean ungoverned. The guidance says that for tools, processes or systems outside its scope, a banking organization's risk management and governance practices should guide the determination of appropriate governance and controls. The guidance also says the relevance of model risk depends on the nature, scale and use of models in relation to the associated business risks. Both statements shape the test below. The OCC's guidance, issued the same day, likewise says practices should be risk-based and commensurate with a bank's size, complexity and extent of model use.

Worked examples: in scope, out of scope and borderline

Consider a staff copilot that drafts internal emails and summarizes meeting notes. It is a generative system, so the footnote 3 language is the controlling text for step 2. If the quoted text excludes it, the outcome is out of scope, with the rationale citing the footnote. The record should then name the internal controls that apply, such as acceptable use, data handling and output review, because the guidance points to the bank's own practices for such systems.

A document summarization tool that condenses loan files for underwriters follows the same definitional path. Reliance and materiality still matter, because they determine how strong the internal governance must be. A summary that an underwriter reads alongside the source documents carries different risk from one the underwriter relies on instead of them.

An agent-assisted workflow raises the action question. If an agent can call tools that change records or trigger payments, the output is no longer only text. The scope outcome may still be driven by footnote 3, but the internal controls need to cover tool permissions, data access and human approval points.

A statistical or machine-learning scoring model that produces quantitative estimates used in credit decisions is the kind of system most likely to meet the model definition. It should be tested against the quoted text and, if it meets it, inventoried and managed under SR 26-2, including effective challenge across the lifecycle.

Borderline cases tend to be hybrids. An LLM that extracts fields from documents and feeds them into a scoring model is one example. The scoring model is assessed on its own. The upstream extraction step needs its own recorded determination, because the in-scope model now depends on its output. A rules engine that a vendor describes as AI is another. Test what the system actually does, not the label, and record the deterministic or non-deterministic basis for the conclusion.

Borderline cases, independent review and re-scoping

Borderline decisions deserve more than one signature. The guidance describes effective challenge as critical analysis by objective experts across the model lifecycle. Applying independent review to borderline scope calls is a reasonable design choice, though the guidance does not require it. The record should show who approved the call and why, and the scoping procedure should align with the model risk policy's framework for assessing the magnitude of model risk.

A scope decision describes a use case at a point in time. An out-of-scope use case can drift toward in-scope behavior when it gains a new tool, a new data source, or a downstream process that begins to rely on its output. The sources do not provide a regulatory list of re-scoping triggers, so these are practitioner suggestions: a new tool or integration, new data access, a change in the population affected, a new downstream consumer of the output, a material vendor model change, and a change from human-reviewed to automated use. Each trigger should force the six-step test to be rerun, with the prior record retained.

Depth should match the institution. The guidance recognizes that practices appropriate for one organization may be inappropriate for another with a different risk profile or a different use for a model. A smaller bank can run a lighter version of this process, as long as it is consistent and documented.

Showing a use case stays within its approved scope

A scope decision is a design-time determination. It states what a system is supposed to do and which controls apply. It does not show what the system did last Tuesday. For out-of-scope and borderline systems, the guidance places the question of controls with the bank's own risk management and governance practices, so how a bank demonstrates ongoing compliance with its approved boundaries is an internal design decision. It is not a requirement of SR 26-2.

Trussed addresses that gap in the execution path. It enforces policy at runtime, not after the fact, on individual interactions and tool calls across models, agents, tools and MCP servers. Each request can be allowed, redacted, blocked, rate limited or escalated for human approval, and that enforcement produces audit-ready evidence of what an AI system was allowed to do and what it did. Evidence is mapped to frameworks including NAIC, NYDFS, EU AI Act and NIST. Trussed runs in production for regulated enterprises, with 100+ models under one policy plane and 30+ GB of audit evidence generated per day. Its customers are in insurance, pharma, healthcare and education.

For a risk leader, the relevance is narrow and practical. If a scope record says an agent may read certain data and may not issue payments without approval, enforcement evidence can show whether that held. That supports the conversation with examiners about model risk management without relying on a pre-deployment review alone.