Chapter 14: GDPR and the AI Act — Where They Overlap and Where They Diverge

EU AI Act Implementation Guide · Full Chapter · Chapter 15 →

Two Laws, One Organisation

If your AI system processes personal data — and the vast majority do — you are subject to both GDPR and the EU AI Act simultaneously. These are not alternative regulatory frameworks. They are cumulative. Complying with one does not satisfy the other.

This creates a practical problem: many obligations sound similar. Both regulations require transparency. Both require impact assessments. Both require human involvement in automated decisions. Both impose documentation requirements. Organisations that treat these as identical risk either under-complying with one regulation or duplicating effort unnecessarily.

The key to navigating this is understanding the fundamental difference in what each regulation protects. GDPR protects personal data and privacy. The AI Act protects against risks arising from AI systems — including but not limited to data-related risks. GDPR asks: “Is personal data being processed lawfully, fairly, and transparently?” The AI Act asks: “Is this AI system safe, transparent, and respecting fundamental rights?” The questions overlap but are not the same.

The Seven Key Overlap Areas

1. Transparency

GDPR (Articles 13 and 14) requires that data subjects be informed about the processing of their personal data, including the existence of automated decision-making and meaningful information about the logic involved.

The AI Act adds transparency requirements that go beyond personal data. Article 50 requires disclosure that a person is interacting with an AI system (regardless of whether personal data is processed). Article 26(7) requires deployers to notify workers before deploying AI in the workplace, and Article 26(11) requires deployers of Annex III high-risk systems to notify the individuals subject to AI-assisted decisions. Article 86 then gives those affected persons the right to obtain from the deployer a meaningful explanation of the role of the AI system in the decision-making procedure and the main elements of the decision.

Where they differ: GDPR transparency focuses on data processing — what data is collected, why, by whom, for how long, and the data subject’s rights. AI Act transparency focuses on the AI system itself — that it exists, what it does, and how it contributes to decisions. A GDPR-compliant privacy notice that does not mention the AI system’s role, its classification, or its specific capabilities does not satisfy Article 50 or Article 26.

Practical approach: Integrate AI-specific disclosures into your existing GDPR transparency framework (privacy notices, consent flows, employee communications), but ensure the AI-specific elements are explicitly present and not buried in general data-processing language. Maintain separate documentation for each regulation’s requirements so that you can demonstrate compliance with both independently.

2. Impact Assessments: DPIA vs FRIA

GDPR (Article 35) requires a Data Protection Impact Assessment (DPIA) when processing is likely to result in high risk to the rights and freedoms of natural persons. This includes large-scale profiling, systematic monitoring, and processing of special-category data.

The AI Act (Article 27) requires a Fundamental Rights Impact Assessment (FRIA) for deployers of high-risk AI systems that are public-law bodies or private entities providing public services, as well as for credit-scoring (Annex III 5(b)) and life/health insurance (Annex III 5(c)) systems.

Where they differ: A DPIA focuses on risks to data protection — unlawful processing, data breaches, excessive data collection, insufficient safeguards. A FRIA focuses on risks to fundamental rights broadly — discrimination, bias, impact on freedom of expression, access to services, dignity, and equality. A DPIA may miss AI-specific risks like algorithmic bias that does not involve personal-data misuse. A FRIA may not cover data-processing risks that fall outside the fundamental-rights framework.

Practical approach: As discussed in Chapter 8, the two assessments can and should be conducted together when both are required, but they must each be complete on their own terms. Use a single process with two assessment layers: first the DPIA (data-protection risks), then the FRIA (fundamental-rights risks including but extending beyond data protection). Document them in a combined report with clearly separated sections, so that each authority — the data protection authority for the DPIA, the market-surveillance authority for the FRIA — can find the relevant analysis.

3. Automated Decision-Making

