GovCompass
Knowledge base

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

By Michel Venniker· · 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 organisations deploying AI systems that process personal data, which is the vast majority of AI systems, the EU AI Act and the GDPR 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 minimisationdata minimisationProcessing only data that is adequate, relevant and necessary — in ML, implemented through pseudonymisation, feature selection, synthetic data and privacy-enhancing techniques.Open full entry →. EU AI Act Art. 26.4 requires deployers to ensure input data quality, completeness, and relevance. These obligations are complementary and can be satisfied by a single, integrated data quality programme.

Impact assessments

GDPR Art. 35 requires DPIAs for high-risk processing. EU AI Act Art. 26.9 requires deployers to integrate AI-specific elements into those DPIAs. EU AI Act Art. 27 (for public sector) requires FRIAs that substantially overlap with DPIADPIAData 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 → content. Best practice: conduct a single combined DPIA/FRIAFRIAFundamental 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 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.7 requires transparency about AI decision-making. These should be addressed in a unified privacy/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 — restricted by GDPR Article 22 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 — meaningful only when the human has authority, information and time to act.Open full entry → requirements create structural safeguards that support GDPR Art. 22 compliance. An organisation 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 systemAI 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 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.Open full entry → sits with the data controller/processor. EU AI Act accountability for high-risk AI sits with the providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry → and deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry →, 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. EU AI Act Art. 73 requires serious incidentserious incidentAn AI incident causing (or nearly causing) death, serious harm to health, property, fundamental rights or infrastructure — triggering regulatory reporting duties for high-risk systems.Open full entry → reporting "without undue delay" (interpreted as approximately 15 business days for most incidents). AI incidents 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 systems 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 governance and classification decisions?

More on Privacy

Art. 10 EU AI Act: data and data governance for high-risk AI

Reference

Art. 10 requires that the training, validation, and testing data for high-risk AI systems meets quality criteria: relevant, sufficiently representative, and as free of errors and complete as possible for the intended purpose. It also requires documented data governance practices covering collection, preparation, bias examination, and gap mitigation, and it permits the limited processing of special-category data where strictly necessary to detect and correct bias, under safeguards.

Art. 26.4 EU AI Act: input data quality for deployers

Reference

Art. 26.4 requires deployers of high-risk AI to ensure that input data is relevant and sufficiently representative for the system's intended purpose. The deployer is responsible for data quality in operation, even though the provider sets the specifications under Art. 10.

Art. 26.9 EU AI Act: DPIA obligation for high-risk AI

Reference

Art. 26.9 links the EU AI Act to the GDPR: where a data protection impact assessment (DPIA) is required under GDPR Art. 35, deployers of high-risk AI must use the information from the provider's documentation to support that assessment.

Control-level compliance: the EU AI Act as an instrumented system

Analysis

Control-level compliance means satisfying the EU AI Act through engineered, evidenced controls rather than policy documents. The technical articles translate directly into system controls: immutable logs (Art. 12, 19), a kill switch (Art. 14(4)(e)), data masking before the model (Art. 10), configurable block policies (Art. 26), risk scoring and incident reporting within deadline (Art. 9, 73), and workspace isolation with role-based access (Art. 14, 26). Compliance at this level is an instrumented system, not a policy as PDF.

More on Accountability

Art. 10 EU AI Act: data and data governance for high-risk AI

Reference

Art. 10 requires that the training, validation, and testing data for high-risk AI systems meets quality criteria: relevant, sufficiently representative, and as free of errors and complete as possible for the intended purpose. It also requires documented data governance practices covering collection, preparation, bias examination, and gap mitigation, and it permits the limited processing of special-category data where strictly necessary to detect and correct bias, under safeguards.

Art. 12 EU AI Act: record-keeping and logging for high-risk AI

Reference

Art. 12 requires high-risk AI systems to technically allow for the automatic recording of events (logs) over their lifetime. The logging must enable traceability of the system's functioning at a level appropriate to its intended purpose, support post-market monitoring, and help identify situations that may lead to risk or substantial modification. It is a design obligation on the provider that makes the system auditable by construction.

Art. 19 EU AI Act: keeping the automatically generated logs

Reference

Art. 19 requires providers of high-risk AI systems to keep the logs that the system automatically generates (under Art. 12) for as long as they control them, for a period appropriate to the intended purpose and at least six months unless other law requires longer. It is the retention counterpart to the Art. 12 logging capability, and it works alongside the deployer retention duty in Art. 26.6.

Art. 26.1 EU AI Act: following provider instructions as a deployer

Reference

Art. 26.1 requires deployers to use high-risk AI systems strictly in accordance with the provider's instructions for use. This means using the system only for its intended purpose, within its specified technical configuration, and by qualified users, and documenting that compliance. Deviating from the instructions can shift liability entirely to the deployer.