AI and GDPR: what's allowed, what isn't, and how to get it right

The short answer: using AI with personal data is allowed under the GDPR — the law doesn't ban the technology, it bans carelessness. You need a lawful basis to process the data, you don't process more than the purpose requires, and you know, demonstrably, where that data goes and who can reach it. Meet those conditions, and nothing stands in the way of an AI application.

What isn't allowed: sending data to a language model "because it works", without thinking about basis, purpose, retention period or transfers outside the EU. That's not specific to AI — it's the same requirement the GDPR has set for every data processing activity since 2018. AI just makes the requirement more visible, because a language model processes data in a new way and is easily deployed without borders.

The GDPR doesn't ban AI — it sets conditions

A common misconception is that the GDPR "gets in the way of AI". That's not true: the law is technology-neutral. It says nothing about language models, embeddings or agents, and everything about how you may process personal data, regardless of the tool. The same principles apply to AI as to a spreadsheet full of customer data: lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, integrity and accountability. AI doesn't change what gets tested — it changes how much attention that test deserves, because a poorly designed system can expose a lot of data at once.

The four questions that make an AI project GDPR-proof

In practice, the trade-off comes down to four questions, in this order.

1. What's the legal basis? Without a lawful basis — consent, contract, legal obligation, legitimate interest — you may not process, no matter how well the application works. For internal use (say, an AI that searches your own documents), legitimate interest usually holds up; for customer data the bar is stricter and depends on what the customer could reasonably expect.

2. Is the processing minimised? Do you send the entire customer file to a model, or only the fragment needed for the answer? Data minimisation isn't a bureaucratic formality but a design choice: the less a system sees, the smaller the risk if something goes wrong.

3. Where does the data go? This is where most AI projects run into trouble. A cloud API outside the EU is an international transfer, with its own requirements (an adequacy decision, standard contractual clauses, or supplementary safeguards following the Schrems II ruling). Run the model on-prem or with an EU-based provider, and this question largely disappears. We cover that trade-off — and when on-prem is worth the investment — in more depth in on-prem AI: when is it worth the investment?.

4. Does human oversight remain? Automated decisions with legal effects on a person (a rejection, a price, a risk score) may not, under the GDPR, be made entirely without human involvement. A human must be able to intervene, and the person affected must be able to get an explanation. For RAG systems that only retrieve information and leave the decision to a human, this point usually doesn't apply — but the moment an agent takes action itself, it does.

The question isn't "is AI allowed under the GDPR", but "which of these four questions haven't I firmly answered yet for this specific project".

Data processing agreement and DPIA: when required?

As soon as an external party (a cloud AI vendor, a hosting provider) processes personal data on your behalf, you're required to sign a data processing agreement. It sets out, among other things, where the data is stored, who can access it, how long it's retained, and what happens in the event of a breach. Request that agreement before putting an AI service into production, not after.

A DPIA — Data Protection Impact Assessment — is required when the processing is likely to result in a high risk to individuals: large-scale processing of special category data (health, criminal data), systematic and extensive profiling, or automated decision-making with real impact. Many AI applications involving customer or employee data fall into this category once scale increases. A DPIA doesn't have to be a heavy process — at its core it's a structured answer to the four questions above, documented before you go live.

Where the EU AI Act adds requirements

The GDPR regulates the data. The EU AI Act regulates the system — even when no personal data is involved. The AI Act classifies AI applications by risk and attaches requirements accordingly: from a ban on certain applications, through strict requirements for "high-risk" systems (think candidate screening, credit scoring, support for judicial decisions), to a light transparency duty for the rest — for example, the obligation to disclose that a user is interacting with an AI system. For most of the RAG and automation applications we build, that transparency duty and the human oversight requirement are what matter most; applications that decide about people (rather than inform people) fall under the stricter requirements. Practical advice: don't treat the GDPR and the AI Act as two separate tracks, but as one combined check — the four questions above cover most of both laws at once.

How to get it right in practice

Most GDPR problems with AI aren't legal puzzles but design choices that weren't made upfront. Four choices that make the difference:

• Document the basis and purpose before the project starts, not as an after-the-fact justification.
• Send only what's needed — a RAG system that retrieves the relevant fragment instead of the full file is, by design, lower risk.
• Know where the data lives — on-prem, EU-hosted, or covered by a data processing agreement that spells it out.
• Keep a human in the decision loop as soon as the system goes beyond surfacing information.

Get these four right, and a GDPR review is nothing to fear — it simply follows from how the system was already built.

Conclusion

AI and the GDPR aren't opposites. The GDPR doesn't ban a technology, it requires an answer to four questions: legal basis, minimisation, where the data lives, and human oversight. Answer those before you build — not after a data protection officer asks — and an AI application involving personal data is just as achievable as one without. Where the data is allowed to run often ties back to the question of when on-prem is worth the investment.