EU AI Act vs GDPR — where they overlap for AI systems
The EU AI Act and GDPR overlap significantly for AI systems that process personal data. This piece maps the overlap, explains where the obligations are additive rather than duplicative, and identifies the review artefacts that satisfy both.
Most enterprise AI systems process personal data. That means most enterprise AI systems are subject to both the EU AI Act and GDPR simultaneously. The two frameworks are not redundant — they were designed with different objects in view — but they overlap substantially for AI systems, and understanding where they overlap is necessary for producing evidence that satisfies both.
This piece maps the overlap, explains where the obligations are additive rather than duplicative, and describes how to produce evidence artefacts that serve both frameworks without duplicating work unnecessarily.
Two frameworks, different lenses
GDPR and the EU AI Act approach risk from different perspectives. GDPR is a data protection framework — its concern is the protection of natural persons in relation to the processing of their personal data. Every GDPR obligation flows from this foundation. If a system does not process personal data, GDPR does not apply.
The EU AI Act is an AI safety and fundamental rights framework — its concern is the risks that AI systems pose to health, safety, and fundamental rights, and the obligations necessary to manage those risks before systems are placed on the market. Critically, the AI Act's high-risk obligations apply based on the system's function and use case, not on whether it processes personal data. A high-risk AI system that processes no personal data still requires Article 9 risk management and Annex IV documentation.
Where they overlap
For AI systems that process personal data — which is the majority of high-risk AI systems in Annex III — the two frameworks overlap in six areas: risk management, transparency, data governance, automated decision-making, accuracy, and accountability. The overlap is real but the obligations are not identical.
EU AI Act vs GDPR — obligation overlap by area
| Area | GDPR obligation | EU AI Act obligation | Relationship |
|---|---|---|---|
| Risk management | Data Protection Impact Assessment (DPIA) under Article 35 — required for high-risk personal data processing including systematic profiling and large-scale processing of special categories | Risk management system under Article 9 — required for all high-risk AI systems regardless of personal data | Additive — DPIA addresses data protection risks; Article 9 addresses AI-specific risks to health, safety, and fundamental rights. A high-risk AI system that processes personal data requires both. |
| Transparency | Articles 13–14 — disclosure of processing purposes, legal basis, data subject rights, and automated decision-making logic at data collection | Article 13 — instructions for use covering system capabilities, limitations, performance metrics, and oversight requirements for deployers | Overlapping focus, different audiences — GDPR transparency is owed to data subjects; AI Act transparency is owed to deployers. Both must be satisfied for AI systems that process personal data. |
| Data governance | Article 5 principles — data minimisation, purpose limitation, accuracy, storage limitation, integrity and confidentiality for personal data processing | Article 10 — training, validation, and testing data requirements covering relevance, representativeness, bias examination, and dataset documentation | Overlapping but with different scope — GDPR Article 5 governs all personal data processed by the system; AI Act Article 10 governs the datasets used to develop and train it. |
| Automated decision-making | Article 22 — right not to be subject to solely automated decisions with legal or similarly significant effects; requires human review on request | Article 14 — human oversight measures that allow operators to monitor, interpret, and intervene in AI system outputs | Complementary — GDPR Article 22 is a right data subjects can exercise; AI Act Article 14 is an obligation providers must build in. Together they define a human oversight framework. |
| Accuracy | Article 5(1)(d) — personal data must be accurate and kept up to date; reasonable steps to erase or rectify inaccurate data | Article 15 — AI system must achieve appropriate levels of accuracy, be robust against errors, and maintain performance consistently | Different objects — GDPR accuracy refers to the accuracy of the personal data processed; AI Act accuracy refers to the accuracy of the AI system's outputs. |
| Accountability | Article 5(2) — controller responsible for and must be able to demonstrate compliance with Article 5 principles (accountability principle) | Article 9 and Annex IV — provider must maintain documented risk management system and technical documentation that can be produced to regulatory authorities | Parallel accountability frameworks — both require documented evidence that obligations have been addressed. Evidence produced for one framework often supports the other. |
Risk management: DPIA vs Article 9
GDPR Article 35 requires a Data Protection Impact Assessment (DPIA) for processing that is likely to result in a high risk to natural persons — including systematic profiling, processing of special categories at scale, and automated decision-making with legal effects. The DPIA assesses risks to data subjects from a data protection perspective.
EU AI Act Article 9 requires a risk management system that covers risks to health, safety, and fundamental rights — including but extending beyond data protection. Article 9 is concerned with the AI system's impact on the physical and social world, not only with data processing risks.
The practical relationship is that a DPIA and an Article 9 risk management system are complementary documents for the same system. They share methodology — both require risk identification, evaluation, and mitigation — but they have different scopes. A well-constructed DPIA for an AI system will cover much of the ground that Article 9 requires for data protection risks. But Article 9 extends to risks that have nothing to do with personal data processing: physical safety risks, discrimination risks based on inferred rather than processed characteristics, and risks to fundamental rights beyond data protection.
A DPIA satisfies the data protection risk assessment requirement. It does not satisfy Article 9. The Article 9 risk management system must address all the risks the DPIA covers and more — the DPIA is an input to the Article 9 process, not a substitute for it.
Transparency: GDPR vs Article 13
GDPR Articles 13 and 14 require controllers to provide data subjects with information about how their data is processed — including the purposes of processing, the legal basis, the recipients of the data, and, where relevant, the logic of any automated decision-making and its significance.
EU AI Act Article 13 requires providers to ensure that high-risk AI systems are transparent enough to allow deployers to interpret the system's output and use it appropriately. This transparency is delivered through the instructions for use.
The two transparency obligations differ in their audience. GDPR transparency is owed to data subjects — the individuals whose data is processed. AI Act transparency is owed to deployers — the organisations that put the system into service. Both must be satisfied for AI systems that process personal data, and the information provided under each framework will be different in scope and level of technical detail.
Where they do overlap practically is in the description of the system's decision logic. Both frameworks require that automated decision-making logic is described with sufficient clarity to allow meaningful understanding. The AI Act's instructions for use will contain a more detailed technical description than a GDPR privacy notice — but the underlying system description is the same source, and it should be produced once and adapted for each audience.
Data governance: Article 5 vs Article 10
GDPR Article 5 principles — including data minimisation, purpose limitation, accuracy, and storage limitation — govern all personal data processed by the AI system in operation. These are operational data governance requirements: they apply to the personal data that flows through the system when it is used, not (primarily) to the data used to build it.
EU AI Act Article 10 governs the training, validation, and testing datasets — the data used to develop and train the system. It requires that these datasets are relevant, representative, free of errors to the extent possible, and examined for potential biases.
The two obligations have different primary objects: GDPR Article 5 is primarily about operational data; AI Act Article 10 is about development data. But for systems trained on personal data — which includes many high-risk Annex III systems — both apply to the training dataset simultaneously: GDPR principles govern the processing of personal data in training, and Article 10 governs the data quality and governance of the training dataset itself.
Where they differ fundamentally
The fundamental difference between GDPR and the EU AI Act is that the AI Act addresses risks that have nothing to do with personal data. A high-risk AI system used in critical infrastructure management, for example, may process minimal or no personal data — but it still requires full Article 9 risk management and Annex IV documentation under the AI Act. GDPR would have limited or no application to such a system; the AI Act would apply fully.
Conversely, GDPR applies to any processing of personal data — including simple database lookups, email processing, and operational systems that have no AI component. The AI Act only applies to systems that meet the definition of an AI system. A CRM system that stores and retrieves customer records without any inference or learning component is subject to GDPR but not to the AI Act.
The AI Act's risk framework also addresses risks that GDPR does not: physical safety risks from AI used in vehicles, medical devices, or critical infrastructure; risks to democratic processes from AI used in elections or judicial proceedings; and systemic risks from general-purpose AI models. These risk categories are outside GDPR's scope by design.
Additive obligations — what each adds
For an AI system that processes personal data and falls within a high-risk Annex III category, the obligations under both frameworks are additive:
The EU AI Act adds: design-time risk management under Article 9; Annex IV technical documentation before market placement; data quality and bias examination for training data under Article 10; deployer-facing instructions for use under Article 13; built-in human oversight capability under Article 14; documented performance metrics and adversarial robustness under Article 15.
GDPR adds: lawful basis for processing personal data; data subject rights (access, rectification, erasure, portability, objection); DPIA for high-risk processing; data protection by design and by default; data breach notification; records of processing activities; data processor agreements for third-party AI providers.
An organisation that has completed a thorough GDPR programme for its AI systems has a significant head start on EU AI Act compliance — but there is meaningful ground remaining to cover in the AI Act-specific areas.
Producing evidence that satisfies both
The most efficient approach to dual-framework compliance is to identify the artefacts that satisfy both frameworks simultaneously and to produce them once with sufficient structure to be reused for either purpose.
The highest-value dual-purpose artefacts are:
- System description — used in the DPIA to describe the processing context, and in Annex IV section 1 as the general description. One document serves both if written with sufficient technical depth.
- Data flow documentation — required for GDPR records of processing activities and for AI Act Annex IV data governance section. A data flow diagram that covers both personal data flows and AI inference flows satisfies both requirements.
- Risk register — the DPIA risk register (data protection risks) and the Article 9 risk register (health, safety, fundamental rights risks) can be maintained as a single document with a GDPR/AI Act column, or as linked documents that share the common risks.
- Automated decision-making documentation— the Article 22 logic description (for GDPR) and the Article 14 human oversight documentation (for the AI Act) both require a description of how the system's output influences decisions. A single decision logic document serves both.
For a systematic mapping of security review evidence to both frameworks, see the evidence mapping guide and the EU AI Act inventory hub.
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
Produce evidence that satisfies both frameworks
Drel's AI security review produces artefacts structured for reuse — system description, data flow documentation, and risk register — that support both EU AI Act and GDPR evidence requirements.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.