Zero-retention LLM APIs: what GDPR actually requires

What zero data retention means for an LLM API

GDPR does not prescribe one universal zero-retention setting for LLM APIs. A controller must have a lawful basis, specified purposes and proportionate retention periods. Personal data must be deleted or anonymised when no longer needed, unless another legal obligation requires retention. A processor acts on documented instructions under an Article 28 contract. This guide separates those duties from a provider's zero-retention marketing claim.

Zero retention is not the same as no training use. Providers can exclude prompts from training while retaining them for review or until an administrator opts out. Compare those policies separately from a commitment not to retain prompt and response content. Then check the contract's treatment of caches, usage records and logs.

• No training use: the provider may store prompts and outputs, but never feeds them into model training or improvement.
• No storage after the response: the prompt and the completion exist only while the request runs, then they are gone.
• Storage for a bounded review window: the provider keeps prompts for a stated period, for abuse monitoring or debugging, then deletes them.
• Storage until the customer opts out: retention is the default, and the customer has to ask to turn it off.

No-training and limited-retention policies can be useful, but they do not establish zero retention. Ask the provider to define exactly which data it retains and for how long.

Your job as a reviewer is to make the provider answer those three questions in a contract, not on a web page.

What GDPR requires of prompt retention: Articles 4, 5 and 25

GDPR regulates prompt retention through three provisions: storage counts as processing (Art. 4(2)), processing is bound to a purpose and a time limit (Art. 5), and that limit is a default setting (Art. 25(2)). The definition comes first: GDPR counts any operation performed on personal data as processing, "whether or not by automated means", and names storage explicitly alongside collection, recording, use and disclosure (Art. 4(2)). A prompt sitting in a cache, a log line carrying a user ID, a conversation history in your own database: each is processing, each needs a purpose, and each needs a limit on how long it lasts.

Three principles of Art. 5 carry the weight. Art. 5(1)(b), purpose limitation: data is collected for specified, explicit and legitimate purposes and not further processed in a way incompatible with them, and the Commission's plain-language restatement is that an organisation may collect and process personal data only for a specific purpose, indicated to individuals when the data is obtained. Art. 5(1)(c), minimisation: process only what the purpose needs. Art. 5(1)(e), storage limitation: personal data is kept in a form that identifies individuals for no longer than is necessary for those purposes.

Art. 25(2) then makes the storage period a default setting, not a negotiation: the controller must implement appropriate technical and organisational measures for ensuring that, by default, only personal data necessary for each specific purpose is processed, and that the obligation applies expressly to the period of storage and to accessibility. The EDPB's Guidelines 4/2019 on Article 25, final version of 20 October 2020, read this as an engineering duty: once personal data is no longer needed for its purpose, it is deleted or anonymised by default, through deletion procedures built into the processing.

• Storage is processing: Art. 4(2) puts keeping data under the same rules as using it, so a cache or a log needs its own purpose and duration.
• The period is set by default: Art. 25(2) requires the storage limit to be built in, not agreed case by case after a customer complains.
• The purpose is stated to individuals: the Commission's obligations page lists the length of time data will be stored among what people must be told.

Read against these articles, "we keep nothing" is one way to satisfy storage limitation, and the strictest one. Where there is no continuing lawful need for personal data, deletion is required. For a provider that keeps a usage record for billing, Art. 5(1)(e) asks whether the record serves that purpose, carries no more than it needs, and is deleted when the purpose ends. GDPR does not ask whether data is kept; it asks for which purpose, for how long, and whether people were told.

How Article 28 puts prompt retention into the DPA

Article 28 turns a retention promise into a contract term: an LLM API provider that processes prompts on your behalf, under your instructions, is a processor in GDPR terms (Article 4(8)), and Art. 28(3) says what its data processing agreement (DPA) with you must contain. Three of its points decide whether a retention promise is worth anything.

1. Art. 28(3)(a): the processor processes personal data only on the controller's documented instructions. So what the processor keeps, and for how long, belongs in those written instructions.
2. Art. 28(3)(g): at the end of the service, the processor deletes or returns all personal data, at the controller's choice, unless Union or member state law requires keeping it. This is where "zero retention" becomes an exit term, not a marketing line.
3. Art. 28(3)(h): the processor makes available all information needed to demonstrate compliance and allows for and contributes to audits, including inspections. A promise you cannot check is a promise you cannot defend to your own customers.

You do not have to draft these clauses from scratch. The Commission adopted standard contractual clauses for controllers and processors in the EU/EEA by implementing decision on 4 June 2021, under Article 28(7) of the GDPR. They are a ready-made model: they spell out documented instructions, the end-of-service exit and audit rights in contract language. Held against a provider's DPA, they make two providers' promises comparable line by line.

The EDPB adopted the final version of its Guidelines 07/2020 on controllers and processors on 7 July 2021. They add two points worth carrying into review. First, the processor must not go beyond the controller's instructions; a provider that keeps prompts for its own model improvement sets a purpose of its own, and for that processing GDPR treats it as a controller (Article 28(10)), whatever its landing page says. Second, the guidelines expect the agreement to contain concrete detail about the processing, not a restatement of the GDPR. "We follow applicable data protection law" answers nothing. "Prompts are deleted when the response is delivered, and usage records are deleted or returned at exit" does.

