SR 11-7 for LLMs: model risk management for generative AI

SR 11-7 was the supervisory guidance on model risk management issued by the Federal Reserve and the Office of the Comptroller of the Currency in 2011 (OCC Bulletin 2011-12). It defined model risk as the potential for adverse consequences from decisions based on incorrect or misused model output, and it laid out how a supervised institution should manage that risk across a model's life cycle through three pillars: sound development, implementation, and use; effective independent validation; and governance, policies, and controls. Its definition of a model was broad enough that a large language model producing a score, classification, or decision in a banking process looked like a model under that framework. In April 2026, SR 26-2 (OCC Bulletin 2026-13) rescinded and replaced SR 11-7 and explicitly excluded generative and agentic AI from its formal scope, so an LLM is no longer formally inside the perimeter SR 11-7 once drew.

That exclusion is a deliberate guidance gap, not a green light. Supervisors still expect banks to apply model-risk principles to consequential AI, and the agencies plan a request for information with further AI-specific guidance to follow. The instinct to treat a generative assistant as a mere productivity tool, which leaves it outside the inventory, outside validation, and outside governance, is exactly the instinct examiners push back on. The work of applying model-risk discipline to AI is mostly the work of closing that gap now rather than waiting.

01What SR 11-7 was

SR 11-7 was issued jointly by the Federal Reserve and the OCC as supervisory guidance on model risk management. It built on earlier OCC guidance and became the reference standard for how banks identify, measure, and control the risk that a model creates. Its central idea was that models are useful but fallible, and that the fallibility itself is a risk to be managed, not merely a technical detail.

The guidance defined model risk as the potential for adverse consequences from decisions based on incorrect or misused model output. It then attributed that risk to two sources: a model may have fundamental errors and produce inaccurate output, or a model may be used incorrectly or inappropriately even if it is sound. Both sources still matter for AI, and the second is easy to underweight.

SR 11-7 was principles-based rather than prescriptive. It did not hand institutions a checklist of approved methods; it set expectations and expected each institution to meet them in proportion to the risk a model carries. That proportionality is why a high-stakes credit model and a low-stakes drafting assistant were never held to identical depth of validation.

The development to be precise about is this: in April 2026 the OCC, Federal Reserve, and FDIC issued revised interagency model risk management guidance, SR 26-2 (OCC Bulletin 2026-13), that rescinded and replaced SR 11-7 for covered banks. Traditional quantitative models, such as credit scoring, market risk, and regulatory capital models, remain in scope. The new guidance explicitly excludes generative and agentic AI, stating that those systems are novel and rapidly evolving and are not within its scope, and the agencies plan a request for information on model risk management and banks' use of AI. The SR 11-7 way of thinking about model risk still informs the new framework, and the supervisory expectation to apply model-risk principles to consequential AI does not disappear; it now sits in a deliberate gap rather than in the formal rulebook.

02Why an LLM looked like a model under SR 11-7

SR 11-7 defined a model as a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates. The definition was deliberately broad, and it had three parts: an information input, a processing component, and a reporting component that turns estimates into useful output.

A large language model fit this on its face. It takes input, applies a statistical method learned from data, and produces output. When that output is a credit recommendation, a fraud score, a suitability classification, an alert disposition, or a figure that feeds financial reporting, the LLM is doing exactly what the definition described: turning inputs into quantitative or decision-relevant estimates that a bank acts on. The 2026 guidance ended the formal version of that classification by excluding generative and agentic AI, but the function-based logic is why model-risk principles still fit these systems.

The places an LLM most often crosses into model territory include:

• Credit and underwriting, where a model summarizes or scores an applicant's file and the output shapes a lending decision.
• Fraud and financial-crime surveillance, where a model triages alerts, classifies transactions, or drafts suspicious-activity narratives.
• Financial reporting, where a model produces or supports a number that lands in a control over financial reporting, which pulls ICFR into view.
• Customer-facing decisions, where a model influences pricing, eligibility, or treatment in ways that touch fair-lending and consumer-protection law.

