← Back to Insights

ARTICLE 13 · 13 MIN READ · Published 14 Oct 2026

By Melika Mohsenipour · Engineer, Seawolf Intelligent Computing

GDPR-Compliant AI Development: What European Companies Must Check Before Sending Data to an LLM

Most guides to AI compliance are written for US healthcare and talk about HIPAA. If your users are in the EU or the UK, the rules that bind you are GDPR and, since 2026, parts of the EU AI Act. This guide explains where GDPR actually applies in an LLM project, what the 2026 timeline really requires after the Digital Omnibus, the seven checks to run before any personal data leaves your systems, and the technical controls that turn a compliance policy into something an engineer can build.

We are engineers, not lawyers, and nothing here is legal advice. What we can offer is the view from the build side: the questions a data protection officer will ask, translated into decisions about architecture, vendors, and code. Every regulatory claim links to its source so your legal team can check it.

Where GDPR Actually Applies in an LLM Project

GDPR does not mention AI, and it does not need to. It applies to any processing of personal data, and an LLM feature processes personal data at more points than most teams expect.

• Every prompt is a processing operation. If a support ticket, a CV, an invoice, or a chat message containing a name, an email, or an account number goes into a prompt, you are processing personal data and need a legal basis for it.
• Every model provider is a processor. When your product calls an external API, the provider processes personal data on your behalf. That makes them a processor under Article 28, and you need a data processing agreement with them before the first request.
• Outputs and logs are personal data too. A generated summary of a customer complaint still contains the customer's details. So does the request log your monitoring stack keeps, and the cached response your app stores to save tokens.
• Training is a separate, harder case. Fine-tuning a model on customer data is processing for a new purpose and needs its own legal basis. The European Data Protection Board's Opinion 28/2024 set a high bar: a model only counts as anonymous if the chance of extracting training data about an individual, directly or through queries, is negligible, assessed case by case.

The practical consequence is that "we only use AI for internal tooling" is not an exemption. An internal assistant that reads HR records or customer emails is processing personal data at scale, and the same obligations apply.

The 2026 Timeline: What Applies Now and What Moved to 2027

There was a lot of confusion this year about the EU AI Act's deadlines, and much of the advice published in early 2026 is now out of date. Here is the position as of October 2026.

Two things follow. First, the high-risk delay is not a reason to pause: the obligations that apply to most products today are GDPR and Article 50, and both are enforceable now. Second, enforcement under GDPR has already reached AI. In December 2024 the Italian authority fined OpenAI €15 million for training without an adequate legal basis, failing to notify a breach, and falling short on transparency. GDPR fines run up to €20 million or 4% of global turnover; AI Act fines for prohibited practices reach €35 million or 7%. The numbers matter less than the pattern: regulators are looking at legal basis and transparency first, which is exactly where most LLM projects are weakest.

Seven Checks Before Personal Data Leaves Your Systems

These are the questions we work through with a client before the first API call. Each one maps to a specific GDPR requirement and a specific engineering decision.

1. What is the legal basis, and does it survive the EDPB test?

