SR 11-7 AI Controls Mapping After SR 26-2

A useful SR 11-7 AI controls mapping starts with a correction and an owner. SR 26-2 replaced the 2011 letter on April 17, 2026. Its revised guidance excludes generative and agentic AI from direct scope. If a bank applies those model-risk disciplines to an LLM through internal policy, each mapped row should identify the bank decision and control objective, the accountable owner and operating point, the repeatable test and retained evidence, plus the coverage verdict and gap. A green box labelled SR 11-7 compliant obscures every one of those facts. I would remove it from the diagram.

TL;DR

• Use SR 26-2 as the current source and record its direct-scope exclusion for generative and agentic AI.
• Map any LLM control to the bank policy or other authority that creates it, then name the owner who can change it.
• Give each row an objective and implementation point, a repeatable test and retained evidence, plus a coverage verdict that identifies the open gap.
• Credit an HTTP policy gateway only for authenticated user or agent traffic deliberately routed to an LLM endpoint.

Source status belongs in every mapped row

The Federal Reserve's SR 26-2 letter supersedes SR 11-7 and SR 21-8. It says the revised guidance is expected to be most relevant to Federal Reserve-regulated banking organizations with more than $30 billion in total assets. The attached revised guidance expressly excludes generative and agentic AI from direct scope.

That distinction changes the first columns of a controls map. Record the current supervisory source and its scope. Add the bank policy or risk decision, including any other authority that applies a chosen discipline to the LLM. Then state the implementation as a bank control, with no implication that SR 26-2 directly prescribes an LLM gateway or log schema, including an evidence package.

The current banking model-risk overview provides the broader transition. This mapping turns the bank's implementation choice into executable control rows.

Governance and risk acceptance belong to senior bank owners

Source principle and objective: SR 26-2 describes a risk-based model-risk framework with active governance and effective challenge for models inside scope. For an LLM, the bank's own policy should state the governance objective and risk tier, the approval path and limits, plus reassessment triggers.

Owner and implementation point: the board or delegated committee approves risk appetite. Senior management establishes the framework. The business owner accepts use-case risk inside delegated authority, while model-risk and compliance functions define review methods. Internal audit independently assesses the framework.

Test and evidence: select one production use case and trace its inventory entry to approval and risk classification, its limitations and accountable executive, plus its latest review. Trigger a defined material change and verify that governance reassessment occurs. Preserve minutes and approvals, challenge records and accepted exceptions, plus remediation.

Coverage verdict: Outside an HTTP gateway. A request record may show traffic under an approved policy version. It cannot establish risk appetite or prove effective challenge. The row remains open when the live route and approved use disagree.

Inventory and classification belong to governance and application owners

Source principle and objective: the current guidance discusses an effective model inventory with enough information to understand model risk for systems inside scope. A bank-defined LLM inventory should identify each governed use and owner, provider and model, route and data context, plus the risk decision, limitations, and status.

Owner and implementation point: model-risk governance owns inventory standards. Business and application owners attest to their uses. AI platform engineering owns endpoint registration, while security supplies observed-route evidence. Procurement contributes contracted services and embedded vendor features.

Test and evidence: freeze the inventory and reconcile it with application egress, provider usage, registered endpoints, and procurement. Investigate every unmatched route or service. Retain extraction queries and timestamps, counts and differences, plus owner dispositions. AI model inventory management covers the route-level fields that turn the register into a testable population.

Coverage verdict: Partial. An HTTP policy point can identify routed destinations and policy context. Direct browser sessions and local inference need discovery evidence elsewhere, as do vendor-managed model calls. The bank's inventory owner closes the combined row.

Independent review belongs to model-risk and assurance functions

Source principle and objective: effective challenge requires objective and informed review with enough standing to identify assumptions and limitations, including unresolved risk. The bank must define an appropriate LLM review method because the revised guidance excludes generative and agentic AI.

Owner and implementation point: model-risk management or another qualified independent function sets the review standard. The use-case owner supplies design and performance evidence. Compliance and legal add conduct or regulatory analysis. Internal audit tests the process without becoming its operator.

Test and evidence: inspect one approved LLM use. Confirm reviewer independence and expertise, scope and acceptance criteria, findings and management responses, plus approval. Introduce a material model or retrieval change and verify that the policy invokes the expected review. Preserve the initial result and later retest.

Coverage verdict: Outside the gateway, with a limited evidence contribution. A routed event can identify the endpoint and policy active for a call. It gives the reviewer a production population, but model suitability and output quality, data fitness, and business impact require separate evaluation.

Change control belongs to engineering with risk oversight

Source principle and objective: preserve controlled changes and reassess risk when the model or its use changes materially. For LLM systems, the bank's policy should define thresholds across models and prompts, retrieval sources and policies, destinations and tools, plus routes.

Owner and implementation point: application and AI platform engineering operate the release process. Security engineering owns policy releases. The business owner and model-risk function approve changes at their assigned thresholds. Provider-management owners track external model changes and notices.

Test and evidence: select one policy release and one model or prompt change. Match approvals and expected results to deployment records. Then locate the first production request carrying the new version. Verify rollback and closure, including any post-release review. Preserve emergency changes as their own population.

