EU AI Act vs GDPR: what is different and what overlaps

Two regimes, two different questions

GDPR asks: is this processing of personal data lawful, fair, transparent, minimised, secure and accountable, and can individuals exercise their rights over it? The EU AI Act asks a product-safety question: is this AI system safe, sufficiently accurate and robust, adequately documented, properly overseen by humans, and does it respect fundamental rights before it reaches the market? The subject matter overlaps constantly, but the questions are genuinely different, and a compliance programme that answers only one of them will fail the other.

The structural consequence is that AI Act duties can bite where GDPR is silent. An AI system predicting machinery failure processes no personal data, so GDPR has nothing to say — yet if it is a safety component of a regulated product it may be high-risk under the AI Act, requiring a risk management system, technical documentation, logging and conformity assessment. Conversely a simple spreadsheet of employee data engages GDPR fully and the AI Act not at all.

• GDPR trigger: processing of personal data.
• AI Act trigger: placing on the market or using an AI system, by risk tier.
• GDPR remedy focus: individual rights and supervisory authority enforcement.
• AI Act remedy focus: market access, conformity and post-market surveillance.

Where the two genuinely overlap

The dense overlap sits around automated decision-making about people. GDPR Article 22 restricts solely automated decisions producing legal or similarly significant effects, and requires meaningful information about the logic involved. The AI Act classifies many of those same use cases — recruitment, creditworthiness, education access, essential services, employment management — as high-risk and demands human oversight, transparency, accuracy targets and record-keeping. Address them once, in one register, or you will write two contradictory descriptions of the same system.

Data governance is the second overlap. GDPR Articles 5 and 25 require accuracy, minimisation and data protection by design; AI Act Article 10 requires training, validation and testing data sets to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete. Documenting data provenance and quality once satisfies both. Transparency is the third: GDPR privacy notices and AI Act disclosure duties (telling people they are interacting with AI, labelling synthetic content) can be delivered through the same customer-facing surfaces.

• Automated decisions about people — GDPR Art. 22 and AI Act high-risk duties.
• Data quality and provenance — GDPR Art. 5 and AI Act Art. 10.
• Transparency — privacy notices and AI disclosure obligations.
• Security — GDPR Art. 32 and AI Act accuracy, robustness and cybersecurity duties.
• Records — records of processing and AI technical documentation and logs.

Where they diverge and catch people out

Roles diverge first. A firm may be a GDPR processor but an AI Act provider, inheriting documentation duties its data processing agreement never contemplated. Second, the AI Act imposes ex-ante obligations: conformity assessment and technical documentation must exist before the system is placed on the market, whereas GDPR accountability is largely continuous and self-assessed. Third, the AI Act contains outright prohibitions — social scoring, certain biometric categorisation, emotion inference in workplaces and education — which no lawful basis or consent can rescue.

Finally, the assessment instruments differ in purpose. A DPIA is about risks to data subjects arising from processing. A fundamental rights impact assessment covers a wider set of rights and affected groups, including people who are not data subjects at all. Treating one as a rename of the other produces an assessment that satisfies neither reviewer.

• Different role taxonomies: controller/processor vs provider/deployer/importer/distributor.
• Ex-ante conformity vs continuous accountability.
• Absolute prohibitions with no consent-based escape.
• Wider affected-population scope in fundamental rights assessments.

One programme, two sets of artefacts

The efficient approach is a single intake for every AI system that branches into both regimes. Register the system once with its owner, purpose, data, affected people and decision impact. From that record, screen for GDPR (is personal data processed, is a DPIA required) and for the AI Act (prohibited, high-risk, transparency-only, or minimal, and what role do we hold). The same interview then produces the DPIA, the AI Act risk-management record and the technical documentation skeleton.

ISO 42001 is the practical management-system wrapper for all of this because its clauses mirror the AI Act's requirements — risk assessment, impact assessment, data governance, transparency, human oversight, monitoring — while sitting alongside ISO 27001 and your existing privacy programme. Firms that adopt it stop treating AI governance as a separate legal project and start running it as an operational process with owners, dates and evidence.

• One AI inventory feeding both screenings.
• One assessment interview producing a DPIA and an AI risk record.
• Shared mitigations tracked as actions with named owners and dates.
• Shared evidence vault for logs, test results and approvals.
• Annual review cycle covering both regimes at once.

Frequently asked questions