The 2026 guidance carves generative and agentic AI out of the formal model-risk scope, describing those systems as novel and rapidly evolving, with a request for information and further AI-specific guidance expected. Even so, supervisors expect banks to apply model-risk principles to consequential AI. The lesson for practitioners is the same either way: if an LLM influences a decision a regulator cares about, treat it with model-grade discipline now rather than wait for the gap to close. This is the heart of financial services AI compliance.

03The three components examiners expect

SR 11-7 organized model risk management around three reinforcing components, and those principles carry forward as the model-risk discipline supervisors expect banks to apply to consequential AI. An examiner reviewing an AI deployment will still look for all three, and a weakness in any one undermines the others.

Robust development, implementation, and use. The institution should be able to show how the model was built, what data and assumptions it rests on, what its known limitations are, and how it is actually used in production. For an LLM this includes the data the model can reach, the prompts and guardrails around it, and the controls that govern what it is permitted to see and do.

Effective validation by an independent party. Validation is the set of activities that confirm a model works as intended and is suitable for its purpose, performed by people independent of those who built it. It includes evaluation of conceptual soundness, ongoing monitoring, and outcomes analysis. SR 11-7 also recognizes effective challenge, the critical review by competent and independent parties, as the engine that makes validation real rather than ceremonial.

Governance, policies, and controls. The framework that ties the first two together: clear ownership, board and senior-management oversight, policies that define how models are approved and reviewed, and controls that enforce them. Without governance, good development and validation are unrepeatable accidents.

The table below maps each expectation to a concrete practice for an LLM deployment.

04The model inventory and why it is the top finding

SR 11-7 expected an institution to maintain a comprehensive inventory of all models in use, in development, or recently retired, and a complete inventory remains a core model-risk principle under the 2026 guidance. The inventory is not a formality. It is the control that makes every other control possible, because a system that is not on the list is one that no one validates, monitors, or owns. Extending it to consequential AI is sound practice even though generative AI sits outside the formal 2026 scope.

An incomplete model inventory is the single most common examination finding in model risk management, and AI makes the problem worse for a specific reason: LLM-based capability rarely arrives through a formal model-approval process. It shows up as a feature inside a vendor product, a copilot bolted onto a workflow, or a script a team wrote to summarize documents. None of those announce themselves as models, so none of them land in the inventory by default, and each becomes an ungoverned decision point.

A defensible AI inventory entry captures, at minimum:

• The model's purpose and the decisions it influences.
• Its owner, the accountable individual or function.
• Its inputs and outputs, including what data it can reach.
• Its known limitations, such as a tendency to hallucinate or to over-collect data.
• Its validation status and the date of last review.
• Whether it is vendor-supplied or embedded, since third-party models are in scope and the bank remains responsible for them.

The practical discipline is to inventory AI at the level of the decision, not the tool. One vendor platform may host several distinct AI-driven decisions, and each is a separate item to govern. Treating the platform as a single line hides exactly the risk the inventory exists to surface.

05Validating a non-deterministic model

The hardest part of applying model-risk discipline to LLMs is validation, because validation was designed around reproducibility and a generative model is not reproducible in the usual sense. The same prompt can yield different output on two runs. Classic validation, which compares a model's output to an expected result, does not map cleanly onto a system whose output is a distribution rather than a point. This is one reason the 2026 guidance excludes generative AI from its formal scope, and one reason supervisors still expect validation-equivalent controls around it.

Validation adapts in a few ways. You test the distribution of behavior rather than a single answer, evaluating the model against benchmark sets and measuring how often it produces acceptable output. You probe deliberately for the failure modes that matter for banks: hallucinated or unsupported claims, exposure of customer data in a prompt or response, and the use of output in a decision without adequate human review. And you bound the system so its behavior is constrained, which shrinks the space a validator has to cover.

