Model Risk Management for AI: Extending SR 11-7 and RBI's Evolving MRM Guidance to ML and Generative AI

SR 11-7 — the Federal Reserve and OCC's 2011 supervisory guidance on model risk management — is still the reference architecture for how a bank governs models: independent validation before deployment, a complete inventory with risk tiering, use limited to the model's declared purpose, and ongoing monitoring in production. Those four principles hold up well for AI. They were written, though, for models that behave like statistics — stable, deterministic, test-set-measurable — and machine learning, and especially generative AI, break several of those assumptions outright. This piece sets out exactly where SR 11-7 still works, where it runs out, and what Indian banks should expect from RBI's own evolving model-risk guidance for AI.

What SR 11-7 gets right, and why banks still need it as the foundation

Independent validation, inventory and tiering, use limitation, and ongoing monitoring are not banking-specific ideas — they're sound model governance, and they apply to an AI system exactly as they applied to the logistic regression credit model it replaced. US banking supervisors have consistently treated existing model-risk frameworks as extending to AI/ML rather than carving out a separate regime, which means a bank cannot argue its way out of SR 11-7 obligations by calling something "an AI system" instead of "a model." That's the right default position, and most of the AI governance failures I've reviewed trace back to a bank treating its AI deployment as outside the existing MRM perimeter entirely, not to SR 11-7 itself being wrong.

Where it runs out is specific, not general: SR 11-7's methodology assumes you can run a model on a fixed test set and get a reproducible performance number. Generative and agentic AI violate that assumption in ways that have no SR 11-7 analogue at all.

Six places a generative AI deployment slips through an unmodified SR 11-7 framework

Gap 1 — Non-deterministic validation. A statistical model gives the same output for the same input every time; a generative model doesn't. Run-it-once-on-a-test-set validation is incomplete for a model whose outputs vary stochastically — you need sampling-based validation with statistical confidence bounds on the metrics you report, and most validation teams I've seen still report a single run as if it were definitive.

Gap 2 — Hallucination. Statistical models don't hallucinate; they're wrong in bounded, measurable ways. Generative models produce fluent, confident, wrong output at a rate that has to be measured against domain-specific ground truth, not a generic benchmark — a model that scores well on a public QA benchmark can still hallucinate badly on BFSI-specific terminology nobody tested for.

Gap 3 — Adversarial robustness. A statistical credit model isn't meaningfully vulnerable to a crafted input designed to manipulate its output; an LLM or agentic system is, through prompt injection and jailbreak techniques that standard SR 11-7 validation never anticipated. This requires purpose-built red-teaming, not an extension of the existing validation test plan.

Gap 4 — Context drift. Traditional model monitoring tracks drift in the input data distribution over time. An LLM accumulates distortion within a single multi-turn conversation as context compounds, and that has no equivalent in SR 11-7's monitoring vocabulary at all.

Gap 5 — Shared-infrastructure leakage. Shared inference caches (KV-cache reuse across tenants or sessions) create a cross-tenant data-leakage risk that is an architecture problem, not a model-performance problem — it won't show up in any validation metric SR 11-7 asks for, because SR 11-7 was never written to look at the serving infrastructure underneath the model.

Gap 6 — Agentic scope and authorization. SR 11-7 governs models that produce outputs for a human to act on. An agentic system takes the action itself. Capability-scope declaration, authorization-boundary enforcement, and action-level audit trails are governance requirements SR 11-7 simply doesn't contain, because the thing it regulates never used to act on its own.

The practical consequence for a bank with a mature SR 11-7 program: it will satisfy inventory and validation-documentation requirements for an AI deployment and still miss hallucination monitoring, adversarial testing, and agentic authorization governance entirely — because none of those show up on an unmodified SR 11-7 checklist. I've reviewed validation reports that are immaculate on the SR 11-7 boxes and silent on all six of these gaps simultaneously.

The MRM lifecycle, adapted for AI

