Aggregate AI Risk Across Shared LLMs at Banks: What SR 26-2 Covers and How to Measure It

What changed with SR 26-2, and what it does not say about LLMs

The Federal Reserve, OCC and FDIC issued SR 26-2, Revised Guidance on Model Risk Management, on April 17, 2026. It supersedes SR 11-7 and SR 21-8. It asks for a risk-based approach tailored to a bank's model risk profile, size and complexity, and it is supervisory guidance that sets no enforceable standards.

Two provisions matter here. First, sound practice involves assessing model risk both individually and in aggregate. The guidance describes aggregate risk as reflecting interactions and dependencies among models, reliance on common assumptions, data or methodologies, and other factors that could adversely affect several models and their outputs at once. Second, an effective model inventory should hold enough information to support risk management at the individual and aggregate levels.

The scope sentence is the catch. The guidance states that its principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. A shared LLM therefore sits outside the stated scope, and a public comment letter characterizes the guidance the same way. Many teams assume otherwise. If a bank applies SR 26-2 aggregate-risk logic to LLMs, it does so as a policy choice. That choice and its rationale should be documented.

Defining aggregate AI risk for a shared LLM

The SR 26-2 definition translates naturally to a shared LLM. One model serving many applications is a case of reliance on common assumptions, data and methodology, where a single failure mode can affect several outputs at once. Four exposure types are usually discussed: common failure modes, correlated errors, data exposure, and dependency on one provider. A June 2024 Treasury request for information on AI in financial services also named monoculture, concentration, herding, hallucinations and data privacy among potential AI risks.

A workable internal definition has three parts: the shared asset (a model and version), the population that depends on it (applications, agents, business lines, data classes), and the loss scenarios the bank cares about. The NIST AI RMF, which is voluntary, supports this framing. Its Measure function calls for quantitative, qualitative or mixed-method analysis of AI risk, and Measure 1.2 calls for regularly reassessing whether the metrics and controls remain appropriate. The NIST Generative AI Profile points to enumerating generative AI systems in an inventory.

The definition, metrics and materiality thresholds are the bank's to set. Neither SR 26-2 nor NIST supplies them.

Candidate dimensions and where the data comes from

The dimensions below are candidate inputs to a bank-defined method, not supervisory requirements. The practical test for each is whether it can be computed from interaction-level records or needs another source.

• Interaction volume by data classification: Derivable from runtime records if each interaction carries a model, application and data class identifier.
• Policy violation and block rates: Derivable from enforcement outcomes (allow, redact, block, rate limit, escalate), segmented by model and business line.
• Human-escalation rates: Derivable where escalation for approval is an enforced outcome and the decision is recorded.
• Tool-call scope: Derivable from records of which tools and systems a model or agent called, and under which policy.
• Provider and version concentration: Partly derivable. Share of interactions per provider and model version comes from records. Provider resilience does not.
• Correlated-error behavior: Not derivable from enforcement records alone. It requires outcome analysis, testing and validation by the bank.

Where per-use-case review leaves gaps

Model risk is usually assessed application by application. Each review can be sound and still miss the sum. Ten applications may each carry a modest exposure to the same model, yet nobody owns the question of how much sensitive data flows to that model in total, or what happens across business lines if it misbehaves.

Three gaps follow. The first is visibility: without a common key linking model, version, application, business line and data class, aggregation is manual and inconsistent. The second is change: a vendor-driven model update can alter behavior while the bank changes no inputs, prompts or processes, so per-application approvals made at one point in time can go stale. The third is evidence: application-level documentation describes intended controls, and after-the-fact review reconstructs events. Neither shows which policy applied to a specific interaction or tool call and what happened.

Internal audit under SR 26-2 is generally positioned to evaluate whether model risk management practices are rigorous and effective and whether policies are implemented accordingly. It does not duplicate validation. That role is easier to perform when implementation can be shown from consistent records rather than inferred from design documents.

How runtime enforcement produces evidence for aggregation

Enforcing policy in the execution path means every interaction and tool call is evaluated before it completes. The outcome is allow, redact, block, rate limit, or escalate for human approval, and the decision is recorded as it happens. Because the record is generated by enforcement rather than assembled afterward, it shows the policy that applied and the result for that individual event. The same policy applied across applications yields comparable records.

That consistency is what aggregation needs. If records carry identifiers for model, version, application, data class and policy outcome, risk teams can group them by any of those dimensions. This is an architectural requirement for the bank's data design, and the identifiers should be confirmed before relying on the records for a given metric.

Trussed provides this as runtime control and evidence infrastructure. It enforces policy across models, agents, tools and MCP servers, and it generates continuous audit-ready evidence from that enforcement. It is not a model risk, GRC or governance platform. Trussed runs 100+ models under one policy plane and generates 30+ GB of audit evidence per day. Its depth is in insurance, a regulated financial sector.

The limits are plain. Runtime evidence does not satisfy any SR 26-2 provision by itself. It does not replace validation, outcome analysis, or the bank's own aggregate risk methodology and governance. It supplies one input: what was allowed, changed or stopped, and when.