Zero Data Retention Policies With LLM Providers and What They Actually Cover

Zero data retention sounds like a single, uniform guarantee. It isn't. Every major LLM provider that offers ZDR draws the line somewhere short of total coverage, excluding account metadata, safety logs, certain endpoints, or entire model families from the promise. Knowing exactly where each provider's line sits, and what sits outside it, is what separates a compliance posture that holds up under audit from one that only looks solid until someone asks the right question.

What zero data retention means at the infrastructure level

Zero data retention is a statement about architecture, not a checkbox in a settings panel. Under a real ZDR agreement, a prompt, its context window, and the model's completion exist only in memory, and only while the request is being processed. None of it gets written to a log file, a database, or a training set. Once the session ends, there is nothing left to retrieve, since nothing was ever stored.

All three of those controls assume the data already exists somewhere. ZDR removes that assumption. It stops the data from landing anywhere persistent to begin with. There's no window of exposure for a breach, a subpoena, or an internal access violation to exploit.

Regulated industries face the practical stakes first. A healthcare agent pulling patient history into a retrieval pipeline is subject to HIPAA. For all three, the question is whether the data was ever retained at all, not whether the provider promises to delete it eventually. Tools that enforce ZDR at the gateway layer, Concentrate among them, add a structural backstop here: when sensitive data is stopped before it ever reaches a provider's infrastructure, it doesn't matter which endpoint or model a request eventually gets routed to.

The structural distinction between training exclusion, data minimisation, and ZDR

Three separate controls get bundled together in most conversations about LLM data safety, and conflating them is the single most common mistake enterprise teams make when they try to document their compliance posture.

Training exclusion is a promise about use, not about storage. Data minimisation, the principle codified in GDPR Article 5, is a step stricter: it requires collecting only what's needed and deleting it on a schedule, but it still permits temporary retention before that scheduled deletion happens. ZDR is stricter again. It permits no persistent retention at any point, which is exactly the kind of architecture GDPR Article 25's Data Protection by Design requirement is built to favor. The distinction between minimisation and ZDR isn't academic. A regulator evaluating Article 25 compliance will treat "we delete data on a schedule" and "we never wrote it down" as materially different answers.

A team that disabled the training opt-in checkbox in its OpenAI account settings may think the data question is closed. Training exclusion and ZDR are negotiated separately and verified separately. Confirming one tells a compliance team nothing about the other.

Where each major provider's ZDR coverage stops

Every provider that offers ZDR draws a boundary around it, and those boundaries follow a recognizable pattern: the core text-completion endpoint is usually covered, while agents, file storage, code execution, and billing metadata usually are not.

OpenAI requires prior approval before granting ZDR access, along with acceptance of additional contractual requirements. Standard pay-as-you-go, Plus, and Team tiers don't have access to it. Even for approved accounts, the /v1/agents endpoint is explicitly excluded from ZDR eligibility, and the Agents API only supports data residency in a single region, so any workload that needs ZDR or needs to keep processing within another region has to stay on separate, ZDR-eligible endpoints. The clearest demonstration of how real this architectural line is came out of litigation: a federal magistrate judge ordered OpenAI to preserve output logs as part of the New York Times copyright case, and API customers under a ZDR agreement were excluded from that preservation order, because their data had never been stored to begin with. A court order can only reach data that exists.

Anthropic retains User Safety classifier results even under a signed ZDR agreement so it can enforce its own Usage Policy, so if a conversation triggers a policy violation, that session's data can be held for up to two years. Code execution containers and MCP connector traffic fall outside ZDR: code execution data is retained for a limited window, and MCP connector traffic follows Anthropic's standard retention policy. As of June 9, 2026, certain newer Claude models require 30-day retention and carry no ZDR eligibility.

Mistral's standard tier holds API data for 30 rolling days so it can support abuse monitoring. Even where ZDR applies, it only covers stateless API endpoints: agents, batch files, conversations, libraries, the Files endpoint, Vibe Work, and Chat are all explicitly carved out. Billing metadata is retained regardless of ZDR status.

AWS Bedrock and Google Vertex AI have the cleanest default posture of the major providers, not every provider's fine print is equally restrictive.

Why the metadata and safety-log exceptions matter

Metadata retention and safety-log exceptions are built into the architecture of nearly every ZDR offering on the market, and the data categories they leave exposed, metadata, safety logs, agent session state, are frequently the exact categories a regulator or opposing counsel goes looking for first.

Metadata feels harmless in isolation: a timestamp, a token count, a model identifier. Research on LLM privacy risk has made the broader point directly: the privacy threat surface of these systems reaches well past training-data extraction, into inference-time context leakage and the ability to infer sensitive attributes from metadata that looks innocuous on its own. Retaining the shape of a conversation can leak almost as much as retaining the words.

Anthropic's safety classifier retention is the sharpest version of this problem. A conversation that looked, from the customer's side, like an ordinary support exchange becomes a two-year data liability sitting outside the protection the company thought it had negotiated.

Agent and multi-turn session state carries the same risk, just at a larger scale. It's the fastest-growing category of enterprise LLM use, and it's also almost universally excluded from ZDR across every provider covered here. Companies build their most complex, highest-stakes automation on the same workloads that get the least retention protection. That mismatch is the sharpest live risk in the entire ZDR landscape right now.

How provider policy changes can void a compliance posture built on ZDR alone

A signed ZDR agreement describes a provider's policy at the moment it was signed. It isn't a permanent architectural commitment, and a compliance posture that treats it as one can be invalidated by a policy change that happens between contract renewal cycles, often without the customer noticing until an audit forces the question.