GDPR (Article 22) gives data subjects the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects or similarly significantly affects them. Exceptions exist for contract performance, legal authorisation, and explicit consent, but in all cases the data controller must implement suitable safeguards including the right to obtain human intervention, to express a point of view, and to contest the decision.

The AI Act (Article 26(2)) requires deployers of high-risk AI systems to assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. The ability to intervene in or disregard the output is a capability the provider must build in under Article 14(4). Article 14 requires providers to design high-risk systems so that they can be effectively overseen by natural persons during the period in which the system is in use.

Where they differ: GDPR Article 22 is triggered by solely automated decisions with legal or significant effects. If a human is meaningfully involved in the decision, Article 22 does not apply. The AI Act’s human-oversight requirement applies to all high-risk AI systems regardless of whether the decision is solely automated. Even if a human makes the final decision, the AI Act still requires that the human has the competence, authority, and tools to effectively oversee the AI system’s contribution.

This creates an important nuance: an organisation might comply with GDPR Article 22 by inserting a human into the decision chain, but still violate the AI Act if that human does not have genuine oversight capability — meaning they rubber-stamp the AI’s output without the training, tools, or authority to meaningfully evaluate and override it.

Practical approach: Design your human-oversight process to satisfy both regulations simultaneously. The human must not only be “in the loop” (GDPR) but must be competent, trained, equipped, and authorised to override (AI Act). Document the oversight process including the person’s qualifications, their access to relevant information, their authority level, and evidence that they actually exercise independent judgment — not just sign off automatically.

4. Data Quality

GDPR (Article 5(1)(d)) requires that personal data be accurate and, where necessary, kept up to date.

The AI Act (Article 10) requires providers of high-risk systems to use training, validation, and testing data sets that meet specific quality criteria — relevance, representativeness, freedom from errors, and completeness. Article 26(4) requires deployers to ensure input data is relevant to the intended purpose of the high-risk AI system.

Where they differ: GDPR data accuracy focuses on whether individual data records are correct — is this person’s address right, is their date of birth accurate? AI Act data quality is broader: it encompasses statistical representativeness, bias in data sets, completeness of training data, and the suitability of input data for the system’s intended use case. A data set can contain perfectly accurate individual records but still be non-representative or biased in aggregate — satisfying GDPR but not the AI Act.

Practical approach: GDPR data-accuracy measures (correction procedures, update requests, data-quality audits) should be maintained as a baseline. Layer AI Act data-quality requirements on top: assess representativeness of data sets across relevant demographic groups, test for systematic biases, verify that input data matches the system’s intended purpose, and document all assessments.

5. Data Subject Rights vs Individual Notification

GDPR grants data subjects a suite of rights: access (Article 15), rectification (Article 16), erasure (Article 17), restriction (Article 18), portability (Article 20), objection (Article 21), and the Article 22 right regarding automated decisions.

The AI Act creates additional individual rights in the AI context. Article 86 gives individuals subject to decisions taken on the basis of the output of high-risk AI systems listed in Annex III — other than point 2, critical infrastructure — the right to receive a clear and meaningful explanation of the role of the AI system in the decision-making procedure and the main elements of the decision, where the decision produces legal effects or similarly significantly affects them. Article 26(11) separately requires deployers to notify those individuals that they are subject to the use of the system.

Where they differ: GDPR rights are data-centric — they concern what data is held, how it is used, and the individual’s ability to control that data. AI Act individual rights are decision-centric — they concern how the AI system contributed to a decision affecting the individual and the substance of that decision. A GDPR subject-access request gives you the data; an AI Act explanation request gives you the reasoning.

Practical approach: Build a unified individual-rights response process that handles both data-subject requests (GDPR) and explanation requests (AI Act). When an individual submits a request, assess whether it triggers GDPR rights, AI Act rights, or both, and respond comprehensively. Ensure your customer-facing teams know that explanation requests exist under the AI Act and are trained to route them correctly.

6. Documentation

