Zero data retention: what does it actually mean?
The short answer: not that nothing is stored. It means your content is excluded from the abuse monitoring logs — but only on certain endpoints, and only with certain exceptions.
By default — without ZDR — one large provider keeps abuse monitoring logs for up to 30 days, "unless the law requires longer".
With ZDR that logging is skipped. But not everywhere:
| Eligible for ZDR | NOT eligible |
|---|---|
| chat and completion endpoints | assistants and threads |
| embedding | vector store |
| speech transcription and synthesis | file upload |
| image generation (with certain models) | fine-tuning |
| moderation | evaluations, batch runs, video |
Read the right-hand column again: vector store and file upload. If you upload the company's documents in order to build RAG on them, ZDR does not apply to that. This is the single most common misunderstanding in the whole area.
And one exception that stays alive even with ZDR: uploaded images and files go through child safety screening, and if the classifier flags something, the content is retained for human review — even when ZDR is switched on.
At the other large provider, ZDR applies to products used with a business API key but not to consumer plans. And there are four exceptions here as well:
- The results of the safety classifier are retained, ZDR or no ZDR.
- ZDR holds, except where legal compliance or action against abuse warrants otherwise.
- With certain models you have to accept limited retention and review as part of the safety work.
- Under contracts covering healthcare data, some features cannot be used — web search, for example.
At both providers, ZDR is not self-service: it is granted organisation by organisation.
Where does the data physically sit?
This part is surprisingly limited in 2026.
One provider's data residency documentation knows two settings, independent of each other:
| Setting | What it governs | Available values |
|---|---|---|
| Inference location | where the model runs, per request | global or US |
| Workspace location | where data is stored at rest | US — the only value |
So in September 2026 there is no EU workspace on that platform. Inference can be narrowed to the US, but not to the EU. The company's general privacy notice confirms it: "data is stored in the United States."
At the other large provider, EU data residency does exist, but it can only be switched on for a new project — not retroactively for an existing one.
That topic is worked through in the EU data residency post, in detail.
Three documented leaks
1. A caching bug, March 2023. Not an attack, not misuse: a bug in an open-source client library meant that cancelled requests handed users each other's data. What leaked: conversation titles, the first message of new conversations, and subscribers' payment details — name, address, the last four digits of the card number. Affected: 1.2% of subscribers, over nine hours.
This is the most important of the three cases, because it shows that provider risk is neither theoretical nor a matter of bad intent.
2. A database left open, January 2025. A security research group found a database at an AI provider that was reachable without authentication: more than a million log entries, containing conversation histories, API keys and internal secrets. The browser-runnable query interface was wide open.
3. Shared conversations in the search index, summer 2025. In the sharing feature, one checkbox made a conversation discoverable. It was a deliberate, two-step user action — but plenty of people did not grasp the consequence. Rewritten CVs and personal questions turned up in search engines. The feature was withdrawn within hours of becoming public.
(How many conversations got indexed is something no source states — and it must not be quantified.)
And the other side: "it runs on our own machine, so it is safe"
This is the most contradictory figure in the article.
A January 2026 survey — 293 days of scanning, 7.23 million observations — identified 175,108 unique, publicly reachable local model servers in 130 countries. Of those, more than 48% advertised tool-calling capability.
The researchers' assessment: tool-calling capability fundamentally changes the threat model, and they consider it the most serious risk in the ecosystem.
An earlier measurement from September 2025, using a different method, found 1,139 instances without authentication, of which 214 were actively serving models.
The two numbers do not measure the same thing — different tooling, different period, different definition ("unauthenticated, vulnerable" versus "unique host observed"). But the direction is the same.
The lesson: running locally is not in itself a data protection measure. These servers are reachable only from the machine itself by default — one setting opens them to the internet, without authentication. And the person who changes that setting is precisely the one who "wants to reach it from the other machine too". Local running is surveyed in the local AI runners comparison, tool by tool.
The three models, side by side
| Aspect | Shared API (with ZDR) | Dedicated cloud | Local running |
|---|---|---|---|
| Who sees the data | the provider, for abuse monitoring — limited by ZDR | the cloud provider, in your tenant | nobody — if it is set up right |
| Processor agreement | yes | yes, part of the cloud contract | none, because there is no third party |
| Subprocessor chain | yes, with a right to object | yes | none |
| Data residency | limited | region-dependent | full control |
| Human review | possible on flagged data | limited, logged | none |
| The typical real risk | shadow AI: people use it from a consumer account | the wrong deployment type | open port, no authentication |
| Who is liable for the mistake | you | you | you |
The last row is the point: in all three models you are the controller. The provider is the processor. Liability does not transfer because you chose a cloud — and it does not disappear because you run things locally.
The EU legal frame
Under the data protection regulation, the processor acts on the controller's instructions, and their relationship has to be governed by a written contract. The large providers all position themselves as processors for business use — one of them says so explicitly in its contract.
One open question worth knowing about: if the provider stores data and has it reviewed by a human for its own abuse monitoring purposes, is it not a controller for that operation? No authority has settled this question in general terms so far. A hypothesis, not a claim.
The European data protection board's opinion of December 2024 says two things that directly affect a company in the EU:
1. A model is not necessarily anonymous. According to the opinion, models trained on personal data "cannot in all cases be considered anonymous". For anonymity, both the probability of extraction and the probability of recovery through queries have to be negligible.
2. And this is the bigger one: the responsibility extends to you. The opinion devotes a separate scenario to the case where one organisation deploys a model whose training data was collected unlawfully. In that case the deployer also has to carry out an accountability assessment of whether the development involved unlawful processing.
In plain terms: it is not enough to say "the provider takes care of that".
On top of that comes the general accountability rule: compliance has to be demonstrable, and the assessment of the legal basis has to be documented at the point the processing starts.
The checklist
1. CHECK WHICH ENDPOINTS THE ZDR COVERS
Not all of them. File upload and the vector
store are typically out - what RAG runs on.
2. ASK FOR THE DATA RESIDENCY IN WRITING
Where the model RUNS is one question, where
the data is STORED is another. Not the same.
3. READ THE EXCEPTIONS
Safety classifier, legal compliance, child
safety screening: all live ALONGSIDE the ZDR.
4. PROCESSOR AGREEMENT AND SUBPROCESSOR LIST
Who has access along the chain, and how much
notice you get about a new subprocessor.
5. IF YOU RUN LOCALLY: CHECK THE PORT
This is the one step that affects 175 thousand
servers. Five seconds.
6. BAN CONSUMER ACCOUNTS FOR WORK
The biggest real risk of the shared API is not
the provider but shadow AI.
7. DOCUMENT THE LEGAL BASIS BEFORE YOU START
Accountability cannot be retrofitted later.
8. WHAT YOU DO NOT WANT LEAKED, DO NOT PUT IN
Not in the cloud, not in a local system. This
is the one measure that works in every case.
The fifth item is the one with the worst ratio to the time it takes: five seconds, and it is exactly the mistake that occurs on a scale of hundreds of thousands.
Common misconceptions
- "We have ZDR, so nothing is stored." ZDR applies endpoint by endpoint, and it does not extend to file upload or the vector store — precisely what you build RAG on.
- "Running locally is private." A 293-day survey found 175 thousand publicly reachable local model servers, close to half of them with tool-calling capability.
- "With a European provider the data stays in the EU." On one large platform there is no EU workspace as of September 2026, and the notice says data is stored in the United States.
- "If the provider is compliant, so are we." According to the EU opinion, the deployer has to carry out its own accountability assessment.
- "Leaks are a matter of bad intent." The largest documented case was a bug in an open-source library.
- "The biggest risk is the provider." In practice it is usually shadow AI: colleagues uploading company material from their consumer accounts.
What to take away
"Private AI" is not a product category but three separate decisions: where the model runs, where the data is stored, and who has access along the chain. All three are separate questions, and all three need a separate answer in writing.
Two specifics that fall out of most plans: zero data retention does not extend to file upload or the vector store, and under EU law the deployer is also responsible for whether the model's training data was lawful.
And the cheapest check if you run locally: look at what your server binds to. Five seconds — and it is exactly the mistake that is present on the internet in the hundreds of thousands. The risks of agents running on your own machine are what the self-hosted personal agents post is about, and the payback of local running is covered by the why run AI locally piece, with the numbers.