Let’s talk
FREN

The blogTake back control · Episode 3/5

Published on

GDPR, the sequel: you thought you were done with it? Your AI projects bring it right back.

Legal bases, DPIAs, data-subject rights: the field manual for doing AI properly, and proving it.

Series "Take back control", Episode 3/5 · 1. Sovereign AI in Europe · 2. The AI Act explained · 4. Building your first sovereign AI agent · 5. Scaling up

A myth to bury from the start

"GDPR? Sorted. We did the project back in 2018, we've got a DPO, cookie banners, nothing to see here."

If that sentence sounds like what circulates in your organisation, I have bad news: GDPR just moved the goalposts. And its new playing field is yours, your AI projects.

A second myth while we're at it: "GDPR blocks AI innovation in Europe." Regulators themselves reject this. What GDPR, the EU General Data Protection Regulation, and its near-identical twin the UK GDPR, demands is not that you give up on AI. It's that you can answer three questions: what personal data enters your systems, on what legal basis, and what people can say about it.

This is no longer a theoretical topic. Data protection authorities across Europe, France's CNIL, the UK's ICO, and their peers, have put AI, and HR tools in particular, at the top of their enforcement priorities. The fines are real, and they are growing.

Let's take fifteen minutes to make it simple.

The core idea: two texts, two different questions

People routinely confuse GDPR and the AI Act. The distinction fits in one line:

The AI Act regulates what your AI does. GDPR regulates what your AI ingests.

The AI Act (episode 2 of this series) classifies uses by risk level. GDPR, whether the EU version or the UK GDPR, couldn't care less whether your system is "high-risk" in the European sense: the moment a piece of personal data, a name, a CV, a customer email, a conversation, enters your pipeline, it applies. In full. Including during a model's training phase.

The two texts are complementary and apply simultaneously. A CV-screening AI, for example, stacks them: the AI Act's "high-risk" obligations plus GDPR's full arsenal on candidate data.

And here is the point almost everyone misses: if you use a third-party LLM with the personal data of your customers or employees, you are the data controller. Not OpenAI. Not Mistral. You. Responsibility does not get outsourced along with the tool. The CNIL, for one, spells out this allocation of roles (controller, joint controller, processor) across the whole AI chain, and is refining its guidance on the responsibilities of every actor (model designers, hosts, reusers, integrators).

EU vs UK, in practice: the substance is the same on both sides of the Channel. The main difference is the regulator, the ICO in the UK, the relevant national authority in each EU member state (the EDPB coordinating them). The UK has also signalled a slightly more "pro-innovation" posture in places, but do not mistake tone for a loophole: the obligations below hold under both regimes.

Question no. 1: on what grounds are you processing this data?

Every processing of personal data requires a legal basis. GDPR (EU) and UK GDPR each offer six, but for AI, three come up again and again:

  • Consent: clean in theory, often impractical at scale (go ask the 50,000 people in your training set for their agreement).
  • Performance of a contract: covers the service delivered to the customer, but not your derived internal uses.
  • Legitimate interests: the most flexible route, and now the best-mapped.

This is the great contribution of the guidance European regulators have consolidated in recent years: legitimate interests is recognised as the most commonly available legal basis for developing an AI system, including a conversational assistant, an anti-fraud tool, or improving a model from user conversations. Both the CNIL and the ICO have published detailed frameworks pointing the same way.

But "available" does not mean "automatic". The three-part test is the same on both sides:

  1. Purpose (legitimacy): the interest pursued is lawful, specific, real. (And a use banned by the AI Act can never be "legitimate": the two texts lock into each other.)
  2. Necessity: no less intrusive means to reach the same objective.
  3. Balancing: your interests must not override people's rights, with compensating safeguards: enhanced transparency, an effective right to object, pseudonymisation, exclusion of certain data.

And a clear red line: special-category data (health, opinions, ethnic origin, biometrics) is excluded from the legitimate-interests route for training, barring an explicit exception under Article 9. Training a disease-detection model on patient records "because it's useful" does not pass.

One last subtlety that changes everything in practice: the legal basis for training is not necessarily the one for deployment. A single AI project can rest on two different bases depending on the phase. Document both.

Data-subject rights: what your AI must be able to honour

GDPR maintains all individual rights in the face of an AI. In concrete terms, your system must be able to handle:

The right to information. People whose data feeds or passes through your AI must know about it. For recruitment, regulators are explicit: if an algorithm sorts, scores or ranks applications, the information is owed at the moment of application, not after, not on request.

