The EU AI Act and the GDPR are not alternatives. Any AI system that touches personal data falls under both at once. The GDPR governs the data: whether you may use it, how, and for how long. The AI Act governs the system: how risky it is, how it is built, and who oversees it. They overlap on roughly two-thirds of what you must do, and they collide on a handful of points that can sink a project if you handle them separately.

This guide maps exactly where the two laws reinforce each other, where they pull in opposite directions, and how to build one compliance programme that satisfies both. It is written for consultants, DPOs, compliance leads and AI product teams.

GDPR
Regulation (EU) 2016/679, applied since 25 May 2018
EU AI Act
Regulation (EU) 2024/1689, in force since 1 August 2024, phased in to 2028
Relationship
The AI Act applies "without prejudice" to the GDPR. Both apply in full.
Max GDPR fine
€20 million or 4% of global annual turnover
Max AI Act fine
€35 million or 7% of global annual turnover (prohibited practices)
GDPR fines in 2025
About €1.2 billion; €7.1 billion cumulative since 2018
High-risk AI deadline
2 December 2027 (Annex III), after the Digital Omnibus delay

What each law actually regulates

GDPR: the data

Applies whenever you process personal data, whatever the technology. It asks whether you have a legal basis, whether you collect only what you need, whether people are informed, and whether they can exercise their rights. It speaks to controllers and processors.

AI Act: the system

Applies to AI systems and general-purpose AI models placed on the EU market or used in the EU, even with no personal data involved. It sorts systems by risk and imposes product-style duties. It speaks to providers, deployers, importers and distributors.

The simplest way to hold both in your head: GDPR asks "may you use this data?" The AI Act asks "may you build and run this system this way?" A credit-scoring model trained on customer records needs a yes to both questions.

EU AI Act vs GDPR at a glance

DimensionGDPREU AI Act
What it protectsPersonal data and privacyHealth, safety and fundamental rights
TriggerProcessing personal dataDeveloping or using an AI system or GPAI model
ApproachPrinciples-based, applies to all processingRisk-tiered: prohibited, high-risk, transparency, minimal
Key rolesController, processorProvider, deployer, importer, distributor
Core assessmentDPIA (Article 35)Conformity assessment; FRIA for certain deployers (Article 27)
Individual rightsAccess, erasure, objection, rectification and moreMainly the right to an explanation of certain high-risk decisions (Article 86)
Applies without personal data?NoYes
RegulatorData protection authoritiesMarket surveillance authorities and the EU AI Office
Maximum fine€20m or 4% of turnover€35m or 7% of turnover

Where they overlap

The good news first. Most AI Act obligations for high-risk systems have a GDPR cousin, so the evidence you build for one is often reusable for the other. This is the map most teams wish they had on day one.

ObligationGDPR requirementAI Act requirementBuild it once?
Risk assessmentDPIA for high-risk processing (Art. 35)Risk management system (Art. 9); FRIA for some deployers (Art. 27)Yes. Art. 27(4) says the FRIA complements the DPIA
Data qualityAccuracy, minimisation, purpose limitation (Art. 5)Data governance for training, validation and test sets (Art. 10)Largely
TransparencyPrivacy notices (Arts. 13–14)Instructions for use (Art. 13); disclosure duties (Art. 50)Partly. Different audiences
Human involvementLimits on solely automated decisions (Art. 22)Human oversight by design (Art. 14)Partly. See the collisions below
RecordsRecords of processing (Art. 30)Technical documentation and logging (Arts. 11–12)Yes, with one register
SecurityAppropriate security measures (Art. 32)Accuracy, robustness and cybersecurity (Art. 15)Largely
IncidentsBreach notice within 72 hours (Art. 33)Serious incident report, generally within 15 days (Art. 73)No. Two clocks, two regulators
The deployer shortcut most people miss

Article 26(9) of the AI Act tells deployers of high-risk systems to use the provider's instructions for use when carrying out their GDPR DPIA. Ask your AI vendor for that document before you start the DPIA. It already contains much of what you need.

Where they collide

This is where projects get stuck. These are the six friction points that show up again and again in real implementations.

1. The AI Act gives you no legal basis to process personal data

Complying with the AI Act does not make processing lawful under the GDPR. You still need an Article 6 basis for every stage: collecting training data, training, fine-tuning and running the model. The European Data Protection Board's Opinion 28/2024, issued in December 2024, says legitimate interest can work for AI development, but it is not a default. You must pass a three-step balancing test and usually add safeguards such as pseudonymisation, extra transparency and an opt-out offered from the start.

Getting this wrong is expensive. In December 2024, Italy's Garante fined OpenAI €15 million over ChatGPT. Its findings included training on personal data without first identifying an adequate legal basis, weak transparency, inadequate age verification and an unreported data breach. OpenAI was also ordered to run a six-month public information campaign.

2. Bias testing needs the very data the GDPR protects most

