You have one AI system. A vendor built it, your company runs it, it processes personal data, and if you work in financial services a prudential regulator supervises the whole operation.
Three rulebooks land on that system at once. The EU AI Act regulates it as an AI system. The GDPR regulates the personal data running through it. DORA, the EU’s financial resilience regulation, regulates the vendor relationship behind it.
Each of them has something to say about risk. Each of them wants an assessment. Each of them names the parties involved, and none of them uses the same names.
At some point you go looking for the provision that says which one governs when they answer the same question differently.
It is not there. For these overlaps the EU never wrote one.
That absence is deliberate, and understanding why it is deliberate may change what you build. The months that disappear into AI governance projects mostly disappear here, into a search for a tiebreaker that does not exist.
There Is No Hierarchy, and Lex Specialis Will Not Help
Two EU instruments of equal rank do not resolve against each other by default.
Where obligations genuinely collide and no express rule applies, the Court of Justice does not pick a winner. It reconciles.
In C-73/17 France v Parliament the Court held that two provisions of the same legal value must be read “in a manner that reconciles those obligations and strikes a fair balance between them.”
Two caveats before you count on that. It concerned primary law, where “same legal value” has a specific meaning. And no judgment has applied the method to two equal-rank regulations. Try applying it either way.
The instinct at this stage is to reach for lex specialis derogat legi generali, the specific displaces the general. It is a real principle and genuinely part of EU legal reasoning. It is also an interpretive tool rather than a hierarchy rule, and it only engages where two provisions govern the same subject matter.
I believe that the AI Act and the GDPR do not. One regulates the placing on the market and the use of AI systems. The other regulates the processing of personal data. They land on the same system without meeting on the same question.
Article 10 of the EU AI Act on data governance, and the new Article 4a, do regulate the processing of personal data. Article 2(7) carves out its own exceptions to GDPR neutrality, which concedes some overlap. I would say that the overlap sits at the edges, and lex specialis needs more than edges. But many might disagree with me.
Which leaves the default: absent an express rule, both instruments apply in full.
Neither is discounted because the other exists. So a single system in a single financial entity might be, at the same time, a high-risk AI system with a provider and a deployer, a processing operation with a controller and a processor, and an ICT service supplied by an ICT third-party service provider to a financial entity.
Three regimes. Three sets of names for the same two parties. Three definitions of risk.
You do not choose between them. You carry all of them.
The EU Knows How to Write a Precedence Rule
Article 4 of NIS2, the EU’s cybersecurity directive, does exactly what the AI Act declines to do. Where sector-specific Union law imposes cybersecurity risk-management measures or incident notification requirements at least equivalent in effect to NIS2’s own, the NIS2 provisions do not apply to those entities.
Do not apply, including the whole supervision and enforcement chapter.
Article 4(2) then supplies the equivalence test. And Recital 28 names the winner outright:
Regulation (EU) 2022/2554 of the European Parliament and of the Council should be considered to be a sector-specific Union legal act in relation to this Directive with regard to financial entities.
DORA displaces NIS2 for financial entities. Written down, by name, in the recitals.
The Commission then published guidelines on how to apply the equivalence test, setting out what the sectoral measures have to cover to qualify.
So the mechanism exists. A template, a test, and official guidance on operating the test. (NIS2 is a directive rather than a regulation, which complicates the comparison slightly but it changes nothing about the point.)
None of it was applied between the AI Act and the GDPR, or between the AI Act and DORA.
What the AI Act Wrote
It wrote interaction clauses.
Article 2(7) says Union law on the protection of personal data applies to personal data processed in connection with the rights and obligations in the AI Act, and that the Regulation does not affect the GDPR. That looks like a precedence clause. It is not quite it. It is the AI Act confirming that the GDPR continues to apply alongside it, in full, and declining to say what happens when the two point in different directions.
Article 9(10) says providers already subject to internal risk-management requirements under other Union law may fold the AI Act’s risk management into those procedures.
Article 8(2) gives providers a choice of integrating testing, reporting and documentation with product-safety law to avoid duplication. However, Article 8(2) opens with a duty, not a choice: providers shall be responsible for ensuring the product is fully compliant with both regimes. Only the integration is optional.
Article 17(4) deems, conditionally. For providers that are financial institutions subject to internal governance requirements under Union financial services law, the quality management obligation is deemed fulfilled by complying with those internal governance rules. Complying, not merely being subject to them. And three points are excepted: the risk management system, post-market monitoring, and serious incident reporting. The AI Act lets existing governance carry the paperwork and keeps the three obligations that detect harm.
And Article 26(9) says shall. Deployers of high-risk AI systems shall use the information the provider supplies under Article 13 to comply with their data protection impact assessment obligation under Article 35 GDPR.
That is the only provision in the AI Act that makes an AI Act piece a required input to a GDPR process. The vendor’s instructions for use are now compulsory reading for company’s DPIA.
Last Month Wrote Precedence Three Times
On 24 July the Digital Omnibus on AI was published in the Official Journal (it was in force three days later). Aside from the deadline deferrals that got all the coverage, it wrote precedence into the AI Act three times, by three different techniques.
The first is an equivalence route. New Article 2(13): where product-safety legislation listed in Section A of Annex I already provides an equivalent or higher level of protection, the application of Articles 9 to 15 and 17 to 25 may be limited. The Commission is to adopt delegated acts by 2 August 2027 specifying which systems, which requirements, and how far. Though nothing is limited yet. This is an empowerment with a deadline, not a live carve-out.
The second is a migration. The Omnibus moved the Machinery Regulation from Section A of Annex I to Section B. Section B triggers Article 2(2), which disapplies the entire high-risk chapter for those systems. Recital 42 calls it a move to a sectoral approach. However, the Recital also provides that the Commission is to adopt delegated acts amending the Machinery Regulation’s own annex to reflect the AI Act’s high-risk requirements, plus Articles 17, 19, 72 and 73, applying by 2 August 2028. Manufacturers can rely on AI Act harmonized standards in the interim. The obligations are not being removed. They are being rehoused.
The third is a hole aimed at the GDPR. New Article 4a lets providers and deployers process special categories of personal data where strictly necessary to detect and correct bias. And post-Omnibus, Article 2(7) now opens “Without prejudice to Articles 4a and 59 of this Regulation.” The clause that announces GDPR neutrality now names its own exceptions to it, in its first line.
So the position after last month is this:
Machinery: rehoused, with the requirements to follow it across by 2028.
Other Section A product legislation, medical devices and toys and lifts among them: an equivalence route, pending 2027.
Personal data: one prohibition, for one purpose. Financial services: nothing, and DORA is not in Annex I at all.
The EU is willing to rank its own instruments. It has at least three techniques for doing it. It used all three last month.
Same Word, Different Meaning
Which brings me back to the beginning and the example of one AI system that falls under three regimes.
Risk
If you assessing such AI system, start with risk, because three regimes use it to mean three different things.
The AI Act defines risk in Article 3(2) as the combination of the probability of harm occurring and the severity of that harm. Harm to whom is answered elsewhere in the Act: health, safety and fundamental rights. Of persons.
The GDPR uses the word risk throughout and never defines it in its definitions article. The operative phrase is risk to the rights and freedoms of natural persons, given content by the recitals, by Articles 24, 32 and 35, and by two decades of supervisory guidance.
DORA does not define risk at all. It defines ICT risk: a circumstance in relation to the use of network and information systems which, if it materializes, may compromise the security of those systems, of technology-dependent tools and processes, of operations and processes, or of the provision of services.
Three objects of harm. The AI Act protects the person from the system. The GDPR protects the person’s rights in their data. DORA protects the firm’s operations from disruption.
A system can be low-risk under one and high-risk under another with no contradiction at all, because they are not measuring the same thing. Which is why your DORA risk register is not an AI Act risk management system, and why handing one to a market surveillance authority in place of the other will not go well.
Roles
The roles diverge the same way, and worse, because the two sets are not even the same kind of category. AI Act roles turn on market position: who placed the system on the market under their own name, who uses it under their authority. GDPR roles turn on decisional control: who determines the purposes and means of processing, who processes on their behalf.
The working assumption is that provider maps to processor and deployer maps to controller. It holds often enough to be dangerous. An AI vendor that decides what to do with customer data to improve its own model is a controller for that processing while remaining a provider under the AI Act.
Role determination has to be done twice, on two different tests, and the two answers do not have to agree.
Where the GDPR Stops, the AI Act Starts?
The sharpest divergence is about explanations.
Article 22 GDPR applies to a decision based solely on automated processing. The received wisdom followed: insert a human who exercises real judgement and Article 22 falls away. It is in most privacy training decks written between 2018 and 2023, and it has not aged well.
The Court of Justice narrowed it in C-634/21 SCHUFA Holding. Where a credit reference agency produces a probability value and a third party draws strongly on that value in deciding whether to enter into a contract, establishing the value is itself a decision within Article 22(1). The human at the other end signing off does not necessarily rescue you.
Meanwhile the AI Act arrives from the opposite direction. Article 86 gives a right to explanation for
a decision which is taken by the deployer on the basis of the output from a high-risk AI system listed in Annex III, with the exception of systems listed under point 2 thereof, and which produces legal effects or similarly significantly affects that person in a way that they consider to have an adverse impact on their health, safety or fundamental rights
Taken by the deployer, on the basis of the output. The human is assumed, not excluded. The AI Act’s right is written for the exact decision the GDPR was thought to release.
The fix that used to remove the obligation is now what both rules are watching.
And then the AI Act does something strange with its own right. It applies only where EU law does not already give you one.
The GDPR does give you one. If a decision about you was made by the machine, you can ask the company for meaningful information about the logic behind it. For years the standard answer was that the logic is a trade secret. In 2025 the Court of Justice closed that off: a trade secret is not a refusal. The company hands the material to the supervisory authority or the court, and they decide how much the person sees.
So the AI Act’s right exists to cover what the GDPR misses, and what the GDPR misses keeps shrinking.
The GDPR right attaches to decisions the machine made. The AI Act right attaches to decisions a person made using the machine. Those are different sets. After the credit scoring judgment they overlap more than they used to, and neither the Commission nor a court has said where one ends and the other begins.
A right defined by the absence of another right, with the boundary still being drawn.
What to Do
As always, I want to give you something that you can implement. Five moves:
Stop asking which regulation governs. Ask what each one is measuring. The first question has no answer. The second always does, and it resolves the practical case. Harm to the person: AI Act. Harm to the person’s rights in their data: GDPR. Harm to the firm’s operations: DORA.
Classify separately, then map. Never classify once and translate. Run role determination twice, on each regime’s own test. Run risk classification separately for each. Build the mapping table as an output, one row per system, one column per regime.
When both rules point the same way, meet the tighter one and write down why. Two regulations rarely ask for opposite things. More often one asks for more than the other, and the stricter version is the one you have to hit. An incident is the clearest case. If you are a financial firm, DORA wants the first report within four hours of classifying it, or 24 hours of noticing it, whichever comes first. The AI Act allows fifteen days. Four hours is your deadline, and the fifteen-day rule is satisfied on the way past. The AI Act lets you reuse the same paperwork for both. It does not let you use the looser standard.
When two rules pull against each other, decide, and write down the reasoning. Sometimes you just have to choose. Bias testing is the live example. The AI Act now lets you use sensitive personal data, health and ethnicity and the rest, to check whether your system discriminates. It also tells you to delete that data once the bias is fixed. Every instinct in a testing team says keep it, so you can prove the fix held. Both positions are defensible, the choice needs to be on paper with a reason attached.
Keep a list of the words that do not match. One line each: the word, the regulation, what it means there, what follows from it. Risk takes three lines. So does provider. So does incident. It is the least impressive document you will produce this year, and it is the one that stops the same argument restarting every quarter, because the answer is written down with a source next to it.
And one note on timing. The AI Act’s high-risk obligations are deferred to 2 December 2027 for standalone Annex III systems and 2 August 2028 for those embedded in regulated products. Most of the collisions above are not operative today. The divergences are already law. The obligations they create mostly are not.
Closing Argument
Cumulative application sounds like an inconvenience. It has a sharper edge,and it shows up in the order things happen.
One system fails. Two regulators can fine you for it: your data protection authority under the GDPR, and whoever supervises the AI Act where you are.
The Court of Justice has been asked whether that is allowed. Its answer is yes, with conditions. The Court said two fines can be lawful, but only where three things are true:
the company could have seen the double exposure coming,
the two authorities work in step, and
the second fine takes the first into account so the total stays proportionate.
It said the same thing a second time on the same day, in a different case.
A specialist regulator followed by a general one. Which is roughly the shape of a data protection authority and an AI regulator looking at the same system.
Now look at what the AI Act tells its own regulator to weigh when setting a fine. One item on that list is whether you have already been fined by another authority, under other EU or national law, for the same conduct.
That is the third condition, written into the statute. Your GDPR fine is something the AI Act instructs the regulator to take into account.
The GDPR does not return the favour. Its own list of factors has no equivalent item. The closest is a catch-all at the end: any other aggravating or mitigating factor in the circumstances. Open-ended, discretionary, and not the same thing as a rule.
So the coordination exists, and it runs one way.
Which means the order matters. Fined under the GDPR first, and the AI Act regulator has to account for it. Fined under the AI Act first, and your data protection authority may account for it, under a catch-all, if it chooses.
The AI Act was written to account for the GDPR. The GDPR was written eight years before there was anything to account for.
Scope is where this becomes something you can use in a meeting: the regulation map, the role assignment, the vendor questions, the AI inventory spreadsheet, the AI policy template, with sources attached and kept current as the law changes.
The Omnibus used a fourth technique, one that sorts by size rather than sector. Point 26 replaces Article 63(1): SMEs, including start-ups, may comply with certain elements of the Article 17 quality management system in a simplified manner, where the original text limited that to microenterprises. The condition is narrow. The company must have no partner or linked enterprises within the meaning of Recommendation 2003/361/EC, so a small firm inside a group is out. Which elements can be simplified is not settled either. The Commission is to develop guidelines, with no date in the text.
Silvia, your discussion just before “What to Do”—where you distinguish GDPR Article 22 from the AI Act’s Article 86 explanation right—raised a question for me.
You note that the boundary between a decision made by an automated system and a decision made by a person on the basis of AI output is increasingly difficult to draw, particularly after SCHUFA. That seems to create a problem underneath the legal classification itself:
What evidence actually establishes that the consequential decision was substantively made by the human, rather than by the AI system or by the coupled human–AI process?
A human may be formally responsible, review the output, have authority to override it, and leave a complete audit trail. But those facts do not necessarily establish that the human was causally determinative in the outcome.
That also made me read point 4 of your “What to Do” section differently. When two rules pull in different directions, you suggest deciding and documenting the reasoning. That clearly establishes provenance and organizational authority. But I wonder whether there is a separate question about the evidential standing of any causal attribution underlying that decision.
In other words: documented human oversight, formal decision authority, and identifiable human causal control may be three different things.
I’d be very interested in how you see that distinction fitting into the Article 22 / Article 86 overlap you describe.