Zero Data Retention: How to Enforce It Across AI Providers

When you send a prompt to an AI provider, something happens to that text before the response arrives. Most providers store it, at least briefly, for abuse monitoring, model evaluation, or general logging. Zero data retention (ZDR) is an agreement that they won’t.

The problem is that “ZDR” is not a standard. Each provider defines it differently, enforces it differently, and carves out different exceptions. If you’re building a product that handles sensitive user data, “we support ZDR” from a provider is a starting point, not a guarantee.

What Zero Data Retention Actually Means

What gets retained, and what doesn’t

ZDR means the provider does not write your input (the prompt) or output (the response) to persistent storage. The request passes through their infrastructure, a response is generated, and nothing about that exchange is logged or saved.

What ZDR typically does not cover:

• Metadata: Request timestamps, token counts, model used, IP address, and API key identifier are almost always retained for billing and security purposes.
• Abuse monitoring logs: Some providers retain a subset of content for safety checks even under ZDR agreements. CSAM detection on image inputs, for example, applies regardless of ZDR status.
• Cached data: Prompt caching stores parts of your request in temporary memory to avoid reprocessing. It is retention for the duration of the cache window, even if not persistent storage.

The working definition: ZDR means your conversation content is not stored after the response is returned. What happens during the request varies by provider and endpoint.

The difference between ZDR and encryption

Encryption protects data while it exists. ZDR eliminates data after it’s used.

These solve different problems. Encryption means stored data can’t be read even if accessed; ZDR means there’s no stored data to access. For industries where the existence of stored data is itself a liability, ZDR is the stronger protection.

ZDR vs data anonymization: Anonymization removes identifying fields but keeps the content. ZDR removes the content entirely. An anonymized medical prompt is still a retained record; under ZDR, no record of that prompt exists after the response.

Why ZDR Matters More Now That AI Is in Your Stack

Prompts contain more sensitive data than developers expect

Developers often think of prompts as technical instructions: “summarize this document,” “write a function that does X.” In production, prompts frequently contain the actual document, the actual data, or direct user input. A support chat that routes through an AI model is passing potentially identifiable user messages to a third-party provider.

That is data exposure. Those messages are in the provider’s infrastructure. Under a standard API agreement without ZDR, they may be retained for 30 days and reviewed by the provider’s trust and safety team.

Regulatory exposure: HIPAA, GDPR, and enterprise compliance

Healthcare applications need BAAs with their AI providers. GDPR-regulated products must demonstrate data is not retained beyond its collection purpose. Financial services under GLBA and FINRA carry similar obligations.

ZDR is not a compliance checkbox on its own, but it is one of the mechanisms that makes compliance achievable. It supports your Data Protection Impact Assessment (DPIA) under GDPR and your BAA negotiations under HIPAA. Without it, default provider retention periods create a gap that compliance teams will flag.

How Major AI Providers Handle Zero Data Retention

OpenAI

OpenAI’s ZDR is available to eligible customers who apply through the sales process. Once approved, ZDR is configured at the project level within the organization. Content is excluded from the 30-day abuse monitoring logs that apply to standard API users. One nuance: extended prompt caching is not itself classified as ZDR-eligible, since it requires storing key/value tensors as application state. For older models, ZDR-enabled organizations default to the shorter in-memory retention window, and extended caching only applies if a request explicitly asks for it, an exception worth monitoring in your traffic. GPT-5.5 and future models remove that choice entirely: they only support the 24-hour extended retention mode, with no in-memory option, regardless of your organization’s ZDR status. The tensors are intermediate model representations, not raw prompt text, but if your compliance posture treats any derived data retention as a concern, this is worth flagging in your risk assessment.

Anthropic

Anthropic offers ZDR as a formal arrangement for Claude Platform (API) and Claude Code on Enterprise plans. Under ZDR, inputs and outputs are not stored at rest after the API response is returned. The standard API retention period is 7 days (reduced from 30 days in September 2025), and API data is never used for model training by default, but ZDR eliminates even that 7-day window. One notable constraint: Anthropic designates certain advanced models as “Covered Models” (currently Claude Fable 5 and Claude Mythos 5), which require 30-day data retention and are not available under ZDR. If your routing includes these models, ZDR cannot apply to those requests.

Anthropic also now offers HIPAA readiness as an independent path: organizations no longer need ZDR enabled to sign a BAA and process PHI, which decouples HIPAA compliance from the ZDR decision entirely.

This restriction is configured at the workspace level, not the organization level: an admin can turn on 30-day retention for the specific workspace that needs Covered Models while every other workspace keeps ZDR. Requests to a Covered Model from a workspace not configured for retention return a 400 invalid_request_error. It’s a clean illustration of why per-request and per-workspace enforcement matters more than a single account-wide ZDR toggle.

Google and others

