AI Act and DORA Overlap
How the EU AI Act and DORA land on the same financial entity without either text citing the other, why Article 74(6) puts the AI file on the financial supervisor's desk, and what Articles 26(5), 26(6), 72(4) and 73(9) actually change.
19 min read
61 views
Technically reviewed by Victor Sineglazov, D.Sc.
Technically reviewed by Olena Zaichenko, D.Sc.
- Neither the AI Act nor DORA cites the other by name The AI Act reaches regulated financial institutions through category language about Union financial services law, never through a reference to a named instrument, and DORA says nothing about artificial intelligence.
- Your existing financial supervisor holds the AI file Article 74(6) puts AI Act market surveillance for these institutions with the national financial supervisor, scoped to systems in direct connection with the provision of financial services and subject to the Member State derogation in Article 74(7).
- Articles 26(5) and 26(6) are deeming rules, not exemptions One deems the monitoring limb fulfilled by internal governance compliance, the other says where logs are filed. Suspension, escalation, serious-incident reporting and the six-month retention floor all survive, and Article 17(4) leaves the same three duties standing on the provider side.
- Narrowing to the fundamental-rights limb changes what you must detect A DORA-shaped detection pipeline built around availability and ICT impact will not see a fundamental-rights incident, which is the exact limb Article 73(9) leaves in place.
- The AI Act date moved to 2 December 2027 and DORA's did not The Digital Omnibus deferred standalone Annex III high-risk applicability, which buys planning time but does not reduce the duty set, and DORA has applied since January 2025 regardless.
A bank inside DORA scope already runs an incident process, a classification standard and a reporting runbook. Then its credit scoring model turns into a high-risk AI system and someone asks how much of that machinery already answers the AI Act. Most published answers assume the two regimes were drafted with each other in view. They were not, and that changes what an institution has to build.
In short: Regulation (EU) 2024/1689 contains no reference to Regulation (EU) 2022/2554, and Regulation (EU) 2022/2554 contains no reference to artificial intelligence. Where the AI Act reaches regulated firms it names a category, Union financial services law, then leaves the matching to the firm. Article 74(6) puts AI Act market surveillance for those firms with the national financial supervisor, so the file lands on a desk the institution already knows. Articles 26(5) and 26(6) are widely read as exemptions and are neither. The practical result is one control set with two independent triggers, not one merged obligation. Useful background sits in our notes on EU AI Act compliance and on DORA compliance software architecture.
The AI Act does not mention DORA, and DORA does not mention the AI Act
Read on 25 August 2026 against the pinned Official Journal text, Regulation (EU) 2024/1689 returns zero occurrences of the string "2022/2554", zero of "DORA" and zero of "digital operational resilience". The measurement runs the other way too. Regulation (EU) 2022/2554 returns zero occurrences of "2024/1689" and zero of "artificial intelligence". Neither instrument cites the other anywhere in its operative text or its recitals.
That is the design, not an oversight to be corrected by reading harder. Any source telling a reader that the AI Act carves out DORA reporters or aligns its clocks with DORA is describing a provision that does not exist. The overlap is structural, created by the fact that one institution falls inside both, and it is assembled by that institution rather than inherited from either text.
What the AI Act names instead
Where the AI Act deals with supervised financial firms it reaches for a category. Article 72(4) extends its post-market monitoring integration option to systems placed on the market by "financial institutions that are subject to requirements under Union financial services law regarding their internal governance, arrangements or processes". For serious-incident notification, Article 73(9) narrows the duty for providers subject to "Union legislative instruments laying down reporting obligations equivalent to those set out in this Regulation". Article 74(6) reassigns market surveillance for systems used by financial institutions regulated by Union financial services law. All three are in Regulation (EU) 2024/1689, none of them amended since.
Category drafting shifts work onto the reader. A named instrument would settle the question once. A category leaves each institution to decide which of its own obligations fall inside it and to record why.
Article 74(6): your financial supervisor is your AI market surveillance authority
This is the strongest and least ambiguous of the overlaps. For high-risk AI systems placed on the market, put into service or used by financial institutions regulated by Union financial services law, the market surveillance authority "shall be the relevant national authority responsible for the financial supervision of those institutions", from Regulation (EU) 2024/1689, Article 74(6). That is the prudential or conduct supervisor the institution already files with.
The provision carries its own limit, and it is easy to read past. The reassignment holds only in so far as the placing on the market, putting into service or use of the system is "in direct connection with the provision of those financial services". A model that sits outside the regulated service, an internal HR screening tool for example, does not travel to the prudential supervisor with the rest of the firm. Article 74(7) adds a second variable, since in appropriate circumstances and provided coordination is ensured "another relevant authority may be identified by the Member State as market surveillance authority for the purposes of this Regulation". Both passages are in Regulation (EU) 2024/1689, Article 74. The answer is therefore not uniform across the Union and has to be checked per Member State.
The AI Office route, and the condition buried inside the carve-out
Regulation (EU) 2026/1744 replaced Article 75 and routed serious-incident reports for providers inside the AI Office's competence to the AI Office rather than to a national authority. One of the carve-outs from that competence covers "AI systems provided by law enforcement authorities, border management authorities and financial institutions, insofar as those AI systems fall under Article 74(6)", from Regulation (EU) 2026/1744. The final clause is a condition and not a blanket exclusion of finance: a system that is not in direct connection with the provision of financial services falls outside Article 74(6), so it is not carved out, so it stays inside AI Office competence and reports there. For the argument here that is the whole of what matters, because it makes the recipient question and the direct-connection question one question, and an institution that has answered the second in its system register has already answered the first. Our note on AI Act serious incident reporting develops the competence classes and the narrower deployer-side test.
The same institution wears two different hats
The two regimes attach to different legal roles, which is why the applicability question has more than one answer inside the same building. DORA duties attach to the financial entity as such. Article 17(1) obliges financial entities to define, establish and implement "an ICT-related incident management process to detect, manage and notify ICT-related incidents", and Article 19(1) obliges them to "report major ICT-related incidents to the relevant competent authority as referred to in Article 46", both in Regulation (EU) 2022/2554. There is one addressee and it is the entity.
The AI Act splits its duties between provider and deployer. A deployer's root obligation is to use the system in accordance with the instructions for use, while a provider carries post-market monitoring, serious-incident reporting and the quality management system. The same firm can hold both sets at once. Newer regulated categories hit this first, which is why DORA for crypto firms surfaces the role question earlier than a large bank does.
Building your own model puts you on both sides at once
An institution that buys a scoring model is a deployer and nothing more. One that builds a model, puts it into service under its own name and runs it internally is the provider and the deployer of the same system, so every provider duty and every deployer duty applies at once. The internal owners are usually different people. Model risk owns the provider half, operations owns the deployer half and neither is reading the other's article. That gap is where the planning error lives, not in the regulatory text.
Side by side: where the two duty sets run in parallel
The table sets equivalent duty areas against each other. Each cell is cited to its own regulation only.
| Duty area | DORA, Regulation (EU) 2022/2554 | AI Act, Regulation (EU) 2024/1689 |
|---|---|---|
| Process obligation | Article 17(1) to 17(3), an ICT-related incident management process with six prescribed process requirements | Article 72(1) and 72(2), a documented post-market monitoring system proportionate to the technology and the risk |
| Written plan | Procedures and processes for consistent monitoring, handling and follow-up, Article 17(2) | A post-market monitoring plan forming part of the Annex IV technical documentation, Article 72(3) |
| Classification | Article 18(1), six impact criteria, with materiality thresholds set by delegated act | Article 3, point (49), four alternative outcome limbs |
| Reporting trigger | A major ICT-related incident, Article 19(1) | A serious incident, Article 73(1) |
| Reporting clock | Four hours and 24 hours for the initial notification, 72 hours for the intermediate report, one month for the final report, Commission Delegated Regulation (EU) 2025/301, Article 5(1) | 15 days as a baseline, two days for a critical infrastructure incident or a widespread infringement, 10 days on the death of a person, Article 73(2) to 73(4) |
| Report structure | Initial notification, intermediate report, final report, Article 19(4) | An incomplete initial report followed by a complete one, Article 73(5) |
| Recipient | The relevant competent authority under Article 46, one designated authority where several supervise, Article 19(1) | The market surveillance authority, which for these institutions is the financial supervisor, Articles 73(1) and 74(6) |
| Outsourcing | Reporting may be outsourced, responsibility may not, Article 19(5) | Deployer escalation ordering, provider first and then importer or distributor and market surveillance authorities, Article 26(5) |
What the table is not
It is an engineering comparison, drawn so that one team can see which of its existing capabilities has a counterpart. It is not a statement of legal equivalence, and neither text authorizes an institution to discharge one duty by performing the other. Two rows deserve their numbers spelled out because teams plan against them. Under Commission Delegated Regulation (EU) 2025/301, Article 5(1), the initial notification is due "within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours", the intermediate report "at the latest within 72 hours from the submission of the initial notification" and the final report "no later than one month after either the submission of the intermediate report, or, where applicable, after the latest updated intermediate report". The AI Act writes its own limits directly into Article 73, at 15 days, two days and 10 days, in Regulation (EU) 2024/1689. The rest of the DORA reporting mechanics, including the update duty and the weekend slip, are covered in our analysis of the CRA NIS2 and DORA reporting overlap.
Where they genuinely diverge
The clean-mapping story falls apart at the definitions. DORA classifies on operational impact. Article 18(1) makes financial entities "classify ICT-related incidents and shall determine their impact based on the following criteria", which run to clients and counterparts affected, duration, geographical spread, data losses, criticality of services and economic impact, in Regulation (EU) 2022/2554. The thresholds are quantified elsewhere, and the economic-impact one is met where costs and losses "have exceeded or are likely to exceed 100 000 euro", from Commission Delegated Regulation (EU) 2024/1772.
The AI Act classifies on outcome. A serious incident is "an incident or malfunctioning of an AI system that directly or indirectly leads to any of the following", and the limbs include "a serious and irreversible disruption of the management or operation of critical infrastructure" and "the infringement of obligations under Union law intended to protect fundamental rights", from Regulation (EU) 2024/1689, Article 3, point (49). Four alternatives, any one of which is enough.
The divergence a DORA-shaped pipeline will miss
Set the two definitions next to each other and a category of event appears that only one of them sees. A scoring model drifting into disparate outcomes for a protected group produces no outage, no downtime, no data loss and possibly no cost above any threshold. On an operational impact scale it registers as nothing. On an outcome scale it is a fundamental-rights event, and a pipeline built around availability has no sensor pointed at it.
Three smaller divergences run the same way. DORA carries a voluntary notification channel for significant cyber threats, and a rule for classifying a cyber threat as significant, in Regulation (EU) 2022/2554, Articles 18(2) and 19(2). Nothing in the AI Act corresponds to either. Article 19(3) obliges the entity to "inform their clients about the major ICT-related incident", in Regulation (EU) 2022/2554, while nothing in AI Act Articles 72 to 74 creates a direct duty to affected individuals. DORA Article 19(6) sends the report onward from the competent authority to named recipients. The AI Act instead starts a clock on the receiving authority, which must act "within seven days from the date it received the notification", per Regulation (EU) 2024/1689, Article 73(8). An institution that folds AI Act incidents into its DORA pipeline unchanged will under-detect fundamental-rights events and mis-time at least one of the two filings.
Article 73(9) narrows the AI Act duty, it does not delete it
This is the provision most worth getting right. For Annex III high-risk systems placed on the market by providers subject to "Union legislative instruments laying down reporting obligations equivalent to those set out in this Regulation", the AI Act says "the notification of serious incidents shall be limited to those referred to in Article 3, point (49)(c)", from Regulation (EU) 2024/1689, Article 73(9).
Read what that does. The duty survives, narrowed to one of four limbs, and the limb it keeps is the fundamental-rights one. The provision that looks like relief is a redirection of effort, from the events an incident pipeline was built to catch toward the one it was not. Point (49) has four alternatives that the operative articles reference individually, so compressing the definition into a general notion of a serious problem loses the mechanism.
Whether DORA counts as equivalent is unresolved
Here is the bridge, and it is analysis rather than citation. DORA is a Union legislative instrument, and it lays down reporting obligations on financial entities. Article 73(9) is written against a class of instruments laying down reporting obligations "equivalent to those set out in this Regulation", per Regulation (EU) 2024/1689, and it names no member of that class. Nothing in either text states whether DORA's major ICT-related incident reporting answers that description, and the two duties are triggered by different events, measured on different criteria and filed on different clocks. An institution relying on Article 73(9) is therefore making a judgment, not reading off an answer, and the sensible response is to write that judgment down with its reasoning before a supervisor asks for it. Nothing in the primary text says how any national supervisor intends to treat the question either.
Article 26(5) and Article 26(6) are not exemptions
Both are routinely presented as relief for regulated firms, and both do something narrower. Article 26(5) states the deployer monitoring duty, then two escalations. Where a deployer has reason to consider that use may result in the system presenting a risk within the meaning of Article 79(1), meaning risks "to the health or safety, or to fundamental rights, of persons", it must inform the provider or distributor and the market surveillance authority and "shall suspend the use of that system". Where it identifies a serious incident it must "immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities of that incident". Both from Regulation (EU) 2024/1689.
The financial-services subparagraph then deems one thing fulfilled. For deployers that are financial institutions with internal governance requirements under Union financial services law, "the monitoring obligation set out in the first subparagraph shall be deemed to be fulfilled by complying with the rules on internal governance arrangements, processes and mechanisms", again from Regulation (EU) 2024/1689. The monitoring limb, and only that limb. The suspension duty, the escalation duty and the serious-incident duty are deemed fulfilled by nothing.
Article 26(6) is a filing rule. Deployers keep logs generated by the system, to the extent those logs are under their control, "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months". Financial-institution deployers "shall maintain the logs as part of the documentation kept pursuant to the relevant Union financial service law". The retention floor is untouched, and Regulation (EU) 2024/1689 sets it in Article 26(6). The paragraph says where the logs live, not whether they have to exist. Providers carry a matching duty under Article 19, with financial-institution providers keeping their logs "as part of the documentation kept under the relevant financial services law". Article 26(6) and Article 19(2) are both in Regulation (EU) 2024/1689.
The provider-side twin in Article 17(4)
The same pattern repeats on the provider side and is less often noticed. Article 17(4) deems the quality management system obligation fulfilled for a provider that is a financial institution already subject to internal governance requirements, but "with the exception of paragraph 1, points (g), (h) and (i) of this Article", again from Regulation (EU) 2024/1689. Those three points are the risk management system, post-market monitoring and serious-incident reporting.
Line the two deeming provisions up and the pattern is unmistakable. On the deployer side, monitoring is deemed fulfilled and suspension, escalation and incident reporting are not. On the provider side, ten of thirteen quality management elements are deemed fulfilled and risk management, post-market monitoring and incident reporting are not. The same three capability areas survive on both sides at once. Whatever else internal governance covers, the legislature declined to let it cover those. Internal governance evidence therefore has to be readable as AI monitoring evidence, which in most institutions means an explicit mapping document rather than an assertion in a policy.
Article 72(4) lets you fold AI post-market monitoring into what you already run
One genuine efficiency exists and it sits here. Article 72(1) requires that "Providers shall establish and document a post-market monitoring system", and Article 72(2) requires that system to "actively and systematically collect, document and analyse relevant data" on performance across the lifetime of the system. Article 72(4) then allows providers already running a post-market monitoring system under Union harmonisation legislation to integrate the necessary elements into it, "provided that it achieves an equivalent level of protection". The second subparagraph extends that option to Annex III point 5 systems placed on the market by "financial institutions that are subject to requirements under Union financial services law regarding their internal governance, arrangements or processes". Both in Regulation (EU) 2024/1689.
The template you would integrate against does not exist yet
Article 72(4) points at a template defined in Article 72(3), and Article 72(3) was replaced. Regulation (EU) 2026/1744 repealed the binding implementing act that was due by 2 February 2026 and substituted non-binding guidance, under which the Commission "shall adopt guidance, including a template, on the post-market monitoring plan by 2 September 2027". Anyone writing a monitoring plan today writes it without a template, against a date that lands after the plan is needed, and against an instrument that will not bind when it arrives.
What changes on 2 December 2027, and what already applies
Regulation (EU) 2026/1744, the Digital Omnibus on AI of 8 July 2026, published in the Official Journal on 24 July 2026 and in force on 27 July 2026, is the only amendment the AI Act has received. It replaced point (c) of the third paragraph of Article 113, moving Chapter III Sections 1, 2 and 3, with Article 6(5) carved out, to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III and to 2 August 2028 for those classified under Article 6(1) and Annex I, per Regulation (EU) 2026/1744. Our EU AI Act compliance timeline carries the development and the rest of the dates.
For an institution inside both regimes the consequence is a gap between two clocks. Credit scoring and life and health insurance pricing sit in Annex III point 5, so they sit on the December 2027 date, while DORA has applied since January 2025 throughout, so the deferral moves the AI Act half of the timeline and nothing else. Material saying that finance-sector high-risk obligations bite on 2 August 2026 was written before the amendment, or has not been updated since it. Whether a given system is in Annex III at all is a prior question, handled in our note on AI Act high-risk classification.
What the amendment left alone
Articles 72(4), 73 and 74 are unamended, as are Article 26, Article 17(4), Article 3 point (49) and Annex III point 5. Every substantive position above therefore rests on text that survived the Omnibus verbatim. The one indirect effect is that Article 72(4) cross-refers to the replaced Article 72(3), so the template timing moved even though 72(4) itself did not. This article was checked against the primary text on 25 August 2026, and anyone relying on these dates should confirm that nothing further has amended the Regulation since.
Building one control set that answers both
The engineering answer is one taxonomy with two independent classification passes, never one merged severity scale. An event enters the pipeline once, then gets classified twice, on operational impact for the DORA question and on outcome for the AI Act question. The two passes disagree by design, and a merged scale hides exactly the events where they disagree.
Fundamental-rights detection then has to become a first-class signal rather than a subset of availability monitoring. That means model outputs monitored for disparate outcomes on a schedule, with thresholds agreed in advance and an escalation path reaching the same incident queue as an outage. Log retention should satisfy the six-month floor while living inside the financial-services documentation set, which is what Article 26(6) contemplates rather than a separate archive nobody maintains. Our cybersecurity services team usually finds the retention side already solved and the classification side not.
The two documents worth writing first
The first is the equivalence memo for the Article 73(9) judgment, recording which Union instruments the institution treats as laying down equivalent reporting obligations and why, dated and owned. A second document is a register that records, per AI system, whether it falls in Annex III point 5, who the provider is, who the deployer is, whether the system is in direct connection with the provision of financial services and therefore which authority holds it. Institutions that already maintain a DORA register of information have the discipline and often the tooling for this, though the fields are different and the two registers should not be merged.
How Pharos Production builds compliance-aware FinTech platforms
We build lending, payments and insurance systems where the model is part of a regulated product rather than a lab artifact, so the evidence has to exist when the system ships instead of being reconstructed when a supervisor asks. In practice that means version-pinned datasets and model artifacts, evaluation runs recorded against those versions, fairness monitoring wired into the same incident queue as availability monitoring and logging designed against the retention rule rather than retrofitted from application logs.
Our FinTech development services and custom software development teams work on that file alongside the build. The test we apply is a cold read: hand the classification logic and the monitoring record to an engineer who was not in the room and see whether they can tell which of the two regimes each control answers. If they cannot, a supervisor will not either.
Sources: Regulation (EU) 2024/1689 (AI Act), base Official Journal text, Articles 3, 17, 19, 26, 72, 73 and 74, via Regulation (EU) 2024/1689; Regulation (EU) 2022/2554 (DORA), Articles 17, 18, 19 and 20, via Regulation (EU) 2022/2554; Regulation (EU) 2026/1744 (Digital Omnibus on AI), Articles 72(3), 75 and 113 as amended, via Regulation (EU) 2026/1744; Commission Delegated Regulation (EU) 2025/301, Article 5, via Commission Delegated Regulation (EU) 2025/301; Commission Delegated Regulation (EU) 2024/1772, materiality thresholds, via Commission Delegated Regulation (EU) 2024/1772. Read on 25 August 2026. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 6
No matches
Try a different keyword, change the topic or clear filters
-
No. Regulation (EU) 2024/1689 contains no reference to Regulation (EU) 2022/2554, to DORA by name or to digital operational resilience, measured against the pinned Official Journal text on 25 August 2026. The measurement runs the other way too, since DORA contains no reference to the AI Act and none to artificial intelligence.
Where the AI Act deals with regulated financial institutions it names a category instead, Union financial services law in Articles 72(4) and 74(6) and Union legislative instruments laying down equivalent reporting obligations in Article 73(9). The overlap between the two regimes is structural rather than textual, and any source telling you the AI Act carves out DORA reporters is describing something the text does not say.
-
For high-risk AI systems placed on the market, put into service or used by financial institutions regulated by Union financial services law, Article 74(6) makes the market surveillance authority the relevant national authority responsible for the financial supervision of those institutions, in so far as the system is in direct connection with the provision of those financial services. In practice that is the same prudential or conduct supervisor the institution already reports to.
Article 74(7) lets a Member State designate a different authority in appropriate circumstances where coordination is ensured, so the answer is not identical in every Member State.
-
No. Article 26(5) deems the monitoring obligation in its first subparagraph fulfilled where a deployer that is a financial institution complies with the internal governance rules under the relevant financial service law. That deeming reaches the monitoring limb only.
The duty to inform the provider or distributor and the market surveillance authority and to suspend use where the system presents a risk within the meaning of Article 79(1), and the duty to escalate an identified serious incident to the provider first and then to the importer or distributor and the market surveillance authorities, are not deemed fulfilled by anything. Nor is the provider's own Article 17(4) quality management system duty deemed fulfilled in full, since the deeming carries the same three exceptions of risk management, post-market monitoring and serious-incident reporting on the provider's side.
-
Yes. Article 26(6) requires deployers to keep logs automatically generated by the high-risk AI system, to the extent those logs are under their control, for a period appropriate to the intended purpose and at least six months unless other Union or national law provides otherwise.
For deployers that are financial institutions subject to internal governance requirements under Union financial services law, the second subparagraph says those logs are maintained as part of the documentation kept under the relevant Union financial service law. That is a filing rule about where the logs live, not permission to stop keeping them. Providers carry a matching duty under Article 19.
-
No, it narrows the duty rather than removing it. For Annex III high-risk systems whose providers are already subject to Union legislative instruments laying down equivalent reporting obligations, notification of serious incidents is limited to those referred to in Article 3, point (49)(c), the infringement of obligations under Union law intended to protect fundamental rights.
The definition has four alternative limbs, so narrowing to one changes which events you must detect. Which instruments count as equivalent is not settled by the AI Act text, so an institution relying on Article 73(9) should record the reasoning behind that judgment.
-
Regulation (EU) 2026/1744, the Digital Omnibus on AI of 8 July 2026, in force 27 July 2026, replaced point (c) of the third paragraph of Article 113. Chapter III Sections 1, 2 and 3, with the exception of Article 6(5), now apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, which is where creditworthiness assessment and life and health insurance risk assessment and pricing sit, and from 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I.
Verify nothing further has amended the Regulation before relying on those dates.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