How GDPR treats prompt caching, logs and review windows

Under GDPR, a prompt cache, a log and a human review window are all processing, so each needs a purpose, a duration and a limit on who can read it. A prompt cache holds prompt-derived data for a reason, for a time, somewhere. A log line is processing too. A review window for abuse monitoring is retention for a stated purpose, and it lives or dies by that purpose being real, bounded and documented.

Art. 5(1)(e) does not say "keep nothing"; it says keep no longer than the purpose needs. A cache that exists to serve repeated prompt prefixes faster is a purpose. A log that exists to detect abuse is a purpose. The review fails when the purpose is vague ("service improvement"), the duration is unbounded, or the access is wider than the purpose requires.

So the three questions to put to any provider are:

1. Which purpose? Name it per data category: the prompt, the output, the cache, the usage record. "To generate the response" is a purpose; "to improve our services" is a drawer.
2. How long? A duration per category, stated before you sign, not discovered after an incident.
3. Who can read it? Which roles at the provider can see prompt content, under what process, and whether prompt content is readable by anyone at all.

Whether a provider's answers hold up technically is a separate exercise: how to check a cache claim, what to look for in client-side behaviour and what to ask engineering is covered in our article on how to verify a zero-retention claim. Where the relevant AI Act requirements apply to your high-risk system, deployers have separate duties concerning automatically generated logs, which deployer logging under AI Act Article 26 explains; the parties must assess their roles and the applicable requirements separately.

How Lyceum serverless inference handles prompts and outputs

Our serverless inference processes prompts and outputs without storing them and never uses them for training, which makes it a good fit for a strict retention review: each of the three questions gets a short answer, and nobody on our team can open a prompt. Here is the worked answer from our own documents, read 9 October 2026: the trust page shows our request retention policy, and our terms, with the DPA as Annex 1, put it in writing. Zero retention is our own statement, set out in those two documents.

• Prompts and outputs are processed, not stored, and never used for training. Nobody on our team can open them.
• The gateway passes the prompt through in memory and never logs it or writes it to a database.
• Recent prompt prefixes stay in GPU memory until newer requests replace them, which is what makes cached input cheaper. Nothing from the cache is written to disk or a database.
• Each request leaves a usage record: organisation and user, model, token counts, time. It never contains the prompt or the response.
• Usage records and system logs are kept to bill, run and secure the service. The personal data in them is deleted or returned when the customer leaves, unless the law requires keeping it.

The contract carries the same statement. Section 5.2 of our terms says inputs and outputs of the Inference product are only processed to generate the result, not stored beyond what is technically necessary for that purpose, and not used for training, improvement or analysis of any AI model. Section 17.4 makes the Art. 28 GDPR agreement Annex 1 of the terms, so the DPA applies when the terms are accepted, with you as controller and us as processor; no separate signature is needed.

Under that DPA you can instruct in writing, audit with notice, and choose deletion or return when you leave. We notify a personal-data breach immediately, and a new subprocessor is announced in advance with 10 business days to object. This describes serverless inference only; GPU virtual machines, training jobs and storage run under other terms.

Zero retention vs your own duties as controller

Zero retention at the provider leaves the controller's duties with you. As controller you keep the lawful basis for sending personal data to the model, and the transparency duty that goes with it. You keep the conversation history in your own application, which is often the largest store of prompt and output data in the whole chain. And you keep the usage record: it carries the user's identity, so it is personal data in your hands too, with its own purpose and retention question.

Which retention terms to get in writing in the DPA

Five retention terms belong in writing before you sign with any LLM API provider:

1. Retention per data category: prompt, output, cache, usage record, system log, each with its own duration.
2. Cache location and duration: what is cached, in what memory or storage, and until what event clears it.
3. Human access: which roles can read prompt content, under what process, or a statement that nobody can.
4. Where the commitment sits: in the DPA or the terms, not on a web page. A promise that is not in the contract is not a promise.
5. Deletion or return at exit: what happens to every category when you leave, per Art. 28(3)(g).

Our answers are the worked example in the table above: section 5.2 of our terms for what happens to prompts and outputs, section 17.4 for the DPA as Annex 1, and the trust page for the per-request detail. Where subprocessor terms come up, and they will in any serious review, our article on sub-processors in an inference DPA covers what to look for.

• "Zero retention" is not a GDPR term. Map it to purpose limitation (Art. 5(1)(b)), storage limitation (Art. 5(1)(e)) and the Art. 28 processor contract before you compare providers.
• A cache, a log and a review window are all processing. Ask which purpose, how long, who can read it, and get the answers per data category.
• Put the commitment where it binds: retention terms in the DPA or terms, with deletion or return at exit, not on a marketing page.

Take our terms and trust page to your security and legal review, then run the workload on our serverless inference, which suits prompts that carry personal data because we are a sovereign European AI inference provider: open models through one OpenAI-compatible API on GPUs in European data centres, billed per token, with prompts and outputs processed, not stored, and never used for training.