Model Risk Management for GenAI: SR 11-7 Meets LLMs

The heritage: SR 11-7 and model risk

In 2011 the Federal Reserve and the Office of the Comptroller of the Currency issued Supervisory Letter SR 11-7, and with it a discipline that had lived in scattered quant desks became a supervised expectation. The letter's premise is deliberately plain: a model is any quantitative method that turns inputs into estimates, every model carries risk because every model can be wrong or misused, and that risk has to be owned and managed across the model's whole life, from development through retirement. Fifteen years of examinations turned that premise into muscle memory for banks, and insurers and large healthcare payers have absorbed the same reflexes through their own supervisors.

The heritage matters because it means regulated firms do not meet generative AI empty-handed. They already run a model inventory, they already staff an independent validation function, and they already answer to a committee that can block a model from going live. GenAI is not a new regulatory universe for them; it is a new and awkward class of model dropped into an existing frame. A large language model that drafts adverse-action letters or triages claims is a model under this guidance, and the fact that it emits fluent prose rather than a probability of default does not exempt it.

The trap is assuming inheritance is sufficient. SR 11-7 was written for models a validator could, in principle, take apart: a logistic regression, a Monte Carlo engine, a scorecard with a fixed feature set. Its machinery assumes you can characterize the input space, reproduce the output, and reason about the internals. Generative models violate all three assumptions at once, which is why the rest of this piece is about adaptation rather than mere compliance.

The three pillars: inventory, validation, monitoring

Strip SR 11-7 to its load-bearing structure and three pillars remain. They are unglamorous, and they are the whole game.

• Inventory. A complete, current register of every model in use, because you cannot govern, validate, or retire what you have not cataloged. Each entry records purpose, owner, risk tier, data sources, and dependencies. The classic failure is the shadow model: a spreadsheet or a script doing consequential work that never entered the register and so was never validated.
• Independent validation. Before a model informs a decision, a function separate from the one that built it challenges its conceptual soundness, tests it against data the developers did not choose, and forms an independent view of whether it is fit for its stated use. Independence is structural, not procedural: the validator must be able to say no and be heard.
• Ongoing monitoring. Validation is a snapshot; the world moves. Monitoring watches live performance for the drift, degradation, and changed conditions that make a once-sound model unsound, and it triggers revalidation when thresholds break.

These pillars are not a checklist to be completed once. They form a lifecycle: inventory feeds validation, validation sets the monitoring plan, and monitoring findings send a model back for revalidation or into the inventory as retired. A program that inventories well but monitors weakly is one that certifies models at birth and never checks whether they are still alive.

GenAI does not add a fourth pillar. It stresses each existing one in a specific way: the inventory has to capture prompts, model versions, and vendor endpoints that change under you; validation has to bound behavior it cannot exhaustively enumerate; monitoring has to score outputs that have no single correct answer. The pillars hold; the techniques inside them have to change. The primer-level treatment is in Model Risk.

What GenAI breaks about classic validation

Traditional validation rests on assumptions that generative models simply do not honor. A scorecard has a bounded, describable input domain; a validator can enumerate the feature ranges, build a representative test set, and claim coverage. A prompt-driven model accepts any string a human or another system can compose, which is an effectively unbounded and adversarially reachable input space. Coverage in the old sense is unavailable.

Each row breaks a specific technique. Non-determinism means a single test run proves nothing; you are measuring a distribution, not checking an equality. Opaque internals mean the validator cannot reason from the mechanism to the behavior, the way they could read a coefficient's sign and know the model treats an input sensibly. The absence of a single correct answer means pass-or-fail gives way to graded, rubric-based judgment. And third-party dependency means the model under validation can change when the provider ships an update, quietly invalidating yesterday's evidence.

The honest conclusion is not that these systems are unvalidatable, but that the word validation has to mean something different. You are no longer proving a model correct. You are bounding how it behaves across the inputs that matter, documenting where it fails, and building the monitoring to catch the failures you did not foresee. That is a weaker guarantee than a validated scorecard offers, and pretending otherwise is the fastest way to lose a risk committee's trust.

Validating a non-deterministic model

If you cannot prove correctness, you bound behavior. In practice that shifts the validator's toolkit from formal analysis to empirical evidence gathered at scale, and it turns validation from a one-time gate into a standing activity.

