DORA and AI: What the Digital Operational Resilience Act Requires of AI Systems and AI Agents, and DORA vs the EU AI Act

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 to banks, insurers, investment firms and 17 other types of financial entity. It never mentions artificial intelligence, but an AI system or agent is an ICT asset and a model API or AI platform is an ICT service, so DORA's rules on ICT risk management, incident reporting, resilience testing and third parties all cover AI. The EU AI Act adds AI-specific duties on top: DORA asks whether the entity stays resilient, the AI Act whether the AI system is safe and respects fundamental rights.

This guide maps each part of DORA onto AI systems and agents, compares DORA with the AI Act and NIS2, and ends with the evidence an agent platform should produce. It is written for CISOs, heads of ICT risk and compliance officers at financial entities, and it is not legal advice.

DORA in brief

Article 2(1) lists 20 types of financial entity, from credit, payment and e-money institutions and investment firms to insurers, occupational pension funds, crypto-asset service providers and crowdfunding service providers; its final point adds ICT third-party service providers, which the regulation reaches mainly through the oversight of critical providers. Proportionality runs through the text, and some smaller entities may use a simplified framework under Article 16. The DORA glossary entry gives the short definition.

Where AI sits in DORA

The official text of DORA contains no reference to artificial intelligence, machine learning or AI. It does not need one. An ICT asset is any software or hardware asset in the entity’s network and information systems (Article 3(7)); ICT services are digital and data services provided through ICT systems on an ongoing basis (Article 3(21)); and an ICT third-party service provider is any undertaking that provides them (Article 3(19)). An agent built in-house is an ICT asset. A model API, a hosted agent platform or an AI feature inside a SaaS product is an ICT service, and its vendor is an ICT third-party service provider. What remains is to apply each pillar.

ICT risk management: inventory, identity, change and logs

The management body bears ultimate responsibility for ICT risk (Article 5(2)), so the decision to let agents act on bank systems belongs on its agenda. Article 8 requires the entity to identify, classify and document its ICT-supported business functions and the assets behind them, map the critical ones and their interdependencies, keep the inventories current, and assess risk on every major change. Each agent, model, tool connection and knowledge index belongs in that inventory, linked to the business function it supports: an agent drafting credit memos supports a different function from one answering staff IT questions.

Delegated Regulation (EU) 2024/1774 turns several controls into specific requirements that fit agents closely:

• Identity (Article 20): policies must ensure the unique identification and authentication of natural persons and of systems that access the entity’s information. An agent is such a system, so it should never run on a person’s account or a shared one.
• Access (Article 21): rights follow need-to-know, need-to-use and least privilege, with segregation of duties, users identifiable for their actions at all times, and reviews at least every six months for systems that support critical or important functions.
• Change (Article 17, with Article 9(4)(e) of DORA): every change is recorded, tested, approved and verified, the approver is independent of whoever requested and implemented it, and fall-back procedures exist. A new model version, system prompt, tool or autonomy level is an ICT change.
• Logging (Article 12): the entity decides which events to log and for how long, covers access, change management and ICT operations, protects logs against tampering and deletion, and detects when logging fails.

DORA itself adds detection of anomalous activity (Article 10), such as unusual tool sequences or a surge in denied permissions, and containment measures for each type of incident (Article 11), which for agents means being able to stop one at once.

Incidents: what an AI-agent incident looks like

Every ICT-related incident must be recorded and classified against six criteria in Article 18: clients and transactions affected, duration, geographical spread, data losses, criticality of the services affected and economic impact. Under Delegated Regulation (EU) 2024/1772, an incident is major when it affects critical services and either meets the threshold for malicious unauthorised access that may cause data loss or crosses two other thresholds; costs and losses above EUR 100,000 meet the economic one. Delegated Regulation (EU) 2025/301 sets the reporting clock: an initial notification within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of that notification, and a final report no later than a month after the last intermediate report.

Agent incidents take recognisable forms:

• A prompt-injected agent uses a legitimate tool to send customer records outside the bank, which can amount to malicious unauthorised access that may cause data loss.
• An agent with write access posts wrong values into a payments or reconciliation system.
• A model provider’s outage stops an agent that supports a critical function.
• A looping agent calls an expensive tool repeatedly until the service it shares slows down.