For most product features the basis is contract performance or legitimate interest. The EDPB opinion is clear that legitimate interest cannot be the default for AI: you must document the three-step test (a legitimate purpose, necessity, and a balance against the data subject's rights and reasonable expectations). A customer who emailed support reasonably expects a human or a tool to read the email. They may not reasonably expect it to be used to fine-tune a model. Write the basis down per use case, not per system.

2. Is there a signed data processing agreement with the model provider?

Every major provider offers one, but it is not always on by default, and consumer terms are not a DPA. Check that the agreement covers the specific service you are calling, names sub-processors, and sets retention. If you are routing through an aggregator or an agent framework that calls several models, you need a DPA chain that covers all of them.

3. Where is the data stored, and where is it processed?

These are different guarantees and vendors often blur them. "EU data residency" usually means storage at rest in the EU. It does not necessarily mean inference runs in the EU. OpenAI's European data residency offers in-region processing for eligible API projects, Azure OpenAI has an EU Data Zone, and Mistral and AWS Bedrock have EU options. Ask the vendor the two questions separately and get the answer in writing.

4. How long does the provider keep prompts and outputs?

Default API terms often include a retention window of around 30 days for abuse monitoring. Zero-data-retention is available from several providers but is typically approval-gated rather than self-serve. Decide which you need based on the data: for prompts containing special-category data, such as health information, retention at the provider should be zero.

5. Are international transfers covered?

If the provider or any sub-processor is in the United States, the transfer needs a mechanism. The EU-US Data Privacy Framework is the usual one, and the EU General Court upheld it in September 2025 against the Latombe challenge, though further appeals remain possible. Confirm the provider is certified under it, or that standard contractual clauses are in place. For providers in countries with no adequacy decision, SCCs plus a transfer impact assessment are required, and this includes development partners, which we return to below.

6. Does the feature need a Data Protection Impact Assessment?

Article 35 requires a DPIA for processing likely to result in high risk, and most authorities treat novel technology applied to personal data at scale as a trigger. For an LLM feature that reads customer or employee data, assume you need one. It is also the document that forces the architecture decisions in this article to be made deliberately rather than by default.

7. Does the AI make or materially shape decisions about people?

Article 22 restricts decisions based solely on automated processing that have legal or similarly significant effects. Summarising a CV is fine. Rejecting the candidate because the model scored them low is not, unless a human genuinely reviews it and the exceptions apply. Design the human step in from the start; retrofitting it is expensive, and the AI Act's high-risk list overlaps heavily with Article 22 cases.

Self-Hosted, EU-Region API, or Global API?

Once the seven checks are answered, the deployment choice usually makes itself. This is how the three options compare on the dimensions that matter for GDPR.

A common and sensible pattern is a hybrid: redact or pseudonymise before the call, send ordinary data to an EU-region API, and route anything special-category to a self-hosted model. The routing decision is a few lines of code; the hard part is the classification step that decides which path a request takes, and that step needs to be tested like any other security control.

Technical Controls That Make Compliance Real

A policy document does not stop a prompt from leaking an email address. These are the controls we build into LLM features, and each one answers a question a regulator or a DPO will eventually ask.

• Minimise before the prompt leaves. Strip or pseudonymise identifiers that the model does not need to do its job. A summarisation task rarely needs the customer's real name; a placeholder works and can be re-inserted after the response. This single step removes most of the risk from the global-API option.
• Log every call with purpose, basis, and data category. Not the prompt contents by default, but the metadata: which feature made the call, under which legal basis, with which classification. This is what lets you answer a subject access request or an audit without reconstructing history by hand.
• Enforce retention in your own stack, not just the provider's. Cached responses, vector stores built from customer documents, and evaluation datasets all hold personal data. Give each a retention policy and a deletion job, and make deletion propagate: when a customer is erased from your database, their chunks must leave the vector index too.
• Apply access control inside retrieval. In a retrieval-augmented system, the retriever must filter by the requesting user's permissions before the model ever sees a document. A model that can be talked into revealing another tenant's data is a breach, however good the prompt is.
• Test for leakage as part of release. Add adversarial cases to your evaluation set: prompts that try to extract other users' data, system prompts, or training examples. The techniques in our article on AI agents in production apply directly, and the same evals that catch quality regressions catch privacy regressions.
• Meet Article 50 in the interface. Tell users they are talking to an AI, label generated content, and make the human escalation path obvious. This is a product requirement now, not a nice-to-have.

Working With a Development Partner Outside the EU

Since Seawolf is based in Armenia, we should address this directly. Armenia has no EU adequacy decision, so if a development partner there, or in India, Ukraine, or anywhere else without adequacy, has access to personal data of EU residents, that access is an international transfer and needs standard contractual clauses and a transfer impact assessment. The same applies to a partner in the United States that is not DPF-certified.

The cleaner answer, and the one we recommend to our own clients, is to design the engagement so the development team does not need production personal data at all. Build and test against synthetic or pseudonymised datasets, keep production access with the client's own staff or an EU-based operations role, and give the external team access to logs and metrics rather than raw records. This is good engineering practice regardless of geography: it keeps the blast radius of a mistake small and makes the DPIA far simpler to write. Where production access is genuinely unavoidable, scope it to named individuals, time-limit it, and log it. Our guide to choosing a software development company in Armenia covers the broader due-diligence questions; this one is specific to data.

The Pre-Build Checklist

Before the first production API call, you should be able to tick every line below. If you cannot, the gap is the first thing to fix.

• Legal basis documented per use case, with the legitimate-interest balancing test written down where that is the basis.
• Signed DPA with every model provider and sub-processor in the chain, covering the exact services used.
• Storage region and processing region confirmed in writing, with zero retention where the data warrants it.
• Transfer mechanism in place for every non-EU party, including your development partner.
• DPIA completed, or a documented reason why one is not required.
• Human review designed in wherever the output affects a decision about a person.
• Minimisation, retention, and deletion implemented in code, with retrieval access control and leakage tests in the release pipeline.
• AI disclosure and content labelling live in the interface, as Article 50 requires.

Conclusion

GDPR-compliant AI development is less about the model and more about the plumbing around it: where data goes, who can see it, how long it stays, and whether anyone can explain why. The 2026 picture is clearer than it was six months ago. High-risk obligations under the AI Act moved to December 2027, but GDPR and the Article 50 transparency duties apply to most LLM features today, and regulators have shown they will enforce them.

The seven checks and the controls above are what we run before any Seawolf project touches EU personal data, including our own products. If you are scoping an AI feature for European users and want the compliance questions answered in the architecture rather than after launch, send us a brief. If you would rather handle it in-house, the checklist is yours to use.

Frequently Asked Questions

Does GDPR apply if we only use AI for internal tools?

Yes. GDPR applies to any processing of personal data, regardless of whether the user is a customer or an employee. An internal assistant that reads HR records, support tickets, or customer emails is processing personal data and needs a legal basis, a processing agreement with the model provider, and appropriate security measures.

Did the EU AI Act high-risk deadline really move to 2027?

Yes. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved the compliance date for Annex III high-risk systems from 2 August 2026 to 2 December 2027. The Article 50 transparency obligations were not delayed and apply from 2 August 2026, with generative systems already on the market given until 2 December 2026 to add machine-readable marking.

Is sending prompts to a US-based LLM provider allowed under GDPR?

It can be, provided there is a data processing agreement and a valid transfer mechanism. The EU-US Data Privacy Framework was upheld by the EU General Court in September 2025, so transfers to certified providers remain lawful, though further challenges are possible. Many teams reduce the exposure by using an EU-region endpoint or by minimising personal data before the request leaves their systems.

Can we use legitimate interest as the legal basis for an AI feature?

Sometimes, but not by default. The European Data Protection Board's Opinion 28/2024 states that legitimate interest must be justified through the three-step test for each AI use case: a legitimate purpose, necessity, and a balance against the individual's rights and reasonable expectations. Using customer data to answer that customer's own query is far easier to justify than using it to train a model.

Does a development partner outside the EU need access to our personal data?

Usually not, and it is better if they do not. Build and test on synthetic or pseudonymised data, keep production access with EU-based staff, and give the external team metrics and logs rather than raw records. Where access is unavoidable, it is an international transfer that needs standard contractual clauses and a transfer impact assessment, scoped to named people and time-limited.