EU AI Act vs. GDPR: How the Two Regulations Interact
GDPR compliance does not mean AI Act compliance. This guide explains where the two regulations overlap, where they diverge, and how to run your obligations together.
Many organisations that have been GDPR-compliant for years are now discovering that the EU AI Act adds a substantial new layer of obligation. The two regulations share certain principles — transparency, accountability, risk assessment — but they operate on different legal logics, cover different harms, and require different documentation.
This guide is for Data Protection Officers, compliance teams, and legal counsel who need to understand exactly where the AI Act reinforces the GDPR, where it introduces genuinely new obligations, and how to integrate both frameworks without duplicating effort unnecessarily.
The Relationship Between the Two Regulations
The EU AI Act does not replace or override the GDPR. Article 2(7) of the AI Act makes clear, consistent with its recitals, that the regulation complements existing EU law on data protection. The GDPR continues to apply in full wherever personal data is processed by an AI system. The AI Act then adds a separate layer of obligations that apply based on the risk level of the AI system itself — regardless of whether personal data is involved.
This is the critical point: an AI system can be subject to AI Act high-risk obligations even if it processes no personal data at all. Conversely, an AI system that processes large volumes of personal data may fall outside the AI Act's high-risk framework if it is not listed in Annex III.
The two regulations are complementary but not interchangeable. GDPR compliance is a floor, not a ceiling.
Where the Regulations Overlap
Automated Decision-Making
GDPR Article 22 gives individuals the right not to be subject to decisions based solely on automated processing that produce significant legal or similarly significant effects. This right has applied since 2018. It requires a legal basis, specific information to the data subject, and meaningful human review options.
The EU AI Act's human oversight requirements (Article 14) reinforce this logic considerably. For high-risk AI systems, Article 14 requires that systems be designed to allow natural persons to effectively oversee the system during its operation — to understand its outputs, identify anomalies, and intervene or override. This is not merely a procedural right granted to individuals; it is a design obligation imposed on the provider.
Where your AI system makes or supports decisions with legal or similarly significant effects on individuals, both frameworks apply simultaneously. Your GDPR Article 22 compliance work informs but does not complete your AI Act Article 14 compliance.
Transparency Obligations
The GDPR requires organisations to inform individuals about automated decision-making through privacy notices (Articles 13 and 14 GDPR) and, in the Article 22 context, to provide meaningful information about the logic involved.
The AI Act adds to this in two ways. Article 13 requires providers of high-risk AI systems to ensure systems are designed to enable deployers to provide transparent information to affected persons. Article 50 goes further: deployers of certain high-risk AI systems that interact directly with natural persons must inform those persons that they are interacting with an AI system.
GDPR privacy notices and AI Act transparency notices have different audiences, different triggers, and different content requirements. You need both, and a privacy notice does not substitute for an AI Act transparency notice.
Training Data and Lawful Basis
The AI Act's data governance obligations under Article 10 require that training, validation, and test datasets be relevant, representative, free of errors, and complete for the intended purpose. They must also be collected and processed in accordance with applicable law — which includes the GDPR where personal data is involved.
This means that for any AI system trained on personal data, you need a valid GDPR lawful basis for processing that data in the training context (often legitimate interests or, for special categories, explicit consent), and you must respect purpose limitation. Using personal data collected for one purpose to train an AI system for a different purpose is a potential violation of both regimes simultaneously.
Your GDPR records of processing activities should therefore include training data processing — and your AI Act technical documentation (Annex IV, Section 3) should cross-reference those GDPR records.
Where the Regulations Diverge
Different Risk Frameworks
The GDPR's risk framework centres on risks to the rights and freedoms of natural persons arising from data processing. The AI Act's risk framework is broader: it covers risks from AI systems regardless of whether personal data is involved, and it categorises systems by use case (Annex III) rather than by the nature of the data processed.
A high-risk AI system under the AI Act (for example, an AI-assisted recruitment tool) may not involve a DPIA-triggering level of data risk under the GDPR — and a processing activity that requires a DPIA under the GDPR may not involve a high-risk AI system under the AI Act at all.
The categories do not map neatly onto each other. You cannot use your DPIA register as a proxy for your AI Act high-risk system inventory, or vice versa.
FRIA vs. DPIA: Similar Names, Different Obligations
This is one of the most commonly misunderstood areas of interaction between the two frameworks.
A Data Protection Impact Assessment (DPIA) under GDPR Article 35 is required when processing is likely to result in high risk to the rights and freedoms of natural persons — particularly for systematic profiling, processing of special category data at scale, or systematic monitoring of public spaces. It focuses specifically on privacy and data protection risks.
A Fundamental Rights Impact Assessment (FRIA) under AI Act Article 27 is required only for a defined subset of deployers — not for all high-risk AI system deployers. Specifically, it applies to: (a) public bodies deploying high-risk AI systems, (b) private entities providing public services (such as banks providing credit under a public mandate, or utilities), and (c) providers and deployers covered by Annex III points 5(b) and 5(c), which cover AI systems used in credit scoring and for access to essential private services.
The FRIA is broader in scope than the DPIA: it considers impacts on all fundamental rights, not just privacy. It must assess impacts on human dignity, non-discrimination, equality, freedom of expression, the right to an effective remedy, and other Charter rights. But it is also more targeted in who must conduct it.
Key differences at a glance:
| Dimension | DPIA (GDPR Art. 35) | FRIA (AI Act Art. 27) |
|---|---|---|
| Legal basis | GDPR | EU AI Act |
| Who must conduct it | Controllers, when high data risk | Public bodies, private/public service providers, certain Annex III deployers |
| Scope of harm | Privacy and data rights | All fundamental rights |
| Trigger | Nature of the processing | Nature of the deployer and use case |
| Required for all high-risk AI | No | No — subset only |
If you are required to conduct both a DPIA and a FRIA for the same system, the most efficient approach is to run them together. A DPIA conducted as part of the AI Act compliance process can feed directly into the FRIA's data protection section. The outputs are separate documents, but the factual analysis overlaps substantially.
Being GDPR-Compliant Does Not Mean Being AI Act-Compliant
This point cannot be overstated. The EU AI Act creates independent obligations — conformity assessments, CE marking, Annex IV technical documentation, EU database registration, post-market monitoring — that have no equivalent in the GDPR. An organisation that has invested heavily in GDPR compliance has useful building blocks for AI Act compliance, but it has not crossed the finish line.
Specifically, GDPR compliance does not provide:
- A conformity assessment demonstrating that your AI system meets the essential requirements of Articles 8–15
- A CE marking authorising market placement
- Technical documentation covering system architecture, training data methodology, and testing results
- Registration in the EU AI database (Article 71)
- A post-market monitoring plan (Article 72)
These obligations are entirely AI Act-specific.
A Practical Integration Strategy
Rather than running two parallel compliance programmes, the most efficient approach is to integrate them at the points where the frameworks genuinely overlap.
- Map your AI systems against both the GDPR's processing activities register and the AI Act's Annex III. Identify systems that are high-risk under one, both, or neither framework.
- Where a system is high-risk under both frameworks, run the DPIA and FRIA together. Use the DPIA's privacy risk analysis to populate the FRIA's data protection section. Avoid doing the factual groundwork twice.
- Align your transparency notices. Draft the AI Act transparency notice (Article 50) alongside the GDPR privacy notice. They serve different legal purposes but share overlapping factual content about the system's logic and effects.
- Cross-reference your documentation. Your Annex IV technical documentation (Section 3 on training data) should reference your GDPR lawful basis for training data processing. Regulators from both the AI Office and data protection authorities may request access to these records.
- Assign ownership. In many organisations, the DPO is well-placed to coordinate AI Act compliance for high-risk AI systems that process personal data. However, AI Act compliance also involves technical teams and product owners who are not typically part of GDPR programmes. Establish clear accountability across both.
How DilAIg Helps
DilAIg generates all four mandatory documents for high-risk AI system compliance — including the FRIA — from a single 50-question audit. The audit captures the factual information that feeds both your AI Act documentation and your GDPR cross-reference obligations, so you are not answering the same questions twice in separate tools.
Contact the DilAIg team for questions about GDPR and AI Act integration →
FAQ: EU AI Act and GDPR
Does the AI Act replace the GDPR for AI systems?
No. The AI Act is complementary to the GDPR, not a replacement. Both apply simultaneously wherever an AI system processes personal data. Article 2(7) of the AI Act confirms this.
Is a FRIA the same as a DPIA?
No. A DPIA (GDPR Article 35) focuses on risks to privacy and data rights. A FRIA (AI Act Article 27) covers all fundamental rights and is required only for a specific subset of deployers — public bodies, private entities providing public services, and certain Annex III deployers. Their scope and triggers are different.
Do all high-risk AI system deployers need to conduct a FRIA?
No. Article 27 limits the FRIA obligation to: (a) public bodies, (b) private entities providing public services, and (c) deployers covered by Annex III points 5(b) and (c). Most private-sector deployers of high-risk AI systems in other Annex III categories are not required to conduct a FRIA.
Can our DPO lead AI Act compliance?
The DPO's expertise in data protection risk is highly relevant, particularly for AI systems that process personal data. However, AI Act compliance covers technical obligations (system architecture, conformity assessments, CE marking) that typically require input beyond the DPO's traditional remit. The DPO is a natural coordinator, but AI Act compliance needs cross-functional ownership.
What happens when GDPR and AI Act obligations conflict?
In most cases they do not conflict — they operate on different dimensions of the same activity. Where a genuine conflict arises, the lex specialis principle applies, but the European AI Office and data protection authorities are expected to coordinate enforcement to avoid contradictory requirements.
Key Takeaways
- The AI Act complements the GDPR; it does not replace it (Article 2(7))
- GDPR Article 22 and AI Act Article 14 both address automated decision-making, but Article 14 imposes design obligations on providers — not just individual rights
- A FRIA (Article 27) is not required for all high-risk AI deployers — only public bodies, private entities providing public services, and certain Annex III deployers
- A DPIA and a FRIA have different scopes: DPIA focuses on privacy risks; FRIA covers all fundamental rights
- Training data processed under AI Act Article 10 must also comply with GDPR lawful basis and purpose limitation requirements
- Being GDPR-compliant does not satisfy AI Act conformity assessment, CE marking, technical documentation, or database registration requirements
- Run DPIAs and FRIAs together where both apply, and cross-reference Annex IV documentation with your GDPR records of processing