Vertex AI supports ZDR-equivalent terms through data processing agreements, with specifics depending on region and service. Mistral offers ZDR on its Scale plan (paid API tier) for stateless API endpoints. The default API retention is 30 days for abuse monitoring, so ZDR is not automatic. Customers must apply and provide justification. ZDR does not cover stateful features and products: agents, batch processing files, conversations, libraries, /v1/files, Vibe Work, and Chat are all explicitly excluded. Azure OpenAI runs through Microsoft’s agreement process and does not currently support extended prompt caching, so that particular exception does not apply.

The Problem With Provider-Level ZDR Alone

You’re trusting a policy, not a technical guarantee

No major AI provider gives you cryptographic proof that your data wasn’t retained. ZDR is a contractual commitment, not a technical enforcement mechanism.

For most applications, that is sufficient. But “ZDR support” is not equivalent to “your data is provably gone.” It means “we have agreed not to store it,” a distinction that matters when explaining your data handling to a client’s legal team or a regulator.

What happens when you route across multiple providers

Modern AI infrastructure rarely relies on a single provider. Each provider has its own ZDR availability, activation process, and exceptions. If you’re routing across three providers, you need agreements with all three, you need to know which requests hit which provider, and your routing logic must respect ZDR at the request level. Without a gateway that handles this coordination, enforcing ZDR across a multi-provider architecture is a manual and error-prone problem.

How to Enforce Zero Data Retention at the Gateway Level

Per-request ZDR enforcement

The cleanest way to enforce ZDR in production is to set it at the request level, not just the account level. Account-level settings apply globally, which works until you need ZDR for some requests but not others. Per-request enforcement means tagging individual requests with a ZDR flag, so the gateway routes only to ZDR-compatible endpoints and disables options that would create retention.

Filtering to ZDR-compatible models only

Not all models at a given provider support ZDR uniformly. A gateway that tracks which models and endpoints are ZDR-compatible can filter routing decisions accordingly, so a HIPAA-relevant request doesn’t land on an endpoint with extended cache retention or a Covered Model restriction.

Audit trails and verification

Since ZDR is a policy commitment rather than a technical guarantee, your internal audit trail matters more. Log which requests were sent under ZDR, to which provider, and at what time. A clean request log showing ZDR-flagged traffic routed to ZDR-eligible endpoints is your evidence when a compliance audit comes.

Conclusion

Zero data retention is not a single well-defined standard. The specifics vary by provider, endpoint, use case, and the agreement you’ve negotiated. Understanding what ZDR actually covers at each provider is the prerequisite to relying on it.

The practical challenge is not getting one provider to honor ZDR. It is enforcing it consistently across a multi-provider architecture, at the request level, with the audit trail to prove it. Provider-level agreements are necessary but not sufficient. What closes the gap is enforcement at the layer you control.

How Infron Handles Zero Data Retention Across 400+ Models

Most ZDR problems in production come from operating at scale across multiple providers. You can manage ZDR agreements provider-by-provider, track which endpoints are eligible, and build request-level enforcement into your routing logic yourself. That is a lot of coordination to maintain.

Infron gives you a single API entry point to 400+ models across 100+ providers, with ZDR enforcement built into the routing layer:

Gateway-level ZDR enforcement. Flag a request as ZDR, and Infron routes only to ZDR-compatible models and endpoints. Options that would trigger retention, such as extended caching on ineligible endpoints, are blocked automatically.

ZDR-aware intelligent routing. When a provider designates certain models as ineligible for ZDR, Infron’s routing respects that constraint. Your HIPAA-relevant request won’t land on a model that requires 30-day retention.

Consolidated audit trail. Every ZDR-flagged request is logged with the provider, model, endpoint, and timestamp. One audit trail across all providers replaces the patchwork of individual provider records.

Start building with ZDR enforcement at infron.

FAQ

Does zero data retention mean my data is encrypted?

No. Encryption and ZDR solve different problems. Encryption protects data that is stored; ZDR means the data is not stored at all after the response is returned. You can have one without the other. For the strongest protection, you want both: ZDR with the provider and TLS encryption for data in transit.

Which AI providers support zero data retention?

OpenAI, Anthropic, Google Vertex AI, Mistral, and Azure OpenAI all offer ZDR in some form. OpenAI and Anthropic require sales-negotiated arrangements; Mistral requires a Scale plan and an application process, with ZDR limited to stateless endpoints. Conditions, coverage, and exceptions vary by provider, so verify the specifics for your use case directly with each one.

Is zero data retention HIPAA compliant?

ZDR supports HIPAA compliance but does not satisfy it on its own. You still need a Business Associate Agreement (BAA) with your provider, appropriate access controls, audit logging, and a complete data flow map. ZDR removes one common liability point (retained PHI at the provider), but HIPAA compliance is a broader obligation that ZDR alone doesn’t fulfill.

What’s the difference between zero data retention and data anonymization?

Anonymization removes identifying fields from stored data but keeps the underlying content. ZDR removes the content entirely after it’s used. An anonymized record of a legal or medical prompt is still a retained record. Under ZDR, no record of that prompt exists after the response is returned. For the strictest privacy requirements, ZDR is the right tool, not anonymization.