SR 11-7 and AI: What Model Risk Management Means for On-Prem LLM Deployments

Summary

SR 26-2, issued April 17, 2026, superseded SR 11-7 and SR 21-8, but Footnote 3 explicitly places generative and agentic AI outside its scope, leaving no AI-specific replacement rule in effect.
MRM teams still apply SR 11-7's four disciplines (inventory and documentation, independent validation, ongoing monitoring, and change control), so AI projects stall on missing evidence rather than immature technology. Chatbot deployments have been blocked for six months in some cases.
LLM dynamism strains every discipline: prompt edits and silent model version bumps count as production changes, and the bank retains full model risk even when a vendor withholds code, data, or methodology.
Prepare for review from day one by choosing on-prem deployment with model version pinning, instrumenting every agent action, establishing human approval gates, and assigning a data scientist to own the evaluation dataset before launch.
Jinba Flow deploys on-prem or air-gapped with immutable audit logs, human approval gates, and versioned agent skills to generate MRM-ready evidence from the first day of a pilot.

AI projects inside banks frequently stall because the model risk management team has unanswered questions. In a recurring pattern across fintech teams, a prototype is built, compliance requests an audit trail that does not exist, and the project remains in review for months. Risk teams have in some cases blocked chatbot deployments for six months because the project team could not answer basic questions about validation, documentation, and change control.

The controlling function in each case is the bank's Model Risk Management function, operating under supervisory guidance that predates large language models by over a decade.

SR 11-7 and the Governance Gap It Left Behind

SR 11-7 was issued jointly by the Federal Reserve and the Office of the Comptroller of the Currency as the foundational guidance for model risk management in banking. It established four core disciplines: inventory and documentation, independent validation, ongoing monitoring, and change control and governance. Those disciplines became the institutional standard against which every model (credit scoring, fraud detection, pricing) was reviewed.

On April 17, 2026, the Federal Reserve issued SR 26-2, which superseded both SR 11-7 and SR 21-8. The OCC issued a corresponding OCC Bulletin 2026-13. SR 26-2 retains the core disciplines of strong model governance, independent review, validation, and controls; this is confirmed by analysis of the transition from SR 11-7 to SR 26-2.

Footnote 3 of the April 2026 guidance places generative and agentic AI explicitly outside the scope of SR 26-2. The new rule does not govern LLMs or AI agents. No replacement AI-specific rule is yet in effect.

The footnote creates a governance gap rather than a permissive environment. In the absence of AI-specific supervisory guidance, MRM teams at banks and institutions supervised by the FFIEC are applying the established principles institutionalized by SR 11-7 to evaluate AI systems. The discipline remains the operative standard. As Tensile's SR 11-7 AI compliance overview states plainly: AI does not escape model risk because it looks like software.

Why LLMs Strain Every Discipline in the Framework

SR 11-7 model risk management AI requirements were written for models with stable inputs, defined outputs, and fixed logic. An LLM does not meet those conditions.

The binding constraint, as identified in Tensile's analysis, is that an LLM's outputs change with prompts, data, integrated tools, vendor updates, and model versions. A prompt edit made by a product manager (not an IT change manager) can alter the system's behavior in ways that invalidate a prior validation. Almost no team treats prompt edits or model version bumps as a production change. From an MRM perspective, both are production changes.

This dynamism means static documentation is insufficient for validation. Validation for an LLM requires behavioral evidence over time, not static documentation, which makes an immutable audit trail the operating evidence MRM demands.

Model risk management reviews of LLMs also raise a frequently underestimated liability question: the bank retains full responsibility for a vendor-hosted model even when the vendor withholds code, data, or methodology. Regulation attaches to the regulated entity rather than the vendor.

The Four Questions MRM Will Ask

SR 11-7's disciplines translate into a concrete evidence checklist. Banks deploying LLMs or AI agents should expect each of the following lines of inquiry.

Inventory and documentation. MRM requires a complete and transparent record of the model's design, purpose, and limitations. For an LLM, that means:

System inventory with a named model and agent owner, a materiality flag, and a dependency map
Recorded use-case baseline, data-source record, and specific prompt and model versions
Control design documentation and implementation signoff

Independent validation. The review must be conceptually sound, performed independently, and cover the model's limitations. For LLMs, the validation packet must include:

Benchmark results against a defined, documented test set
Exception analysis and a log of observed weaknesses
Notes on challenger models or alternative approaches considered
Status of any open remediation plans

Ongoing monitoring. MRM expects continuous monitoring for performance degradation. For LLMs, this requires:

Performance drift reports over time
A time-series view of control health
An incident trace for every unexpected output or failure
A flag for stale evidence or outdated validations

Change control and governance. MRM requires a formal process for every change to the model, its data, and its environment. For an LLM deployment, the production environment includes prompts, tools, and integrated data sources, all of which can be modified outside traditional IT change management. Evidence required:

An immutable change log covering model versions, prompt revisions, and tool configurations
Escalation procedures for performance degradation or incidents
Committee-ready summary reports for governance oversight

Auditors consistently require named human accountability that automated systems alone cannot satisfy. Accountability must rest with a person rather than a pipeline.