1. Inventory and tiering — discover, register, and risk-tier every AI model including vendor and shadow AI, not just the ones the model-risk team was told about.
2. Pre-deployment validation — independent validation covering accuracy, fairness, adversarial robustness, hallucination rate, and agentic scope, as a single validation package rather than accuracy alone.
3. MRC approval — committee review and sign-off, documented with an owner and chained to evidence, not a slide deck summary.
4. Production monitoring — continuous tracking of performance, fairness, drift, adversarial evasion attempts, and hallucination rate together.
5. Periodic re-validation — on a tier-based cadence, with Critical models reviewed far more often than Standard-tier ones.

RBI's evolving Model Risk Management guidance for Indian banks

RBI has been moving toward a more AI-explicit model-risk framework for Indian banks, building on the principle-level guidance in its earlier AI-related communications. Industry commentary sometimes shorthands this as "eMRM" (enhanced Model Risk Management). With that caveat squarely in place, the direction RBI has signalled is consistent with three themes that matter operationally:

• Independent validation of vendor-supplied AI models. The expected direction closes a real gap — most Indian banks have relied on vendor attestations and SLAs for credit-scoring, KYC, and fraud-detection AI rather than running their own independent review, and that posture is not likely to survive the final guidance.
• Tier-based review frequency, broadly consistent with SR 11-7's materiality-based cadence but made more explicit for AI — more frequent revalidation for higher-tier, higher-impact models.
• More explicit governance-committee requirements than SR 11-7 carries, reflecting RBI's own observation that model-risk governance at Indian banks has historically been lighter-touch than at comparable US institutions.

A bank building toward this now should build the control, not the specific tier label — independent validation of every vendor AI model and a documented, tier-based revalidation cadence are good practice regardless of exactly what RBI's final Master Direction calls them.

Extending SR 11-7 component by component

What an examiner actually wants to see in your documentation

Five artifacts decide whether an OCC examiner, an RBI inspector, or an EU AI Act auditor leaves satisfied or leaves with findings:

1. A model inventory with risk tier and rationale, updated within the last quarter, including shadow AI and vendor models — an inventory an examiner has to ask you to go find is already a finding.
2. An independent validation report per Tier 1-2 model, including hallucination rate and adversarial robustness results for generative models, from a team that can demonstrate it wasn't the model's own development team.
3. Dated, signed MRC approval records in a tamper-evident ledger, naming the specific model, tier, use limitation, and monitoring plan — an email thread or a slide deck does not satisfy this.
4. Monitoring results showing the approved plan was actually executed, with BFSI-domain accuracy, fairness metrics for any customer-facing decision, and security metrics for any customer-facing deployment.
5. Issue tracking with an owner and a timeline for every validation finding or production incident — an open high-severity issue with no remediation plan is, on its own, an examination finding regardless of anything else in the file.

Action checklist for a bank's Model Risk Management function

1. Run your six-gap check against every generative or agentic model in production today. If you can't point to a hallucination rate, an adversarial test result, and an enforced capability scope for each one, your SR 11-7 program is covering outputs but not AI-specific risk.
2. Stop accepting vendor attestations in place of independent validation for any AI model feeding a credit, KYC, or fraud decision — build the independent-validation capability now, ahead of RBI's final guidance rather than in reaction to it.
3. Move use-limitation enforcement from the system prompt to the tool-call layer for any agentic deployment — a prompt instruction is not a control an examiner will accept.
4. Build the tamper-evident MRC approval ledger before you need it for an inspection, not during one.
5. Brief your board on what's confirmed versus directional in RBI's AI-specific MRM guidance. Build toward tiered validation and vendor-model review now, but don't cite a specific framework name or date to your board until you've verified it against RBI's actual published text.

Extend your MRM framework to cover AI — without replacing it

Zytra adds the AI-specific extensions to SR 11-7 and to RBI's evolving model-risk guidance that traditional MRM platforms don't cover, and produces examination-ready documentation for OCC, RBI, and EU AI Act audits.