GDPR and the EU AI Act: Two Regimes, One Compliance Programme
GDPR and EU AI Act apply cumulatively. Map 7 key intersections — FRIA vs DPIA, Art 14 vs GDPR Art 22, dual enforcement — for your compliance programme.
The EU AI Act does not replace GDPR. Both regulations apply simultaneously, and if your AI system processes personal data, you owe obligations under both — the Act for risk governance, GDPR for data protection. Treating them as separate workstreams is where compliance programmes break down.
This page maps the seven key intersections: where the regimes overlap, where they diverge, and what that means in practice for companies deploying or building AI systems in the EU.
The fundamental principle: cumulative, not alternative
Regulation (EU) 2024/1689 — the EU AI Act — was designed to sit alongside Regulation (EU) 2016/679 (GDPR), not above it. Recital 9 of the AI Act states explicitly that it is without prejudice to GDPR. The result: a company running a high-risk AI system that processes personal data must satisfy both regimes fully. Compliance with one does not count toward the other.
This matters operationally. Your data protection officer and your AI governance lead need to work from a shared documentation structure, not separate silos.
1. FRIA (Article 27) and DPIA (GDPR Article 35): related but distinct
The AI Act's Fundamental Rights Impact Assessment (Article 27) and GDPR's Data Protection Impact Assessment (Article 35) are the two assessments most often confused.
A DPIA is a GDPR obligation triggered when processing is "likely to result in a high risk to the rights and freedoms of natural persons" — typically when special-category data is processed at scale, or when automated decision-making has legal or similarly significant effects. The DPIA focuses on the lawfulness, necessity, and proportionality of the data processing, and on data-subject safeguards.
A FRIA is an AI Act obligation triggered for certain deployers of high-risk systems: specifically, public-body deployers and private deployers running creditworthiness (Annex III point 5(b)) or life/health-insurance (point 5(c)) systems. The FRIA focuses on the system's impact on fundamental rights — fairness, non-discrimination, access to justice — regardless of whether personal data is involved.
The two assessments are legally distinct. The AI Act expressly recognises this: Article 27(4) states that the FRIA may build on or incorporate a DPIA where one has already been conducted. In practice, if you are a public-sector deployer running a creditworthiness AI, you will likely need both — and structuring the DPIA first gives you a head start on the FRIA's fundamental-rights section. Document them as related annexes to a single compliance file rather than two disconnected exercises.
One common error: assuming every high-risk deployer must run a FRIA. Article 27 is narrower than that. Most private-sector employers deploying a recruitment AI do not automatically owe a FRIA; they do owe a DPIA under GDPR if that system profiles applicants.
2. Human oversight (Article 14) and the GDPR Article 22 right against solely automated decisions
These two provisions both concern automated decision-making, but they operate at different levels.
GDPR Article 22 is a data-subject right: individuals have the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, unless consent, contract necessity, or an explicit legal basis applies. The controller must provide a right to human intervention, to express a point of view, and to contest the decision.
AI Act Article 14 is a provider and deployer duty: high-risk AI systems must be designed so that natural persons can effectively oversee them during operation, with authority to intervene, suspend, or override.
A recruitment AI that produces ranked shortlists with no human review could simultaneously breach Article 22 (no meaningful human check on a legally significant decision) and Article 14 (no effective oversight). A genuine Article 14 mechanism — where the reviewer holds real authority to override — is strong evidence of Article 22's human-intervention requirement. But they are not identical: Article 14 applies to any high-risk AI system even if Article 22's scope is not triggered; Article 22 applies to low-tech automated systems that are not AI under the Act's definition.
Design the human-oversight mechanism once, document it under both regimes, and ensure the reviewer can actually override — not a nominal approval that rubber-stamps every output.
3. Special-category data: Article 10(5) creates a limited permission
GDPR Article 9(1) prohibits processing special-category data (race, ethnicity, religion, health, biometric data, etc.) absent an explicit legal ground under Article 9(2). For most AI development purposes, special-category data is off-limits.
AI Act Article 10(5) creates a narrow exception that sits alongside GDPR, not above it. Providers of high-risk AI systems may process special-category data for the specific purpose of detecting and correcting bias in the training dataset — but only with "appropriate safeguards for the fundamental rights and privacy of natural persons," and subject to all other applicable law, including GDPR. This is not a blank licence. The processing must be strictly limited to bias detection and correction; the data must be protected against other uses; and the GDPR ground still applies (in most cases, Article 9(2)(g) — substantial public interest — or a domestic implementing law will be required).
The practical consequence: if you are building a recruitment or credit-scoring AI and want to test whether your training data encodes demographic bias, you may be permitted to process racial or ethnic origin data for that purpose under Article 10(5), provided you have documented the legal basis under GDPR Article 9(2), have implemented technical safeguards (pseudonymisation, access controls, retention limits), and can demonstrate the processing is confined to bias testing. Document this decision in both your Article 11 technical documentation and your DPIA.
4. Data minimisation versus data quality and representativeness
GDPR's data minimisation principle (Article 5(1)(c)) requires that personal data be "adequate, relevant and limited to what is necessary." AI Act Article 10 imposes a different requirement: training data must be "relevant, sufficiently representative, and to the best extent possible, free of errors and complete" (Article 10(3)).
Representativeness can require more data, not less. A credit-scoring model trained only on majority-group applicants will systematically underperform on minority groups — a failure of Article 10(3), but also a GDPR Article 22 risk (discriminatory automated decisions). Collecting broader demographic data to correct this may conflict with minimisation unless justified.
There is no clean resolution in either regulation. The defensible approach: document the representativeness rationale in your Article 11 technical documentation; use the Article 10(5) bias-detection permission where applicable; pseudonymise sensitive attributes after training; and retain only what is necessary for ongoing bias monitoring. Address the tension explicitly in the Article 35 DPIA — regulators will look for evidence you considered it.
5. Transparency: AI Act Articles 13 and 50 alongside GDPR Articles 13–15
Both regimes impose transparency obligations, but they serve different purposes and target different parties.
GDPR Articles 13–15 require controllers to inform data subjects about their processing: legal basis, purposes, retention periods, rights (access, rectification, erasure, objection), and whether automated decision-making is in use.
AI Act Article 13 requires providers to give deployers instructions sufficient for effective oversight — system purpose, limitations, performance metrics, and data categories used in training.
AI Act Article 50 requires disclosure directly to users when they interact with a chatbot, synthetic media, emotion-recognition output, or AI-generated content. Article 50 obligations apply from 2 August 2026.
In practice: a deployer running a high-risk AI over personal data must issue GDPR privacy notices to data subjects and ensure the provider's Article 13 instructions are accurate enough for those notices to be truthful. The chain runs provider → deployer → data subject; gaps at any link create dual exposure.
6. Lawful basis: GDPR still governs every personal-data processing step
The AI Act does not create a new legal basis for processing personal data. GDPR Article 6 (general processing) and Article 9 (special categories) remain the only sources of legitimate authority.
Companies building high-risk AI systems need a GDPR Article 6 basis — typically legitimate interests (Article 6(1)(f)) or, for employees, the employment-law ground in Article 9(2)(b) — for every processing activity: data collection, model training, inference, logging (AI Act Article 12 requires logs to be kept), and output storage. The AI Act's documentation, risk management, and conformity assessment requirements do not themselves constitute a processing ground.
This becomes concrete in the Article 11 / Annex IV technical documentation pack: it must describe training data and its characteristics, which is only legally sound if that data was collected on a valid GDPR basis. Market-surveillance authorities reviewing your technical documentation may ask for the underlying GDPR records of processing.
7. Dual enforcement: two authorities, cumulative penalties
A single non-compliant AI system can trigger enforcement from two separate bodies.
GDPR enforcement rests with national Data Protection Authorities (DPAs) under GDPR Article 55. GDPR fines reach €20,000,000 or 4% of total worldwide annual turnover for major violations — those are GDPR figures, not AI Act figures.
AI Act enforcement rests with national market-surveillance authorities (Article 70) and, for GPAI models, the AI Office. AI Act penalties under Article 99 reach €35,000,000 or 7% for Article 5 prohibition breaches, and €15,000,000 or 3% for most high-risk system violations.
Both penalty sets reference worldwide annual turnover, so exposure compounds rather than caps. A biased recruitment AI that fails Article 14 human-oversight requirements and produces unlawful automated decisions (GDPR Article 22) could face fines from both the DPA and the market-surveillance authority for the same failure.
DPAs and market-surveillance authorities are increasingly coordinating investigations. Expect joint enforcement to become more common as the 2 December 2027 deadline for Annex III systems passes and active supervision begins.
How Confir helps
Confir's compliance workflows are structured around the AI Act, but they explicitly flag GDPR touchpoints where the regimes intersect. When you run a structured assessment through Confir, the AITO module (Transparency & Human Oversight, covering Articles 13, 14, 27 and 50) surfaces the Article 22 GDPR interaction alongside the AI Act human-oversight requirement, so you address both in a single documentation pass. The FRIA workflow under Article 27 notes where a DPIA may already exist and where its findings can be incorporated.
Confir's classification and scoping logic is deterministic and rule-based — the same intake produces the same output, with the rule that fired visible in the audit log. There is no inference engine guessing at your obligations. For a compliance document that will face regulatory scrutiny, reproducibility matters.
Frequently Asked Questions
Does the EU AI Act replace GDPR for AI systems?
No. The AI Act is explicit that it applies without prejudice to GDPR (Recital 9). Both regulations apply cumulatively when an AI system processes personal data. Compliance with one does not satisfy the other — you need to address data-processing obligations under GDPR and system-governance obligations under the AI Act separately, even where the documentation overlaps.
Is a FRIA the same as a DPIA?
No. A Data Protection Impact Assessment (GDPR Article 35) focuses on risks to data subjects from the processing of personal data. A Fundamental Rights Impact Assessment (AI Act Article 27) focuses on the AI system's broader impact on fundamental rights — non-discrimination, access to justice, fairness. Article 27(4) allows the FRIA to build on an existing DPIA, and producing the DPIA first is usually more efficient. But the FRIA covers additional ground and is only required for certain deployers (public bodies, and private deployers of creditworthiness or life/health-insurance AI systems).
Can special-category data be processed to test for AI bias?
Yes, within limits. AI Act Article 10(5) permits processing special-category data strictly for the purpose of detecting and correcting bias in training data, provided appropriate safeguards are in place. This does not override GDPR — you still need a legal basis under GDPR Article 9(2) for that processing. In most cases that will be a substantial-public-interest ground under national implementing law. Document both the Article 10(5) justification and the GDPR basis in your Article 11 technical documentation.
Which authority enforces the AI Act — the DPA or a different body?
Different body. GDPR enforcement sits with Data Protection Authorities (GDPR Article 55). AI Act enforcement sits with national market-surveillance authorities designated under Article 70. For GPAI models, the AI Office at EU level has enforcement powers (Article 99 and Article 101). DPAs and market-surveillance authorities are separate bodies, but they coordinate on cases where the same system triggers both regimes. Both can act simultaneously.
Does Article 14 human oversight satisfy GDPR Article 22?
Partially. AI Act Article 14 requires high-risk systems to be designed so a human can effectively oversee and intervene. GDPR Article 22 gives data subjects the right to obtain human intervention and to contest automated decisions with legal or similar effects. A genuine Article 14 mechanism — where the reviewer holds real authority to override — satisfies Article 22's intervention requirement. But Article 22 also grants a right to contest the decision, which needs a separate complaints process. Design both in from the start.
What penalties apply if both regimes are breached?
They are calculated independently. GDPR fines (under GDPR Article 83) reach €20,000,000 or 4% of total worldwide annual turnover for major violations — those are GDPR's figures. AI Act fines (under Article 99) reach €35,000,000 or 7% for Article 5 prohibition breaches, and €15,000,000 or 3% for most high-risk system violations. Both are calculated against worldwide turnover, and both can apply to the same underlying failure.
When must high-risk AI systems comply with the AI Act?
Under the Digital Omnibus agreed in May 2026, stand-alone high-risk AI systems (those in the Annex III list — recruitment, credit scoring, biometrics, etc.) must comply from 2 December 2027. High-risk AI embedded in regulated products under Annex I (machinery, medical devices) has until 2 August 2028. GDPR obligations have been in force since May 2018 and continue unchanged — if your system is already processing personal data, GDPR applies now.
Related guides
- Article 6 risk classification tool
- risk classification levels framework
- EU AI Act regulatory overview
- Article 8 compliance requirements chapeau
- compliance obligations checklist
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →