Zero Data Retention: Using Cloud AI Without Leaving Your Data Behind

Zero Data Retention: Using Cloud AI Without Leaving Your Data Behind

The starting point is a dilemma every company knows in 2026. The most capable models — Kimi K3 with 2.81 trillion parameters, DeepSeek V4-Pro with 1.65 trillion — run exclusively on datacenter GPUs. Whoever wants to use them sends their prompts across the network. And at exactly that moment the question arises that decides the success and the legality of the entire AI deployment: what happens to my data after the answer comes back?

The industry’s answer is called Zero Data Retention (ZDR) — and it is as important as it is misunderstood. Some dismiss it as a marketing phrase, others treat it as a guarantee it legally cannot be. Both are wrong. This article dissects what ZDR technically means, what the data flow actually looks like, which risks ZDR does not solve — and how a company verifiably checks that a vendor keeps its promise. At the end: a comparison of the major providers based on their own documentation — and why Ollama Cloud occupies a special position in it.

What Zero Data Retention means — and what it does not

Zero Data Retention is a contractual and technical commitment: the provider does not persistently store customer data. Prompts and responses are kept only as long as the request technically requires — in RAM, while the model generates the token stream. Then the memory is released. Nothing lands in a database, nothing in a training corpus, nothing in an archive.

The distinction from two weaker tiers matters, because ZDR is constantly confused with them:

These tiers are not theory — they appear verbatim in the providers’ documentation. OpenAI retains API data by default for up to 30 days for abuse monitoring; ZDR is available only on request, after enablement, and only for listed endpoints. Google logs prompt and response data from the paid Gemini API “for a limited time” solely to enforce its usage policies. Anthropic deletes API data by default “within 30 days” and offers ZDR as a separate agreement that must be activated per organization. The takeaway: almost every major provider requires you to actively ask for ZDR — at Ollama Cloud it is the documented default for every request.

Default retention of prompt/response data per provider documentation (days). Ollama Cloud: transient, “not stored beyond the time required to fulfill the request”. OpenAI/Anthropic: up to 30 days abuse monitoring; Gemini (paid): limited time, policy enforcement only.
Default retention of prompt/response data per provider documentation (days). Ollama Cloud: transient, “not stored beyond the time required to fulfill the request”. OpenAI/Anthropic: up to 30 days abuse monitoring; Gemini (paid): limited time, policy enforcement only.

How it works technically: the life of a request

To understand why ZDR is credible at all, you have to see what technically happens during a cloud inference. The diagram shows the life cycle of a prompt — and the exact point where the policies diverge:

Life cycle of an AI request: the difference between the standard policy (30-day abuse log, then deletion) and Zero Retention (no log, no persistence).
Life cycle of an AI request: the difference between the standard policy (30-day abuse log, then deletion) and Zero Retention (no log, no persistence).

Three technical properties make Zero Retention possible in the first place:

OpenAI documents one hard technical consequence for ZDR customers: the store parameter of Chat Completions and Responses is forcibly treated as false — the API simply refuses to persist your data even if the request asks for it. That is the difference between “we promise it” and “the architecture does not allow it”. Hard guarantees like this are exactly what a due-diligence process should probe for.

Why frontier models only run in the cloud anyway

One objection remains: if local AI is so data-safe, why go to the cloud at all? The answer is physics, not convenience. The chart shows the scale of the current model generation:

Model sizes 2026 (parameters in billions): frontier models sit two orders of magnitude above what workstation hardware can load. Sources: ollama.com/library — model pages kimi-k3 (2.81T), deepseek-v4-pro (1.65T), qwen3.5 (397B), gpt-oss (120B/20B).
Model sizes 2026 (parameters in billions): frontier models sit two orders of magnitude above what workstation hardware can load. Sources: ollama.com/library — model pages kimi-k3 (2.81T), deepseek-v4-pro (1.65T), qwen3.5 (397B), gpt-oss (120B/20B).

Kimi K3 with 2.81 trillion parameters (MoE, 16 of 896 experts active, 1 million token context) categorically does not fit into the VRAM of a workstation — even high-end hardware with 16, 24, or 48 GB fails at the sheer model size before a single token is generated. Frontier inference is a datacenter matter. The strategic question is therefore not “cloud or local?” but “cloud — under which retention conditions?”

