EU AI Act vs. GDPR: Where the Two Regimes Overlap and Diverge

Article 2(7) of the EU AI Act settles a question a lot of GDPR-mature companies get wrong before they even start: the Act applies without prejudice to the GDPR. Not instead of it. Not as an AI-flavored restatement of it. Alongside it, in full, at the same time. A company that has spent years building real data protection impact assessments and a genuine privacy-by-design culture starts from a much better position than one that hasn't — but that head start isn't coverage. The two regimes ask different questions, attach to different triggers, and in at least one common scenario require two separate assessment documents running in parallel, not one file doing double duty.

Where the two regimes are asking the same question

The overlap is real, and it's exactly what makes the "we already handle this" mistake so easy to make. Two areas account for almost all of it.

Automated decision-making: GDPR Article 22 and AI Act deployer obligations

GDPR Article 22 gives people a right not to be subject to a decision based solely on automated processing — including profiling — where that decision produces legal effects or similarly significantly affects them. It's been on the books since 2018, and it already covers plenty of what people now think of as "AI decisions": automated credit denials, automated e-recruitment rejections, automated eligibility determinations. The right isn't absolute — it gives way where the decision is necessary for a contract, authorized by law, or based on explicit consent — but wherever one of those exceptions applies, GDPR still requires safeguards: at minimum, the ability to obtain human intervention, to state a case, and to contest the outcome.

The AI Act layers a separate, additional set of obligations on top of that for a high-risk system doing the same kind of work — deployer duties under Article 26 around human oversight, monitoring, and logging. Those obligations are real and independently enforceable, but they don't discharge Article 22. A deployer that has fully implemented its AI Act deployer duties and never separately asked "do we have a valid Article 22 basis, and are the required safeguards actually in place" has finished one compliance track and not started the other.

DPIAs and FRIAs: overlapping impact assessments, not interchangeable ones

Both regimes force an organization to formally assess risk before a system goes live, and it's tempting to assume that's one assessment wearing two names. It isn't. A GDPR Data Protection Impact Assessment under Article 35 is required wherever processing is likely to result in high risk to individuals — Article 35(3)(a) names systematic, extensive automated evaluation of personal aspects, including profiling, that produces legal or similarly significant effects as one of the categories that mandates one outright.

A Fundamental Rights Impact Assessment under AI Act Article 27 is a narrower, differently triggered obligation. It applies to bodies governed by public law, private entities providing public services, and — critically — private deployers using a high-risk AI system for creditworthiness assessment or credit scoring, or for risk assessment and pricing in life and health insurance, regardless of whether they're public or private. A retailer running an internal, non-financial AI risk score on its own customers might need a DPIA and have no FRIA obligation at all. A bank running an AI credit-decisioning tool will typically need both, and they're not the same document: one exists to protect data subjects' rights under data protection law, the other to protect fundamental rights specifically in the deployment of a high-risk AI system, and each has its own required contents.

Where they genuinely pull apart

Past the overlap, the divergences matter just as much, because they're the places a team can be fully compliant with one regime and still be exposed under the other.

The scope trigger is the biggest one. GDPR's applicability is entirely conditioned on personal data being processed — no personal data, no GDPR obligation, full stop. The AI Act doesn't work that way. Its obligations turn on whether something meets the Act's own AI system definition and lands in a regulated risk category, independent of whether personal data is involved anywhere in the pipeline. A high-risk AI system controlling a factory's safety shutoff logic, with no personal data touched at any point, is fully inside AI Act scope and entirely outside GDPR's.

The risk-classification logic is also structurally different. GDPR's DPIA trigger is a case-by-case likelihood judgment — is this processing, in this context, likely to produce high risk? The AI Act's Annex III high-risk list works the opposite way: it's a fixed, enumerated set of use cases (biometric categorization, credit scoring, employment decisions, and others) that are high-risk by definition, whatever the actual risk profile of a specific deployment looks like. A system can sail through a GDPR risk assessment as genuinely low-risk in practice and still be automatically high-risk under the AI Act purely because of the use case it falls into.

Enforcement runs through different doors, too. GDPR enforcement sits with each member state's national Data Protection Authority. AI Act market surveillance generally runs through separately designated national market surveillance authorities, with the EU AI Office handling general-purpose AI model obligations directly. A single system processing personal data can be answerable to two regulators, asking two different sets of questions, on two different timelines.

And one question the AI Act simply doesn't answer: the legal basis for processing personal data used to build or run a system in the first place. Training-data legal basis, consent management, and purpose limitation are GDPR questions from end to end. The Act's own data governance requirements — set out in Article 10 — cover data quality, bias, and representativeness, not the underlying lawfulness of processing that data at all.

One system, two compliance tracks

Larkspur Community Bank is rolling out an AI-driven loan-underwriting tool that scores applicants and recommends approve/decline decisions with limited human review. Walk it through both regimes side by side and the picture gets concrete fast.

On the GDPR side, the tool triggers a DPIA the moment it's clear this is systematic, automated profiling that produces a decision with real legal effect on an applicant — denial of credit is about as legally significant as an outcome gets. If the decision is ever made without a human meaningfully reviewing it, Article 22 kicks in too: Larkspur needs a valid basis (contractual necessity is the natural fit for a loan application) and has to build in the safeguards — a genuine path to request human review, present additional information, and contest the outcome — not just a customer-service line that reroutes back to the same model.

On the AI Act side, a credit-scoring tool lands squarely in Annex III's high-risk category, which triggers the full high-risk stack: an Article 9 risk management system, the Article 10 data governance work on the training data behind the model, Article 13 transparency obligations to the people the tool assesses, and — because creditworthiness assessment is one of the named FRIA categories — a Fundamental Rights Impact Assessment under Article 27, sitting alongside the DPIA rather than replacing it.

Some of Larkspur's existing GDPR work genuinely carries over: its data mapping of what applicant data flows into the model, and the DPIA's analysis of impact on individuals, both feed directly into the FRIA and the Article 9 risk file rather than needing to be redone from scratch. But the AI Act's technical documentation, risk management system, and conformity work are new deliverables with their own required contents — none of them exist yet just because a DPIA does.

What this means for teams reusing existing GDPR work

A mature GDPR program is genuinely useful raw material for AI Act compliance — records of processing, existing DPIAs, and data mapping all shorten the AI Act analysis considerably. What doesn't work is relabeling any of it and submitting it as AI Act documentation. The Act's conformity assessment and its Article 9, 10, 11, and 27 deliverables have their own required contents, spelled out independently of anything GDPR asks for.

The practical sequencing that tends to work best: run the GDPR analysis first. Knowing what personal data is involved, what legal basis applies, and whether Article 22 is triggered clarifies exactly what the AI Act analysis still has to add — rather than starting an AI Act risk file cold and discovering the data protection questions only once a regulator, or a rejected applicant, asks them.