The right to object. If your legal basis is legitimate interests, people can object, and you must be technically able to process that opt-out. "Our model is already trained" is not an answer.

Article 22, the right to a human. No one may be subject to a solely automated decision producing significant effects (loan refusal, application rejection) without being able to request human intervention. It is GDPR's twin of the AI Act's "human oversight", and the same trap: a human who rubber-stamps in bulk without looking does not count.

The right to an explanation. Automated decisions must be explainable in an understandable way. "The model decided" is precisely the sentence an auditor loves to hear... at someone else's company.

The DPIA: the document that will save you (or that you'll be missing)

The Data Protection Impact Assessment (DPIA, the artefact the French text calls an AIPD) is mandatory for AI processing that poses high risk to individuals: HR and recruitment, health, scoring, surveillance. It is THE document a regulator asks for first during an inspection, and its absence on a CV-screening tool is exactly the kind of gap flagged as an enforcement priority.

The good news: a well-run DPIA is not paperwork. It is the exercise that forces you to answer, before the incident, the questions you'll be asked after: what data, what risks, what measures. Organisations that do it seriously often uncover flaws they're delighted to have found themselves.

The five watch-points

1. The third-party LLM fed with customer data. Your teams paste customer emails into a consumer AI assistant? You are the controller of a data transfer you have neither scoped nor documented, potentially outside the EU/UK (back to episode 1: the US Cloud Act offers no protection, Schrems II killed easy transatlantic transfers, and a sovereign, EU/UK-hosted provider simplifies everything). Shadow AI is a GDPR problem before it is a security problem.

2. Unanticipated reuse. Can your customer-service data train your internal LLM? Not so fast: regulators require that people could reasonably have anticipated this use. A customer writing to support does not expect to become a dataset. You'll need a compatibility test, transparency, a right to object.

3. Web scraping without guardrails. Harvesting online data to train a model is not banned, but it is fenced in: define in advance what you're looking for, filter out special-category data, respect sites' technical protections, offer an opt-out mechanism. Unfettered scraping is a time bomb.

4. Forgotten retention periods. Are your 2022 candidates still in your ATS? Guidance typically points to keeping recruitment data no longer than necessary (France's CNIL references two years after last contact as a benchmark). An HR AI wired to a database that is never purged is two breaches for the price of one.

5. Documenting design choices. By practitioners' own account, this is the most critical and most neglected point. Why this model, why this data, why this legal basis: if it isn't written down, in an auditor's eyes it doesn't exist.

The method: graft AI onto your existing GDPR foundation

You don't have to start from scratch, you already have the 2018 foundations. The point is to extend them:

  1. Complete your Record of Processing Activities (RoPA) with every AI use (including those uncovered in the episode 2 inventory: it's the same exercise, share the effort).
  2. Qualify the legal basis of each processing operation, training and deployment separately, three-part test in hand for legitimate interests.
  3. Trigger DPIAs on high-risk uses: HR, scoring, health first.
  4. Update your privacy notices (candidates, customers, employees) and build tooling for the right to object.
  5. Check your DPAs (data processing agreements) with each AI vendor: data location, reuse for training, security guarantees. Under both EU and UK GDPR, an Article 28 processor contract is non-negotiable.

The DPO who ran the GDPR project is your best ally: give them a seat in every AI project, from design onwards, not in the final review committee.

The last word

GDPR is eight years old, and it's ageing well, because it was never a text about cookies. It's a text about a timeless question: who decides what we do with information about people? AI does not make that question obsolete. It makes it urgent.

The organisations that have understood this treat GDPR not as a brake but as a spec sheet: clean, documented, minimised data, which is to say, exactly what a good AI project needs anyway. Here, compliance and quality are the same road.

And the loop closes: sovereignty tells you where to run your AI (episode 1), the AI Act how you're allowed to use it (episode 2), GDPR what you owe the people whose data it processes. One question remains: how do you actually build?

That's episode 4. Get the keyboard out.

📖 In the same series, Episode 1: Sovereign AI in Europe (state of play, roadmap, self-hosting vs API) · Episode 2: The AI Act explained (risk pyramid, obligations, pitfalls) · Episode 4: Building your first sovereign AI agent, step by step · Episode 5: Scaling up (users, models, machines and euros).

Main sources: EU and UK data protection authorities' AI guidance (CNIL, ICO, EDPB, 2024–2026), regulators' guidance on legitimate interests, the EDPB's December 2024 opinion, published 2026 enforcement priorities, and recruitment retention benchmarks. This article popularises: it replaces neither legal advice nor your DPO.

← Back to the blog