SR 11-7 and Generative AI: Six Things Your MRM Framework Doesn't Cover

SR 11-7 has been the reference point for model governance in banking since 2011, and RBI's own model risk expectations lean on the same architecture — a three-stage lifecycle of development, validation, and ongoing monitoring, built around independence between the people who build a model and the people who sign off on it. It was written for a specific kind of model: fixed calculations, a quantifiable output, and a validation process that means comparing predictions against observed outcomes.

Generative AI breaks that pattern in six distinct ways, not because SR 11-7 is poorly written but because it predates the technology by a decade. Below are the six gaps, what each one actually costs you in an examination, and what an extended MRM framework needs to cover instead.

Gap 1: there is no validation methodology for an output that changes every time you ask

SR 11-7 validation asks whether a model produces the correct output for a given input. A generative model doesn't produce one output per input — it produces a distribution, and the same prompt can return a different answer on the next run. Back-testing against a fixed validation set doesn't apply when the thing you're testing refuses to hold still.

What replaces it: sampling-based output quality assessment, semantic consistency testing across repeated runs, and adversarial red-team evaluation. SR 11-7's conceptual-soundness criterion still applies in spirit — the test methodology underneath it has to be built from scratch.

Gap 2: hallucination has no statistical analogue

SR 11-7 frames model error as the gap between a model's output and the observed outcome. A hallucination — a confident, plausible, false statement — isn't a version of that. A model that hallucinates on 2% of a BFSI query set is not "a 2% error rate model" in the SR 11-7 sense; it's a model that produces untraceable false information in one out of fifty production interactions, with no ground truth anywhere nearby to catch it.

Validation has to include hallucination-rate measurement on BFSI-specific test sets, and governance has to set — and document — the maximum acceptable hallucination rate for each deployment context before it ships, not after a customer complains.

Gap 3: prompt injection bypasses validation entirely

SR 11-7 has nothing to say about adversarial attacks, and for statistical models that's a reasonable silence — you can't meaningfully manipulate a credit scoring model through an input you control. An LLM is different: prompt injection, where instructions embedded in a user input or a retrieved document override the model's intended behavior, is a documented, repeatable attack. A model that sails through SR 11-7 validation in a controlled test environment can be completely exposed to injection the day it goes live, because validation and adversarial robustness are testing two different things.

MRM frameworks need adversarial testing added as a pre-deployment gate and runtime detection added as an ongoing control — not as a security add-on reviewed separately from the model risk sign-off, but as part of it.

Gap 4: drift doesn't mean what SR 11-7 thinks it means

SR 11-7's ongoing-monitoring section assumes drift looks like statistical performance decay as the real world diverges from the training distribution. An LLM's weights don't move unless you retrain it — but its behavior can shift anyway, because the system prompt, the retrieved context, or the documents a RAG pipeline is pulling from change underneath it. A model behaving correctly in January can behave differently in October purely because what it's being fed has quietly drifted.

That's context drift, not statistical drift, and the monitoring tooling built for the latter doesn't see the former. Banks need semantic drift detection on retrieved context specifically — embedding-space monitoring on the document distribution a RAG pipeline is serving — not just an output-accuracy dashboard.

Gap 5: shared inference infrastructure creates a risk SR 11-7 never had to consider

SR 11-7 assumes each model inference is independent. On shared LLM infrastructure, the key-value cache — the computational state behind the model's attention mechanism — can be shared across requests. A cache poisoned by one request, or data leaking from one tenant's context into another's through a shared cache, is a cross-inference contamination risk with no precedent in traditional model risk management. Any bank running on shared cloud AI infrastructure needs explicit KV-cache governance: tenant isolation enforcement and the ability to forensically replay cache state, because "trust the cloud provider's isolation" is not an evidence package an examiner will accept.

Gap 6: agentic AI creates authorization risk that model-level validation was never built to catch

SR 11-7 validates individual models. It has nothing to say about a system that executes a multi-step workflow, calls external tools, and makes decisions without a human reviewing each step. Three risk categories fall entirely outside SR 11-7's scope:

• Indirect prompt injection into agent pipelines — an agent manipulated through a retrieved document or a user-provided file rather than a direct prompt.
• Authorization boundary failures — an agent accumulating capabilities or access beyond what it was originally scoped for.
• Multi-agent coordination failures — one agent manipulating another's behavior inside a shared pipeline, where accountability for the final action gets diffuse fast.

Any bank running agentic AI needs its MRM framework extended to cover agentic risk tiering, explicit agent-scope definition, and real-time authorization-boundary enforcement — none of which a traditional model validation report was ever asked to produce.

What an extended MRM framework actually has to add

A model that cleared SR 11-7 validation last quarter can be running an undetected prompt-injection vulnerability today. The validation event and the current production state are not the same fact, and SR 11-7's ongoing-monitoring requirements were never written with adversarial manipulation in mind — that gap is structural, not a tooling shortfall you can patch with a dashboard.

How this connects to the regulatory record you'll actually be asked about

• RBI's model risk guidance for AI — referred to in industry commentary as "eMRM," though the precise title, scope, and publication date deserve direct verification against RBI's own release rather than being taken on faith from a secondary source — speaks to independent validation covering third-party AI, which maps onto Gaps 1 and 3 above.
• RBI's FREE-AI committee report (August 2025) speaks to robustness and hallucination-adjacent controls under its Reliability-related recommendations, which maps onto Gaps 2 and 3.
• The OCC has signaled that SR 11-7 extends to AI/ML models generally, and that banks should expect to extend their own MRM practice to generative AI explicitly rather than wait for a bespoke rulebook.

What to do before your next model risk committee meeting

1. Write down, model by model, which of the six gaps above apply to each generative AI system you run — most banks find every GenAI deployment hits at least three.
2. Set a board-approved maximum hallucination rate per deployment context before the next release, not after an incident forces the conversation.
3. Separate your adversarial red-team report from your functional validation report — an examiner will ask for both, and conflating them signals the testing wasn't adversarial.
4. If you run on shared cloud AI infrastructure, get a direct answer from your provider on KV-cache tenant isolation — "they handle that" is not evidence.
5. For any agent with multi-step autonomy, document its capability scope and who signed off on it, before the scope quietly expands past what anyone approved.