AI and GDPR: What Changes When You Add an LLM to a Live Product

Updated October 2026

In short

GDPR doesn’t stop you from adding AI to a product that already runs. What changes on release day is the path your users’ data takes: it now goes to a new processor, into new logs, and often into a vector store. Each of those places needs an answer before launch.

Below, one example runs through every step: a support assistant that drafts replies to customer tickets. For each step you get what to check, which article of the law it comes from, and where the current provider terms stand. Treat it as a working map of AI and GDPR for engineering and product leads, which your lawyer can then confirm for your case.

Reading the law right: does GDPR ban AI?

No. GDPR doesn’t mention AI at all. It governs the personal data an AI feature processes, so a prompt follows the same rules as any other query against your users’ records: a lawful basis, a stated purpose, and no more data than the task needs.

The real question is usually narrower: can data you already hold now go to a model? Take the support tickets. You collected them to answer customers, and now a model reads them to draft those answers. Article 5(1)(b) bans further processing “incompatible” with the original purpose, and Article 6(4) gives the test: the link between the two purposes, the context of collection, the nature of the data, the possible consequences, and safeguards such as pseudonymization. Drafting replies to the same tickets sits close to the original purpose. Training a marketing model on them doesn’t, and would need a legal basis of its own.

Using someone else’s model doesn’t hand the question to the vendor. The European Data Protection Board’s Opinion 28/2024 expects a company deploying a model to do due diligence on whether it was developed lawfully. In practice, that means keeping the provider’s documentation on training data in your records.

GDPR has no article about AI. It has articles about your users’ data, and your new feature is one more place that data goes.

Knowing your regulator: who enforces GDPR on an AI feature

If your company has an establishment in the EU, one lead authority in that country handles your cross-border cases. Without one, any national authority where your users live can act on its own. Fines under Article 83(5) reach €20 million or 4% of worldwide annual turnover, whichever is higher.

The same rule applies to your AI provider, and it decides how stable your feature is. In December 2024, the Italian regulator fined OpenAI €15 million. In March 2026, a Rome court annulled the fine without examining the violations. Since February 2024 OpenAI has had a single establishment in Ireland, so its cross-border processing falls under the one-stop-shop mechanism rather than the Italian authority.

Single EU establishment

One lead authority

• OpenAI, in Ireland since 2024
• One-stop-shop applies
• Italian fine annulled

Outside that mechanism

National authorities act

• DeepSeek
• Italy restricted processing
• Berlin targeted transfers

DeepSeek is the other case. It told Italy it doesn’t operate there, and the Garante restricted its processing anyway. Berlin’s authority separately demanded that it stop transfers to China. A feature built on a provider like that can lose its model in one country overnight. So check where a provider is established before you build on it, and when you weigh AI and GDPR risk, don’t skip transparency. Italy fined the maker of the Replika chatbot €5 million in 2025, with Articles 12 and 13 on informing users among the breaches.

Step 1. Mapping the prompt: what personal data reaches the model

A prompt is rarely just what the user typed. It also carries profile fields, conversation history, retrieved documents, and tool results. Minimization means deciding which of those the model actually needs.

Start with a list for each AI feature: every field the code puts into the request, and why it’s there. The support assistant needs the ticket text and the customer’s product plan. It doesn’t need the billing address, even if the support record holds it. Of all the GDPR considerations when developing AI, this one lives in your code: Article 5(1)(c) asks for data “limited to what is necessary,” and the request payload is where that limit sits.

What goes into a prompt

• What the user typed

• Profile fields

• Conversation history

• Retrieved documents

• Tool results

Masking helps. You replace names, emails, and account numbers with tokens before the call and restore them in the answer. It lowers the risk but keeps the data inside GDPR: the EDPB’s 2025 guidelines say pseudonymized data is still personal data. Our AI readiness guide covers who on your side signs off on what can be sent.

Step 2. Checking the provider: training, retention, and where data lives

The three providers most teams start with don’t train on API data by default. OpenAI and Anthropic keep it for up to 30 days, zero retention needs the provider’s approval, and EU-only processing is available from OpenAI and Azure but not from Anthropic’s own API.

Checked October 24, 2026, against OpenAI’s data controls; Anthropic’s pages on training, retention, zero retention, and residency; and Microsoft’s pages on data privacy and deployment types. These terms change often.

The product tier matters as much as the vendor. If your team also uses Claude’s chat product, note that Claude Enterprise keeps data indefinitely unless the organization sets its own retention period, while the API deletes within 30 days.

“We don’t train on your data” and “we don’t store your data” are two different promises. Ask for both, in days.

What to put in the contract

The provider is your processor, so Article 28 applies. It requires processing only on your documented instructions, sub-processors only with your written authorization, and deletion or return of the data when the service ends. Two lines are worth checking by name: a ban on training written into the contract itself, and a retention period in days for every service the data passes through.

Transfers to the US rest on the EU–US Data Privacy Framework or on standard contractual clauses under Article 46. The framework survived its first challenge at the EU General Court on September 3, 2025, and an appeal is pending. Ask whether the provider’s agreement also includes standard contractual clauses, so the transfer has a second footing if the framework falls.

Step 3. Finding your own copies: logs, traces, and the vector store

The provider’s copy is only one of several. Your application logs, tracing tools, caches, evaluation sets, and vector store keep prompts and documents too, and an erasure request has to reach all of them.