GDPR requires records of processing activities (Article 30), DPIA documentation (Article 35), and evidence of compliance measures.

The AI Act requires technical documentation (Annex IV for providers), FRIA documentation (Article 27), log-retention records (Article 26(6)), IFU records, monitoring records, training records, and classification assessments.

Where they differ: The overlap is significant in structure but different in substance. GDPR documentation centres on data flows — what data, from where, to where, why, how long, what safeguards. AI Act documentation centres on the AI system — how it works, what it does, how it was assessed, how it is monitored, who oversees it.

Practical approach: Maintain a unified compliance documentation system but with separate sections for GDPR and AI Act requirements. A single document-management system, consistent formatting, and cross-references between the two sets of records reduce administrative burden while ensuring each regulation’s requirements are independently traceable. An authority asking for GDPR records should be able to find them without wading through AI Act technical documentation, and vice versa.

7. Breach and Incident Reporting

GDPR (Article 33) requires notification to the supervisory authority within 72 hours of becoming aware of a personal-data breach likely to result in a risk to the rights and freedoms of natural persons. Article 34 requires notification to affected data subjects if the breach is likely to result in a high risk.

The AI Act (Article 73) requires providers of high-risk AI systems to report serious incidents to the market-surveillance authority. Article 26(5) requires deployers to notify providers and, where applicable, authorities of serious risks identified through monitoring. The AI Office handles incident reports related to GPAI models.

Where they differ: A data breach is about unauthorised access to, or loss of, personal data. An AI incident is about the AI system causing or contributing to harm — a discriminatory output, a safety failure, a fundamental-rights violation. These can overlap (an AI system breach that exposes personal data) or be entirely separate (an AI system that produces biased hiring decisions without any data breach occurring).

Practical approach: Establish a single incident-response framework with two parallel notification streams. When an incident occurs, assess whether it constitutes a GDPR data breach (→ notify data protection authority within 72 hours), an AI Act serious incident (→ notify market-surveillance authority), or both. Use a shared incident-detection and triage process but route the notifications and documentation to the appropriate regulatory channels.

Where the AI Act Goes Beyond GDPR

Several AI Act obligations have no GDPR equivalent:

AI Literacy (Article 4). GDPR has no equivalent training obligation. Data-protection training is a widespread practice but is not a specific legal requirement in the same way Article 4 mandates AI literacy.

Conformity Assessment and CE Marking (Articles 43, 48). These are product-safety-derived obligations with no parallel in data-protection law.

EU Database Registration (Article 49). The public registration of high-risk AI systems has no GDPR equivalent. The GDPR register of processing activities is an internal document; the AI Act EU database is public.

Risk Classification (Articles 5, 6, 50). GDPR does not classify processing activities by risk category in the same structured way. It uses a general risk-based approach for DPIAs and data-protection-by-design, but there is no equivalent of the prohibited/high-risk/limited-risk/minimal-risk classification system.

Provider-Specific Obligations (Articles 9–17). Risk-management systems, technical documentation to Annex IV standards, post-market monitoring plans, and quality-management systems are AI Act concepts without direct GDPR parallels.

Where GDPR Goes Beyond the AI Act

Conversely, several GDPR obligations have no AI Act equivalent:

Lawful Basis for Processing (Article 6). The AI Act does not specify when it is lawful to use an AI system (other than prohibiting certain practices). GDPR requires a legal basis — consent, contract, legal obligation, vital interests, public interest, or legitimate interests — for every processing activity involving personal data. Using a fully AI-Act-compliant system to process personal data without a GDPR lawful basis is still unlawful.

Data Minimisation (Article 5(1)(c)). The AI Act does not include an explicit data-minimisation principle. GDPR requires that personal data be adequate, relevant, and limited to what is necessary. An AI system that complies with all AI Act requirements but collects excessive personal data violates GDPR.

Data Protection Officer (Articles 37–39). The AI Act does not require a designated compliance officer (though appointing one is a practical best practice). GDPR requires a DPO in specific circumstances.