• Eval suites as validation evidence. A curated, versioned set of representative and edge-case inputs, scored against a written rubric, is the core artifact. Pass rates on that suite are the closest GenAI analog to a validation test result, and the suite becomes the executable statement of what the model is expected to do. The mechanics are in the Evals deep-dive.
• Adversarial and red-team testing. Because the input space is adversarially reachable, deliberate attack is validation, not an afterthought: prompt injection, jailbreaks, data-exfiltration attempts, and inputs engineered to elicit prohibited output. See Red-Teaming and Prompt Injection Defense.
• Benchmarking against a challenger. Classic model risk loves a challenger. Keep the practice: run a second model, an earlier version, or a simpler baseline alongside the candidate on the same eval set, so a quality claim is relative and defensible rather than absolute.
• Documented known limitations. Every validation report states, plainly, where the model fails, which inputs are out of scope, and what residual risk the business is accepting. A limitation you wrote down is managed risk; one you discovered in production is an incident.

The consequence a risk committee has to absorb is continuity. A scorecard validated in March is, absent change, still validated in September. A generative model sits on a provider endpoint that updates, faces an input mix that shifts, and confronts adversaries who adapt. Its validation has a shelf life measured in weeks, not years, and the eval suite has to run on every model version, prompt change, and material shift in usage. Validation stops being an event and becomes a process the platform runs continuously.

Governance structure and three lines of defense

Technique means nothing without the structure that gives it teeth, and here GenAI inherits a model regulated firms already trust: the three lines of defense. The point is separation of duties. The people who benefit from a model going live are not the people who decide whether it may.

Two ideas make the structure work rather than merely exist. The first is effective challenge: critical review by parties who have the competence to understand the model, the independence to disagree, and the standing to make disagreement stick. A validator who cannot delay a launch is decoration. The second is risk tiering. Not every model earns the same scrutiny; a GenAI system that drafts internal meeting notes is not the one that denies a claim. Tier by decision impact, autonomy, and exposure, and spend validation effort where the consequences live.

The load-bearing element is a committee with the authority to say no. A model risk committee that reviews high-tier GenAI systems, accepts or rejects residual risk on the record, and can order a model out of production is what turns all the prior machinery into governance rather than paperwork. You can rehearse the whole structure in the Governance Sandbox.

Documentation the regulator expects

To a supervisor, a control that is not documented did not happen. The documentation is not bureaucratic residue; it is the evidence that the firm managed the risk, and in an examination it is often the only evidence that exists. For GenAI the expected file has a recognizable shape.

• Model card. The identity record: model and version, provider, intended use, in- and out-of-scope uses, training-data characteristics as far as they are known, and known limitations.
• Intended-use and limitations statement. An explicit boundary of what the system may and may not be relied on for, written before deployment and binding on the first line.
• Validation report. Eval results, adversarial and red-team findings, challenger comparison, residual risk, and the validator's sign-off or objection.
• Monitoring plan. The metrics watched in production, their thresholds, the revalidation triggers, and who is paged when a threshold breaks.
• Audit trail. A durable record of model versions, prompt changes, approvals, and incidents, so any past decision can be reconstructed.

Two things keep this from becoming theater. The documentation has to be living, regenerated when the model version or prompt changes rather than frozen at first approval, which is only feasible if the platform produces it as a byproduct of operation rather than as a manual write-up. And it should map to a recognized framework so the effort is legible to auditors and regulators alike.

Building it into the platform

Everything above fails in practice if governance is a set of manual gates a delivery team can route around under deadline. The architect's job is to make model risk a property of the platform, so that the compliant path is the only path. The controls become services on the reference architecture's governance plane, not a review meeting bolted on at the end.

  build or change request
          |
          v
  +---------------------+   not registered
  |   MODEL INVENTORY   |---------------------> blocked
  |   registry + tier   |
  +---------------------+
          | registered
          v
  +---------------------+   eval fail /
  |   VALIDATION GATE   |---------------------> blocked
  |   eval suite + tier |
  +---------------------+
          | pass + sign-off
          v
  +---------------------+
  |     PRODUCTION      |
  +---------------------+
          |
          v
  +---------------------+   drift / breach
  |     MONITORING      |----> back to validation
  +---------------------+
            

Concretely, three services carry the load. A model registry is the system of record for every model, version, prompt, and risk tier, and nothing deploys without an entry. A validation gate wired into the deployment pipeline runs the eval suite on every model or prompt change and blocks promotion when scores fall below the tier's threshold, with the same finality as a failing test. And a monitoring service scores production traffic, watches for drift and threshold breaches, and files the revalidation trigger automatically. The observability foundations are in Tracing & Observability, and the plane these sit on is in Reference Architectures.

Built this way, the audit trail is a byproduct: every deployment already carries its inventory entry, eval results, and approval, because the pipeline refused to run without them. That is the difference between a firm that can produce evidence on demand and one that assembles it in a panic before an examination. Governance that lives in the platform scales with the number of models; governance that lives in a committee's calendar does not.