The Architectural Answer: On-Prem Deployment and Immutable Audit Logs

Generating the evidence above requires a specific architecture. Two components are foundational: on-premises deployment for control over data and model state, and immutable audit logging that converts each SR 11-7 obligation into verifiable proof rather than assertion.

Data residency and model pinning. The primary concern banks raise is that company policy will not allow sensitive data to leave the institution's infrastructure. On-premises deployment resolves this directly: raw data stays inside the bank's control boundary and is never transmitted to a third-party model host. For MRM purposes, on-prem hosting or private model endpoints also allow the bank to pin the model to a specific version. Version pinning stops third-party drift from the vendor and creates a stable, reproducible system state against which validation artifacts remain meaningful. Without it, a vendor's silent model update can invalidate a completed validation overnight.

Immutable logs as evidence. In AI deployments in financial services, audit evidence is frequently scattered across model logs, API logs, and application logs, with no common correlation identifier. Compliance will not accept mutable logs as proof. The reproducible chain auditors require (this identity, this authorization, this intent, these tool calls, this result, this reviewer) cannot be reconstructed from fragmented, dispatchable records. An immutable, unified audit trail converts each MRM obligation from a self-reported assertion into documented, verifiable evidence.

The NIST AI Risk Management Framework and FINRA's generative-AI guidance both address governance expectations for AI systems, reinforcing that documentation and monitoring requirements are converging across regulators, though each framework carries its own scope and applicability.

Building a Defensible AI Stack with Jinba

Jinba is SOC II compliant and supports on-premises and air-gapped deployment, making it architecturally suited to the data residency requirements banking MRM teams enforce. The platform is an enterprise AI platform rather than a compliance product, and its components generate the evidence an MRM review demands.

Jinba Brain: auditable, consistent knowledge

Jinba Brain is a specialized knowledge layer (Layer 03) that sits above general-purpose data layers in the AI agent stack. Unlike RAG, Jinba Brain does not retrieve variable text chunks. It stores facts as ontology-validated records: structured, schema-validated, linked data that produces the same answer to the same business question every time, because the rules are encoded in the schema rather than inferred on each retrieval run.

For banking deployments, Jinba Brain ships with FIBO, the EDM Council Financial Industry Business Ontology, as the industry-standard schema covering legal entity, financial instrument, and contract. For insurance, it ships with the ACORD Information Model covering Policy, Product, Party, and Claim. These schemas provide the structured, validated data foundation that MRM documentation requires.

Every fact is stored as a linked record carrying its source path and a SHA-256 hash. This provides full traceability: an auditor can follow any agent answer back to its origin document with a verifiable fingerprint. In practice, this is a reproducible chain: a cryptographically anchored reference rather than a log assertion.

The knowledge update process includes a governance gate. Both of Jinba Brain's learning loops (the data ingestion loop and the interaction learning loop) converge on a human reviewer before any knowledge change goes live. There are no automatic knowledge updates. A proposed revision becomes knowledge only after reviewer approval, and every change is retained in full history. This is the named human accountability that auditors require: a person, with a record, at the point of decision.

Raw data is kept unmodified on-premises throughout. The pipeline reads data but never alters it.

Jinba App Neo: governed agents with auditable actions

Jinba App Neo is a governance layer for shared Claude agents built on Anthropic's Claude (Opus/Sonnet/Haiku 5.5). It provides enterprise controls across a team rather than serving a single user and is distinct from single-user AI tools.

Every task run is captured as a reviewable chat thread, providing a complete action audit. Audit logging is a core feature: AI operations are logged and credentials are never passed through the log. Role-Based Access Control (RBAC) governs workspace access, with admin operations restricted to owners.

Critical workflows support human-in-the-loop approval steps. A run pauses until a human approves or rejects the proposed action via an in-chat approval card or the run console. This pause-and-approve pattern directly satisfies the MRM requirement for human accountability at the point of consequential decisions.

Skills (the equivalent of agent prompts and logic) carry full version history with restore capability. A prompt edit is therefore a governed, recorded change with rollback rather than an untracked modification. This closes the change control gap that MRM teams most commonly identify in LLM deployments.

Jinba Toolbox: sandboxed, logged tool execution

Jinba Toolbox is a centralized tool management and execution platform for AI agents. Tools execute in isolated sandbox containers, preventing AI-generated code from running unsafely in shared environments. Every tool execution is recorded as a Run with status, input, output, logs, duration, and error fields. Schema validation runs before execution; violations are rejected before consuming sandbox resources. Access control is governed by organization membership with roles scoped to an environment.

The result is granular, structured evidence for every action an agent takes: the tool-call-level detail that audit reviewers require when tracing an agent's behavior through a decision sequence.

Moving from Prototype to Production

Deploying LLMs in banking requires evidence; capable technology is not the limiting factor. MRM teams, operating under the enduring principles that SR 11-7 institutionalized and SR 26-2 carried forward, require documented proof of control, validation, and continuous monitoring. Generative AI currently sits outside the scope of any replacement rule that would define an alternative standard.

