EU AI Act vs GDPR – What Governs What?

A common misconception is that the AI Act “replaced” or “extended” GDPR. It didn’t. They’re two separate regulations that happen to meet at the same table the moment you buy an AI system that processes personal data – and they place different requirements on different parties. Here’s how they work together.

Two role systems at once

The first thing that confuses people is that the same project suddenly carries two sets of roles.

GDPR divides the world into controller and processor – who decides over the data and who processes it on someone else’s behalf.

The AI Act divides that same world into provider and deployer – who supplies the AI system and who uses it in their operations.

The point: one and the same AI project carries both role systems at once, and they can point to different parties. Your cloud vendor may be a processor under GDPR but not a provider under the AI Act. Mixing them up leads to the wrong party being assigned the wrong obligation in the contract.

Two documents, one workflow

The regulations also require different assessments, but they overlap enough that running them separately would be wasteful.

• A DPIA (data protection impact assessment) handles the risk to personal data under GDPR.
• A FRIA (fundamental rights impact assessment) is required in certain high-risk cases under the AI Act.

Run them as one combined workflow. They build on the same mapping of what the system does, what data it touches, and who is affected. Sharing the underlying material saves time and reduces the risk that the two documents contradict each other.

The sanctions logic: they stack

Here’s a detail that often gets overlooked: the AI Act’s fines come on top of GDPR’s, not instead of them. The cap per violation is a fixed amount or a share of global turnover, whichever is higher.

The key word is “on top of.” A single AI purchase gone wrong can therefore be hit by both a GDPR sanction for the personal data breach and an AI Act sanction for the systems breach. The two regulations protect different things and therefore fine independently of each other.

A concrete example

Say you buy an AI tool meant to help HR screen candidates. Both regulations activate immediately. GDPR applies because you’re processing personal data about applicants: you need a legal basis, you must handle data subject rights, and you must know where the data is stored. At the same time, recruitment is a use case the AI Act treats strictly, which adds requirements around risk classification, transparency to candidates, and human oversight of the decisions.

Now the role split becomes concrete. Under GDPR, you’re the controller and the tool vendor is the processor. Under the AI Act, you’re the deployer and whoever built the tool is the provider. You need a DPIA for the data protection risk and, since the case touches fundamental rights, likely a FRIA too – and it would be wasteful to do them separately when both start from the same mapping of what the tool does. One purchase, two regulations, double roles, and double documents. That’s the regulations working together in practice.

The most common pitfall here is letting one role split overshadow the other. A team used to GDPR routinely appoints a controller and a processor and assumes the roles are now settled. But the AI Act’s provider and deployer is a separate question, and they need to be identified separately in the contract. Another common mistake is assuming a tool bought “as productivity support” escapes the high-risk requirements – it’s the use case, not the label, that decides. If the tool screens candidates, it’s a sensitive use case regardless of how it was marketed.

Which regulation governs which question

When you’re in the middle of an AI purchase wondering “who decides this?”, a simple breakdown helps:

It’s simplified, but it brings order to everyday work. The data questions go to the GDPR track, the model and use questions go to the AI Act track, and the documentation stays together since the requirements overlap.

Navigating both regulations at once is demanding, especially in a high-risk case where the roles need to be sorted out in the contract. If you want a sounding board for how a specific AI purchase shakes out, read about our AI services or get in touch. This page is decision support, not legal advice.