EU AI Act vs GDPR: How the Two Regulations Interact

The AI Act regulates systems, the GDPR regulates personal data. Where they overlap, what each adds, and why an existing DPIA does not discharge AI Act duties.

Different objects, overlapping scope

The clearest way to hold the two apart is to remember what each one regulates.

• The GDPR regulates the processing of personal data. Its trigger is personal data, whatever technology touches it.
• The AI Act regulates AI systems placed on the EU market or put into service. Its trigger is the system and its intended purpose, whether or not personal data is involved.

An AI system that forecasts machine failure from sensor readings is in scope of the AI Act and outside the GDPR. A spreadsheet of customer records is in scope of the GDPR and outside the AI Act. A CV-screening tool is squarely in both.

The AI Act does not carve anything out of the GDPR. Where both apply, they apply cumulatively.

Side by side

Where the roles do not line up

Controller/processor and provider/deployer are not parallel concepts, and mapping one onto the other is a frequent source of error.

A vendor that builds and sells a recruitment-screening tool is the provider under the AI Act. If the tool runs on the customer's data under the customer's instructions, that same vendor is likely a processor under the GDPR. The customer is the deployer under the AI Act and the controller under the GDPR.

The two axes move independently. Under Article 25, a deployer that substantially modifies a system or puts it on the market under its own name becomes a provider — with no change whatsoever to its GDPR role. See providers vs deployers.

Automated decisions: Article 22 GDPR and Article 14 AI Act

These are often treated as the same requirement. They are not.

GDPR Article 22 gives the data subject a right not to be subject to a decision based solely on automated processing which produces legal or similarly significant effects, subject to exceptions, with safeguards including the right to obtain human intervention. It is a right held by an individual, exercised after the fact.

AI Act Article 14 requires that high-risk systems be designed and developed so that human oversight is effective while in use. It is a design and operating obligation on the provider and deployer, owed before anything goes wrong.

You can satisfy Article 22 with a review process bolted on afterwards. You cannot satisfy Article 14 that way — the oversight capability has to be built into the system and staffed by someone competent to exercise it, which is where AI literacy becomes load-bearing.

DPIA and FRIA

Article 27 requires certain deployers of Annex III high-risk systems — bodies governed by public law, private entities providing public services, and deployers of creditworthiness and life/health insurance pricing systems — to carry out a fundamental rights impact assessment before first use.

The scopes differ:

• A DPIA examines risks to the rights and freedoms of natural persons arising from data processing.
• A FRIA examines the deployment context: the categories of people affected, the specific risks of harm to them, human oversight measures, and the governance arrangements if risks materialise.

Article 27 explicitly says the FRIA complements the DPIA and that the assessment may build on it where one has already been carried out. In practice the efficient path is a single combined exercise with two clearly labelled outputs — not a DPIA relabelled.

Data governance pulls in both directions

Article 10 requires training, validation and testing data for high-risk systems to be relevant, sufficiently representative and, as far as possible, free of errors. Achieving representativeness can require processing more data, and sometimes special-category data, to detect and correct bias.

The Regulation anticipates the tension: Article 10(5) permits processing of special categories of personal data strictly for the purpose of bias detection and correction in high-risk systems, subject to safeguards including technical limits on re-use, pseudonymisation where possible, and deletion once the bias has been corrected. This is a narrow, purpose-bound gateway — not a general licence.

Practical sequencing

1. Inventory once, classify twice. One register of systems, assessed against the GDPR (is personal data processed?) and against Article 6 (is it high-risk?).
2. Map both role pairs per system. Controller/processor and provider/deployer. Record them separately.
3. Combine the assessments, keep the outputs distinct. One workshop, one evidence pack, two documented conclusions.
4. Reuse the GDPR machinery you already have. Records of processing, retention schedules, vendor due diligence and incident response all extend to AI Act duties with modest adaptation.
5. Do not assume GDPR maturity equals AI Act readiness. Technical documentation under Annex IV, logging under Article 12, accuracy and robustness under Article 15 and conformity assessment have no GDPR equivalent at all.

For the convergence picture across the wider EU regulatory stack, see AI Act vs DORA vs NIS2.