Treat it as one. Under PRA SS1/23, a model is a method that turns inputs into outputs used in decisions, and a generative AI agent that classifies, recommends or decides does that, even when its output is text. The language model is a vendor component inside it; the brief, sources and tools also shape its outputs and belong in scope.
What does SS1/23 say a model is?
SS1/23 sets the PRA's model risk management principles for banks. Its first principle requires firms to have a clear definition of a model, to identify the models they use, and to classify them by risk. The definition is deliberately broad: a method that processes input data into outputs, applied to AI and machine learning techniques as well as traditional statistical ones. The PRA expects firms to think about where model risk arises, not to look for reasons to place tools outside scope.
The other principles follow from classification: governance, sound development and use, independent validation, and mitigants for model risk. For the full set applied to agents, see PRA SS1/23 model risk management for agents.
Who does it apply to?
Primarily UK banks and building societies with permission to use internal models for regulatory capital. Other PRA-regulated firms are encouraged to consider the principles. In practice many UK lenders apply them to all model use, because the alternative is a second, weaker framework for AI.
Why is the question harder for generative agents?
Traditional models produce numbers: a probability of default, a price, a score. Generative agents produce text and actions. That leads some firms to argue an agent is "software", not a model. The argument fails on what the agent actually does.
An agent handling complaints reads a customer's message, decides what kind of complaint it is, judges whether it is upheld, and drafts a response. Each step is an estimate turned into a decision. The output happens to be words, but the classification and the judgement inside them are model output in every sense that matters for risk.
Generative agents also carry the features that make model risk worth managing: their behaviour depends on assumptions (the brief), on data (the sources), and on a method the firm cannot fully inspect (the language model). They can be wrong in systematic ways, and they can be used beyond their intended purpose.
How do you decide which parts are in scope?
Break the agent into its parts and ask of each whether it shapes outputs used in decisions.
| Part of the agent | In scope? | Why |
|---|---|---|
| Language model | Yes, as a vendor component | Processes inputs into outputs; firm cannot inspect it fully |
| Brief: role, criteria, instructions | Yes | Encodes the method and assumptions |
| Sources and retrieval | Yes | Determines which facts the outputs rest on |
| Tools and limits | Yes, as model use | Decide how outputs become effects |
| Logging and records | Supporting control | Evidence for validation and monitoring |
Then decide on edge cases. An agent that only routes messages to queues may be a low-tier model or a simple tool, depending on whether routing affects customer outcomes. An agent that summarises documents for staff is in scope if staff decisions rely on the summaries. An agent that moves money is always in scope and belongs in a high tier.
Take an illustrative case. A UK bank's model risk team reviews a generative agent that drafts responses to credit limit increase requests. The business argues it is a drafting tool. The team finds the agent's draft states whether the request is granted, and that underwriters change the outcome rarely. It records the agent as a model, with the language model as a vendor component, tiers it by its influence on credit decisions, and requires validation on past requests before the agent continues.
How do you record and govern the decision?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Model definition covers AI | Definition explicitly addresses generative agents and their parts | Approved model definition |
| Identification | Process to find agents across the business, including those built by business teams | Discovery records |
| Scoping decision | Written decision per agent on which parts are in scope and why | Scoping memo |
| Classification | Tier based on decision influence and what the agent can do | Tier rationale |
| Vendor component | Language model recorded with provider, version and change process | Inventory entry |
| Review of exclusions | Out-of-scope decisions reviewed periodically and on change | Review log |
Validation then follows the tier; see PRA SS1/23 model validation for agents.
What will a PRA supervisor or internal audit ask?
- How does your model definition treat generative AI agents?
- Which agents did you decide are not models, and why?
- How do you find agents that business teams have built themselves?
- Is the language model recorded, and how do you learn of changes to it?
- Does tiering reflect what the agent can do, not only what it says?
What does SS1/23 not settle?
It does not list which AI tools are models; the firm decides, and must justify the decision. It does not address conduct risk, data protection or operational resilience directly. Other supervisors have reached similar conclusions in their own frameworks; see how OSFI E-23 applies to AI agents for Canada. For a short answer focused on scope, see whether SS1/23 covers AI agents. For the full map, see our guide to AI agent regulation mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
If an agent only produces text, can it still be a model?
Yes. What matters is whether its output carries estimates or judgements used in decisions. A drafted response that says a complaint is not upheld contains a classification, whatever its format.
Should every prompt change count as a model change?
Changes to the brief alter the method, so they should go through change control. Minor wording fixes can follow a light path; changes to criteria, scope or tools should trigger re-validation.
Is the model provider responsible for model risk?
No. The provider supplies a component. The bank owns the risk of how the agent uses it, and must manage it through validation, monitoring and limits.