Here the loop closes back to the local world: for the model class up to ~14B parameters, local inference remains the most data-safe option in existence — the data never leaves the premises. Ollama covers both worlds with the same interface: ollama run llama3.2:8b runs locally, ollama run kimi-k3:cloud goes to the cloud. The reference architecture:

Hybrid reference architecture: local models for sensitive data, cloud frontier models with Zero Retention for everything that no longer fits locally.
Hybrid reference architecture: local models for sensitive data, cloud frontier models with Zero Retention for everything that no longer fits locally.

The risks Zero Retention does not solve

Whoever sells ZDR as “100% data security” makes a false assurance — that plain-language warning belongs in every procurement process. ZDR addresses exclusively the persistence of content after processing. These risk areas remain fully intact:

Zero Retention turns the cloud AI into a transient pass-through — not into a data vault and not into a risk bubble. Those who know the residual risks can manage them; those who deny them are managed by them.

Operating it safely: the rules that hold up in practice

Five operating rules follow from the risk picture — all proven in practice:

  1. Classify data before choosing tools. Red (personal data, trade secrets, regulatory), yellow (internal, usable anonymized), green (public). For red data the rule is: local or nothing; everything else may go to the cloud under ZDR conditions.
  2. Central gateway access. All AI calls run through a managed instance that logs metadata (who, when, which model — never prompt content), manages keys, and applies DLP filters. That eliminates shadow IT and turns the metadata gap into an audit trail.
  3. Contractual safeguards. A DPA under Art. 28 GDPR, a written ZDR addendum defining “customer content”, a subprocessor list with notification duties on changes, and deletion confirmation as part of the contract.
  4. Train prompt hygiene. No customer IDs, no names, no secrets in the prompt unless the task demands it. Pseudonymization remains the strongest lever — it reduces risk before transmission.
  5. Take the hybrid architecture seriously. Not everything needs frontier. Up to ~14B parameters, inference runs locally with zero data transfer; the cloud (with ZDR) is the exception for long contexts and heavy tasks — not the default.

Verify, don’t trust: the due-diligence plan for companies

The core procurement question is: how do you establish that a vendor actually honors Zero Retention? The honest answer first: an absolute, mathematical proof from the outside is impossible. What is possible — and what professional buyers of cloud services have done for years — is a combination of contract, architecture evidence, audit, and spot technical checks. Combining these four levels produces a risk that is auditable and defensible. The process:

Due-diligence process for cloud AI with a Zero-Retention claim: check documents, close contracts, demand audits, pilot with classified data — with hard abort criteria.
Due-diligence process for cloud AI with a Zero-Retention claim: check documents, close contracts, demand audits, pilot with classified data — with hard abort criteria.

Level 1 — documents and contract. The retention policy must be in the data processing agreement, not just the blog. Ask for: a written ZDR addendum, the subprocessor list (who sees data at all), deletion periods per data category, and notification duties on policy changes. OpenAI and Anthropic enable ZDR exclusively via contract and organization-level enablement — a vendor that refuses this has given its answer.

Level 2 — architecture evidence. Demand the technical details: is prompt content written into application state (Files API, Threads, session stores, history)? Under ZDR the answer must be “no”, or those features must be locked — exactly as OpenAI documents for its ZDR endpoints. Treat with suspicion any vendor promising ZDR while leaving stateful features with server-side history enabled.

Level 3 — independent audits. SOC 2 Type II, ISO/IEC 27001, ISO/IEC 42001 (AI management), and for German public-sector contexts BSI C5 are the usual attestations. They do not prove the individual deletion, but they check whether the claimed processes exist and run. A vendor without current audits and with only marketing-language assurances fails Level 3.

Level 4 — technical spot checks in operation. Canary tests with uniquely marked but fictional sensitive data (e.g. invented customer numbers with watermarks), support requests referring to “lost” prompts (an honest vendor cannot restore them — and must be able to say so), inspection of the logs the vendor can export, an annual re-audit of policy versions. That is not 100% certainty — but it is the only combination that turns a GDPR-relevant trust problem into a documented residual risk.

