GDPR-Compliant AI

With AI, data protection is rarely about the model alone. It is about what happens around it: which data is entered, who processes it, where, and what happens to it afterwards? The same application can be unproblematic or risky depending on the contract and the configuration.

This is a technical overview, not legal advice. What is permitted in a given case is for data protection officers and legal counsel to decide. Our job is to set up architecture, contracts and settings to match what they decide. The obligations under the EU AI Act we cover separately.

What the GDPR requires for AI

The GDPR applies as soon as personal data reaches an AI application, whether as an input, as a document in a knowledge base or as training data. Every processing operation needs a legal basis, such as contract, consent or legitimate interest. In its Opinion 28/2024 the European Data Protection Board (EDPB) stresses that legitimate interest does not apply automatically to AI but has to be weighed case by case. Then there is purpose limitation: data may only be used for the purpose it was collected for, so an assistant that analyzes customer data needs a sound basis for it. Data minimization means passing on only what the task really needs. And the people concerned have to be informed, including about the use of AI. For automated individual decisions, Article 22 adds further requirements.

The German supervisory authorities have set out their expectations in guidance from the Data Protection Conference (DSK), for example on AI and data protection (May 2024), on technical and organizational measures and on RAG systems (October 2025). The guidance is not binding but shows what authorities look at. The Commission’s proposals to amend the GDPR, the so-called Digital Omnibus, have, as far as we know, not been adopted. Until they are, the GDPR applies unchanged.

The contract with the AI vendor

When a company uses a service provider’s AI offering, the provider is usually a processor, and under Article 28 GDPR a data processing agreement is needed. With AI vendors a few points deserve a look. Are inputs and outputs used for training? Many business offerings rule this out by contract, while consumer versions often differ, so the current terms of the plan you actually booked are what counts. Which sub-processors are involved and where are they based? How long are inputs stored, who can see them for abuse monitoring, and where are they stored and where processed?

For transfers to third countries such as the US, the EU-US Data Privacy Framework or standard contractual clauses come into question. The framework rests on an adequacy decision from 2023. The General Court dismissed the challenge to it in September 2025, and as far as we know the Court of Justice has not yet ruled on the appeal. Anyone who wants to reduce the risk of a future change should plan alternatives.

An EU region does not automatically mean EU processing

Large vendors now offer options to limit processing to the EU. The details differ and change often, and the following comes from the vendors’ own documentation. In Microsoft Foundry there are deployment types with processing only in the EU (“Data Zone”). With “Global” types, prompts and responses can instead be processed in any Azure region, while stored data stays in the chosen geography. The EU Data Boundary describes which Microsoft services store and process data in the EU and EFTA.

Google and AWS follow the same principle. An EU endpoint or EU inference profile keeps processing within the EU, while global variants give no guarantee about where processing happens. Whether a model is processed locally in Germany at Google depends on the model. OpenAI offers data residency in Europe to eligible customers, and which products and settings it covers has to be checked case by case. Vendors based in the EU, such as Mistral AI, are an option when headquarters and legal jurisdiction matter, though processing locations and subcontractors need checking in the contract there too.

What matters is not just picking the region but looking at the whole picture: storage location, processing location, support access and contract terms. Anyone who only chooses the storage location overlooks that processing may happen globally. Whether the vendor’s headquarters also matters is a legal assessment.

When no data should leave the house

Anyone who does not want to give data to a model vendor can run open models themselves, in their own infrastructure or with a European hosting provider. There is a growing choice, such as gpt-oss, which is released under Apache 2.0, as well as models from Mistral AI, Qwen and Llama. The license terms differ per model and need checking before use.

The advantage is that the data does not leave your own environment, and logs, updates and access stay in your hands. Against that stand the effort of operations, hardware and securing the setup, and for demanding tasks large cloud models sometimes deliver better results. A mixed approach often makes sense: sensitive data in your own model, general tasks in the cloud service.

Safeguards in operation

Regardless of hosting, a few measures almost always belong. Names and identifiers are replaced or removed before data is passed to a model. Pseudonymized data remains personal data, and true anonymization is demanding and has to be verified. The access concept makes sure an assistant only reaches content that the person asking could also see otherwise. An assistant that searches across all documents would otherwise show content individuals are not allowed to see. Access and actions are logged without storing more personal content than necessary, and retention periods also apply to chat histories, vector databases, logs and caches.

If processing is likely to pose a high risk to the people concerned, Article 35 GDPR requires a data protection impact assessment. For that we supply the technical description, data flows and measures. In day-to-day work the problem is often elsewhere: teams use AI services with private accounts, without a contract and without data protection knowing, and vendors change terms and features without anyone noticing. That is why regular review of the settings belongs in operations, and why documenting data flows and keeping vendors replaceable lets you respond to new legal situations without rebuilding the applications.