Methodology
·
6 MIN
GDPR and AI: what is forbidden, what is conditional, and what you control
Under the GDPR, very little about AI is flatly forbidden. Most is conditional, and the conditions are architectural.
LOCATION
European Union
SERIES
AI Governance & Compliance
AUTHOR
Sayan Sinha
PUBLISHED
Under the GDPR, the honest answer to "what can we do with AI" is that very little is flatly forbidden. Most of it is conditional, and the regulator keeps saying so out loud.
The European Data Protection Board's keystone opinion on AI models leans on the phrase "case by case", and the joint EDPB and European Commission guidance on how the GDPR meets the EU AI Act is not expected before early 2026. So the useful question is not "is AI allowed under the GDPR". It is "under which conditions, and which of those conditions do we actually control". This piece maps the few hard limits, the large conditional middle, and the levers a Mittelstand team can pull. It is orientation, not legal advice, so involve your data protection officer before you act.
01.
Start with the few things that are genuinely restricted
A short list of AI uses sits close to a real prohibition under the GDPR. Knowing them first makes the rest easier to reason about.
Solely automated decisions about people. Article 22 restricts decisions with legal or similarly significant effect that are taken without meaningful human involvement. German supervisory authorities read this strictly and expect effective human oversight rather than a rubber stamp (Hogan Lovells).
Special-category data by default. Health, biometric, belief and similar data is prohibited for processing under Article 9 unless a specific exception applies. The EU AI Act adds one narrow opening: Article 10(5) allows such data strictly for detecting and correcting bias in high-risk systems (IAPP).
Models built on unlawfully collected data. The EDPB's Opinion 28/2024, published on 18 December 2024, holds that if a model was developed using personal data processed unlawfully, that can taint the lawfulness of deploying it, unless the model has been duly anonymised (EDPB).
Most AI work sits outside this short list, where the answer is rarely a flat "no". It is a "yes, if".
02.
Most of it is conditional, not forbidden
The large middle of AI work is lawful when you can show the right conditions and document them.
Two conditions do most of the work. The first is a lawful basis. For training and using models on personal data, the EDPB set out a three-step test for relying on legitimate interest, weighing the interest itself, whether the processing is necessary, and a balance against the rights of the people in the data (EDPB). Legitimate interest is available, but it is earned through that test, not assumed.
The second is anonymity, which you do not get to declare. The same opinion holds that a model trained on personal data is not automatically anonymous. It counts as anonymous only when it is very unlikely both to identify the individuals whose data trained it and to have that data extracted through queries, assessed case by case by the supervisory authority (IAPP). The opinion leans on "case by case" so heavily that legal analysts counted the phrase across the text (Ropes & Gray). The practical reading: most AI processing is permitted, on the condition that you can show your basis and your documentation.
03.
The conditions are mostly architectural
The encouraging part is that the conditions you must meet are largely decided by how you build the system, not by who you are.
Keep less, for less time. Data minimisation and purpose limitation apply to the AI-specific places data hides: prompt and system logs, and the vectors inside a RAG store. EDPB guidance points to minimising what is logged, preferring aggregated or pseudonymous identifiers, and short retention (EDPB analysis).
Decide where the data sits, on purpose. Since the Schrems II ruling, sending personal data to a US provider is not settled by signing standard contractual clauses. You have to assess whether those clauses can actually be upheld given US surveillance law, and that responsibility cannot be handed to the vendor (analysis).
This is the practical reason data residency and on-prem deployment are control levers rather than ideology, the same point behind running models you own instead of rent (iiterate).
04.
The GDPR and the EU AI Act are two regimes, not one
It helps to treat data protection and AI regulation as separate obligations that meet, rather than a single rulebook.
The GDPR is a fundamental-rights regime about personal data; the EU AI Act is closer to product-safety law for AI systems (IAPP). One high-risk system can owe duties under both: a Data Protection Impact Assessment under Article 35 of the GDPR, and a Fundamental Rights Impact Assessment under Article 27 of the AI Act, which complements rather than replaces it. The two also interact in awkward ways. Practitioners point out, for instance, that GDPR profiling can pull a system back into scope that an AI Act exemption seemed to release (r/gdpr). Official help is on the way: the EDPB and the European Commission are due to publish joint guidance on the overlap in early 2026 (IAPP).
05.
A working compliance posture for a Mittelstand team
You do not need certainty the regulator has not provided. You need a defensible, documented posture. A practical order:
Map where personal data enters the system: inputs, prompts, logs, training data, and the RAG store.
Choose and write down a lawful basis for each use. If you rely on legitimate interest, run the balancing test rather than assuming it.
Run a DPIA before deploying anything that profiles or decides about people, and keep a human meaningfully in the loop for Article 22 cases.
Minimise and time-box what the system keeps, especially prompt logs and vectors.
Decide data residency deliberately. If personal data would leave the EU, do the transfer assessment, or keep the processing in-EU or on-prem.
Revisit the posture when the EDPB and Commission joint guidance arrives in 2026.
The short version: very little about AI is categorically forbidden under the GDPR, a few things genuinely are, and most of the rest is a documented "yes, if". The conditions that decide it are mostly architectural, which means they are yours to set. The same governance questions surface the moment an internal agent touches client data (iiterate). This remains orientation rather than legal advice, so make your data protection officer the next reader.