Coverage verdict: Partial. The HTTP decision record can show when a route or policy version appeared in production. Source-code review and provider model changes, business acceptance, and rollback execution remain with their actual systems and owners.

Monitoring belongs to the owner of the claimed outcome

Source principle and objective: SR 26-2 retains ongoing monitoring and outcomes analysis for models inside scope. A bank applying similar disciplines to an LLM should define measures tied to the approved use and its limitations, with measures scaled to risk rather than substituting infrastructure uptime for outcome evidence.

Owner and implementation point: the business owner defines the consequential outcome. Model-risk and data owners set evaluation methods and thresholds. Operations handles escalations. Security monitors route coverage and denials, restricted classifications and latency, plus policy failures.

Test and evidence: trace one reported metric to raw records and inspect a threshold breach. Join request-level events to application handling and the resulting case or transaction disposition. Preserve model tests, human-review samples, complaints, overrides, and issue decisions alongside route telemetry.

Coverage verdict: Partial. An HTTP policy point contributes request and response evidence for traffic it sees. It cannot establish customer outcome quality or explain business decisions. AI model monitoring separates these evidence streams and their owners.

Third-party controls belong to procurement and risk management

Source principle and objective: the revised model-risk guidance addresses vendor and third-party products for models inside scope. The agencies' Interagency Guidance on Third-Party Relationships provides a broader risk-based lifecycle for banking organizations' third-party relationships.

Owner and implementation point: third-party risk management owns the framework. Procurement and legal form the contract. Security and privacy assess the service. The business owner monitors performance and incidents, while continuity teams test exit arrangements.

Test and evidence: select the provider used by one production route. Match the approved service and model, region, and data-use terms to the endpoint observed in traffic. Inspect change notices and incident history, subcontractors and performance reviews, plus open issues and termination provisions.

Coverage verdict: Partial. A gateway can restrict a destination and record the endpoint selected. Contract rights and provider diligence, service continuity, embedded inference, and independent assurance sit outside that request decision. Third-party AI risk management describes the vendor-controlled paths that need separate evidence.

Runtime policy and decision records belong to security engineering

Source principle and objective: this is a bank-defined implementation pattern for governing authenticated HTTP LLM traffic. It supports approved-use restrictions and creates request-level evidence. SR 26-2 names neither this architecture nor a required event schema for generative AI.

Owner and implementation point: security engineering owns the inline policy service and restrictive failure behavior. The application supplies a stable user or agent identity and workflow purpose. Data governance owns classifications, while AI platform engineering registers allowed model endpoints.

Test and evidence: at 14:06 ET, send synthetic customer data through an approved application to an allowed model. Repeat with missing identity, restricted content, an unapproved destination, and policy-service failure. Confirm expected outcomes and retain the route and supplied principal, classification and policy version, decision and timestamp, plus the correlation ID.

Coverage verdict: Full only for the defined decision on traffic deliberately routed through the HTTP control. It excludes local inference and direct browser sessions, hidden vendor calls and downstream tool execution, plus identity proofing and business disposition. The post-authentication gap explains the context the application must supply after login.

Issue closure belongs to control owners and independent retesters

Source principle and objective: documentation should support recommendations and responses, including exceptions and remediation. A mapped LLM control should keep failures visible until the assigned owner completes a defined closure test.

Owner and implementation point: the control owner fixes the defect. Model-risk issue management tracks dates and extensions, including risk acceptance. An independent reviewer performs or challenges the retest. Senior authority closes issues according to severity and policy.

Test and evidence: select one closed finding. Reproduce the original failure and interim containment, the root-cause analysis and remediation, plus the raw retest and approval. Confirm that the affected period and population received appropriate review. A June closure should preserve the May bypass record.

Coverage verdict: Outside the gateway for governance, with evidence contribution where the issue affected routed traffic. A request event may prove the repaired behavior. Issue ownership and severity, extension and retrospective review, plus closure remain bank decisions.

Use coverage verdicts that expose dependencies

Use Full only for a narrowly stated objective with complete coverage at the named control point. Partial should name the functioning component and missing dependency. Outside assigns the objective to its actual owner. Every gap needs an interim treatment and target date, followed by a repeatable closure test.

My blunt view is that an enterprise coverage percentage should stay out of this map. 96% covered can conceal the one wealth-management assistant calling a provider directly. Put that route on the page in red, with the owner and due date. The line is more useful than the percentage.

Keep shared evidence from merging responsibilities. A single request event may support inventory reconciliation and change testing, plus monitoring and an audit sample. Each row retains its own objective and test, owner, and result.

DeepInspect

DeepInspect contributes to the runtime policy and decision-record row for authenticated HTTP traffic deliberately routed between bank users or agents and LLM endpoints. It evaluates application-supplied identity and workflow context against content and destination policy before an allowed request proceeds, then inspects response handling at the same boundary.

Each decision creates a signed, tamper-evident record containing the route and classification, active policy version and outcome, plus the timestamp. The bank retains governance and identity proofing, route completeness and independent review, model evaluation and business outcomes, third-party oversight and retention, plus issue closure. Direct browser use and local inference, embedded vendor calls, and downstream actions need controls from their actual owners. Book a technical deep dive at deepinspect.ai.