DORA and the EU AI Act: Where the Two Regimes Overlap

DORA and the EU AI Act are separate regulations that happen to reach the same AI systems from different angles: DORA through the ICT risk rules financial entities already follow, the AI Act through obligations tied to AI systems themselves. The AI Act's Digital Omnibus, in force since 27 July 2026, pushed most high-risk deadlines out to December 2027, but that delay changes nothing under DORA. An AI model supporting a critical or important function is already an ICT asset a financial entity has to manage today.

Two regimes, two different objects

DORA (Regulation (EU) 2022/2554) regulates financial entities: banks, insurers, payment firms, investment firms, and a handful of other sectors listed in Article 2, plus the ICT providers they depend on. It does not care what technology sits inside a system; it cares whether that system supports a function the entity needs to keep running, and whether the entity has mapped, tested, and can recover that system under the ICT risk management framework set out in Article 6.

The AI Act (Regulation (EU) 2024/1689) regulates something narrower: the AI system itself, wherever it sits and whoever uses it. It sorts AI systems into risk tiers, bans a short list outright, and attaches documentation, oversight, and conformity duties to the systems it classifies as high-risk. A bank's credit-scoring model can be subject to both regimes at once, DORA because it runs on ICT infrastructure the bank must manage, the AI Act because of what the model decides.

Where the overlap actually sits

In practice, the overlap shows up in three places rather than across the whole of DORA. First, the ICT risk management pillar: any AI system supporting a critical or important function has to be identified in the entity's asset inventory, assessed for risk, and covered by the same business continuity and recovery planning as any other system, regardless of whether the AI Act also applies to it. Second, third-party risk: an AI vendor providing a model or platform a financial entity relies on is an ICT third-party provider under Articles 28-30, with the same contractual clauses, register-of-information entries, and exit-strategy obligations as any other supplier, AI-specific or not. Third, incident reporting: an AI system failure or manipulation that disrupts a critical function can trigger DORA's major-incident reporting duty under Articles 17-23, on DORA's own four-hour and twenty-four-hour clock, independently of anything the AI Act separately requires.

Which AI uses in finance count as "high-risk" under the AI Act

The AI Act's Annex III lists the AI uses it treats as high-risk. Two entries land squarely in financial services: point 5(b) covers AI used to evaluate the creditworthiness of natural persons or set a credit score, and point 5(c) covers AI used for risk assessment and pricing in life and health insurance. Fraud-detection models are generally carved out of 5(b), and property and casualty insurance pricing generally falls outside 5(c) unless another Annex III category applies. A bank running an AI-driven credit-scoring model for retail lending, or an insurer pricing life cover with a predictive model, sits inside the AI Act's high-risk category; the same bank's AI fraud-detection system typically does not.

This matters for how the two regimes overlap in a given firm: a bank using AI for retail credit decisions and a life insurer pricing policies with a model both carry AI Act high-risk obligations on top of their existing DORA obligations for the same system. A payment firm using AI only for fraud screening generally carries the DORA obligations without the AI Act's high-risk layer.

What the Digital Omnibus actually delayed

Regulation (EU) 2026/1744, the "Digital Omnibus on AI," amended the AI Act and entered into force on 27 July 2026, three days after its publication in the Official Journal. Its headline change for financial services: the compliance date for stand-alone Annex III high-risk systems, credit scoring and insurance pricing among them, moved from 2 August 2026 to 2 December 2027. High-risk systems embedded in regulated products move further out, to 2 August 2028, a category that rarely applies to financial-services AI. The AI Act's transparency duties under Article 50 (telling people they are interacting with an AI system, for example) were not part of the delay and still apply from 2 August 2026.

The practical effect is a longer runway for the technical documentation, human-oversight arrangements, and conformity assessments the AI Act expects of a high-risk credit-scoring or insurance-pricing model. It is not a holiday from AI governance altogether, and it has no bearing on DORA, which was never on the AI Act's clock to begin with.

Why the delay doesn't give DORA-regulated entities a pass

On 31 July 2026, the EBA, EIOPA, and ESMA issued a joint statement calling for a consistent, risk-based supervisory approach to the ICT risks that increasingly capable, "frontier" AI models create for the EU financial sector. The statement does not create new legal obligations; supervisors describe it as clarifying how existing requirements, DORA's among them, already reach this risk. It sits alongside the ESRB's July 2026 warning on systemic AI-driven cyber risk and the ESAs' Autumn 2026 risk update, which flagged AI-accelerated cyber risk again two months later. Read together, the message from supervisors is consistent: the AI Act's own timeline moving does not pause DORA's expectation that AI-related ICT risk, from a vendor's frontier model to an in-house scoring tool, is managed now, not once the AI Act's high-risk duties eventually land in December 2027.

A practical way to avoid duplicate compliance work

Entities that treat DORA and the AI Act as two separate project streams tend to produce two separate, overlapping sets of documentation for the same system. A tighter approach starts from the asset, not the regulation:

• Add an AI flag to the ICT asset inventory. For each system already mapped under Article 6, note whether it is or contains an AI model, and whether that model falls inside an AI Act Annex III category. The DORA mapping work is not wasted; it becomes the starting point for the AI Act assessment rather than a parallel exercise.
• Treat the AI vendor like any other ICT third-party provider. If an external model or platform supports a critical or important function, it already belongs in the register of information and needs the Article 30 contractual provisions. The AI Act's own documentation and oversight requirements can sit on top of that same contract rather than needing a separate vendor review.
• Keep incident-response playbooks explicit about which clock applies. An AI-related failure affecting a critical function may trigger DORA reporting on its own timeline regardless of what the AI Act separately requires; writing that down in advance avoids confusion mid-incident.
• Do not wait for December 2027 to start on high-risk AI Act duties. The delay buys time to build documentation and human-oversight controls properly; it does not reduce DORA's expectation that the underlying system is already risk-assessed, tested, and recoverable.

Entities scoping this work alongside a broader DORA gap assessment can use the DORA Readiness Score to see how their ICT risk management and third-party pillars score before adding an AI-specific review on top.

Sources

• Regulation (EU) 2022/2554 (DORA), Articles 2, 6, and 17-30, EUR-Lex.
• Regulation (EU) 2024/1689 (the AI Act), Annex III and Article 50, EUR-Lex.
• Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending the AI Act's compliance deadlines, EUR-Lex.
• EBA, EIOPA, and ESMA, EBA, EIOPA and ESMA call for enhanced governance and consistent supervision to mitigate ICT risks from frontier AI models in the EU financial sector, 31 July 2026.

Last updated: 19 October 2026.