EU AI Act vs GDPR: how the two regulations work together

The first question almost every compliance officer asks about the EU AI Act is: how does this relate to GDPR? The short answer is that they overlap heavily in scope, regulate different things, and apply concurrently. You do not get to choose one. If your AI system processes personal data — which most of them do — both regimes apply, and a sensible programme treats them as a single body of work split across two regulatory tracks.

This article maps the overlap and the divergence so you can plan accordingly. It assumes some prior familiarity with both. Where the AI Act introduces a new concept (provider, deployer, high-risk, Annex III), the overview article is the lighter introduction.

The fundamental difference

The simplest way to think about it: the GDPR regulates the personal data, the AI Act regulates the system.

The GDPR is a data-protection regulation. Its subject matter is personal data: how it is collected, used, stored, shared, and deleted. It binds the controller and processor through a set of principles (lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, accountability), supplemented by specific rules for special categories of data, international transfers, and individual rights.

The AI Act is a product-safety regulation. Its subject matter is the AI system: how it is designed, validated, documented, deployed, monitored, and decommissioned. It binds the provider primarily, with downstream obligations on deployers, importers and distributors. Its principles are about safety, transparency, robustness, human oversight, and accountability for the system as an engineered artefact.

These two perspectives are complementary. The AI Act references the GDPR throughout — Article 10's data-governance obligations explicitly require lawful processing under the GDPR for personal data used in training, validation and testing — but the AI Act does not replicate the GDPR's substantive privacy rules. It assumes those still apply.