Cross-Border Data Transfer (Chapter V). The AI Act does not regulate where data is stored or transferred. GDPR imposes strict conditions on transfers of personal data outside the EEA. An AI system using a cloud provider in a third country must comply with GDPR transfer rules regardless of AI Act compliance.

Right to Erasure (Article 17). The AI Act does not grant a right to have data deleted from AI systems. GDPR does — and this can create practical challenges when training data includes personal data that a data subject wants erased.

Building a Unified Compliance Framework

The most efficient approach is not to build two separate compliance programmes but to build one integrated framework with clearly labelled components. The following structure works for most organisations:

Step 1: Inventory. Create a single register listing all AI systems and all personal-data processing activities. For each entry, note which regulation applies (AI Act only, GDPR only, or both). Most entries involving AI will be “both.”

Step 2: Classification. For each AI system, determine the AI Act risk category (Chapters 3–5). For each processing activity, determine the GDPR risk level and whether a DPIA is required. Map the two classifications side by side.

Step 3: Gap analysis. For each entry, list the obligations under both regulations. Identify where a single action satisfies both (e.g., a well-designed human-oversight process satisfies both GDPR Article 22 safeguards and AI Act Article 26(2)). Identify where separate actions are needed (e.g., GDPR erasure requests have no AI Act equivalent — this is a GDPR-only process).

Step 4: Unified documentation. Maintain one document system with clearly separated sections. Cross-reference where obligations overlap. Ensure each section can stand alone for its respective regulatory audience.

Step 5: Unified training. Integrate AI Act and GDPR training rather than delivering them as separate programmes. Staff who work with AI systems that process personal data need to understand both frameworks simultaneously, not in isolation.

Step 6: Unified incident response. One triage process, two notification streams. Assess every incident against both sets of criteria and route accordingly.

Common Mistakes

Assuming GDPR compliance covers the AI Act. It does not. GDPR addresses data-protection risks. The AI Act addresses AI-system risks. A system can be fully GDPR-compliant and still violate the AI Act — for example, by lacking a conformity assessment, missing a FRIA, or failing to provide human oversight.

Assuming the AI Act covers GDPR. It does not. A system can be fully AI-Act-compliant and still violate GDPR — for example, by processing personal data without a lawful basis, collecting excessive data, or transferring data outside the EEA without adequate safeguards.

Treating DPIA and FRIA as interchangeable. They assess different risk dimensions. A DPIA can miss algorithmic bias that does not involve data-protection violations. A FRIA can miss data-processing risks that fall outside the fundamental-rights framework.

Duplicating effort unnecessarily. Some organisations create entirely separate compliance teams, documentation systems, and training programmes for GDPR and the AI Act. This wastes resources and creates inconsistencies. An integrated approach with clearly labelled components is more efficient and more robust.

Ignoring the DPO’s role in AI Act compliance. The Data Protection Officer already has expertise in impact assessments, individual rights, transparency, and regulatory interaction. While the AI Act does not require a DPO, involving the existing DPO in AI Act compliance creates efficiency and ensures the GDPR perspective is not lost.

Self-Check

Summary

The EU AI Act and GDPR are cumulative, not alternative. Any AI system processing personal data is subject to both, and compliance with one does not satisfy the other. The seven key overlap areas — transparency, impact assessments, automated decision-making, data quality, individual rights, documentation, and incident reporting — each require coordinated but distinct compliance efforts. The AI Act extends beyond GDPR in areas like AI literacy, conformity assessment, risk classification, and provider-specific obligations. GDPR extends beyond the AI Act in areas like lawful basis, data minimisation, DPO requirements, cross-border transfers, and erasure rights. The most effective approach is a unified compliance framework with clearly separated components — one inventory, one documentation system, one training programme, one incident-response process — that can demonstrate compliance with each regulation independently while avoiding unnecessary duplication.