Follow one customer through the support assistant. Their tickets sit in your database. To answer questions, the assistant also searches past tickets, so those were split into chunks and stored as embeddings in a vector store. Every call wrote the prompt and the reply into your logs and a tracing tool. A few tickets went into an evaluation set when you tested answer quality. The provider holds the same calls until its retention window ends.

Article 17 says you erase personal data “without undue delay” when, for example, the customer withdraws consent or objects. Article 12(3) gives you one month to tell them what you did. In the old product that meant deleting rows. Now it means finding every copy above.

1. Find

   The user's source documents

2. Delete vectors

   By chunk and vector ID

3. Purge

   Logs, traces, caches

4. Provider

   Check its retention window

5. Reply

   Within one month

The vector store is the hard part. If you never recorded which chunks and vectors came from which ticket, you can only find them by searching the content, and that misses copies. Store the mapping on day one: source document, chunk, vector ID. Give traces and evaluation sets a retention period of their own, like any production data. Then an erasure request is a lookup by customer and document ID.

An erasure request in an AI product is a search across every copy. Make it a lookup before the first one arrives.

Step 4. Deciding on a DPIA and a human in the loop

A Data Protection Impact Assessment, or DPIA, is mandatory when a feature evaluates people through automated processing and the result has legal or similarly significant effects. A feature that drafts text for a person to review rarely meets that bar. One that rejects or ranks people on its own does, and Article 22 adds limits on top.

Article 35(3) names three cases that always need an assessment: “systematic and extensive evaluation of personal aspects” based on automated processing, with decisions that “produce legal effects” or “similarly significantly affect” the person; large-scale processing of special categories of data; and large-scale monitoring of publicly accessible areas. Beyond those, Article 35(1) asks for one whenever new technology is likely to result in high risk.

A DPIA is required for

• 01

  Automated evaluation

  With legal or similar effects

• 02

  Special categories

  Processed on a large scale

• 03

  Public monitoring

  On a large scale

• 04

  New technology

  Likely high risk

Article 22 gives people the right not to be subject to a decision “based solely on automated processing” with such effects. It’s allowed only when necessary for a contract, authorized by law, or based on explicit consent. Even then, people keep at least the right to human intervention, to give their view, and to contest the decision.

What the feature does with the output draws the line. The support assistant drafts a reply, and an agent sends it. If the same model started closing refund requests on its own, you’d need to check whether that decision has a significant effect on the customer. Write down which side each feature is on and who reviews the hard cases.

Step 5. Telling users: the privacy notice and the sub-processor list

Before release, the privacy notice needs the new purpose, its legal basis, the AI provider as a recipient, and any transfer outside the EU.

Article 13 lists what users must be told. For the support assistant, check four lines:

• the purpose, in plain words, such as “to draft replies to your support requests“;
• the legal basis, and the legitimate interest if you rely on one;
• the model provider among recipients or categories of recipients;
• the transfer to a third country and what it relies on.

If you sell to businesses, you’re their processor, and the model provider becomes your sub-processor. As covered in Step 2, Article 28 makes that subject to the customer’s written authorization, so check what your customer contracts say before the feature goes live.

Placing the AI Act: how the new law sits next to GDPR

The AI Act sits on top of GDPR rather than replacing it. Most of it has applied since August 2, 2026, high-risk duties moved to December 2027 and August 2028, and the proposed GDPR changes in the Digital Omnibus aren’t law yet.

Article 2(7) says the act “shall not affect” GDPR, so for GDPR AI regulation means two sets of duties that run side by side. The dates, from the European Commission:

• August 1, 2024: the act entered into force.
• February 2, 2025: prohibited practices and AI literacy duties apply.
• August 2, 2025: rules for general-purpose AI models apply.
• August 2, 2026: most of the act applies, with exceptions.
• December 2, 2027 (Annex III systems) and August 2, 2028 (Annex I products): high-risk obligations, after the AI Omnibus amendment that took effect in July 2026.

The GDPR part of the Digital Omnibus is still in Parliament. Until it passes, GDPR applies unchanged.

Wrapping up: what to settle before the pilot

AI and GDPR questions are cheapest to settle before the first line of integration code. Start with one page for the first feature: the fields that go into the prompt, the provider and its retention in days, every copy you keep, whether a DPIA applies, and the lines for the privacy notice. Then bring in whoever owns privacy on your side.

Our pilots run in four to six weeks on your real data, so these questions come first, on a free call about your task. See how we build AI into products you already run.

FAQ

Is it GDPR compliant to use the OpenAI or Claude API with customer data?

It can be. You need a lawful basis, a processor agreement, a transfer mechanism, and a privacy notice that names the use. Neither provider trains on API data by default, and both keep it for up to 30 days by default, with some exceptions, unless you get zero retention.

Is EU data residency enough for GDPR?

No. Residency answers where data is processed. You still need a lawful basis, minimization, retention limits, and a way to handle erasure in your own systems.

Can I fine-tune a model on my customers’ data?

Only if the new purpose passes the compatibility test of Article 6(4) or has its own legal basis. Under Opinion 28/2024, unlawful training may affect the lawfulness of later use unless the model has been properly anonymized.

What are the penalties for non-compliant AI under GDPR?

Up to €20 million or 4% of worldwide annual turnover for the most serious breaches, and up to €10 million or 2% for others. Regulators can also restrict processing, as Italy did with DeepSeek.