Insights

DORA and the EU AI Act Share an Integration Clause Nobody Is Using

Terry Yodaiken ·

“…may be part of, or combined with, the risk management procedures established pursuant to that law.” Seventeen words sitting at the end of Article 9(10), and for a European bank they are worth a great deal more than the attention they have received.

What the clause says is that where a provider of a high-risk AI system is already subject to risk management requirements under other Union law, the AI Act’s own risk management obligations can be folded into the procedures that already exist. For a financial institution, the other Union law is Regulation (EU) 2022/2554, and the procedures that already exist are its ICT risk management framework.

Research and drafting for this article were AI-assisted. Every figure is linked inline to the source that published it. Editorial responsibility is mine.

Two translucent document panels edged in gold meeting at a glowing cyan seam, one showing a shield labelled DORA resilience, the other a circuit-brain labelled AI Act governance.
Produced by Gemini-Nano-Banana

So a bank running an AI credit-scoring system does not need two risk processes, two documentation standards and two sets of governance minutes. It can run one.

Almost none of them do.

One Clause, Two Regimes

Two stacked columns labelled DORA and AI Act, beams of light from each striking a shattering point at the centre where fragments break away.
Produced by Gemini-Nano-Banana

DORA has been fully applicable since 17 January 2025. The AI Act’s high-risk obligations bite on 2 August 2026 as the Regulation stands, although the Digital Omnibus package, if formally adopted, would push the Annex III deadlines out to 2 December 2027. It had not been published in the Official Journal when this was written, so the earlier date is still the binding one.

The two regimes look at the same system from different ends. DORA asks whether a failure would compromise the institution’s ability to keep operating. The AI Act asks whether the system could harm the person on the other side of the decision.

The overlap between them is substantial: risk assessment, documentation, incident reporting, and accountability sitting with the management body. A credit-scoring model, an AML risk-profiling engine or an automated underwriting system has to satisfy both. Running two parallel programmes over one model produces duplication and no additional protection.

What BaFin Did That Nobody Else Has

In January 2026, BaFin published 35 pages of guidance on ICT risks in the use of AI at financial entities. It is non-binding, and it is the clearest supervisory statement anyone in Europe has made on this question.

The instruction is to embed. AI systems belong inside the existing DORA-compliant ICT governance across the whole lifecycle: identification, protection, detection, response, recovery, continuous improvement. Jones Day’s reading of it is that the expectation is architectural rather than procedural. Not a separate AI annexe bolted onto the ICT framework. Inside it.

No other national competent authority has gone this far. There is no ECB-level equivalent. The EBA’s November 2025 factsheet confirmed it will promote a common supervisory approach across 2026 and 2027, and confirmed equally that it is not issuing new guidelines and does not plan to.

Which makes BaFin’s document the de facto template. If you are building an integrated framework and want to know what a supervisor will recognise, that is currently the only document in Europe that tells you.

The Systems That Fall Between

Now the part that gets missed, and it is the reason I would not treat Article 9(10) as the headline.

Integration under that clause is available for high-risk systems, meaning those listed in Annex III. In financial services that mostly comes down to credit scoring of natural persons, life and health insurance pricing, and eligibility assessment for public services. A short list.

The AI systems that dominate a bank’s operational risk profile are frequently not on it. Corporate credit scoring. Algorithmic execution. Fraud detection against institutional counterparties. Real-time risk aggregation. Bird & Bird set this out clearly in its 2026 analysis: these systems are critical under DORA, they would appear on any serious register of ICT assets supporting critical or important functions, and they sit outside the high-risk perimeter entirely.

So the interesting problem is not the overlap. It is the space beneath both regimes.

DORA requires those systems to be secure, resilient and available. It imposes no bias testing, no explainability requirement, no human oversight obligation, because it was not written for statistical models that drift. The AI Act contains all of that, and does not apply to them.

A bank’s most operationally significant AI therefore ends up governed for uptime and not for the things that make AI different from ordinary software: model drift, training data going stale, adversarial manipulation, and the plain opacity of a large ensemble. Bird & Bird’s recommendation is to adopt the high-risk requirements as an internal benchmark inside the DORA framework, scaled to each system’s genuine criticality. Not because anything compels it. Because it is the only answer that survives contact with a supervisor asking what controls sat around the model that produced last Tuesday’s outputs.

Building the Single Framework

A flow diagram with DORA ICT Risk on the left and AI Act High-Risk on the right, both feeding a glowing gold node labelled Article 9(10) Integration, which flows down to a single Unified Risk Register box.
Produced by Gemini-Nano-Banana

Article 9(10) is permissive. It says “may”, not “shall”, and a supervisor remains free to ask for separate evidence under each regime. Integration is a design decision you have to defend, not an entitlement you can claim.

Fontvera’s article-level comparison finds three genuine overlaps, risk management, logging and incident reporting, and robustness and cybersecurity, alongside two structural gaps where the AI Act asks for capabilities DORA never contemplated: conformity assessment and human oversight. A unified framework has to handle both categories differently.

Risk management. One assessment process can serve DORA’s ICT risk identification and the AI Act’s continuous risk management, provided it covers operational resilience and fundamental rights risk in the same register with clear tagging. Two lenses, one exercise.

Documentation. DORA wants an ICT asset register and continuity documentation. The AI Act wants technical documentation covering training data, model architecture, performance metrics and test results. These are complementary. Add AI-specific fields to the register you already maintain rather than standing up a parallel one.

Incident reporting. Here integration gets genuinely hard. DORA’s major incident reporting runs to a 72-hour initial notification to the national competent authority. Serious incident reporting for high-risk AI systems has its own clock and its own content requirements. The Digital Omnibus, agreed politically by the European Parliament on 16 June 2026 and the Council on 29 June, introduces a single reporting gateway spanning NIS2, DORA, GDPR and the CER Directive. The gateway is not operational and the final text is not published, so for now you run both clocks.

Conformity assessment and human oversight. No DORA equivalent exists. These cannot be integrated, only sequenced, so the institution needs to know which systems require conformity assessment and trigger it alongside the ICT risk cycle rather than after it.

Three to Six Months You No Longer Have

Vision Compliance’s 2026 readiness report found 78% of enterprises with no meaningful steps taken towards AI Act compliance, and 61% with no process at all for generating the technical documentation high-risk systems require. No data governance records. No model performance metrics. No documented human oversight procedure. Those are precisely the components that would form the AI layer of an integrated framework, so the firms furthest from compliance are also the firms with the least to integrate.

The Cloud Security Alliance puts conformity assessment at three to six months. Count backwards from August and a firm that has not started has not missed a deadline by a little.

What separates the institutions that will absorb this from the ones that will not is whether DORA was treated as a project that finished in January 2025 or as a framework that keeps taking on load. The clause gives the legal basis. BaFin gives the supervisory template. The EBA’s cooperation work across 2026 and 2027 will eventually give the cross-border consistency that is missing today.

The unified risk register, the single documentation standard, the coordinated reporting process: nobody is providing those. That part is construction, and it is on the institution.

Article 9(10) has been sitting in the text since the Regulation was adopted. It will be quoted eventually, most likely by a supervisor asking a bank why it built two frameworks over one model and could reconcile neither.

Regulatory position as at August 2026. The Digital Omnibus had not been published in the Official Journal at that date. Deadlines cited follow the Regulation as enacted.

Documents Cited

AI GovernanceDORAEU AI Act