The most effective move is structural. Wrap the non-deterministic model in deterministic controls, so the parts of the system that actually govern risk are reproducible even though the model is not. A formal policy engine that decides what data the model is allowed to see is deterministic by construction: the same inputs produce the same verdict every time. That property is what makes a control validatable. You can test it exhaustively, document its behavior, and demonstrate to an examiner that it does what it claims, in a way you can never quite do for the stochastic core.

This reframes the validation problem from "prove the model is correct," which is intractable for an LLM, to "prove the controls that constrain the model are correct," which is tractable. The model still needs evaluation and monitoring, but the institution's defensible line of control runs through the deterministic layer, not the model's internals. That layer is where AI data governance meets model risk management.

06Ongoing monitoring and documentation

SR 11-7 treated validation as continuous, not a one-time gate, and ongoing monitoring remains a model-risk principle supervisors expect applied to consequential AI. A model that passed review at launch can degrade as the world it models shifts, as its inputs drift, or as its use expands beyond what was validated. For LLMs the drift can come from a model-version update, a change in the data the system can reach, or a quiet expansion of the decisions it touches.

Effective monitoring for an AI deployment watches several signals at once.

• Output quality, sampled and reviewed against expectations, to catch degradation before it reaches a decision.
• Control performance, confirming that the guardrails and access controls are firing as designed and failing closed when they should.
• Scope creep, checking that the model is still used only for the purpose it was validated for, not quietly repurposed.
• Version and configuration change, so that a swap in the underlying model or its settings triggers re-validation rather than slipping through.

Documentation is the connective tissue. SR 11-7 expected records detailed enough that a knowledgeable third party can understand how a model works, what its limitations are, and how it is controlled, without relying on the people who built it, and the 2026 guidance preserves that expectation for in-scope models. For AI, that documentation has to cover the deterministic control layer as much as the model, because the controls are where the institution's defensible risk management actually lives, and they are the auditable evidence supervisors look for in the gap.

07Evidence and the audit trail

Documentation describes how a system is supposed to behave. Evidence proves how it behaved on a given request. Model-risk governance and audit expectations, and any examiner reviewing the deployment, turn on the second. The question is concrete: for this decision, what policy applied, what verdict was reached, and which data was allowed or withheld?

An audit trail built to answer that should satisfy several properties at once.

Evidence with these properties does something documentation cannot: it lets the institution demonstrate, request by request, that its controls operated. For a stochastic model that is the difference between asserting a control exists and proving it worked, and it is the form of proof an examiner can act on.

08How Custosa supports model risk management for LLMs

Custosa is the runtime data-control plane for enterprise AI. It sits between your data and the LLM and inspects every record and field at runtime, before the model sees it. For a bank applying model risk management to generative AI, Custosa is the deterministic control layer that sits around the non-deterministic model and is, by design, the part you can validate and evidence.

Decisions are made by a deterministic formal policy engine, Cedar, not a model, so the same inputs always produce the same verdict and the system fails closed. That determinism is what makes the control validatable in the model-risk sense: it can be tested exhaustively and documented, where the model's own behavior cannot. Verdicts are per-field Pass or Redact, by role, through a five-level clearance lattice, and fields a role is not cleared for are withheld before they enter the prompt, which directly addresses the data-exposure failure mode examiners probe for.

The data plane runs inside your environment, so records never leave your boundary; self-managed, on-premises, and air-gapped options are available, along with a FIPS build, and the control plane receives only content-free verdict evidence. Every decision is signed with HMAC-SHA256 and hash-chained into an append-only, tamper-evident, content-free evidence ledger that can be verified offline, which is the audit trail an examiner can act on. Custosa ships SOC 2 and SOC 1 packs and maps its controls to SR 11-7, FFIEC, and ICFR expectations. Data is protected with TLS in transit and AES-256-GCM at rest, with BYOK on request, and the p99 added-latency target is 50 to 110ms. Custosa is early-stage and in production with design partners.

To be precise about scope: Custosa provides the controls and the evidence. It does not validate your model, sign your model risk management framework, or stand in for your independent validation function. Model risk governance remains the institution's responsibility; Custosa makes the control layer around the model deterministic, enforceable, and provable.

Frequently asked questions