Why the operational work converges across EU AI Act, GDPR, DORA, and NIS2 - and what that means for compliance budgets
Your HR team uses Phenom to screen CVs. Phenom triggers obligations under four EU regulations simultaneously. Your DPO is tracking the GDPR exposure. Your CISO is tracking the NIS2 supply chain question. Your Legal team is tracking the EU AI Act Annex III classification. Your Compliance team is tracking the DORA Article 28 register entry. None of them is talking to the others, and the firm is producing four documents for one underlying reality.
Call it the four-clock problem. One shadow AI, sanctioned or not, starts four regulatory timers at once: DORA's four-hour major incident notification, NIS2's 24-hour early warning, GDPR's 72-hour breach clock, the EU AI Act's event-triggered reporting for serious incidents involving high-risk AI systems. Different speeds, different supervisors, different paperwork. Same underlying fact.
The same shadow AI tool runs against four regulatory clocks, each with different deadlines, different supervisors, and different documentary outputs. The mistake firms make is treating these as four separate workstreams. The leverage point is recognising that the operational substrate beneath them is the same.
The Four Clocks
The EU AI Act - Regulation (EU) 2024/1689, runs on a phased clock. Article 5 prohibited practices have been binding since 2 February 2025. The bulk of high-risk obligations apply from 2 August 2026. Existing high-risk systems already in service get an additional year, until 2 August 2027. The reporting trigger is not time-based but event-based: serious incidents involving high-risk AI systems must be reported to the relevant national authority and to the provider.
The GDPR - Regulation (EU) 2016/679, runs on the seventy-two-hour clock that European compliance teams know well. Article 33 requires notification of personal data breaches to the supervisory authority within 72 hours of awareness. Beyond the breach clock, GDPR runs continuously on the Article 30 record of processing activities, on Article 35 DPIA obligations for high-risk processing, and on Article 28 processor due diligence.
The DORA - Regulation (EU) 2022/2554, runs on the fastest clock. Article 19 requires major ICT-related incidents to be reported to the competent authority within four hours of classification as major. The classification criteria are set out in Commission Delegated Regulation (EU) 2024/1772.
The NIS2 Directive - (EU) 2022/2555, runs on a two-stage clock. Article 23 requires an early warning to the national CSIRT or competent authority within 24 hours of awareness of a significant incident, followed by a fuller incident notification within 72 hours. NIS2 also runs continuously on Article 21 cybersecurity risk-management measures, including the supply chain security obligation in Article 21(2)(d).
Four clocks. Different speeds, different triggers, different supervisors. For a financial entity that is also in scope of NIS2, DORA's clock takes precedence: DORA is lex specialis, and the four-hour major-incident notification under DORA discharges what would otherwise be the NIS2 24-hour obligation for the same incident.
One Tool, Four Regimes
A 600-person fintech in Dublin uses Phenom for AI-driven candidate matching. The fintech is the deployer; Phenom is the provider. The same shadow AI tool generates obligations under all four regimes.
Under the EU AI Act, Phenom-driven CV screening is high-risk under Annex III, employment category. The fintech, as deployer, takes on the deployer obligations under Article 26: use the system in accordance with the provider's instructions, ensure human oversight, monitor operation, inform affected workers before deployment, and where applicable conduct a fundamental rights impact assessment under Article 27.
Under GDPR, Phenom is a processor under Article 28; a Data Processing Agreement must be in place. The processing must appear in the fintech's Article 30 RoPA. Because shortlisting is a decision producing significant effects, a DPIA under Article 35 is likely required, and Article 22 candidates are entitled to human intervention in significant automated decisions.
Under DORA, Phenom is an ICT third-party service provider. The fintech, as a financial entity in scope, must include Phenom in its Article 8 register of information, with criticality assessed under Commission Delegated Regulation (EU) 2024/1502. The standard register format is set out in the implementing regulation.
Under NIS2, Phenom sits in the fintech's supply chain. Article 21(2)(d) requires the fintech, as an essential or important entity, to address supply chain security including the security of Phenom and its sub-processors. Because the firm is a financial entity in scope of DORA, DORA's third-party regime governs in practice, but Article 21 discipline applies for any non-financial in-scope service the firm operates.
One tool. Four regimes. Currently, in most firms, four documents produced by four people who do not talk to each other.
When a serious incident involving an AI tool surfaces, the first question in the room is always the same: Who owns the response? In most firms, the honest answer is that four people own a piece of it and nobody owns all of it. The DPO owns the GDPR assessment. The CISO owns the security response. The compliance team owns the DORA classification call. The legal team owns the EU AI Act question. Each of them is competent, and none of them has been told that the others are also working on the same underlying event. The four-clock problem is not a regulatory design failure; European regulators designed it this way deliberately. It is an organisational design failure. Most firms built their incident response for one clock and are now operating under four. - Namita Razdan, Co-Founder, Montro |
Where The Obligations Diverge
The unique features of each regime are real and worth naming, because the convergence story can be oversold.
The EU AI Act has Annex III. Nothing else does. The risk-tier mapping is unique to the Act, and the deployer-versus-provider distinction shapes which obligations attach in ways no other regulation tracks.
GDPR has Article 22 automated decisioning. The right to human intervention in significant automated decisions is GDPR-specific and creates obligations the EU AI Act does not duplicate.
DORA has the four-hour major-incident clock and the structured ICT register format. The criticality classification under the published RTS is DORA-specific and uses sector-specific materiality thresholds.
NIS2 has the management body accountability under Article 20. No other regime makes the management body directly responsible for cybersecurity risk-management measures with personal liability exposure under sanctions in Article 34.
Where They Converge - The Operational Substrate
The convergence story is operational, not legal. Strip away the framework-specific outputs, and the underlying questions each regime asks are largely the same.
Each regime requires you to know the AI tool exists, which starts with AI tool discovery. Each requires you to know what it does and what data flows through it. Each requires you to know who is responsible for it. Each requires you to carry out an AI risk assessment against the regime's specific tiers, and each requires evidence that you did so. The operational work - inventory, classification, processor identification, controls, evidence - runs once. The framework-specific outputs are templates that map the shared substrate to the regime's required structure.
A unified inventory layer that captures every AI tool in active use, the foundation of any credible shadow AI governance programme - classified against EU AI Act tiers, mapped to GDPR processor status, positioned in the DORA register, and assessed against NIS2 supply chain criteria, serves all four regimes from one record. The DPIA is generated from that record. The DORA register entry is generated from that record. The Annex III classification is generated from that record. The NIS2 supplier assessment is generated from that record.
The Arithmetic
Done four times, the compliance work for one shadow AI tool - separate inventory entries maintained by different teams, separate vendor questionnaires, separate risk assessments, separate evidence files, eats the equivalent of six to eight weeks of FTE per year per twenty tools at most mid-market firms. Done once, against a shared operational substrate, it is a continuous output of the inventory the firm maintains anyway.
The arithmetic is the case for unified shadow AI governance. The regulatory architecture is plural; the compliance architecture does not have to be.
Frequently Asked Questions
What exactly is the four-clock problem?
One AI tool in active use - whether IT sanctioned it or not, can trigger reporting obligations under four EU regulations simultaneously, each running to a different authority on a different timeline. DORA (Regulation (EU) 2022/2554, Article 19) requires major ICT incident notification within four hours of classification. NIS2 (Directive (EU) 2022/2555, Article 23) requires an early warning within 24 hours. GDPR (Regulation (EU) 2016/679, Article 33) requires breach notification within 72 hours. The EU AI Act (Regulation (EU) 2024/1689) runs on event-triggered reporting for serious incidents involving high-risk AI systems. One fact. Four clocks. This is why shadow AI governance cannot be treated as a single-team problem.
If we are a financial entity under DORA, do we still have to meet NIS2's 24-hour deadline?
Not for the same incident. DORA is lex specialis, where it overlaps with NIS2, DORA governs. A financial entity that files its Article 19 major incident notification within four hours has discharged what would otherwise be its NIS2 Article 23 early warning obligation for that incident. The NIS2 supply chain security obligation under Article 21(2)(d) applies independently and is not displaced by DORA.
Is AI-driven CV screening high-risk under the EU AI Act?
Yes. Recruitment and employment screening falls under Annex III, category 4 of Regulation (EU) 2024/1689. An organisation using an AI tool to shortlist candidates is the deployer. Article 26 deployer obligations include: using the system in accordance with the provider's instructions, ensuring human oversight, monitoring operation, and informing affected workers before deployment. Where the conditions in Article 27 are met, a Fundamental Rights Impact Assessment is also required.
Does GDPR Article 22 add anything the EU AI Act does not already cover?
Yes, and the distinction matters in practice. Article 22 of Regulation (EU) 2016/679 gives individuals the right not to be subject to solely automated decisions that produce significant effects, including the right to human intervention and the right to contest. Satisfying Article 22 by inserting a human reviewer into the process does not satisfy Article 86 of the EU AI Act, which separately requires explanation generation capability in the AI system itself. Both apply to AI-driven employment decisions. Meeting one does not discharge the other.
What has to go into a DORA ICT third-party register, and do shadow AI tools belong in it?
Article 28.3 of Regulation (EU) 2022/2554 requires financial entities to register all ICT third-party service providers. Each entry must record the provider's identity, the services supplied, a criticality assessment under Commission Delegated Regulation (EU) 2024/1502, contractual terms, and concentration risk. DORA defines ICT services broadly: digital and data services provided through ICT systems on an ongoing basis. A shadow AI tool an employee signed up for without IT involvement is still an ICT service under that definition. It belongs in the register regardless of how it was procured. This is precisely why AI tool discovery is a prerequisite for DORA compliance, not an optional exercise.
What does running four separate compliance workstreams for the same tool actually cost?
At most mid-market firms, maintaining separate inventory entries, vendor questionnaires, risk assessments, and evidence files across four regimes for the same AI tool consumes six to eight weeks of FTE per year per twenty tools. A single inventory record - built on continuous AI tool discovery and classified against EU AI Act risk tiers, mapped to GDPR processor status, entered in the DORA register, assessed against NIS2 Article 21(2)(d) supply chain criteria, generates all four framework outputs from the same underlying fact. The compliance work runs once. The regulatory architecture stays plural; the operational response does not have to be. A structured AI risk assessment conducted once, against that shared record, replaces four parallel assessments.
