GDPR-compliant AI: what legally sound actually means
A GDPR-compliant AI is not a property of a model but the result of an architecture and contracting decision. Anyone deploying AI in a company that processes personal data, which happens faster than expected, in emails, contracts, support tickets or job applications, must meet the same obligations as for any other data processing. The question "AI and GDPR: are we allowed to do this?" cannot be answered in the abstract, only along the concrete articles of the regulation. This article maps the key obligations and explains why sovereign self-hosting on your own servers is a particularly clean route to genuinely privacy-compliant AI.
One caveat up front: Beyonetix advises and builds along these frameworks but does not provide legal advice. We hold no ISO or BSI certifications and give no compliance or legal guarantee. The points below do not replace a case-by-case legal review; a binding assessment belongs with your data protection officer or a lawyer specialised in data protection law. What we structure here are the technical and organisational decisions that, in practice, co-determine compliance.
Legal basis, data processing agreements and third-country transfers
Every processing of personal data needs a legal basis under Art. 6 GDPR. In practice this is usually legitimate interest (Art. 6(1)(f)) or consent (Art. 6(1)(a)). Legitimate interest requires a documented balancing test against the data subjects' interests, the European Data Protection Board confirmed a three-step test for AI models in its Opinion 28/2024; consent must be freely given, informed and revocable. A blanket "AI clause" buried in your terms does not carry that weight.
As soon as an external AI provider processes data on your behalf, it becomes a processor, and you need a data processing agreement (DPA) under Art. 28. It must govern instruction-binding, confidentiality, sub-processors, technical measures and deletion obligations. Many cloud LLM services do offer a DPA, but the decisive weakness lies elsewhere.
If the provider is in the US or is a US corporation, the third-country transfer rules of Art. 44 ff. apply. Since 2023 there is again an adequacy decision in the form of the EU-US Data Privacy Framework (DPF): transfers to US companies certified under it are, in principle, permitted. But the DPF does not solve the core problem and is legally contested, a challenge (Latombe) was dismissed by the General Court in 2025, with an appeal now pending before the CJEU. More importantly, after the CJEU's Schrems II ruling, even standard contractual clauses alone are insufficient when the recipient is subject to US law: the US CLOUD Act and FISA 702 compel US-controlled providers to hand data to authorities even when the servers sit in Europe, and neither the DPF nor SCCs prevent that access power. This is exactly where many "EU region" offerings fail: the legal possibility of access remains.
Data residency is not sovereignty
This is the most frequently overlooked point: EU data residency does not equal digital sovereignty. A data centre in Frankfurt offers no protection from extraterritorial access if the operator is subject to a third country's law. Sovereignty only exists when neither a foreign parent company nor its home jurisdiction can compel technical or legal access.
The clean route is sovereign self-hosting: open models such as Llama, Mistral, Qwen or Germany's Teuken (built by Fraunhofer/OpenGPT-X) run on your own servers in Germany with vLLM, consolidated behind a LiteLLM gateway. The data never leaves the controlled environment, there is no telemetry to third parties, and no US models by default. The third-country question then disappears structurally rather than through contracts. We describe what this looks like in practice under sovereign AI and AI infrastructure & hosting.
Data minimisation, purpose limitation and no covert training
The principles in Art. 5 apply to AI too: only the data needed for the specific purpose may be processed (data minimisation), and only for that purpose (purpose limitation). A common violation is silently continuing to train models on customer or employee data, without its own legal basis, that is unlawful. With self-hosted models you decide whether, with what and when training or fine-tuning happens; with many public cloud services you have to rely on contractual assurances.
These principles can be reinforced technically, for example through pseudonymisation before processing, strict tenant separation and auditable logging. Anyone applying AI to knowledge assets should keep source and answer cleanly separated, which leads directly to the architecture question.
Data subject rights: why RAG makes deletion easier
Data subjects have the right to access (Art. 15), rectification (Art. 16), erasure (Art. 17) and objection (Art. 21). In a model whose weights have absorbed personal data, deleting individual records cleanly is practically very hard, a central risk of generative systems.
A citation-grounded RAG architecture defuses exactly this. Instead of "baking" knowledge into model weights, the content stays in a controlled, searchable knowledge base; the model retrieves it at runtime and backs every statement with its source. An erasure request is then fulfilled at a single, controlled point, the record is removed from the knowledge base, and the AI can no longer cite it. We run this pattern, combined with PageIndex and a knowledge graph, in production in a large-scale AI archive with millions of documents, and describe it under research & archive systems. Grounded answers also reduce hallucinations and make processing auditable.
TOMs, DPIA, the EU AI Act and a practical checklist
Under Art. 32, technical and organisational measures (TOMs) are mandatory: encryption, access control, tenant separation, logging and a roles-and-permissions concept. For processing likely to result in high risk, and AI often qualifies, Art. 35 requires a data protection impact assessment (DPIA) before go-live. In parallel, the EU AI Act regulates AI systems by risk class and is phasing in over several years; for many applications it adds transparency, documentation and oversight duties. GDPR and the AI Act apply alongside each other, not as alternatives.
A practical checklist to start: define the legal basis per use case; sign a DPA with every provider; assess third-country transfers (DPF certification, SCCs or self-hosting) or avoid them structurally; implement data minimisation and pseudonymisation; train on personal data only with a legal basis; operationalise data subject rights technically (RAG makes deletion easier); document TOMs under Art. 32; run a DPIA where risk is high; classify under the AI Act; and record everything in your processing activities register. The concrete design should be agreed with your data protection officer.
The regulatory frame will tighten rather than loosen over the coming years, with the AI Act phasing in and supervisory authorities scrutinising third-country transfers more closely. Companies that build their AI today on a sovereign, evidenced architecture will less often have to retrofit tomorrow: those who design in data sovereignty, traceability and controlled deletion from the start have already answered the hardest questions to a large degree.