For banks and AI programme owners, the practical implication is direct. Before a model reaches production, the four evidence requirements (documentation, independent validation, ongoing monitoring, and change control) must already be generating records. An audit trail is the precondition for approval and cannot be retrofitted after the prototype is approved.

On-premises deployment provides the control layer: data stays inside the institution's boundary, model versions are pinned and stable, and the system state is reproducible. A governed platform with immutable logging, human approval gates, and version-controlled agent skills provides the evidence layer: every fact, every decision, every tool call, and every knowledge change is traceable to a named reviewer and a verifiable source.

For AI teams preparing for an MRM review, the preparation starts with the architecture. Choose an on-prem deployment model. Instrument every agent action from the first day of the pilot. Assign a data scientist to own the evaluation dataset before launch; starting without evaluations in place is a recurring deployment pitfall. Establish the human approval gate for every knowledge update before agents touch production data.

The MRM team will ask what changed, when, who approved it, and what the output was. With the right architecture in place, those questions have documented answers before the review begins.

Explore how Jinba's on-premises AI stack is built to generate that evidence from the first day of deployment.

Frequently Asked Questions About SR 11-7 and AI Model Risk Management

What is SR 11-7 and why does it matter for AI in banking?

SR 11-7 is the Federal Reserve and OCC guidance that established the core disciplines of bank model risk management: inventory and documentation, independent validation, ongoing monitoring, and change control. It matters for AI because those disciplines became the institutional standard MRM teams still apply when reviewing large language models and AI agents, even after SR 26-2 superseded the original guidance in April 2026.

Does SR 11-7 apply to AI and large language models after SR 26-2?

In practice, yes: banks' MRM teams still apply SR 11-7's disciplines to AI and LLMs, even though SR 26-2 formally superseded SR 11-7 in April 2026. SR 26-2 retains the core principles of strong model governance, independent review, validation, and controls, but Footnote 3 explicitly places generative and agentic AI outside its scope. Because no AI-specific replacement rule is yet in effect, the principles SR 11-7 institutionalized remain the operative framework for AI reviews.

Why do AI projects in banks get blocked by model risk management?

AI projects in banks usually get blocked because the team cannot produce the evidence MRM requires, not because the technology is unready. Prototypes are built, but compliance asks for an audit trail, validation records, and change-control documentation that do not exist. Projects can then sit in review for months, with chatbot deployments sometimes blocked for six months over unanswered questions about validation, documentation, and change control.

What evidence does MRM require for an LLM or AI agent?

MRM requires evidence across four disciplines: inventory and documentation, independent validation, ongoing monitoring, and change control. For an LLM, that means a named model and agent owner, recorded use-case baselines, prompt and model versions, benchmark results, exception analysis, drift reports, incident traces, an immutable change log, escalation procedures, and committee-ready governance reports. The exact artifacts vary by bank, but the theme is consistent: documented, verifiable proof rather than assertions.

Why is an immutable audit trail important for AI compliance in banking?

An immutable audit trail is important because it turns each model risk obligation into verifiable evidence instead of a self-reported claim. Mutable logs are not accepted as proof, and evidence scattered across model logs, API logs, and application logs cannot reconstruct the reproducible chain auditors need: this identity, this authorization, this intent, these tool calls, this result, and this reviewer. A unified, immutable trail lets MRM and auditors trace an agent's behavior through a decision sequence.

Why does on-premises deployment matter for AI model risk management?

On-premises deployment matters because it addresses data residency and model-state control, two requirements bank MRM teams enforce. Raw data stays inside the institution's control boundary and is never sent to a third-party model host, and private model endpoints allow the bank to pin a specific model version. Version pinning prevents silent vendor updates from invalidating a completed validation and creates a stable, reproducible system state for ongoing monitoring.

How should a bank prepare an AI pilot for an MRM review?

A bank should prepare an AI pilot for MRM review by generating evidence from day one, before the prototype reaches production. Choose an on-prem deployment model, instrument every agent action from the first day of the pilot, assign a data scientist to own the evaluation dataset before launch, and establish human approval gates for every knowledge update before agents touch production data. Prompt and model changes should be version-controlled and logged so the MRM team can answer what changed, when, who approved it, and what the output was.

Does using a third-party AI vendor transfer model risk away from the bank?

No. The bank retains full responsibility for a vendor-hosted model even when the vendor withholds code, data, or methodology. Regulation attaches to the regulated entity, not the vendor, so MRM still expects documentation, validation evidence, monitoring, and change control for the deployed AI system. Vendor contracts and architecture should therefore support the bank's ability to produce that evidence.

How does Jinba support SR 11-7 and SR 26-2 readiness?

Jinba supports SR 11-7 and SR 26-2 readiness by generating MRM evidence through on-premises or air-gapped deployment, immutable audit logging, and human approval gates. Jinba Brain stores ontology-validated facts with source paths and SHA-256 hashes; Jinba App Neo logs agent tasks, governs access, and versions skills with restore history; Jinba Toolbox records every tool execution with status, input, output, logs, duration, and errors. Together, these components provide the traceable documentation, change control, and human accountability that bank MRM reviews demand.