Usually, yes. Under SR 11-7 a model is a quantitative method that turns inputs into estimates used for decisions, and an AI agent that classifies, scores, prioritises or recommends does exactly that. The underlying language model is a vendor model inside it. The agent's instructions, sources and actions shape its outputs too, so the whole agent belongs in scope.
What does SR 11-7 say a model is?
The interagency guidance SR 11-7 defines a model, in substance, as a quantitative method, system or approach that applies statistical, economic, financial or mathematical theories, techniques and assumptions to process input data into quantitative estimates. It has three components: an information input component, a processing component that turns inputs into estimates, and a reporting component that translates estimates into useful business information.
The definition also covers quantitative approaches whose inputs are partly or wholly qualitative or based on expert judgement, provided the output is quantitative in nature.
Model risk arises from two sources: a model with fundamental errors producing inaccurate outputs, and a model used incorrectly or inappropriately. SR 11-7 expects banks to manage both through sound development and use, independent validation and governance with effective challenge. Our short answer to whether SR 11-7 applies to AI agents sets out the scope argument.
Who does it apply to?
Banking organisations supervised by the Federal Reserve and the OCC, with the FDIC applying the same approach to the banks it supervises. Many non-bank lenders and fintechs adopt it because their bank partners or investors expect it.
Which parts of an agent fall within model risk management?
The practical question is not "is it a model?" but "which parts of it carry model risk?". Map the agent onto SR 11-7's three components.
| Agent part | SR 11-7 component | Why it carries model risk |
|---|---|---|
| Data sources and retrieval | Input | Wrong, stale or incomplete facts produce wrong outputs |
| The language model | Processing | Vendor model whose behaviour may change and cannot be fully inspected |
| The brief: role, criteria, instructions | Processing (assumptions) | Encodes the method; a change alters every output |
| Tools and actions the agent can take | Reporting and use | Translates output into effect, often without a person |
| Limits and escalation rules | Use controls | Determine when the output is relied on |
Three conclusions follow.
The language model is a vendor model. SR 11-7 expects vendor models to be in scope, with validation adapted to what can be seen. You may not see the weights, but you can test behaviour on your own cases and require the vendor to disclose changes.
The brief is part of the model. Changing the agent's instructions is a model change. It should go through the same change control and, where material, revalidation as a change to a scorecard's variables.
Text outputs do not escape scope. An agent that writes "recommend decline: high debt-to-income" is producing a classification. An agent that ranks alerts produces an ordering. Both are quantitative in nature, even if expressed in words.
When is the answer no?
Some agents fall outside the definition: an agent that only retrieves approved answers to customer questions, with no assessment, ranking or recommendation; or an agent that formats documents. Even then, banks usually govern them as tools under broader technology and third-party risk rules. Record the reasoning, because the scope can change with one edit to the agent's brief.
The general-purpose model behind the agent raises a separate question in the EU; our explainers on what a general-purpose AI model is and whether general-purpose AI model rules apply to agent builders cover that regime, which does not change the SR 11-7 analysis.
How do you bring an agent into model risk management?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Model inventory | Agent recorded with each capability, its model, brief, sources and actions | Inventory entry; see SR 11-7 model inventory for AI agents |
| Risk tiering | Tier set per capability by impact and reliance | Tiering record |
| Conceptual soundness | Brief, criteria and sources reviewed for fitness to purpose | Development documentation |
| Validation | Independent testing on cases from the bank's own operation | Validation report; see SR 11-7 model validation for AI agents |
| Ongoing monitoring | Outcome tracking with thresholds that trigger review | Monitoring reports |
| Change control | Changes to brief, sources, model version or actions assessed for revalidation | Change log with decisions |
| Vendor model oversight | Notice of model changes; behavioural tests after each | Vendor terms; test results |
| Use limits | Actions restricted to the validated scope | Permission map; refused actions |
What will an examiner ask?
- Is the agent in your model inventory, and is each capability rated?
- Who validated it, independent of its developers, and on what cases?
- How do you control changes to the agent's instructions?
- What happens when the model provider updates its model?
- How do you detect when the agent's outcomes drift?
- Which uses has it been validated for, and what stops it being used for others?
What does SR 11-7 not cover?
It does not address data protection, fair lending or consumer protection, though those apply to the same agent. It does not prescribe specific tests for language models. It does not by itself resolve accountability for vendor failures. For the full map, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme never updates model weights for a customer; qualification changes the agent's brief, sources, bounds and certification, all of which are versioned. Attest certifies each agent on real cases from your own operation, certificates lapse after 90 days, and a run that clears no depth drops the agent to depth 1 the same day. That gives model risk teams a current validation status per capability.
Questions people ask
Does each agent capability need separate validation?
Validation should cover each use the agent is relied on for. A capability that drafts credit memos and one that triages complaints have different risks and need different tests, even inside one agent.
Is prompt engineering model development?
Under SR 11-7, yes in substance. The brief encodes the method and assumptions. Treat changes to it with the same discipline as changes to model code.
Can we validate an agent whose model we cannot inspect?
Yes, by focusing on outcomes: testing on representative cases, benchmarking against people or existing processes, and monitoring in production. SR 11-7 expects this approach for vendor models where full transparency is not available.