SR 11-7 and Banking AI Model Risk After SR 26-2
SR 11-7 was superseded by SR 26-2 on 17 April 2026. For banks using LLMs and agents, SR 26-2 keeps the model-risk-management disciplines of governance, independent challenge plus monitoring and outcomes analysis while expressly placing generative and agentic AI outside its direct scope. This guide explains the governance decision plus production-review evidence and the limits of request-layer controls.
On 17 April 2026, the three federal banking agencies issued SR 26-2, superseding SR 11-7 and SR 21-8 for the model-risk-management guidance it covers. That change alters the answer to "SR 11-7 compliance AI": a bank can use SR 11-7's validation vocabulary to understand a legacy program, but it needs a documented governance decision for each LLM or agent because SR 26-2 expressly puts generative and agentic AI outside its direct scope.
I would preserve the disciplines, then stop calling an LLM automatically SR 11-7 compliant. A model owner needs an approved purpose, a materiality assessment, independent challenge, production monitoring, and an escalation route for evidence that changes the risk decision. The paper trail belongs in the bank's governance program, not in a vendor feature list.
TL;DR
SR 11-7 remains relevant search vocabulary and a legacy reference, but SR 26-2 is the current supervisory letter. Its direct scope excludes generative and agentic AI. Banks still need their own governance and controls for LLM use, including an approved purpose, a validation approach, and accountable ownership supported by monitoring evidence.
What SR 26-2 changed
SR 26-2 replaces the older guidance for the covered model-risk-management program and retains a familiar operational pattern: board and senior-management oversight, model inventory, independent validation, ongoing monitoring and outcomes analysis, plus effective challenge. Its calibration is tied to model materiality and risk rather than a uniform review rhythm. Footnote 3 is the decision point for this article: generative and agentic AI models sit outside the letter's scope, while a bank's own risk-management and governance practices still determine the controls it applies.
That leaves a practical bank question. An LLM that drafts a decision explanation or classifies and ranks a loan file may influence a decision even where SR 26-2 does not prescribe the exact LLM control set. The bank must decide and record how its existing model-risk process extends to that use case.
The SR 11-7 framework banks still recognize
The SR 11-7 text remains useful historical context. It described model risk as potential adverse consequences from incorrect or misused model output and organized the program around development and validation, with governance. SR 26-2 is now the primary supervisory source for the covered program.
Sound development and use
The first pillar asks for disciplined model development with a clear statement of purpose, sound data, plus documented assumptions and limitations. For a vendor LLM the bank did not train, the development record is thin, so the bank documents the use: which decisions the model informs and known limitations, alongside the model version with its approved route and intended reliance.
Effective challenge through independent validation
The second pillar is validation, and its core is effective challenge, meaning critical review by objective, informed parties who can and will identify problems. Validation covers conceptual soundness plus ongoing monitoring and outcomes analysis. A language model resists conceptual-soundness review because its internals are opaque and its output varies run to run, which means the validation team leans harder on monitoring and outcomes than on inspecting the mechanism.
Governance and controls
The third pillar puts model risk under board-approved policy with clear roles across three lines of defense: the model owners, an independent model risk management function, and internal audit. Governance requires a model inventory recording each model with its owner and validation status. AI model inventory management covers that artifact.
Why effective challenge breaks on an opaque model
Effective challenge assumes the reviewer can inspect the model's construction and reason about its behavior. A third-party language model gives the validation team no weights, no training data, and no guarantee that today's responses match last quarter's. The classic validation techniques, sensitivity analysis and conceptual review, have limited reach against a system that is non-deterministic and hosted elsewhere. What remains is the empirical half of validation: ongoing monitoring of live behavior and outcomes analysis against actual results. That half depends entirely on having a record of what the model was asked and what it returned in production, at the granularity of individual requests. A bank that monitors only aggregate accuracy has no way to challenge a specific decision after the fact.
The production monitoring gap
SR 11-7 treated validation as an ongoing activity, and SR 26-2 continues to name ongoing monitoring and outcomes analysis. For a language model in a live workflow, a bank's own monitoring plan should identify the approved use, model route, calling application, release version, sampling method, escalation threshold, and reviewer. Capturing prompts or responses creates privacy, retention, and data-classification obligations, so the evidence design needs minimization and access controls rather than indiscriminate collection.
When an examiner asks a model-risk function to demonstrate ongoing monitoring of an LLM, aggregate uptime and token counts are thin evidence. The stronger record ties reviewed behavior to the actual routed request, the authenticated caller, applicable policy, outcome, and model version, while preserving the privacy limits the bank chose. This is the request-layer visibility gap covered in the broader AI compliance map for banking and the NIST AI RMF.
DeepInspect
This is production evidence a bank can use in its LLM governance program, and it is what DeepInspect produces for routed HTTP AI traffic. DeepInspect is a stateless proxy on the AI request path between a bank's authenticated applications or agents and the LLM endpoints they call. It binds each policy decision to the authenticated identity and model route, then commits a per-decision record that the model-risk function can review alongside its validation and outcomes-analysis work.
It also enforces scope on those routed LLM calls. The governance program approves a model for specific uses, and DeepInspect applies identity-bound policy before the request reaches the provider. Model development, validation, local agent execution, tool authorization, and credit-decision governance retain their own owners. The inventory, monitoring record, and route-policy evidence support review without pretending that one proxy completes the whole program. Book a demo today.
Frequently asked questions
- Is a large language model a model under SR 11-7?
SR 11-7's functional definition helps explain why banks historically brought AI-assisted decisions into model-risk programs. The current answer requires SR 26-2 as well: its footnote 3 excludes generative and agentic AI from direct scope. A bank should document the governance decision for each LLM deployment, especially when its output informs a customer, fraud, credit, or compliance workflow.
- How do you validate a third-party LLM you cannot inspect?
Validation shifts toward evidence the bank can obtain: approved purpose and limitations, test cases tied to the use case, model and prompt-change review, sampled production evidence, outcome review, and escalation criteria. Production telemetry is one input, provided it respects the bank's data-handling rules. Effective challenge of an opaque model is only as strong as the evidence the independent reviewer can examine.
- What does ongoing monitoring mean for a language model?
It means capturing production behavior and analyzing it over time for drift, anomalous output, and use outside approved scope. For an LLM that requires recording the prompts, responses, and calling identities, then reviewing them against the model's documented purpose. Aggregate accuracy metrics miss the specific decisions an examiner or an adverse-action inquiry will ask about, so monitoring has to reach individual-request granularity to satisfy the guidance and to support outcomes analysis.
- Where does the model inventory fit?
The governance pillar requires an inventory recording every model in use, its owner, and its validation status. For AI, the inventory has to reflect which models applications and agents are actually calling, which frequently diverges from the approved list once teams add a new provider. Deriving the inventory from observed request traffic, rather than a manually maintained spreadsheet, keeps it accurate and surfaces shadow model usage that the governance function needs to bring into scope.