EU AI Act and GDPR: Where the Two Regimes Overlap and Diverge

The regimes are not parallel

They are concurrent but not aligned. The GDPR regulates the processing of personal data; the AI Act regulates AI systems as products and certain practices outright. Neither is a subset of the other, and satisfying one says nothing about the other.

The structural difference is what generates most of the friction. The GDPR attaches obligations to a processing activity and gives rights to the person whose data is processed. The AI Act attaches obligations to a system at points in its lifecycle (placing on the market, putting into service, using) and gives comparatively few individual rights. So the same facts get sliced differently: a model trained on personal data raises GDPR questions about that training and AI Act questions about the resulting system, and the answers do not have to agree.

Mapping the roles

Provider and deployer are AI Act roles; controller and processor are GDPR roles. They are determined by different questions and do not correspond, so both have to be established separately for every system.

A worked example makes the independence obvious. A vendor sells a CV-screening tool to an employer. Under the AI Act the vendor is the provider and the employer the deployer. Under the GDPR the employer is almost certainly the controller, because it determines why candidates are being assessed, and the vendor is likely a processor acting on its instructions. So the party with the heavier AI Act burden has the lighter GDPR one, and vice versa.

Two consequences follow. Contractually, an AI Act allocation of responsibilities does not double as a GDPR Article 28 processor agreement, and vice versa; both are needed. Operationally, if the vendor also uses candidate data to improve its own model, it becomes a controller for that purpose while remaining a processor for the screening, and the AI Act provider role does not change at all.

Protected attributes and bias testing

Testing a model for bias usually requires the protected attributes the GDPR restricts most tightly. Article 10(5) of the AI Act creates room for that where it is strictly necessary, subject to safeguards, and the Omnibus widened the basis further with Article 4a.

The tension is real and well known. Article 9 GDPR prohibits processing special categories of personal data unless an exception applies, and C-184/20 extended the concept: where an organisation can infer or deduce special category data, the data supporting that inference is itself special category data. In a machine-learning context that reaches proxy variables, which is a wide net. Yet you cannot demonstrate that a model does not discriminate on a protected attribute without reference to that attribute.

Article 10(5) resolves this for high-risk providers: they may process special categories to the extent strictly necessary for bias monitoring, detection and correction, with appropriate safeguards. Regulation (EU) 2026/1744 then added Article 4a, providing a legal basis for processing special categories for bias detection across providers and deployers more broadly, again under strict conditions.

DPIA and FRIA are different instruments

A DPIA under Article 35 GDPR and a fundamental rights impact assessment under Article 27 of the AI Act have different triggers, different authors and different scope. Neither discharges the other.

One asymmetry is worth spelling out because it catches deployers. A provider’s conclusion that a system is not high-risk does not remove the deployer’s DPIA obligation. The provider assessed the system against the AI Act; the deployer must assess its own processing against the GDPR, on its own facts, in its own context. Buying a system marked “not high-risk” is not a data protection conclusion.

Automated decisions after SCHUFA

The question of whether generating a score is itself a decision is resolved. In Case C-634/21 (SCHUFA), judgment of 7 December 2023, the Court of Justice held that automated establishment of a probability value about a person’s ability to service a loan is a decision within Article 22(1) GDPR where that value plays a determining role in whether credit is granted.

That matters well beyond credit. The reasoning turns on the determining roleof the output, not on the sector or the label. Any system producing a score that a downstream human decision reliably follows is now squarely within the reasoning: tenant screening, insurance underwriting, candidate ranking, fraud triage. “A human made the final call” is not a sufficient answer where the human predictably defers.

Note how this interacts with the AI Act. Article 14 requires human oversight of high-risk systems, and one of its explicit design goals under Article 14(4)(b) is to counteract over-reliance on output. SCHUFA supplies the reason that goal has teeth: oversight that rubber-stamps does not just fail Article 14, it leaves the decision inside Article 22 GDPR with its own conditions and safeguards to satisfy.

Two regulators, one system

A data protection authority can examine the processing while a market surveillance authority examines the system. Both can fine, on their own grounds, for the same underlying facts.

Article 99(7) of the AI Act directs authorities to take into account fines already imposed on the same operator for the same infringement, but that is expressed across market surveillance authorities, not across regimes. There is no general provision netting a GDPR fine against an AI Act fine.

Practically, this argues for a single evidence base rather than two. The material a DPO assembles for a DPIA and the material an AI governance function assembles for Article 27 and Chapter III overlap substantially: data provenance, purpose, affected populations, testing results, oversight arrangements. Organisations that keep these in separate systems answer the same questions twice and, more damagingly, answer them inconsistently.

Running both at once

The efficient posture is one evidence base, two lenses, not two programmes.

Next: read the oversight requirement that interacts with Article 22 in the human oversight guide, or establish scope with the high-risk classification guide.