Whoever writes “100% data security” into a requirement gets the same answer from every serious company’s legal departments: it does not exist — not locally (a compromised laptop is a full-blown data leak), not in the cloud. Realistic and achievable is a state in which no persistence path for prompt content exists at the provider, contractually assured, architecturally enforced, and verifiable by audit. That is exactly what the process above delivers, and exactly the standard vendors should be measured against.

Provider comparison: who documents retention how

All statements follow the providers’ linked primary sources (as of September 2026 — policies change, check the current version before every contract):

The structural difference: at OpenAI, Google, Anthropic, and Azure, ZDR (or its approximation) is a negotiated matter with carve-outs — at Ollama Cloud it is the documented product default. Add the fully local foundation: same CLI, same API, and for sensitive workloads everything stays on your own machine. For teams that need both worlds, that is an unusually clean starting position.

What does the cloud option actually cost? The Ollama model prices (base window, per 1M output tokens) span this range:

Ollama Cloud output prices per 1M tokens (USD, base window). Source: ollama.com/pricing (model table, September 2026). Peak prices (12:00–18:00 UTC, Mon–Fri) are e.g. double for deepseek-v4-pro.
Ollama Cloud output prices per 1M tokens (USD, base window). Source: ollama.com/pricing (model table, September 2026). Peak prices (12:00–18:00 UTC, Mon–Fri) are e.g. double for deepseek-v4-pro.

The pricing structure is simple: a Free plan with starter credits, Pro at $20/month with $60 usage credits, Max at $100/month with $300 credits and 10 concurrent requests, Team at $500/month with a shared $1,000 in credits. No service fees on token prices, local usage unlimited. For a pilot project the entry point sits below a typical SaaS budget — and the retention policy does not depend on the plan tier.

The legal frame: GDPR, the AI Act, and the limits of contracts

For European companies, ZDR is not a nice-to-have — it is often the precondition for GDPR-compliant use: Art. 5(1)(c) and (e) GDPR demand data minimization and storage limitation — a vendor keeping prompts for 30 days needs a legal basis for that and must defend it in the balancing test. For processing on behalf of a controller, a DPA under Art. 28 is mandatory; with US vendors, Standard Contractual Clauses (SCCs) come on top for the transfer. The EU AI Act stacks transparency and risk duties above it, depending on the use case. The sober reading: Zero Retention is the shortest path to “storage limitation fulfilled” — but it replaces neither a legal basis, nor a risk assessment, nor a DPA.

Trend: retention becomes a procurement criterion

Three developments reinforce each other. First: frontier models get bigger, not smaller — local coverage stays capped at the 14B class, and the cloud share of enterprise AI grows. Second: regulation tightens — the EU AI Act and rising documentation and auditability requirements turn “we trust the vendor” into a liability risk. Third: the vendors themselves discover retention as a competitive advantage — Ollama markets Zero Retention as a selling point, Azure expands CMK and EU processing, OpenAI advertises ZDR for frontier models. The direction is clear: whoever procures cloud AI in 2026 negotiates retention conditions — not features.

The bottom line: verifiable trust instead of blind faith

Zero Data Retention is no longer a marketing word — it is a checkable product and contract posture with real engineering behind it. And it is not a guarantee: residual risks from transmission, metadata, abuse carve-outs, and the supply chain remain. The right posture is therefore sober:

  1. Classify your data — red data stays local; everything else may go to the cloud under ZDR.
  2. Read the vendors’ policy documents — and get the retention clause into the contract, not just the marketing page.
  3. Demand audits and architectural evidence (SOC 2, ISO 27001/42001, BSI C5; store=false enforcement, no application state for content).
  4. Verify with canary data and log exports — and repeat annually.
  5. Think hybrid: local where it suffices; cloud with ZDR where frontier is needed. That is exactly what Ollama Cloud is built for — local AI and a zero-retention cloud under one interface, no training on your data, no content logging, and the same expectations placed on partners.
Nobody seriously promises 100% data security. What can be promised and verified: there is no path by which your prompts become data assets at the provider.

Sources