SR 26-2 Hybrid AI System Classification: ML Scores, LLMs and Runtime Evidence

Why hybrid systems create a classification problem

SR 26-2, Revised Guidance on Model Risk Management, is issued by the Federal Reserve, the OCC and the FDIC. The Federal Reserve letter is dated April 17, 2026, and, as of November 2026, it supersedes and replaces SR 11-7 and SR 21-8. The agencies state that the guidance highlights sound principles for effective model risk management while recognizing that practices appropriately vary among banking organizations based on their risk profiles and model usage.

That flexibility matters for hybrid pipelines. A traditional ML model produces a score, and an LLM then interprets, explains, summarizes or acts on it. A bank can treat the pair as a single model, as two components with separate entries, or as an ML model feeding a tool or application that sits outside the model definition. Each choice changes the inventory entry, the tier, the validation scope and the monitoring plan.

Classification is not a formality. One public commenter on a Federal Reserve-hosted proposal characterized SR 26-2 as excluding deterministic rule-based processes from the model definition, and argued that this kind of classification determines whether monitoring is validated at all. That is a commenter's view, not regulator text, but it shows the practical stakes. The approach below is a practitioner framework for reaching a consistent, documented decision. Model risk management should own the final call under the bank's policy.

How each outcome tends to affect inventory, tiering, validation and monitoring

The table shows how obligations typically flow under each outcome. The specifics depend on the bank's policy and on the text of the guidance, so treat it as a working illustration for policy design.

• Single model: Best fit when LLM output feeds a decision directly with limited review. Inventory: one entry covering score and LLM. Tiering: combined purpose and exposure. Validation: the whole pipeline, including LLM behavior. Monitoring: combined outputs. Runtime evidence supports monitoring.
• Separate components: Best fit when the LLM has a distinct purpose from the score. Inventory: linked entries, with the reason for separation stated. Tiering: each component on its own use. Validation: scoped per component, plus the interface between them. Monitoring: per component. Runtime evidence covers the LLM and its tool calls.
• Tool or application: Best fit when the LLM only formats or summarizes for a human who decides independently. Inventory: the ML model as a model, the LLM step in the application inventory with a cross-reference. Validation: the LLM is not validated as a model, so define risk-based testing explicitly. Runtime evidence carries more weight because the component is outside model validation.

Governance considerations and tradeoffs

Each outcome has a cost. Classifying the pipeline as a single model gives the widest coverage but enlarges validation scope and may be hard to sustain across many pipelines. Treating the LLM as a tool or application lightens the validation burden. A tool or application classification does not by itself remove the need for testing, though. Define what independent testing and monitoring apply even where a component sits outside the model definition, so the classification is never a way to skip scrutiny.

Consistency matters more than any single answer. Inventory detail should be enough to understand model risk at the individual and aggregate level, and detail may vary with complexity and usage. For hybrids, that means a stated rule for whether components are recorded together or separately, and a tiering input set (purpose, exposure) applied the same way across business lines.

Internal audit's role is generally to evaluate whether model risk management practices are rigorous and effective and whether policies are implemented accordingly. A written classification rationale for each hybrid pipeline gives audit something concrete to test against.

Where Trussed fits

Trussed enforces policy in the execution path on individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact. Each interaction can be allowed, redacted or blocked, or escalated for human approval, and that enforcement produces audit-ready evidence. Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency.

Trussed does not validate or govern models, and it does not provide model lineage or end-to-end workflow tracing. It addresses the runtime question in the checklist above. Insurance, a regulated financial sector, is where Trussed is deepest. Trussed has run continuously in production in a regulated enterprise for more than 18 months, with 100+ models under one policy plane and customers in four regulated verticals: insurance, pharma, healthcare and education.