Yes, in most cases. DORA treats digital and data services supplied through ICT systems as ICT services, and an AI agent platform or model provider serving an EU financial entity fits that description. The duties sit mainly with the financial entity: manage the vendor as ICT third-party risk, contract for specific terms, record the arrangement and plan an exit.
What does DORA require, in plain words?
The Digital Operational Resilience Act (Regulation (EU) 2022/2554), which applies from 17 January 2025, sets common rules for how EU financial entities manage technology risk. It has four main areas: ICT risk management, incident reporting, resilience testing, and ICT third-party risk. Our explainer on what DORA is covers the whole regulation.
The third-party part requires a financial entity to treat its ICT suppliers as a source of risk it must manage. In substance: assess suppliers before contracting, include certain terms in contracts, keep a register of all ICT contractual arrangements, monitor suppliers over time, and have exit strategies. Requirements are heavier where a service supports a critical or important function. Separately, the most systemically important providers can be designated for direct oversight at EU level.
Who does it apply to?
DORA applies to a wide range of EU financial entities: banks, payment and e-money institutions, investment firms, insurers, crypto-asset service providers and others. The obligations described here fall on those entities. A vendor is not regulated by DORA simply for being a vendor, but it will feel DORA through its customers' contracts, audits and information requests.
What does it mean when the service is an AI agent?
An agent vendor is often more embedded than a typical software supplier. The agent reads from systems of record, acts in operational processes and may hold credentials. That raises three questions DORA's framework forces you to answer.
Is the function critical or important? An agent drafting internal notes may not be. An agent that processes payments or handles customer claims may well be. The answer drives contract terms, testing and exit planning.
What is the chain of providers? An agent platform usually depends on a model provider and a cloud host. Those are subcontractors in the chain, and your risk assessment and register need to reflect them. The guide on DORA ICT third-party risk when an agent runs on a vendor platform goes through this chain.
Can you exit? If the vendor holds your agents' briefs, bounds and records in a form you cannot take away, an exit plan is hard to make credible. Our view that DORA makes agent providers ICT third parties follows from this point.
How do you meet it?
| Requirement in substance | Control for an agent vendor | Evidence it leaves |
|---|---|---|
| Pre-contract risk assessment | Assess the vendor, its model provider and hosting | A signed assessment |
| Contract terms | Service description, data location, audit and access rights, incident support, termination and exit | The executed contract |
| Register of arrangements | Record the vendor and its material subcontractors | Register entries |
| Ongoing monitoring | Review performance, incidents and changes to model or hosting | Monitoring reports |
| Exit strategy | Briefs, sources, bounds, case sets and records kept exportable; fallback to people tested | Exit plan and drill results |
| Incident handling | Vendor incident notice wired into your classification process | Incident records |
The agent itself can help prepare these assessments, but a person decides; see whether an AI agent can assess third-party risk.
What will a supervisor ask?
Expect questions such as: which functions do your agents support, and are any critical or important? Who are the vendor's subcontractors, including the model provider? Where is your data processed? What happens to your operations if the vendor or the model provider fails tomorrow? Can you show the last time you tested that?
What does DORA not cover?
DORA does not decide whether your agent's decisions are fair, lawful or explainable to customers. Those questions come from data protection law, conduct rules and, for certain uses, the EU AI Act. It also does not apply to firms outside its scope, although similar expectations exist elsewhere; US banks, for example, face third-party risk expectations from supervisors including the OCC, discussed in OCC third-party risk and AI agent vendors.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What does that look like for one firm?
Say an EU payment institution uses an agent platform to triage payment exceptions, with a model provider behind it. It classifies the function as important, because delayed exceptions affect customers' payments. It records both the platform and the model provider in its register, negotiates audit rights and data location terms, and requires notice of any model change. Its exit plan keeps every agent's brief and record exportable, and it drills a two-day fallback to people each year.
The wider rules picture is in our guide to AI agent regulation.
Questions people ask
Is the model provider a third party if we only use it through the agent platform?
It is part of the chain, usually as a subcontractor of the platform. Your assessment and register should reflect it, especially if it supports a critical or important function.
Does using an open-weight model we host ourselves avoid this?
It removes the model provider from the chain, but your hosting provider and any platform vendor remain. You also take on running the model yourself as part of your own ICT risk.
Do agent vendors need to be in the EU?
DORA does not ban non-EU providers, but location affects risk assessment, data protection and contract terms. Some arrangements for critical functions attract closer scrutiny.