SR 26-2 vs NIST AI 600-1: Where Generative AI Sits After the Scope Clarification

What changed, and why the original question shifts

The common framing treats SR 26-2 as a model-centric document whose edges banks must probe to see how far it reaches into generative AI. The current position is more direct. The Federal Reserve issued SR 26-2, Revised Guidance on Model Risk Management, on April 17, 2026. On May 1, 2026, Vice Chair for Supervision Bowman said the Fed, together with the OCC and FDIC, recently amended its model risk management guidance to clarify that it does not apply to generative or agentic AI. She also said supervisors had expanded the scope of the previous guidance beyond its original purpose and applied it in unintended ways.

The guidance's definition of a model points the same way. It excludes simple arithmetic calculations and deterministic rule-based processes where no statistical, economic or financial theories underpin their design or use. The Fed's guidance page also states that it does not set forth enforceable standards or prescriptive requirements, and that non-compliance will not result in supervisory criticism.

For a risk leader, this changes the task. Validation, ongoing monitoring and documentation expectations in SR 26-2 are not the primary supervisory vehicle for generative AI. The bank must decide for itself what control standard applies, and be able to show it followed that standard.

SR 26-2 and NIST AI 600-1 side by side

The documents are complementary rather than competing, because they answer different questions. One describes supervisory expectations for a defined class of quantitative models. The other offers a generative-specific reference for organizations that choose to use it.

• Document type: SR 26-2: supervisory guidance from the Federal Reserve. NIST AI 600-1: cross-sectoral profile of the AI Risk Management Framework.
• Binding force: SR 26-2: states it sets no enforceable standards or prescriptive requirements. NIST AI 600-1: voluntary, and not a supervisory standard.
• Subject matter: SR 26-2: complex quantitative methods that apply statistical, economic or financial theories to produce quantitative estimates. NIST AI 600-1: generative AI.
• Generative and agentic AI: SR 26-2: outside scope, per the Fed's stated position. NIST AI 600-1: the direct subject.
• Control orientation: SR 26-2: governance built on clear policies, effective controls and practices commensurate with risk. NIST AI 600-1: a voluntary reference for trustworthiness considerations in generative AI.
• Examiner relevance: SR 26-2: sets the model risk vocabulary examiners know. NIST AI 600-1: useful for structuring internal policy, but not a test a bank is examined against.

The risks that fall between the two documents

Generative systems differ from the quantitative models SR 26-2 describes in ways that matter for control design. Outputs are non-deterministic, so the same input can produce different results. Behavior is steered by prompts, which are text rather than code under change control. Agents can take actions through tool calls, so an output can become an effect. Many deployments depend on third-party foundation models whose internals the bank cannot inspect.

SR 26-2 does not address these as generative-specific risks because the Fed has placed generative AI outside it. NIST AI 600-1 addresses generative AI but, being voluntary, leaves a bank to decide which parts to adopt and how to evidence them. The gap is therefore one of ownership and proof, not only of subject matter.

Third-party exposure is the clearest open area. The Fed has posed open questions about how third-party risk-management expectations should apply to vendor-provided AI tools or partnerships, and about what aspects of model risk management should apply to AI. Until that is settled, a bank should assign internal ownership for foundation-model and vendor AI risk rather than wait for a supervisory answer.

Being outside the model definition also does not mean no testing expectation exists. One public commenter notes that the FFIEC manual treats rule-based surveillance systems as subject to independent validation even though SR 26-2 excludes deterministic rule-based processes. That is an individual's reading, but it is a reason to check other supervisory materials for systems that are not models under SR 26-2.

What runtime enforcement can close, and what it cannot

Controls applied at runtime act on individual interactions and tool calls. Policy is enforced in the execution path: a request or action is allowed, redacted, blocked, rate limited, or escalated for human approval, and the decision is recorded. This suits risks that appear in a single interaction, such as sensitive data leaving in a prompt, a tool call outside an agent's permitted scope, or an action that needs a person's sign-off.

Runtime enforcement does not close gaps that live elsewhere. Deciding which uses are in scope, validating a foundation model's fitness for a purpose, assessing a vendor, approving policy, and reviewing aggregate performance are governance, validation and process controls. A runtime layer can supply evidence to those processes, but it does not replace them.

• Closable at runtime: Data redaction on prompts and outputs, blocking prohibited tool calls, rate limits, human approval for defined actions, and a per-decision record of what was enforced.
• Needs governance: Use-case inventory, scope determination against the SR 26-2 model definition, policy approval, and ownership of third-party and foundation-model risk.
• Needs validation or testing: Assessing model behavior before deployment, testing for fitness of purpose, and periodic review of whether control intensity still matches risk.
• Needs process controls: Change management for prompts and configurations, vendor due diligence, incident handling, and monitoring of supervisory developments.

Practical sequence for risk teams

A workable order of operations keeps the voluntary and supervisory layers distinct and puts runtime enforcement where it fits. Trussed provides one such layer: it enforces policy in the execution path across models, agents, tools and MCP servers, and generates audit-ready evidence mapped to frameworks including NIST. Its depth is in insurance, a regulated financial sector. This page makes no claim of bank deployments, and the sequence below applies whatever tooling a bank selects.

• 1. Classify uses: Record whether each generative or agentic use falls inside or outside the SR 26-2 model definition, and keep the rationale for hybrid cases.
• 2. Write the policy: Set generative control objectives in internal policy, informed by NIST AI 600-1, and state that the profile is voluntary.
• 3. Assign ownership: Name owners for foundation-model and vendor AI risk, and route them through third-party risk processes.
• 4. Separate the layers: Decide which policy rules are enforced per interaction or tool call and which depend on validation or process controls.
• 5. Define the evidence: Specify what record each control must produce, its retention, and who reviews it.
• 6. Watch supervisory signals: Track further agency communications on third-party and AI-related model risk, and check other supervisory materials that may still apply.