GovCompass

EU AI Act and GDPR: how do the two regulations relate?

By GovCompass.ai· Last updated August 2026· Aligned with the consolidated EU AI Act, including the 2026 Omnibus amendments.

The EU AI Act and the GDPR create overlapping but distinct obligations for AI systems that process personal data. They align on data quality, impact assessments, transparency, and individual rights, but differ in scope, accountability roles, and incident-reporting timelines, so the efficient approach is integrated compliance, such as a combined DPIA/FRIA.

Updated: June 2026

Introduction: two frameworks, one compliance reality

For Dutch organizations deploying AI systemsAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs (predictions, content, recommendations or decisions) that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → that process personal data, which is the vast majority of AI systems, the EU AI ActEU AI ActRegulation (EU) 2024/1689, the European Union's law on artificial intelligence. It takes a risk-based approach: prohibited practices, requirements for high-risk AI systems, transparency obligations for specific uses, and a separate regime for general-purpose AI models. Obligations are divided between providers and deployers. See general-purpose AI, conformity assessment.Open full entry → and the GDPRGDPRRegulation (EU) 2016/679, the General Data Protection Regulation, the EU's law on the processing of personal data. It applies to AI wherever personal data enters training, inputs, outputs, or logs, and it operates alongside the EU AI Act rather than being replaced by it. See controller, processor, lawful basis, DPIA.Open full entry → create overlapping obligations. Understanding where they align, where they conflict, and where one framework is stricter than the other is essential for efficient, integrated compliance.

Where do they align?

Data quality

GDPR Art. 5.1(d) requires data accuracy and GDPR Art. 5.1(c) requires data minimizationdata minimizationProcessing only data that is adequate, relevant and necessary. In ML it is implemented through pseudonymization, feature selection, synthetic data and privacy-enhancing techniques.Open full entry →. EU AI Act Art. 26.4 requires deployersdeployerAn organization using an AI system under its own authority in its activities. It carries the operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → to ensure input data quality, completeness, and relevance. These obligations are complementary and can be satisfied by a single, integrated data quality program.

Impact assessments

