GDPR-Safe LLM Integration for German and EU Clients

German and EU clients ask about GDPR before they ask about features, and they are right to. An LLM integration moves personal data to a third party, often across a border, and often into logs nobody planned for. None of that makes it unlawful. It makes it something you design for from the first commit rather than bolt on before launch.

This is the practical checklist I work through on EU projects. It is an engineer's view, not legal advice: the client's data protection officer or lawyer makes the final call, and my job is to give them a design they can sign off quickly. For the separate question of AI Act obligations, see my post on the EU AI Act deadline for AI builders.

Who is the controller and who is the processor?

In a typical integration the client is the controller and the LLM provider is a processor acting on the client's instructions. That relationship is governed by Article 28 of the GDPR, which says controllers must "use only processors providing sufficient guarantees" and requires a binding contract. According to the text on gdpr-info.eu, that contract must cover, among other things, that the processor:

• acts only on the controller's documented instructions, including for transfers to third countries;
• keeps staff bound by confidentiality and implements the security measures in Article 32;
• engages sub-processors only with the controller's authorisation, and notifies planned changes so the controller can object;
• helps the controller answer data subject requests and meet its obligations under Articles 32 to 36, which include breach handling and impact assessments;
• deletes or returns personal data at the end of the service;
• provides the information needed to demonstrate compliance and allows audits.

In practice, every major model provider and cloud platform publishes a data processing addendum for business customers. The engineering task is to make sure the integration actually uses the account and settings that the addendum covers. A developer's personal API key on a consumer plan is not covered by the client's DPA, however good the code is.

If I am building the integration as a contractor, I am usually a processor too, or a sub-processor, and my own access to production data should be covered in my contract with the client. Keep that chain written down: client, you, cloud platform, model provider.

Where does the data go, and is the transfer lawful?

Data location is the question German clients ask first, and it has two parts: where inference runs, and where anything is stored at rest.

For transfers to the US, the legal position is more settled than it was a few years ago. The European Commission adopted an adequacy decision for the EU-US Data Privacy Framework on 10 July 2023; as Luxembourg's data protection authority explains, personal data can flow to US organisations on the Department of Commerce's list without standard contractual clauses or other transfer tools. On 3 September 2025 the EU General Court refused to annul that decision in a challenge brought by Philippe Latombe, though Baker Botts notes the judgment could be appealed to the Court of Justice. So US transfers to certified providers have a lawful basis today, with some legal uncertainty attached.

Many EU clients still prefer EU processing, either as policy or to avoid that uncertainty. Your options depend on the provider:

• OpenAI introduced European data residency for the API in February 2025. Maginative's report says customers create new projects for it, existing projects cannot be moved, and OpenAI "will not retain any data processed via the API" for those requests.
• Anthropic's first-party API, per its data residency documentation, offers only "global" and "us" as inference geographies, and "us" as the only workspace geography, as of late 2026. For EU-only inference with Claude, the route is a cloud platform's EU regions, where the page notes the inference region is set by the endpoint or inference profile.

I compare the cloud routes in Claude on AWS, Azure or Google Cloud. The short version: if the client already has an EU cloud tenancy with a signed DPA, running the model inside it is usually the fastest path to approval.

How do you minimise personal data before it reaches the model?

Send the model only the fields the task needs, because data minimisation is a principle, not a nice-to-have. Article 5(1)(c) of the GDPR, on gdpr-info.eu, requires personal data to be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed".

For an LLM integration, that turns into concrete engineering choices:

• Select fields, don't dump records. If the model is classifying a support ticket, it needs the ticket text, not the customer's address, date of birth and order history.
• Pseudonymise where you can. Replace names, emails and account numbers with placeholders before the call, keep the mapping on your side, and restore them in the response if needed.
• Strip what the user pasted by accident. Free-text fields collect phone numbers, IBANs and health details. A simple pattern-based redaction pass catches the obvious ones; it will not catch everything, so it complements the other steps rather than replacing them.
• Scope retrieval by permission. In a RAG system, the retriever should only return documents the current user is allowed to see. Otherwise the model becomes a way around your access controls.
• Avoid special category data unless the purpose requires it, and if it does, involve the client's DPO before you build.

Minimisation also makes the system cheaper and faster, because fewer tokens go over the wire; it belongs on any list of ways to cut LLM app costs. It is one of the rare cases where the compliant design is also the efficient one.

What about logging, retention and training?

Your own logs are often the largest GDPR exposure in an LLM system, larger than the provider. Teams log full prompts and responses for debugging, ship them to a third-party observability tool, and keep them forever. Article 5(1)(e) says personal data should be "kept in a form which permits identification of data subjects for no longer than is necessary".

The pattern I default to:

• Log metadata for every call: timestamp, model version, token counts, latency, cost, outcome.
• Log full content only when needed, with redaction applied first, behind access control, and with a short, written retention period.
• If an observability vendor receives prompt content, it is another processor and belongs in the sub-processor list.
• Check the provider's own retention settings, and use zero data retention options where the client requires them and the provider offers them.

On training: confirm in writing that the provider does not train on API inputs under the client's plan. If the project itself involves fine-tuning on personal data, the analysis gets heavier. The European Data Protection Board's Opinion 28/2024, published 18 December 2024, says whether a model is anonymous "should be assessed on a case by case basis", and that legitimate interest can work as a legal basis "only if the processing is shown to be strictly necessary and the balancing of rights is respected." That is a conversation for the client's DPO, before any data is prepared.

A GDPR checklist for LLM integrations

Use this as the working list for the first design review with the client's DPO.

The data subject rights row is the one teams forget. If someone asks for their data to be deleted, can you find every prompt, cached embedding and log line that contains it? Design the storage so the answer is yes.

What should go in the contract with your client?

The contract between you and the client should make the data flow explicit, so nobody discovers a sub-processor during an audit. I make sure it covers:

• a description of the processing: what data, whose, for what purpose, for how long;
• the full chain of sub-processors, including the model provider, the cloud platform and any logging or vector database service;
• the inference and storage regions, and what happens if a provider changes them;
• retention periods for prompts, outputs, embeddings and logs;
• how data subject requests and breaches are handled, and who notifies whom;
• deletion or return of data at the end of the engagement.

Keeping API keys and credentials server-side is part of the security story too; my guide to protecting API keys in AI web apps covers the code side.

Work with me

I build LLM integrations for EU clients with the data flow, regions and logging designed for review by a DPO from the start. See AI integration and AI agent development, browse my work, and book a scoping call.