To prove a model doesn't discriminate by ethnicity or health status, you often need ethnicity or health data. That is special category data under GDPR Article 9, which is prohibited unless an exception applies. The AI Act's Article 10(5) originally created a narrow exception for high-risk providers. The Digital Omnibus on AI moved this into a new Article 4a and widened it to other AI systems and to deployers. But it kept tight conditions: the processing must be strictly necessary, synthetic or anonymised data must be insufficient, and the data must be deleted once the bias is corrected.

3. Data minimisation vs representative datasets

The GDPR says collect as little as possible. Article 10 of the AI Act says training data must be relevant, sufficiently representative and, as far as possible, complete. The way through is documentation: record why each data field is needed for performance or fairness, and why less would not do.

4. Erasure and objection vs a trained model

People can ask you to delete their data or stop using it. Deleting a row from a database is easy; removing its influence from a trained model is not. The EDPB has said that if a model was trained unlawfully, authorities may order erasure of all or part of the dataset, or even retraining. Plan for rights requests before training, not after.

5. Human oversight is not the same as Article 22

A human who rubber-stamps an AI decision satisfies neither law. GDPR Article 22 restricts decisions based solely on automated processing. AI Act Article 14 requires oversight that lets a person understand the system, spot problems and override it. Design one oversight process that is meaningful enough for both.

6. Roles don't line up

An AI Act "provider" is not automatically a GDPR "controller", and a "deployer" is not automatically a "processor". A SaaS company that trains a model on customer data can be a provider under one law and a processor, controller or joint controller under the other, depending on the step. Map roles per processing activity, not per company.

Two regulators can investigate the same system

Data protection authorities enforce the GDPR. Market surveillance authorities enforce the AI Act. For some high-risk areas, such as biometrics, law enforcement, migration and the administration of justice, the AI Act points to data protection authorities as the market surveillance authority. Expect overlapping questions and keep your answers consistent.

Working through this right now?

I post practical breakdowns of AI Act and GDPR questions most weeks. Connect with me on LinkedIn and tell me which collision point is blocking your project.

Enforcement: what the numbers say

GDPR enforcement is mature and still accelerating. DLA Piper's January 2026 survey put fines for 2025 at about €1.2 billion and the cumulative total since 2018 at €7.1 billion. Breach notifications averaged 443 a day, up 22% on the prior year and above 400 a day for the first time. The largest fine of 2025 was €530 million against TikTok, over international data transfers.

€1.2bnin GDPR fines imposed during 2025
€7.1bncumulative GDPR fines since May 2018
443/dayaverage data breach notifications, up 22% year on year

AI Act penalties are higher on paper. The ceiling for prohibited practices is almost double the GDPR's top tier.

Maximum fine as a share of global annual turnover
AI Act: prohibited practices 7%
GDPR: upper tier 4%
AI Act: most other obligations 3%
GDPR: lower tier 2%
AI Act: misleading information to authorities 1%

Each tier also has a fixed euro cap (€35m, €20m, €15m, €10m and €7.5m respectively); the higher of the two amounts applies, with lower caps for SMEs under the AI Act.

The timeline you are working to

  • 25 May 2018

    GDPR applies across the EU.

  • 1 Aug 2024

    AI Act enters into force.

  • 2 Feb 2025

    Prohibited AI practices and AI literacy duties apply.

  • 2 Aug 2025

    Obligations for general-purpose AI models apply.

  • 2 Aug 2026

    Article 50 transparency duties and AI Act penalties apply.

  • 2 Dec 2026

    Machine-readable marking of AI-generated content for systems already on the market; new bans on AI-generated non-consensual intimate imagery and CSAM.

  • 2 Dec 2027

    Stand-alone high-risk systems (Annex III), such as hiring, credit scoring and education.

  • 2 Aug 2028

    High-risk AI embedded in regulated products (Annex I).

What is still changing

The two laws are being amended on different tracks, and it is easy to confuse them.

AI Act changes: agreed

The Digital Omnibus on AI was provisionally agreed on 7 May 2026 and formally adopted in June 2026. It delayed the high-risk deadlines, softened the AI literacy duty to "take measures to support" literacy, and created the Article 4a bias-detection basis.

GDPR changes: still a proposal

The separate Digital Omnibus proposal to amend the GDPR, including a legitimate-interest clause for AI development, was still at proposal stage as of late October 2026. The Council had no agreed negotiating mandate and Parliament had no position, so trilogue had not started.

Don't plan around GDPR changes that aren't law

Several articles describe the proposed GDPR amendments as if they were settled. They are not. Build your legal basis on the GDPR as it stands today and the EDPB's existing opinions. Joint EDPB–Commission guidelines on how the two laws interact have been previewed, with a final version expected by the end of 2026.

