How banks document the boundary between SR 26-2 models and excluded AI systems

What the guidance sets as the boundary

SR 26-2 was issued on April 17, 2026 by the Federal Reserve, OCC and FDIC and replaces SR 11-7. It defines a model as a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates. The definition has two tests: does the method apply those theories, and does it produce quantitative estimates. A classification record should show how each system was tested against both.

The guidance excludes simple arithmetic calculations, such as those in spreadsheets, and deterministic rule-based processes and software with no statistical, economic or financial theories underpinning their design or use. Separately, footnote 3 states that generative AI and agentic AI models are novel and rapidly evolving and are not within the scope of the guidance. Controls for systems not covered are left to each bank's own risk-management and governance practices.

These are different exclusions with different logic, and they should be recorded separately. One nuance matters for AI inventories: the guidance's principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. An AI system is not outside scope simply because it is AI. Exclusion from the model definition also does not necessarily remove other validation expectations. FFIEC material on rule-based surveillance monitoring, for example, still calls for independent validation of programming methodology and effectiveness.

As of November 2026, the agencies plan a request for information on model risk management that will consider banks' use of AI, including generative AI, agentic AI and AI-based models. Criteria written now should be reviewed when it issues.

Build the classification decision record

The guidance does not prescribe a template for scoping decisions, so the following is a practice recommendation. One record per AI system, completed before the system is deployed and revisited on defined triggers, gives business lines a single method and gives examiners a consistent artifact to review.

• System identity: Name, business purpose, intended use, and the specific system and version identifier. A provider or model-family name alone is a weak identifier when versions behave differently.
• Definition tests: A yes or no answer, with reasoning, on whether the method applies statistical, economic or financial theories and whether it produces quantitative estimates.
• Exclusion relied on: Simple arithmetic, deterministic rule-based process, or generative or agentic AI under footnote 3. Where none applies, the system is classified as in scope.
• Rationale: A short narrative a reviewer can follow without the author present, including facts about design that support the conclusion.
• Ownership and approval: A named business owner, the person who made the classification, and an approver independent of the system's developer. The bank remains ultimately responsible for the outcome.
• Compensating controls: For excluded systems, the controls that replace model risk management, such as change control, testing, monitoring and third-party review, with owners.

Inventory treatment and risk-based tailoring

When a system leaves the model inventory, it can also leave the change control, documentation standard and performance evidence that inventory status administers. Exclusion should therefore not mean deletion. Keep excluded AI systems in the inventory with an exclusion status, or in a linked register, and record what each was permitted to do. Without that record, an excluded system has no stated limits against which behavior can later be compared.

The replacement controls need to be designed explicitly. Because the guidance leaves them to the bank's own practices, the exclusion approval should reference the specific controls that apply, connect them to existing third-party risk and operational risk processes, and name who is accountable for each.

The guidance emphasizes a risk-based approach tailored to a bank's model risk profile, size and complexity. It is expected to be most useful for models supporting significant business lines, operations, services and functions, and most relevant to organizations with over $30 billion in total assets. Organizations at $30 billion or less typically fall under internal practices suited to their size, though the guidance may still be relevant where model risk exposure is significant. Whatever tailoring a bank applies, document the choice and the reasoning so that depth of scoping effort is itself a recorded decision.

The gap for systems judged out of scope

A scoping decision records intent. It says what the bank concluded about a system and what the system was meant to do. It does not show what the system actually did. For in-scope models, validation and ongoing monitoring address that. For excluded systems, the bank has to supply its own evidence, and examiners reviewing an exclusion are likely to ask for it.

One way to supply it is policy enforced at the point where AI interactions happen. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval, and enforcement generates audit-ready evidence of what was permitted and what occurred. Policy is enforced at runtime, not reviewed after the fact. Trussed offers self-managed deployment in the customer cloud, with configurable retention and data residency.

In practice, the permitted-use statement in the exclusion record can be expressed as enforceable policy, and the resulting evidence can be compared with that statement. If the record says an excluded assistant may not send certain data categories to external tools, enforcement events show whether such calls were attempted and how they were handled.

The limits matter as much as the capability. Runtime evidence shows only what the enforcement point observed and decided on individual interactions and tool calls. It does not show whether a system meets the model definition, whether its outputs are correct, or how it behaves across a full workflow. Any evidence layer should also be tied to the same system identifier and version recorded in the inventory, so records can be matched to the classification they support. Output correctness, repeatability and behavior after vendor updates still need their own testing under the compensating controls.

Practical next steps

Start by drafting the classification decision record and testing it on a small set of AI systems from different business lines. Differences in how teams complete it will show where criteria need tightening. Next, confirm that every excluded system has an inventory or register entry with a permitted-use statement, a named owner and an approver.

Then assign reclassification triggers to owners, including a way to learn of vendor version changes. Finally, decide which evidence supports each exclusion in operation, and be clear about what that evidence does and does not demonstrate. The result is a boundary that can be explained, re-tested and defended, rather than a list of systems that were classified once.