The corollary: an AI system can be subject to the AI Act without involving any personal data at all. A predictive-maintenance AI system for industrial machinery, trained entirely on sensor telemetry, is in scope of the AI Act (potentially high-risk via Annex I's machinery regulation) but not in scope of the GDPR. Conversely, processing personal data via a non-AI rule-based system is fully in scope of the GDPR and untouched by the AI Act.

Where the two intersect

The intersection — AI systems that process personal data — is where most of the real complexity lives. Five specific touchpoints:

1. Profiling and 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 concerning them or similarly significantly affects them. Article 22 imposes safeguards on the controller (right to obtain human intervention, to express their point of view, to contest the decision).

The AI Act adds substantial obligations on the system for many of the same use cases. Annex III high-risk areas (employment, essential services, law enforcement, migration) cover the kinds of decisions Article 22 is designed to protect against. A recruitment AI system that automates candidate screening is:

• Subject to Article 22 (the candidate has the right to human intervention).
• High-risk under Annex III area 4 (the provider needs technical documentation, risk management, data governance, human oversight, conformity assessment, registration).

The two obligations stack. The human-oversight obligation under the AI Act (Article 14) helps you meet the human-intervention obligation under Article 22, but does not replace it. You still need to be able to give the data subject a meaningful explanation of the logic involved on request.

2. Lawful basis for training data

Article 10 of the AI Act requires high-risk AI providers to use training, validation and testing datasets that are subject to data-governance and management practices appropriate for their intended purpose, including: examination for possible biases, appropriate measures for prevention and mitigation of bias, identification of relevant data gaps, and (crucially) compliance with Union law including the GDPR.

This bites at the training-data layer. You cannot train a high-risk AI system on personal data that you cannot show was lawfully collected and processed under the GDPR. Lawful basis (Article 6 GDPR), purpose-compatibility, and where relevant special-category processing under Article 9 are not optional. The AI Act does not give you a new legal basis to process personal data for training; it just makes failure to have one under the GDPR also a failure under the AI Act.

A specific case worth flagging: Article 10(5) of the AI Act allows providers of high-risk AI systems to process special categories of personal data to the extent strictly necessary for the purpose of ensuring bias detection and correction, subject to strict conditions. This is a narrow carve-out, not a general permission. It applies only to bias-detection use, requires technical and organisational safeguards (pseudonymisation, access restrictions), and the data cannot be transmitted to third parties. It is one of the few places the AI Act creates a legal basis the GDPR doesn't have on its own.

3. Transparency obligations

Both regimes have transparency provisions, but they target different audiences.

• GDPR Articles 13 and 14 require the controller to inform the data subject about the processing of their personal data, including (where Article 22 applies) the existence of automated decision-making and meaningful information about the logic involved.
• AI Act Article 50 requires that natural persons interacting with an AI system be informed they are interacting with AI (unless obvious), and that AI-generated content (including deepfakes) be labelled.

These obligations are additive. A chatbot deployed on a customer-service website that processes personal data must:

• Tell the user it's an AI system (Article 50 AI Act).
• Tell the data subject about the personal-data processing (Articles 13/14 GDPR).
• Provide a meaningful explanation of any automated decision (Article 22 GDPR + Article 26(11) AI Act for high-risk deployers).

A single, well-drafted "How this works" page can usually satisfy both, but the disclosures are individually mandated.

4. Impact assessments

Two parallel assessments, with different scope:

• DPIA (Data Protection Impact Assessment) — mandatory under GDPR Article 35 for processing likely to result in high risk to rights and freedoms. Focuses on data-protection risks to natural persons.
• FRIA (Fundamental Rights Impact Assessment) — mandatory under AI Act Article 27 for certain deployers of high-risk AI systems (public authorities, public-service deployers, and private deployers of credit-scoring and life/health-insurance pricing systems). Focuses on broader fundamental-rights risks from the AI deployment.

They can share evidence — the same demographic and risk analysis can feed both — but they are not interchangeable. A DPIA assesses personal-data risks; an FRIA assesses fundamental-rights risks (which include privacy but also non-discrimination, dignity, due process, freedom of expression, and others).

Practically, run them as one workstream: a single impact-assessment process that produces two documents with shared appendices.

5. Records and accountability

Both regimes require detailed records.

• GDPR Article 30: record of processing activities (RoPA), maintained by every controller and processor (with limited exemptions for SMEs).
• AI Act Article 11: technical documentation for high-risk AI systems, kept up to date for ten years after the system is placed on the market.

Different artefacts, overlapping content. The RoPA contains processing-activity-level metadata; the AI Act technical documentation contains system-level engineering documentation. A well-organised compliance programme links them: the AI system is a processing activity in the RoPA, and the RoPA entry links to the AI Act technical documentation as the underlying source.

Where they diverge

Three areas where the AI Act adds obligations that have no GDPR equivalent:

Accuracy and robustness. The AI Act requires high-risk systems to declare an accuracy level and to be robust against errors, faults and inconsistencies (Article 15). It requires testing against benchmarks, documentation of expected performance, and continuous monitoring against the declared level. GDPR has an accuracy principle (Article 5(1)(d)) but it is about personal-data accuracy, not model-output accuracy.

Post-market monitoring. The AI Act requires providers to systematically collect and analyse data on the performance of their high-risk AI systems after they are placed on the market (Article 72). GDPR has no equivalent ongoing-performance obligation; it focuses on prior assessment via the DPIA.

Conformity assessment and CE marking. High-risk AI systems must undergo a conformity assessment before being placed on the market and bear a CE mark (Article 43, Article 48). For most Annex III systems this is self-assessment, but for biometric systems and Annex I-integrated systems it requires a notified body. GDPR has nothing equivalent; it is not a pre-market certification regime.

And one area where the GDPR adds obligations the AI Act doesn't:

Data subject rights. The right to access, rectify, erase, restrict, port, and object to processing of personal data are GDPR rights and apply to AI systems just as they apply to anything else. The AI Act does not create new data-subject rights; it does require transparency that helps data subjects exercise their GDPR rights, but the substantive rights themselves come from the GDPR.

How the supervisory architecture works

Member States' Data Protection Authorities (DPAs) supervise the GDPR. The AI Act introduces its own supervisory architecture: national market surveillance authorities (designated by each Member State by August 2025) for AI systems generally, and the European AI Office at the Commission for general-purpose AI models.

The two architectures are explicitly required to cooperate. DPAs play a specific role under the AI Act:

• They are listed as a national competent authority for the purposes of fundamental-rights enforcement in the high-risk AI context.
• They are the supervisory authority for AI systems used for law enforcement, border control, migration and asylum in the area of biometrics (Article 70(7)).
• They must be consulted on the designation of the relevant market surveillance authority.

For most non-public-sector high-risk AI deployments, the market surveillance authority is the first port of call for the AI Act and the DPA is the first port of call for the GDPR. Where the two overlap — say, a complaint about a biased recruitment AI that processes personal data unlawfully — both authorities can investigate and the Act envisages joint action.

Fines

GDPR has two tiers: up to EUR 20 million or 4% of worldwide annual turnover for the most serious breaches, EUR 10 million or 2% for lesser breaches.

The AI Act has three tiers, with higher headline numbers:

• Up to EUR 35 million or 7% of worldwide annual turnover for breaches of the prohibited practices (Article 5).
• Up to EUR 15 million or 3% for most other obligation breaches.
• Up to EUR 7.5 million or 1.5% for supplying incorrect information to authorities.

For a single incident that breaches both regulations, both fines can apply. Member States are instructed to ensure penalties are effective, proportionate and dissuasive, with safeguards against double jeopardy.

See the penalties article for the full breakdown of how the AI Act fines work, including the SMB-specific provisions.

A practical compliance pattern

If you already have a mature GDPR programme, the path to an integrated AI Act programme runs through your existing data-governance and risk-management muscles. The pieces that are new and need building:

1. An AI system inventory. Distinct from the RoPA. Lists every AI system with its intended purpose, risk tier, role (provider/deployer/etc.), and the linked processing activities in the RoPA.
2. A classification process. For each new AI system or material change, run the Article 6 + Annex III + Article 6(3) exemption logic before deployment. Document it. (See the classification guide.)
3. A combined impact-assessment process. DPIA + FRIA in one workstream, two outputs.
4. Technical documentation for high-risk systems. New artefact, system-level, distinct from the RoPA.
5. A post-market monitoring programme. New obligation. GDPR's prior-assessment posture does not extend to it.
6. Conformity assessment for high-risk systems before placing on the market. New obligation. Often (for Annex III) self-assessment, with documentation kept for ten years.
7. AI literacy training. Article 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy of their staff. Many organisations layer this on top of existing GDPR training.

A common reorganisation we see: the GDPR DPO function is extended into a DPO+ role that also coordinates AI Act compliance, with a dedicated AI risk-management workstream that reports into the same governance committee. Whether you make the AI workstream part of the DPO function or stand it up separately depends on volume; for an SMB with five AI systems, integration is usually right. For a large enterprise with fifty, a separate AI risk function makes sense.

The key insight: the work overlaps because the data-protection and AI-system perspectives keep landing on the same artefacts, but the obligations themselves are distinct. Treat them as one programme with two regulatory tracks, not as one or the other.