For EU financial entities in its scope, DORA treats a provider of digital services as an ICT third-party service provider. An AI agent platform, and usually the model provider behind it, fits that description. That puts agent providers inside the firm's ICT third-party risk management: due diligence, contract terms, monitoring, exit planning and stricter oversight for critical work.
What does DORA require?
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It sets requirements for financial entities in four main areas: ICT risk management, the handling and reporting of ICT-related incidents, digital operational resilience testing, and the management of ICT third-party risk. Our explainer on what DORA is gives the overview, and our page on the DORA ICT risk management framework for AI agents covers the first area.
The third-party area is where agent providers land. In substance, firms must manage the risk arising from their use of ICT services supplied by others: assess providers before contracting, put specific terms in contracts, keep a record of their arrangements, monitor the provider, plan how to exit, and take extra care where a service supports a critical or important function.
Why are agent providers ICT third parties?
Because they supply digital services the firm relies on to operate. An agent platform that hosts agents, connects them to the firm's systems, checks their actions and keeps their records is an ICT service. So is the model provider whose model the agents call. So may be the providers of retrieval, storage or identity services in the chain.
Our explainer on whether AI agent vendors are ICT third-party providers under DORA works through the definitions. The practical point is that firms should assume agent providers are in scope unless there is a clear reason they are not, and treat them through the existing third-party framework rather than a separate AI process.
What changes when the ICT service is an agent?
Agents are not like most ICT services, and the differences matter for how third-party risk is managed.
| Third-party risk activity | Usual ICT service | Agent platform |
|---|---|---|
| Due diligence | Security, availability, financial standing | Also: how bounds are enforced, how actions are recorded, how model changes are handled |
| Contract terms | Service levels, data location, audit rights | Also: notice of model changes, export of the decision record, ability to lower agent authority instantly |
| Monitoring | Uptime, incidents, performance | Also: verdict patterns, attempts beyond bounds, certification status |
| Concentration | Reliance on one provider | Also: many agents relying on one model provider through several platforms |
| Exit | Migrate data and workloads | Also: hand work back to people, preserve the decision record |
Two rows deserve attention. Monitoring an agent platform is not only about whether it is up. A healthy platform can host an agent that is acting wrongly, which is an operational risk the firm must see. And exit is not only about moving data. If the agent is withdrawn, the work it did must go somewhere, usually back to people, which needs planning long before it is needed. Our page on DORA ICT third-party risk when your agent runs on a vendor platform covers these in more detail.
Why does the model provider matter even if you never contract with it?
Because your agent platform depends on it. If the model provider changes its model, suffers an outage or withdraws a service, your agents are affected. DORA expects firms to understand the chain of providers supporting critical or important functions, not just the provider they contract with directly.
Model changes are a particular issue for agents. A new model version can change how an agent behaves on your cases, even if nothing else changes. Contracts and monitoring should make sure the firm learns of such changes in time to re-test its agents before relying on them.
When does an agent support a critical or important function?
When its failure or misbehaviour would materially impair the firm's performance, compliance or ability to continue its services. An agent that drafts internal summaries probably does not. An agent that processes payments, handles customer onboarding or manages claims at volume may well do. The answer depends on the agent's depth and scope, not on the fact that it is AI.
Where it does, the stricter expectations apply: fuller contractual terms, closer monitoring, tested exit plans and, in some cases, inclusion in resilience testing. Incidents involving the agent may also fall within DORA's incident classification and reporting rules.
How does this sit with the EU AI Act?
They operate side by side. DORA addresses operational resilience and third-party risk. The EU AI Act addresses risks from AI systems themselves, with separate duties for providers and deployers. A bank using an agent platform may be a DORA financial entity managing an ICT third party and, at the same time, an AI Act deployer with its own obligations; our explainer on how using an agent makes you a deployer covers the second role.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What is the trade-off?
Bringing agent providers into DORA third-party management adds work: more due diligence questions, more contract terms, more monitoring and exit planning that involves operations as well as technology. Some providers will resist terms on model change notice or record export.
Treating agents as an ordinary software purchase is easier and leaves a gap that supervisors are likely to find. Add agent-specific questions to your due diligence, agent-specific terms to your contracts, decision-level monitoring to your oversight and a handback plan to your exit strategy. The wider mapping of rules to controls is in our guide to AI agent regulation, mapped to controls.
Where Pryme fits
Pryme is an ICT service for firms that use it, and should be managed as one. Each customer can lower an agent's depth at once, export the append-only verdict record, and see each agent's certification status. Those features support monitoring and exit planning; they do not replace the firm's own third-party risk management.
Questions people ask
Does DORA apply to every company using AI agents?
No. DORA applies to a defined set of EU financial entities, such as banks, insurers, investment firms and payment institutions. Companies outside that set are not subject to it, though its practices are sound for anyone.
Do agent incidents need to be reported under DORA?
If an incident meets DORA's criteria for a major ICT-related incident, it must be reported, whether or not an agent was involved. An agent acting wrongly on a third-party platform may qualify, depending on its impact.
Should agent providers be included in resilience testing?
Where agents support critical or important functions, testing should consider how the firm would cope with the agent platform failing or behaving wrongly, including handing work back to people.