Skip to main content
SecureAI Guard

GDPR and LLM data handling

How the GDPR applies when personal data goes into a prompt — lawful basis, transfers, DPIAs, retention and subject rights, for teams deploying LLM applications.

Published ·5 min read·SecureAI Guard
GDPR
data protection
PII
compliance

The moment personal data enters a prompt, it has been disclosed to a processor — usually one in another country, often one that logs the request, sometimes one whose default terms permit training on it. Nothing about that sentence is novel law. It is ordinary Regulation (EU) 2016/679, applied to a data flow most organisations created without a transfer assessment because it arrived as an API key rather than as a procurement.

That is the whole of the LLM data protection problem, and it is why the useful questions are the boring ones: what is your lawful basis, who is the processor, where does it run, how long is it kept, and can you honour an erasure request against a prompt log.

Source and currency. Checked on 12 August 2026. This page is a summary for engineers and security teams and is not legal advice — the primary sources are linked at the end, and your DPO is the person who decides.

The five questions a data protection review will ask

1. What is your lawful basis, and does it survive the transfer?

Article 6 requires one. For internal productivity tooling it is commonly legitimate interests under Article 6(1)(f), which obliges you to run and record the three-part test — purpose, necessity, and a balance against the data subject's rights and reasonable expectations. The clause that bites for LLM use is necessity: if the same outcome is achievable with the personal data removed, sending it is not necessary, and the balancing test that assumed you had to send it does not hold.

Article 5(1)(c) data minimisation is the operative principle and the one most directly satisfiable in a technical control: send the minimum personal data the task requires. Redacting or tokenising identifiers before the call is the data-minimisation argument made concrete rather than asserted. See PII redaction for LLMs for how that is done without breaking the answer.

If special category data under Article 9 — health, biometrics, political opinions, trade union membership — can reach a prompt, the bar rises sharply and "legitimate interests" is not available. For a health or HR assistant this is the design constraint, not a footnote.

2. Who is the processor, and is there an Article 28 agreement?

Every model provider you call is a processor or a sub-processor of personal data in the prompt. Article 28 requires a written contract with defined subject matter, duration, nature and purpose, categories of data and obligations — including that the processor acts only on documented instructions and does not engage a further processor without authorisation.

Two things to check that teams routinely miss:

  • Whether the provider's default terms permit training on your inputs. Some do by default on consumer or self-serve tiers and do not on enterprise tiers. A processor training its own model on your data is processing for its own purposes, which is a controller act, not a processor one.
  • Whether the provider's retention window is compatible with your own. A thirty-day abuse-monitoring log at the provider is a thirty-day retention of personal data you told your data subjects you kept for seven days.

3. Where does it run, and under what transfer mechanism?

Chapter V governs transfers outside the EEA. Most model endpoints are outside it unless a region has been chosen deliberately, and "our provider is global" is not a transfer mechanism. You need adequacy, Standard Contractual Clauses, or another Chapter V instrument, plus a transfer impact assessment where SCCs are the basis.

Where residency is a hard requirement that no region selection satisfies — the data cannot leave the network at all — the answer is an architecture where the prompt never leaves, not a stronger contract. See on-premises deployment.

4. Do you need a DPIA?

Article 35 requires one where processing is likely to result in a high risk to individuals, and expressly where there is systematic and extensive automated evaluation producing legal or similarly significant effects. An LLM triaging job applications, scoring credit, prioritising benefit claims or making decisions about access to services is squarely in that territory, and Article 22 rights around solely automated decision-making apply on top.

An internal document-search assistant usually is not. Assess per application, and re-assess when the application's job changes — which for an agentic system whose tool set grows sprint by sprint is more often than an annual cycle will catch.

5. Can you honour a subject access or erasure request?

This is the question that finds the gap, because the answer depends on parts of the system nobody assigned to data protection:

  • Prompt and completion logs. These are personal data records if a prompt contained personal data, and they are held in your application, in your observability stack, and possibly at the provider. Classify them as such or you cannot search them.
  • Retrieval indexes. An embedding derived from a document containing personal data is not anonymous — embeddings are partially recoverable, which is the point of embedding inversion. Deleting the source document without re-indexing leaves the personal data in the index.
  • Anything fine-tuned on the data. Erasure from a training set does not remove the influence from the weights, and there is no accepted mechanism that does at production scale. Treat any personal data used for fine-tuning as effectively irreversible and decide accordingly, before rather than after.

The EDPB addressed the related question of when an AI model may itself be considered anonymous, along with the use of legitimate interest as a basis for model development, in Opinion 28/2024, adopted 18 December 2024.

Where the answer is architecture, not paperwork

The technical controls that carry the most weight in a data protection review of an LLM application are unglamorous, and there are three:

  1. Detect and remove personal data before the call. This is Article 5(1)(c) implemented rather than argued. Tokenisation is the version that survives contact with the product, because it restores the value in the completion so the answer still reads correctly.
  2. Enforce the asking user's permissions on retrieval. A vector index has no access control of its own; distance does not know who is asking. Enforcing entitlements at query time is what stops a RAG answer quoting a record the user has no right to see. See RAG security.
  3. Record what left, and to whom. Every argument above — lawful basis, transfers, retention, subject rights — depends on knowing what personal data actually reached which provider. Without a control on the request path, the honest answer to a regulator is that you do not know.

For the full inventory of ways personal data escapes an LLM application, see how LLM applications leak sensitive data.

Primary sources