The same event can also be a serious incident under the AI Act, where a deployer of a high-risk system informs the provider first, and a personal data breach under the GDPR. Keep one incident record that feeds every clock; the containment playbook for private agents sets out the steps.

Testing: agents in the resilience programme

Entities other than microenterprises must test all ICT systems and applications that support critical or important functions at least yearly (Article 24(6)), with methods ranging from vulnerability scans and source code reviews to scenario-based, end-to-end and penetration tests (Article 25). Entities identified for threat-led penetration testing must run it at least every three years on live production systems, covering outsourced functions and the providers behind them (Article 26). For an agent that supports a critical function, the programme should include prompt injection and tool misuse, failover when a model endpoint is unavailable, behaviour under load and rollback of a faulty model version.

Third-party risk: the register, the contract and the exit

The financial entity stays fully responsible for its obligations whatever it outsources (Article 28(1)). It keeps a register of information covering every ICT contractual arrangement, using the templates in Implementing Regulation (EU) 2024/2956, and distinguishes arrangements that support critical or important functions (Article 28(3)). Before contracting, it assesses the function, the risks and the provider, including concentration risk (Articles 28(4) and 29), which grows when one model provider or hyperscaler sits under many workflows.

Article 30(2) sets the minimum content of every ICT contract, and three points matter most for AI:

• the regions or countries where services are provided and data is processed and stored, with advance notice of any change;
• access to, recovery and return of the entity’s data if the provider fails or the contract ends;
• assistance in ICT incidents and full cooperation with supervisors.

Where the AI service supports a critical or important function, Article 30(3) adds quantitative service levels, notice and reporting duties, tested contingency plans, participation in threat-led tests, unrestricted rights of access, inspection and audit, and an exit strategy with a mandatory transition period. For those services, Article 28(8) also requires tested exit plans that let the entity remove the services and the data and move them to another provider or back in-house. The model provider behind an AI vendor is usually a subcontractor in DORA’s terms, which brings Delegated Regulation (EU) 2025/532 into play for critical functions. AI adds questions of its own: whether prompts and outputs train models, how much notice a model change gets, and whether the workload can run on another model. The AI vendor security questionnaire turns these into scored questions.

Information sharing

Article 45 lets financial entities exchange cyber threat information, including indicators of compromise, tactics, techniques and procedures, within trusted communities. Prompt-injection payloads seen in the wild and malicious tool servers are the kind of intelligence such arrangements can carry.

Are AI model providers critical ICT third-party providers?

Any AI vendor supplying ICT services is an ICT third-party service provider. Critical status is different: under Article 31, the European Supervisory Authorities (EBA, EIOPA and ESMA), acting through their Joint Committee on the Oversight Forum’s recommendation, designate providers as critical based on systemic impact, the systemic importance of the entities relying on them, reliance for critical or important functions and substitutability. Each critical provider gets a Lead Overseer, and the list is updated yearly. Intra-group providers, and providers serving only financial entities active in a single member state, cannot be designated.

The first list, published on 18 November 2025 and the only one available when checked on 6 November 2026, names 19 providers: Accenture, Amazon Web Services EMEA, Bloomberg, Capgemini, Colt Technology Services, Deutsche Telekom, Equinix (EMEA), Fidelity National Information Services, Google Cloud EMEA, IBM, InterXion HeadQuarters, Kyndryl, LSEG Data and Risk, Microsoft Ireland Operations, NTT DATA, Oracle Nederland, Orange, SAP and Tata Consultancy Services. Several sell AI model services on their clouds; no standalone AI model developer is on the list. Designation changes nothing for the bank’s own duties: the register, the contract terms and the exit plan apply to every AI vendor, critical or not.

DORA vs the EU AI Act

The AI Act already makes room for financial supervision. Deployers that are financial institutions keep AI Act logs within the documentation financial services law already requires, and they meet the AI Act’s monitoring duty by complying with their internal-governance rules (Article 26(5) and (6)). The AI Office’s exclusive competence over systems that a model provider builds on its own general-purpose model also excludes AI systems provided by financial institutions that fall under Article 74(6), which stay with national supervisors. The AI Act guide for banks and insurers covers the high-risk uses in detail, and the companion piece on how the AI Act treats agents covers roles and classification.