How to comply with both: a 7-step plan

  1. Build one AI and data register

    List every AI system, its AI Act risk tier, the personal data it uses, its GDPR legal basis and its owner. One register serves your Article 30 records and your AI inventory.

  2. Map roles per activity

    For each stage, from data collection to training, deployment and monitoring, record who is provider or deployer and who is controller or processor. Put the result into your contracts.

  3. Set a legal basis for each lifecycle stage

    Training and inference often need different bases. If you rely on legitimate interest, document the three-step test and the safeguards the EDPB expects.

  4. Run a combined DPIA and FRIA

    Use one template with a fundamental-rights section that goes beyond privacy: discrimination, access to services, freedom of expression. Article 27(4) explicitly allows the FRIA to build on the DPIA.

  5. Design oversight that satisfies Article 22 and Article 14

    Give reviewers the information, authority and time to override the system, and log when they do. If no one ever overrides it, your oversight probably isn't real.

  6. Write one transparency layer

    Update privacy notices to explain AI use and logic, and add AI Act disclosures where people interact with AI or see AI-generated content.

  7. Run a dual-clock incident playbook

    A single event can trigger a 72-hour GDPR breach notice and an AI Act serious-incident report. Decide in advance who assesses each, and who talks to which regulator.

Common mistakes to avoid

  • Assuming AI Act conformity makes the data processing lawful
  • Treating "a human clicks approve" as meaningful oversight
  • Running the DPIA and FRIA as two disconnected documents
  • Collecting sensitive data "for bias testing" without meeting the Article 4a conditions
  • Labelling every vendor a "processor" without checking who decides the training purpose
  • Planning on proposed GDPR changes that haven't been adopted

A prompt for a combined DPIA and FRIA screening

Paste in a description of your AI system to get a first-pass screening of both laws, with every gap marked. Treat it as a starting draft for your DPO and legal team, not a legal opinion.

Combined GDPR + AI Act screening prompt
You are an EU data protection and AI Act compliance specialist.
Screen the AI system described below against both the GDPR and the
EU AI Act (Regulation (EU) 2024/1689, as amended by the Digital
Omnibus on AI). Use only the facts I provide. Where facts are
missing, write "UNKNOWN" and say what I need to find out.

System description:
[purpose, users, affected people, data sources, personal data
categories, any special category data, model type, vendor or
in-house, where it is used, whether decisions are automated]

Produce:
1. AI Act classification: prohibited, high-risk (cite the Annex III
   area), Article 50 transparency, or minimal risk. Give reasons.
2. Our role(s) under the AI Act and under the GDPR, per lifecycle
   stage (collection, training, deployment, monitoring).
3. A GDPR legal basis for each stage, and whether Article 9 or
   Article 22 is engaged.
4. Whether a DPIA and/or a FRIA is required, and why.
5. A table of the top 10 risks to individuals, each mapped to the
   GDPR article and AI Act article it relates to, with one control.
6. A list of every UNKNOWN, ranked by how much it affects the result.
The GDPR decides whether you may touch the data. The AI Act decides whether you may build the machine. Get one wrong and the other won't save you. — Kumail Mehdi

Frequently asked questions

Does the EU AI Act replace the GDPR for AI systems?

No. The AI Act applies without prejudice to the GDPR. If your AI system processes personal data, both laws apply in full, and complying with one does not satisfy the other.

Do I need both a DPIA and a FRIA?

Often, yes. A DPIA is required under the GDPR for high-risk processing. A FRIA is required under AI Act Article 27 for certain deployers of high-risk systems, such as public bodies, providers of public services, and those using AI for credit scoring or life and health insurance pricing. The AI Act lets the FRIA complement an existing DPIA, so one combined assessment is the practical route.

Can I use legitimate interest to train an AI model?

Possibly, but not by default. The EDPB's Opinion 28/2024 says you must pass a three-step test showing a legitimate interest, necessity and a fair balance with people's rights, usually backed by safeguards such as pseudonymisation, extra transparency and an easy opt-out.

Can I process sensitive data to test my AI for bias?

Only under strict conditions. The Digital Omnibus on AI added Article 4a, which allows it where strictly necessary, where synthetic or anonymised data won't do, with strong safeguards, and with deletion once the bias is corrected.

Does the AI Act apply if my system uses no personal data?

Yes. The AI Act regulates AI systems by risk, whether or not personal data is involved. The GDPR applies only when personal data is processed.

Are the GDPR changes in the Digital Omnibus in force?

No. As of late October 2026, the GDPR amendments were still a Commission proposal. Only the separate AI Act amendments (the Digital Omnibus on AI) have been adopted.

Master AI governance in 6 months — 15 minutes a week

Join AI Governance – Decoded, my weekly newsletter that turns the EU AI Act, GDPR, ISO 42001 and the frameworks around them into one short, practical read. And if you want to talk through your own compliance programme, connect with me on LinkedIn.

Subscribe to AI Governance – Decoded

Sources