So ask every provider two questions, not one. Is training on your data off by default? Is storage of your prompts off by default, with no setting you must change? Then ask which document makes those answers binding for you.
"Which LLM API providers guarantee they do not train on customer data?"
The question usually comes up just before a product sends its first support ticket to a model. A security reviewer then wants the answer in writing. This guide follows one hypothetical ticket through three default setups.
Not training on your data and not storing it are separate promises
Training means a provider uses your data to train or improve its models. Zero data retention (ZDR) means the provider does not store your prompts and outputs after it has answered. Many readers treat the two as one promise. They are switched separately.
Together AI is a clear example, read on 3 November 2026 from its own documentation. Use of customer data for training is a separate opt-in, and it is off by default. But unless an organisation enables ZDR, Together AI stores your prompts and the responses its models return. It may use them for product improvements. ZDR is not enabled by default: an admin turns it on by switching off Prompt storage in the organisation's privacy settings.
So a provider can truthfully say "we don't train on your data" while your prompts sit on its disks. That is why one question is not enough.
We are Lyceum, a sovereign European AI inference provider for open-source models. Inference means running a model to answer your request, and we do it on GPUs in European data centres. Our serverless models run in Paris and Finland. Our legal page puts both parts of our position in writing, and neither depends on a setting.
What zero data retention still keeps
Zero data retention covers the content of a request, not every trace of it. Every provider needs some record to bill you.
With ZDR enabled, Together AI still keeps request metadata for billing and its usage dashboard. That means usage records such as token counts, model IDs and timestamps. Metadata here means data about the request, not its text.
Our gateway is the server that checks your API key before a request reaches a model. It keeps one record per request: a usage record with your organisation and user, the model, token counts and the time. It never contains your prompt or the response. We keep it to bill you, run and secure the service, and plan capacity.
There is one more place your text sits briefly. Prompt caching means a model reuses the work it did on text it has already read, which makes repeated input cheaper. On our GPUs, recent prompt prefixes (the opening part of a prompt) stay in GPU memory as a cache until newer requests replace them. Our legal page lists them as not kept after a request: we never write your prompt to disk or a database.
Ask for the metadata list when you compare policies. A precise list is easier to check than a claim that nothing is kept.
One support ticket through three default setups
Take one hypothetical case. Your support tool sends a single ticket to an LLM API. The ticket contains a customer's name and email address. The table follows it through three default setups, with no settings changed.
| Default setup | During the request | One hour later | What stays |
|---|---|---|---|
| Our serverless API | In memory on our gateway and a GPU | Only the usage record | Organisation, user, model, token counts, time |
| Replicate API (read 3 November 2026) | Inputs, outputs, files and logs kept | Removed after one hour by default | No ticket text after the hour |
| Together AI without ZDR (read 3 November 2026) | Prompt and response stored | Still stored | Ticket text, until someone deletes it or turns off Prompt storage |
Hypothetical ticket. Defaults as each provider's own page states them on 3 November 2026; settings and contracts can change them.
On our side, the usage record is the only trace. Our legal page shows an example: 1,204 input tokens, 896 of them cached, and 312 output tokens. Cached tokens were reused from the cache and billed at the lower cached rate. The record holds those counts. It never holds the ticket.
Notice what the table shows. Training can be off in every row, and the ticket can still exist for an hour, or until someone acts. For a ticket with personal data, how long it exists is part of the risk.
The example does not show three things. It leaves out your own logs and backups. It covers no other products of these providers. And it ignores contract terms negotiated beyond the default.
Where a no-training promise becomes binding
A policy page states a position. A contract makes it binding for you.
Under the GDPR, you are the controller: the party that decides why personal data is processed. The provider that processes it for you is a processor. The processor contract must say that the processor acts only on your documented instructions. The processor may also not engage another processor without your prior written authorisation.
Two GDPR principles explain why the training question matters. Personal data must be collected for specified purposes and not processed further in an incompatible way: that is purpose limitation. It must also be kept in identifiable form no longer than necessary: that is storage limitation. Training a provider's model is a different purpose from answering your request. So write down which purposes the provider may use your data for.
Our contract works this way. Our data processing agreement (DPA) is Annex 1 of our terms, so it applies when you accept them. Under it, you are the controller and we are the processor. A subprocessor is another company that runs part of the service for us. We tell you before we add or replace one, and you can object within 10 business days.
Some subprocessors sit outside the European Economic Area (EEA). Transfers there need a safeguard, and standard contractual clauses (SCCs) are one recognised safeguard. Our legal page says our subprocessors are mainly in the EU and the EEA, and anything outside is covered by such safeguards. Our subprocessor list is available on request by email. For how to read that list, see the DPA question: sub-processors in AI inference.
What a provider's policy page cannot prove
A policy page tells you what a provider says. It does not tell you who else has checked it.
It also reflects one moment. Pages change, and a default that held when you read it may differ next quarter. Note the date you read each page, as we did in the table above.
A policy page cannot show you three things. It cannot show how a provider's systems behave on a given day. It cannot show which settings your own organisation has changed. And it cannot bind the provider to you unless your contract refers to it.
You can test some of this yourself. The checks for whether zero retention holds in practice are in our guide to verifying zero data retention. What the GDPR requires on retention is covered in zero-retention LLM APIs: what the GDPR actually requires.
What to ask for before you send customer data
Ask every provider for the same short set of documents, and keep the answers with the date you received them:
- The training position: is use of your data for training off, and is it off without a setting?
- The storage position: are prompts and outputs stored, for how long, and who can switch that?
- The metadata list: what the provider keeps about each request, and why.
- The DPA, with your documented instructions and the subprocessor rules.
- The technical and organisational measures (TOMs), the security controls the DPA refers to.
- The subprocessor list.
We recommend getting both answers in writing before the first customer record goes out. If a provider says training and storage are both off by default, and its contract says the same, you have your answer. If storage depends on a setting, record who changed it and when. A wider checklist for your first proof of concept is in before an LLM proof of concept: DPA, NDA and the customer data checklist. Our EU sovereign inference platform comparison covers the other criteria.
Before your product sends its first customer record, get the DPA, the TOMs and the subprocessor list your reviewer needs from our legal page.
Frequently asked questions
Does zero data retention mean nothing about my request is kept?
No. The text is not kept, but a record of counts and times usually is. Ask each provider for the exact list of what that record holds.
Do we need to sign a separate DPA with you?
No. Accepting our terms is enough. If your legal team needs changes to the DPA, email us.
If a provider does not train on our data, is that enough for personal data?
No. Storage is a separate question, and the GDPR also asks how long personal data is kept and for which purposes. Check the storage default and get both answers into the processor contract.