DORA asks financial entities to assess ICT concentration risk before contracting for services that support critical or important functions. With AI agents, the risk often hides one layer down: several agent vendors may depend on the same few model providers and the same cloud. Assess concentration at the model and hosting layer, not just at the vendor you sign with.
What does DORA require on concentration risk, in plain words?
DORA (Regulation (EU) 2022/2554) applies from 17 January 2025. As part of managing ICT third-party risk, a financial entity that plans to contract for ICT services supporting critical or important functions must assess, in substance, whether the arrangement would lead to:
- contracting with an ICT third-party provider that is not easily substitutable; or
- having several arrangements with the same provider, or with closely connected providers.
The entity weighs the benefits and costs of alternatives, considers subcontracting chains, particularly where subcontractors are in third countries, and reflects the outcome in its decision and its exit planning. At EU level, concentration in the market is one reason supervisors designate critical ICT third-party providers for direct oversight. The general third-party position is in DORA makes agent providers your ICT third parties.
Who has to assess it?
Every financial entity within DORA's scope that relies on ICT third parties for critical or important functions, applying proportionality. Whether an agent vendor counts as an ICT third-party provider at all is covered in are AI agent vendors ICT third-party providers under DORA; in most cases it does.
The model provider is usually a subcontractor of the agent vendor rather than a direct counterparty. DORA still expects the entity to understand material subcontracting, and for agents that layer is where concentration lives.
Why is concentration different for agents?
Picture a bank that buys a servicing agent from one vendor, a collections agent from another and a fraud triage agent from a third. On paper it has diversified. Underneath, all three vendors call the same model provider, hosted in the same cloud region. A single outage, a single pricing change or a single behaviour change in that model reaches every agent at once.
Three features make this worse than ordinary IT concentration.
Substitution is slower than it looks. Swapping the model behind an agent is not like swapping a server. The agent's behaviour changes, so it must be re-tested and re-certified on the entity's own cases before it can keep its authority. Until then it should operate at lower depth.
Behavioural change is a concentration risk too. A model provider's update can change how every dependent agent behaves on the same day, without an outage. That is a correlated failure in integrity, not availability.
Visibility is poor. Vendors do not always disclose which model they use, or may switch between providers. Without contract terms, the entity cannot see its own concentration.
How do you assess and manage it?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Assess substitutability before contracting | For each agent, estimate time and effort to move to another model, including re-certification | Substitutability assessment per agent |
| Identify multiple arrangements with connected providers | Map every agent to its vendor, model provider and hosting | Dependency map across all agents |
| Understand subcontracting chains | Contract requires disclosure of model providers and hosting locations, with notice of change | Subcontractor schedules and change notices |
| Weigh alternatives | Consider second model provider, in-house option or human fallback for each critical function | Options analysis in the decision record |
| Reflect in exit plans | Exit plans cover model switch as well as vendor exit | Exit plans with model-switch steps |
| Record in the register | Model providers recorded as subcontractors supporting the relevant functions | Register of information entries |
Record the model provider in each agent's inventory entry, as shown in our model risk inventory entry template. That single field is what lets you see concentration across the estate. The register itself is covered in DORA register of information and AI agent providers.
What will a supervisor ask?
- Which model providers sit behind your agents, and how many critical or important functions depend on each?
- How long would it take to move an agent to a different model, and what would happen to its authority meanwhile?
- Does your contract tell you when the vendor changes model provider?
- What did your concentration assessment conclude before you signed?
- If your main model provider changed its model tomorrow, how would you know which agents were affected?
What does DORA's concentration duty not cover?
It does not ban reliance on a single provider; it requires you to assess and manage it. It does not require a second model for every agent; a staffed human fallback can be the right answer for some functions. It does not cover concentration in non-ICT services. And it does not by itself address model risk, the question of whether the model's outputs are sound, which sits in your model risk and testing framework. Concentration should feed into the wider DORA ICT risk management framework for AI agents. For the cross-regime view, 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 certifies each agent on the customer's own cases, so moving to a different model is a defined process: re-run Attest, and the agent keeps or regains its depth only on that evidence. Facts reaching the agent carry their provenance whatever model sits behind it, which keeps the bounds stable during a switch.
Questions people ask
Is using two agent vendors enough to avoid concentration?
Not if both rely on the same model provider or hosting. Check the layers underneath before counting it as diversification.
Should every agent support a second model?
For agents in critical or important functions, a tested fallback is sensible, whether that is a second model or a staffed manual process. For low-impact agents, accepting the concentration may be reasonable.
Does a model provider become a critical ICT third-party provider?
That designation is made at EU level by the supervisory authorities based on systemic importance. Whether or not a provider is designated, you must assess your own concentration.