What Is Zero Data Retention (ZDR)?

Every prompt sent to an AI model has to go somewhere, if only briefly, for the model to actually process it and generate a response. The question of what happens to that prompt after the response comes back — whether it's deleted immediately, kept for a short diagnostic window, or retained indefinitely — is a genuinely important detail for anyone sending sensitive work through an AI system, and it's exactly what zero data retention is designed to answer.

What ZDR actually means

Zero data retention, almost always shortened to ZDR, is a contractual arrangement under which an AI provider does not store a customer's prompts or the model's responses at rest after the response has been returned — meaning the content is processed to generate an answer and then not kept afterward, rather than being written to storage and held for some retention period the way API requests are typically handled by default. Both of the major U.S. labs offer a version of this. Anthropic's documentation defines its ZDR arrangement in those exact operational terms for eligible Claude API usage, and OpenAI's own description of its equivalent arrangement adds a few specific guarantees: under ZDR, content becomes unavailable to the provider's own personnel for review, and it isn't used to train future models unless a customer has separately opted in.

The phrase "at rest" is doing real work in that definition, and it's worth understanding precisely. It doesn't mean a prompt is never processed anywhere — a model obviously has to receive and work with the content to generate a response. It means that once the response is returned, the content isn't written to persistent storage the way it otherwise would be under a provider's standard retention policy, which for both major labs typically runs around thirty days by default, kept largely for abuse monitoring and safety review.

Who actually gets it, and how

ZDR isn't a setting anyone can simply toggle on. Both Anthropic and OpenAI offer it specifically to qualified organizations through their commercial or enterprise terms, generally requiring a request through the provider's sales team and an approval process, rather than something available self-serve to an individual developer or a standard business account. It's also scoped narrowly to specific, eligible API endpoints rather than applying universally across every feature a platform offers. Anthropic's current documentation, for instance, lists the core Messages API as covered, while features that inherently require server-side storage to function — things like a files API, a persistent memory tool, or cloud-hosted sessions — are excluded by design, because a feature that stores state for you to retrieve later is structurally incompatible with a promise not to store anything at all. Using one of those features is treated as a deliberate choice to step outside the ZDR arrangement for that specific data, with that feature's own separate retention policy applying instead.

There's a specific, more recent wrinkle worth knowing about on Anthropic's side, since it directly illustrates how narrow and conditional these arrangements can get. As of mid-2026, Anthropic designates its most capable model tier as "Covered Models," and usage of those models carries a mandatory thirty-day retention window that overrides a standing ZDR agreement entirely, unless Anthropic has separately authorized an exception. In practice, that means an organization with a genuine ZDR agreement in place may still need to explicitly enable thirty-day retention for a specific workspace if it wants to use one of those particular models — the rest of the organization's workspaces stay at zero retention, but that one carve-out doesn't follow the blanket rule. It's a good illustration of why "does this provider offer ZDR" is rarely a simple yes-or-no question — the real answer usually depends on which specific model, which specific endpoint, and which specific account tier you're actually asking about.

Why ZDR doesn't cover everything it sounds like it should

The most important limitation to understand about ZDR is also the easiest one to miss: it's a provider-level guarantee, not an application-level one. A model provider's zero data retention agreement governs what that provider does with your data once it reaches their infrastructure — it says nothing about what any application built on top of that API does with your data before or after that point. A product that connects to a provider under a genuine ZDR agreement can still retain your transcripts, your conversation history, or your uploaded files indefinitely on its own separate servers, entirely independent of whatever promise the underlying model provider made. ZDR with the model provider and genuine data minimization by the application you're actually using are two different guarantees, and having one doesn't automatically mean you have the other.

This matters more than it might initially seem, because the practical privacy exposure most people actually care about usually isn't limited to what happens at the model provider's layer. It's the full path your data travels — from the application you typed it into, to whatever that application does with it before forwarding your request, to the model provider itself, and back. A ZDR agreement addresses one link in that chain. It's a meaningful one, but it's not the whole chain, and a product that only talks about its model provider's retention policy without saying anything about its own is leaving out half the actual answer.

It's also worth being clear that even a genuine ZDR agreement comes with carve-outs that are worth knowing rather than assuming away. Both major labs retain the ability to keep data despite a ZDR arrangement where required to comply with law or to investigate a usage policy violation — ZDR means data isn't stored as a matter of routine, not that it's categorically impossible for the provider to ever retain anything under any circumstance.

Why this matters for how you actually use AI

For most everyday, low-stakes AI use, standard retention policies are a reasonable default, and chasing a ZDR agreement for routine, non-sensitive work is more process than the situation calls for. Where it genuinely matters is work involving confidential client information, proprietary business data, legal or medical content, or anything else where a provider retaining a copy — even briefly, even for a stated, limited purpose — represents a real risk rather than an abstract one. For that category of work, understanding whether ZDR is available, at which layer it applies, and what it actually excludes is a genuinely important piece of due diligence, not an exercise in excessive caution.

Where Kahlo fits into this

Kahlo's architecture is built around the same principle ZDR reflects, applied at the layer Kahlo itself controls. Rather than routing requests through consumer-tier access, where retention and training policies are generally broader by default, Kahlo connects to model providers through their APIs, and each provider only receives the prompt and context actually needed to answer a given request — not your account identity, which stays with Kahlo rather than being passed along to Anthropic, OpenAI, Google, or any of the other labs in the workspace. For organizations that have their own negotiated ZDR agreement directly with a specific provider, Pro and Max plans support bringing your own provider keys, so that agreement applies to your usage exactly as it would if you were calling that provider's API directly yourself.

The broader lesson from how ZDR actually works is one worth carrying into how you evaluate any AI product handling sensitive work: a provider's retention policy is only one link in the chain, and it's worth asking the same question about every layer your data actually passes through, not just the model provider sitting at the end of it.