Anthropic's own history shows how fast consumer-tier terms can move. In September 2025, Anthropic reversed an earlier, more privacy-restrictive stance: users who opted in through a forced-choice prompt began having their conversations used for training, with retention for those users extended to five years. Users who opted out kept the prior 30-day deletion policy. Enterprise customers under Commercial Terms kept their existing protections through that change, but the reversal is still instructive: consumer-tier precedent can shift in a single policy update, and no enterprise tier is guaranteed immunity from a future version of the same shift.

The New York Times preservation order showed a second way a compliance posture can get overridden from outside. A court order reached into OpenAI's non-ZDR retention architecture and forced it to preserve data that would otherwise have followed the standard retention schedule. ZDR-covered data was excluded from that particular order only because it had never been stored. Whether a future order could ever reach data inside a true ZDR architecture isn't settled by that case, and it isn't settled law generally.

Model upgrades add a third vector that's easy to miss. A ZDR agreement signed against one generation of models doesn't automatically extend to every model a provider releases afterward. Newer OpenAI models have removed the in-memory-only option that earlier models supported, so a routine model upgrade can quietly downgrade retention protection without any contract amendment ever crossing a compliance team's desk. What looks like a fixed, audited agreement is really a moving target that needs active monitoring, contract management, and a defined review cycle, not a document filed away after signing.

What a defensible compliance posture requires beyond the provider agreement

A signed ZDR agreement is necessary, but it's not enough on its own. The gaps cataloged above, agent endpoints, safety logs, billing metadata, mid-cycle policy changes, all live at a layer the provider's contract can't reach: the point where data leaves a company's own systems and crosses into the provider's. Closing that gap takes controls built at the point of transmission, not controls negotiated after the fact.

Three technical pieces do most of the work. The first is dynamic PII masking applied before transmission, so sensitive fields are redacted or pseudonymized before a request ever reaches the provider's inference layer. Even if a metadata exception captures the request's shape, it captures no identifiable content. The third is metadata-only audit logging: timestamps, token counts, guardrail outcomes, and anomaly flags get recorded in enough detail to satisfy a compliance review, while the log itself never holds a single word of the actual prompt or response. It records that a data category was detected, that redaction ran, which model handled the request, which team sent it, and a trace ID, without ever recording what was said.

That same gateway layer is where ZDR eligibility gets enforced operationally, so it isn't left to individual judgment. Routing rules can guarantee that any workload carrying PHI, PCI data, or privileged legal content only ever reaches ZDR-eligible endpoints, and can block ineligible endpoints, agents, batch processing, MCP connectors, from receiving that kind of request. This is the problem a unified gateway like Concentrate is built to solve: rather than every engineering team independently checking ZDR eligibility for each provider, model, and endpoint it touches, a managed gateway enforces those routing rules once, centrally, for the whole organization. If the gateway blocks that path before the request leaves, a team building against OpenAI's Agents API can't accidentally route a PHI-bearing request to a ZDR-ineligible endpoint.

The architecture pattern isn't unique to any one vendor. Salesforce AgentForce and Microsoft Copilot take two distinct technical approaches to achieving ZDR inside enterprise AI assistants, which makes the larger point clearly: the application consuming a model has to build its own enforcement layer rather than assuming the model provider's guarantee covers everything downstream of it.

None of this replaces the contract. A defensible posture still requires a signed DPA with explicit audit rights, not a self-service toggle flipped on in a dashboard somewhere. What changes is what that audit can actually verify: with metadata-only logging in place, a regulator or an internal security team can confirm what happened on every request, which model handled it, what data category it touched, whether redaction fired, without ever needing access to the underlying content. That's the bridge between a contract that promises zero retention and an operational environment that delivers it.

The Questions a Compliance Review Asks

Whether a ZDR posture is defensible is decided by whether the organization can answer a specific set of questions about scope, enforcement, and evidence, and answer them with specifics rather than reassurance, not by whether a provider agreement exists on file somewhere.

Scope is the first question: whether ZDR actually covers every model, every endpoint, and every API call currently in use, or whether agents, batch jobs, file endpoints, and newer models are quietly excluded from a guarantee the rest of the stack enjoys. The second is contractual standing: is ZDR backed by a signed agreement or DPA carrying explicit audit rights, or is it just a toggle switched on in a settings panel with no enforceable commitment behind it? The third digs into the safety and abuse-monitoring carve-outs directly: what does the provider retain under those exceptions, and for how long does that retained data survive after a policy flag gets triggered? The fourth concerns geography: where is data actually processed and stored, and does that answer change the moment a request crosses a regional boundary or gets routed to a third-party model through a model garden, and the fifth is whether personally identifiable information can reach the provider at all, or whether it is stripped out before transmission at the gateway layer, before the provider's infrastructure ever sees it. The sixth concerns evidence: is there an audit log capturing the governance events that matter, model used, team, data category, guardrail outcome, without ever storing the prompt content itself? The seventh is about change management: what's the process for finding out when a provider updates its retention policy, ships a new model with different retention terms, or receives a legal preservation order that might touch the data in question?

Data that doesn't exist can't be breached, can't be subpoenaed, and can't leak. That principle only holds, though, when the architecture, the contract, and the operational controls are all aligned with each other. A gap in any one of the three brings back exactly the exposure ZDR was supposed to remove. The work of closing that gap is specific and checkable: know where each provider's coverage stops, build the redaction and routing controls that cover the rest, and keep reviewing both as providers change their terms. That's what turns zero data retention from a line in a vendor's marketing page into a compliance posture that actually holds up.