Where NIS2 fits

DORA declares itself the sector-specific act for financial entities under Article 4 of NIS2 (Article 1(2) of DORA), and NIS2’s recital 28 says DORA’s provisions on ICT risk management, incident reporting, testing, information sharing and third-party risk apply instead of its own. A bank’s AI systems therefore follow DORA, while an energy company’s AI follows NIS2; the NIS2 and AI guide covers the second case.

Mapping DORA to an AI agent platform

An AI agent audit trail supplies most of the logging and incident evidence in this table.

On-premises versus SaaS under DORA

Deployment choice changes how hard four duties are. With SaaS AI, the contract has to pin down data locations and sub-processors, audit rights have to reach a provider that serves many other customers, concentration risk builds when the same few clouds sit under many workflows, and an exit means retrieving prompts, configurations and logs before switching models. With on-premises or air-gapped deployment, inference, embeddings and logs stay in data centres the entity already lists, audit evidence sits on its own systems, and an exit means replacing software rather than recovering data. The trade-offs by deployment model are compared in AI agent deployment options, and the recovery side in disaster recovery for on-premises AI.

Most banks will run a mix: open-weight models on their own hardware for confidential workloads and a cloud model for low-risk drafting. DORA prefers neither, but the register should show which workflow relies on which provider and model, and the routing rules should be written down so a supervisor can see why a request went where it did. Keeping each routing decision in the logs turns a design choice into evidence.

On-premises does not take the vendor out of DORA. A company that licenses, supports and updates a self-hosted platform still provides ICT services, so it belongs in the register of information and its contract needs the Article 30 terms, with the stricter Article 30(3) set if the platform supports a critical or important function. Software updates and open-weight model files also need supply-chain review. The wider case for this architecture in financial services is made in on-premise AI for financial services and the executive brief for finance.

What supervisors have said about AI

Two supervisory papers from 2025 show how the authorities expect AI to sit inside existing rules rather than under new ones:

• EIOPA, 6 August 2025. An opinion addressed to national supervisors on governing insurance AI that is neither prohibited nor high-risk under the AI Act, read through Solvency II and the Insurance Distribution Directive. It expects risk-based, proportionate measures on data governance, record-keeping, fairness, cybersecurity, explainability and human oversight, and EIOPA stresses that it “does not set new requirements”.
• EBA, 21 November 2025. A factsheet on a mapping of the AI Act’s high-risk requirements, centred on credit scoring, against banking and payments law, DORA included. The EBA found the frameworks complementary rather than contradictory, saw no immediate case for new guidelines and stressed cooperation between financial supervisors and market surveillance authorities, which it plans to support.

For the wider set of rules a bank’s AI meets, from model risk to the AI Act, see AI for banks; the cross-cutting risk view for agents is in agentic AI risk management.

How VDF AI fits

VDF AI runs in VDF’s managed cloud, in an entity’s own data centre, in a private cloud or VPC, in a sovereign cloud or fully air-gapped. In the on-premises and air-gapped options, models, indexes and logs stay on the entity’s hardware, which settles the data-location question for those workloads. VDF AI Router applies allow, deny and pin lists before any model call, returns every routing decision with its reason and candidate list, fails over across an ordered list of candidates, and in air-gap mode routes to local models only.

The registry in the AI governance platform records every agent, Network and model with an owner, a purpose, a risk class and a version, which can feed the Article 8 inventory. VDF AI Agents grants tools per agent with least-privilege scopes under role-based access control, and on-premises sign-in uses Microsoft Entra ID natively. Each run leaves an audit log and execution trace, consequential actions wait for a named approver, and VDF AI Networks adds retry with backoff, circuit breakers, fallback routing and SLO tracking for multi-agent workflows.

For incidents and audits, the Vault keeps a cryptographically durable record of each execution, decision receipts bind prompt, sources, model, tools and outcome, and a kill switch stops an agent, a Network or a model. Controls are mapped to DORA, which means the platform supports the entity’s measures; the register entry, contract terms and exit plan for any vendor, VDF included, remain the financial entity’s to set. Banks can see the sector view on the finance and banking solution page and the value for the finance sector summary.