How SR 26-2 defines a model and whether large language models fall within it

What the definition turns on

Model definitions in US financial rules commonly follow a quantitative-method structure. The AVM quality control standards rule, the clearing agency model risk management frameworks and the ONC health IT rule each describe a model as a quantitative method, system or approach that applies statistical, economic, financial or mathematical techniques and assumptions to process input data into quantitative estimates. This guide uses that formulation as a reading frame. It is not a quotation of SR 26-2, and the exact wording of SR 26-2 should be read directly and checked against each element below.

The AVM rule and the clearing agency frameworks also describe three components: an information input component that delivers assumptions and data, a processing component that transforms inputs into estimates, and a reporting component that translates estimates into useful business information. They state that quantitative approaches with partly or wholly qualitative inputs, or inputs based on expert judgment, are covered when the output is quantitative in nature. That wording suggests the output element carries more weight than the input element.

The same texts list uses that bring a model into scope, including informing business decisions, identifying and measuring risk, valuing exposures, stress testing and meeting regulatory reporting requirements. One clearing agency filing adds a purpose test: only models that meet the definition and support compliance with the relevant standards are subject to the framework. That is one example of a definition-plus-purpose scoping test, and it shows why the stated use of a system matters as much as its architecture.

Mapping the elements to LLM-based systems

The mapping below is interpretation, not regulatory text. The method element is rarely the obstacle. An LLM applies statistical and computational techniques to inputs, and broader AI definitions, such as the one in Executive Order 14110, describe an AI model as a component that uses computational, statistical or machine-learning techniques to produce outputs from inputs. That formulation is wider than a quantitative-estimates test and is not a banking-supervision definition.

The contested element is output. LLM outputs are often natural-language text, not numeric estimates. If the definition requires output that is quantitative in nature, a system that only drafts or summarizes may sit outside it, while a system that returns a risk score, a classification or a numeric estimate used in a decision sits closer. Because qualitative inputs do not take a system out of scope under the wording above, a free-text prompt is not a reason to exclude a use case on its own.

The reporting component invites a further comparison. An LLM application layer can look like a component that translates estimates into business information, but treat that as interpretation. The practical question is whether the system's output is used to inform a decision of the kind the definition lists.

Deployment patterns and likely scope reading

These readings are starting positions for a documented scoping decision, not conclusions. Each depends on the actual use and on the definition's wording.

• LLM producing a score, rating or classification that feeds a decision: Closer to the output element. Likely to be treated as in scope and inventoried with validation and monitoring owners.
• Vendor-hosted LLM API behind an internal application: Scope follows the use case, not the hosting arrangement. How third-party AI is inventoried and validated is an open question for the model risk owner.
• Internal assistant for drafting and summarization: Output is text, so the quantitative-output element is a judgment call. Record the rationale either way.
• Assistant with retrieval over internal documents: Scope depends on what the output informs. Inventory the retrieval sources with the deployment.
• Tool-calling agent: Treat as a separate pattern. Tool access can change the use case, for example when an agent starts feeding a scoring process.

Scoping, inventory and ownership

Assign the scoping decision to a named model risk owner, with written criteria and periodic re-review. A use case that is out of scope today can move in when an assistant gains tool access or begins to feed a scoring process, so re-review should be triggered by change, not only by calendar.

Build the inventory at use-case level. For each LLM deployment, record the model or vendor API, the system prompt and retrieval sources, connected tools, and the decisions the output informs. The GSA acquisition text, a procurement definition and not model risk guidance, treats an LLM as including its surrounding environment: system prompts, configurations, knowledge bases, retrieval mechanisms, APIs and monitoring. That system-level framing is a useful analogue for inventory granularity. NIST AI RMF GOVERN 1.6 likewise supports inventorying AI systems in proportion to organizational risk priorities.

For every deployment, document the outcome as in scope, out of scope or escalated for review, state which elements drove it, and mark where judgment was applied. An undocumented exclusion is the main way LLM use cases drop out of the inventory, validation scope and control design.

What runtime enforcement evidence covers and what it does not

Once a deployment is in scope, some expectations can be supported by evidence generated at runtime. A policy enforcement point in the execution path, between the application, the LLM API and its tools, can allow, redact, block or escalate for human approval each prompt, response and tool call. Each outcome, together with the policy configuration in force at that moment, becomes a record of what the system was permitted to do and what it did. This is the kind of evidence a regulator can examine on request.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers at the level of individual interactions and tool calls, and generates audit-ready evidence from that enforcement. It does not establish model provenance, training lineage or end-to-end tracing of agentic workflows, and runtime evidence should not be presented as doing so.

Validation and conceptual soundness need separate work, and ownership for them should be explicit. NIST AI RMF MEASURE 2.9 (the model is explained, validated and documented, and output is interpreted in context) and MANAGE 3.2 (pre-trained models are monitored as part of regular system monitoring) are useful reference points. They are NIST guidance, not SR 26-2 requirements.