GDPR Art. 35 requires DPIAsDPIAData Protection Impact Assessment: required before likely-high-risk processing (systematic profiling with significant effects, large-scale special categories, public monitoring); AI development triggers it constantly.Open full entry → for high-riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → processing. EU AI Act Art. 26.9 requires deployers to integrate AI-specific elements into those DPIAs. EU AI Act Art. 27 (public-law bodies, private providersproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → of public services, and all Annex IIIAnnex IIIThe EU AI Act's list of high-risk use-case areas: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice.Open full entry → 5(b)/(c) deployers such as banks and insurers) requires FRIAsFRIAFundamental Rights Impact Assessment: required of public bodies and certain private deployers before using some high-risk AI systems under the EU AI Act.Open full entry → that substantially overlap with DPIA content. Best practice: conduct a single combined DPIA/FRIA that satisfies all three requirements simultaneously.

Transparency

GDPR Arts. 13–14 require transparencytransparencyOpenness about the fact that AI is used and how it operates in general: disclosures, documentation, notices. Pairs with explainability, which addresses individual outcomes.Open full entry → about data processing. EU AI Act Art. 26(11) requires transparency about AI decision-making. These should be addressed in a unified privacyprivacyThe principle that personal data used by or produced through an AI system stays within the purpose and the legal basis it was collected for. Three routes cause most of the trouble: personal data in training material that was never intended for it, model output that reproduces what the model retained, and purpose creep, where a system built for one use drifts into another the original basis never covered. The GDPR governs this in full, and the EU AI Act adds data governance duties for high-risk systems (Article 10). See DPIA, purpose limitation, responsible AI.Open full entry →/AI disclosure framework, typically in your privacy notice and any point-of-interaction disclosures.

Individual rights

GDPR Art. 22 provides rights related to automated decision-makingautomated decision-makingDecisions based solely on automated processing with legal or similarly significant effects. GDPR Article 22 restricts them to three exception grounds, with human-intervention safeguards.Open full entry →. EU AI Act human oversighthuman oversightDesigned-in human ability to monitor, intervene in, override or shut down an AI system. It is meaningful only when the human has authority, information and time to act. One of the seven pillars of responsible AI, and under the EU AI Act a requirement for high-risk AI systems: Article 14 requires that those systems are designed so natural persons can effectively oversee them. Oversight that exists on paper but amounts to confirming in practice does not meet that bar. See override rate, automation bias, high-risk AI system, fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, responsible AI. In the IAPP AIGP body of knowledge, this principle appears as human-centricity, with human oversight as one of its elements.Open full entry → requirements create structural safeguards that support GDPR Art. 22 compliance. An organization with robust EU AI Act human oversight arrangements is well-positioned to satisfy Art. 22 obligations.

Where they differ

Scope

GDPR applies to all processing of personal data. The EU AI Act applies specifically to AI systems, and only to some of them (classified by risk). An AI system that processes no personal data is outside GDPR scope but may still be subject to EU AI Act obligations.

Accountability

GDPR accountabilityaccountabilityThe principle that a named human or organization answers for an AI system's outcomes, through ownership, documentation, audit trails and redress; never the system itself. The EU AI Act attaches obligations to the role rather than the technology, with provider duties in Article 16 and deployer duties in Article 26, supported by technical documentation (Article 11) and record-keeping (Article 12). See provider, deployer, record-keeping, responsible AI.Open full entry → sits with the data controllercontrollerUnder Article 4(7) GDPR, the party that alone or jointly with others determines the purposes and means of the processing of personal data. The controller carries most GDPR obligations, including the duty to bind any processor by contract. In AI projects, the organization that decides why and how personal data is used for training or operation is typically the controller. See processor, GDPR.Open full entry →/processorprocessorUnder Article 4(8) GDPR, the party that processes personal data on behalf of the controller. A processor acts under the controller's documented instructions, bound by an Article 28 contract. AI vendors that run models on customer data are often processors, though the split must be assessed per service. See controller, GDPR.Open full entry →. EU AI Act accountability for high-risk AI sits with the provider and deployer, which may not correspond to the GDPR controller/processor split. Verify that your GDPR data processing agreements with AI vendors also cover EU AI Act compliance commitments.

Incident reporting

GDPR Art. 33 requires breach notification to the supervisory authority within 72 hours. Art. 73 sets explicit deadlines for serious-incident reporting, and these are calendar days, not business days: immediately after the causal link is established and at the latest 15 days after becoming aware (Art. 73(2)); no later than 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure (Art. 73(3)); no later than 10 days in the event of a death (Art. 73(4)). The reporting duty falls on the provider; a deployer's route is Art. 26(5), notify the provider first, and the market surveillance authoritymarket surveillance authorityThe national body that enforces the AI Act in a member state, with powers to investigate, order corrective action and apply penalties.Open full entry → where the provider cannot be reached. AI incidentsAI incidentAny event where an AI system's outputs, actions or data handling caused or plausibly could cause harm, or materially deviated from validated behavior, including harmful outputs from a system that is technically working.Open full entry → involving personal data may trigger both obligations simultaneously, with different timelines and reporting requirements.

Practical integration

  • Extend your GDPR Article 30 register of processing activities to include AI system classification data
  • Update data processing agreements with AI vendors to include EU AI Act compliance obligations
  • Conduct integrated DPIA/FRIA assessments for all high-risk AI systemshigh-risk AI systemAn AI system that falls under the EU AI Act's strictest requirements, following Article 6. There are two routes in: a system that is a product or safety component covered by the Union harmonization legislation in Annex I and subject to third-party conformity assessment, or a system used in one of the areas listed in Annex III, such as employment, education, or access to essential services. Article 6(3) contains a filter: an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, although a system that profiles natural persons is always high-risk. See EU AI Act, Annex III, conformity assessment.Open full entry → processing personal data
  • Establish a unified incident response process that covers both GDPR and EU AI Act reporting obligations
  • Ensure your DPO is involved in AI governance from the outset

Compliance checklist

  1. Have you identified all AI systems that process personal data?
  2. Are GDPR DPIAs and EU AI Act FRIAs/DPIAs integrated for relevant systems?
  3. Do your data processing agreements with AI vendors cover EU AI Act obligations?
  4. Is your Art. 30 processing register updated to reflect AI system data?
  5. Is your incident response process integrated for both GDPR and EU AI Act reporting?
  6. Is the DPO involved in AI governanceAI governanceGovernance extended for AI: the same organizational steering at the highest level, widened to cover what makes AI different (it works in probabilities rather than fixed rules, learns from data, and can act at a speed and scale no human reviewer can match). It inherits the existing governance structure and brings AI inside the disciplines the organization already runs, rather than creating a parallel system in a silo. It operates on two levels, design and execution. See governance, governance design, execution level, responsible AI.Open full entry → and classification decisions?
Continue withPrivacy
Share Share on LinkedIn

More on Privacy

More on Accountability

Agentic AI and governance: why autonomy sharpens the control question

Analysis

Agentic AI does not need a new kind of governance. Autonomy widens the gap between what a system does and who is accountable for it, which makes the existing governance chain, control tracing to risk and forward to evidence, more important, not less. The actions are real and sometimes irreversible, so the stakes on each control rise.

Agentic AI risk assessment: from architecture decisions to control objectives

Analysis

Assessing the risk of an AI agent does not need a separate method. The steps stay the same: recognize the risk, assess how likely and how severe it is for your system, and control it. What changes is the input. An agent runs the process through recorded architecture decisions, about the model, the instruction, retrieved knowledge, tools, orchestration, memory, and autonomy, and each of those decisions, alone or in combination, creates the possibility of harm. The output of the assessment is a set of risk scenarios with a control objective for each.

AI certification: what exists and what it proves

Analysis

AI certification is not one category. Three different objects are assessed, each by a different kind of assessor: a person, an organization's AI management system, and an AI system placed on the EU market. The first two can be certified. The third is subject to a legal conformity assessment, which produces a certificate on one of its two routes and none on the other. Identifying which object a credential covers is the first step to judging what it is worth.

AI governance and enterprise risk management: where they meet

Analysis

AI governance is not a parallel structure that sits beside enterprise risk management. It belongs inside it. The seven pillars of responsible AI are the control structure the organization uses to govern each AI system; enterprise risk management is the machine that carries the residual risk those controls leave behind into the board's risk appetite, the risk register, and the assurance plan. The practical question is not whether to build AI governance or ERM, but how to slot the first into the second so that one accountable structure, not two competing ones, owns AI risk.