Zero Data Retention for AI: What ZDR Covers and What It Excludes

Zero data retention (ZDR) is an arrangement with an AI model provider under which prompts and outputs are not stored at rest after the response is returned, including in the provider's abuse monitoring logs. It is not a default and not a single switch: it applies to specific endpoints and features, it is usually granted on approval, and stateful features such as file storage, batch jobs, conversation objects and hosted agents keep data regardless. Teams that sign a ZDR amendment and then build on a stored-state feature often discover their data was retained after all. This guide explains what ZDR and its close relative, modified abuse monitoring, actually cover at four major providers, which features fall outside, what is still kept, and how to verify the arrangement is in force. It is for security, privacy and procurement teams approving AI use with sensitive data. For retention and deletion of AI data you hold yourself, see the AI Data Retention and Deletion guide.

Key takeaways

• Abuse monitoring is what ZDR removes: by default providers keep prompts and outputs for a period to detect misuse; ZDR or modified abuse monitoring stops that storage, usually after an approval process.
• "No training" is a different promise: the providers covered here state that API and enterprise data is not used for training by default; that says nothing about how long data is stored.
• Stateful features are outside ZDR: files, batch jobs, stored conversations, assistants, vector stores and hosted agent sessions keep data until deleted or until a feature-specific period ends.
• Some retention survives ZDR: flagged content for trust and safety, legal obligations, short-lived caches and certain grounding or search features can still retain data.
• Verify, do not assume: each provider exposes a setting or attribute that shows the arrangement is active; check it per organisation, project or resource and block non-eligible features in code.

What it is

Every hosted model API processes your prompt in memory to produce a response. What happens next varies: the provider may write the prompt and output to an abuse monitoring store for a period, may keep application state for features you asked to persist, and may cache intermediate computation for performance. ZDR addresses the first of these and, depending on the provider, forces some features to not persist content. It does not change the third-party services your application calls, and it does not change where data is processed unless combined with data residency options.

How it works

The providers below are listed alphabetically; the order is not a ranking. Each summary comes from the provider's own documentation as checked on 8 November 2026. Terms and feature lists change, so confirm against the current page and your contract.

Anthropic (Claude API)

• Arrangement: ZDR is requested through Anthropic's sales team and enabled per organisation; each new organisation is enabled separately. Under ZDR, prompts and responses are not stored at rest after the response is returned, for features that do not need to store content.
• Eligible: the Messages and Token Counting APIs and eligible features such as prompt caching, thinking, citations, PDF support, web search and web fetch, computer use, memory and tool search, with some marked as qualified. ZDR is also available on request on Claude Platform on AWS and Claude models on Google Cloud managed by Anthropic.
• Outside ZDR: the Files API, batch processing (29-day retention), the code execution tool and programmatic tool calling (container data up to 30 days), Agent Skills and the MCP connector, Managed Agents sessions, the Claude Console and Playground, consumer plans and the Teams and Enterprise interfaces. Some models require 30-day retention and can be enabled in a dedicated workspace while other workspaces keep ZDR.
• Still retained: content flagged by automated trust and safety systems may be kept for up to 2 years, data required by law, and bounded technical artefacts such as cache entries for the cache lifetime.
• Verification signal: ZDR organisations cannot call the API directly from a browser, because CORS requests are rejected; route calls through your back end.

Google Cloud (Gemini Enterprise Agent Platform)

• Arrangement: Google's documentation page "Gemini Enterprise Agent Platform and zero data retention" describes ZDR as a configuration you achieve through project settings and request parameters. Google's documentation also has a page on name changes from Vertex AI.
• Configuration steps: keep request-response logging (off by default) disabled; set store to false on Interactions API requests; keep Gemini Live API session resumption off; set the project's cache retentionType to EPHEMERAL to stop durable caching or disableCache to true to stop all caching (both need roles/aiplatform.admin); and use Web Grounding for Enterprise for search grounding.
• Outside ZDR: Grounding with Google Search stores derived queries for up to 3 days, Grounding with Google Maps stores prompts, context and outputs for 30 days, and Deep Research sessions are kept for 7 days and can be deleted early. Keep these out of ZDR workloads.
• Still retained: prompts may be logged for abuse detection for customers under the Google Cloud Platform Terms of Service, and some advanced models or features may log prompts and responses; confirm with your account team.
• Verification signal: the project cache configuration and logging settings, readable by administrators, show the ZDR-relevant state.

Microsoft (Azure OpenAI and models sold by Azure in Foundry)

• Arrangement: Microsoft's arrangement is called modified abuse monitoring. Managed customers apply through a form linked from the data privacy page, which also links to the Limited Access requirements.
• Effect: when approved, abuse monitoring storage and human review are skipped while automated review continues. Data is not used to train foundation models without permission, and models do not interact with provider-operated services such as the OpenAI API.
• Stateful features: the Responses API, Assistants threads, stored completions, batch and fine-tuning store data in your Foundry resource, in the resource's geography, encrypted at rest with AES-256 by default and deletable at any time.
• Still retained: if automated review detects severe or recurring abuse, Microsoft may limit access and ask you to turn on abuse monitoring with human review. Preview features may follow different practices.
• Verification signal: the resource's ContentLogging capability shows false in the Azure portal JSON view, Azure CLI or management API; the attribute appears only when abuse monitoring storage is off.

OpenAI (API platform)

• Arrangement: ZDR and modified abuse monitoring (MAM) need prior approval; approved organisations choose either in Settings, Organization, Data controls, Data Retention, and projects can inherit or override the setting.
• Effect: both exclude customer content from abuse monitoring logs, which are otherwise kept for up to 30 days. ZDR also forces store to false on /v1/responses and /v1/chat/completions. API data is not used for training unless you opt in.
• Eligible: endpoints including /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/moderations, the audio endpoints and /v1/realtime, some with stated limitations.
• Outside ZDR: endpoints that keep application state until deleted, including /v1/files, /v1/vector_stores, /v1/assistants, /v1/threads, /v1/conversations, /v1/batches, /v1/fine_tuning/jobs and /v1/evals. Remote MCP servers follow the third party's retention.
• Still retained: image and file inputs in rare cases such as CSAM detection, prompt cache entries (encrypted, expiring within 24 hours) and data needed for legal obligations.
• Verification signal: the Data Retention setting at organisation and project level in the dashboard.

Reference summary

Why it matters

• Breach surface: every stored copy of a prompt is a copy of whatever was pasted into it, including personal data, source code and secrets. Less retention means less to lose. See the AI and Privacy Guide.
• Regulatory fit: storage limitation and purpose limitation under data protection law (GDPR Article 5(1)(b) and (e)), client confidentiality duties and sector rules all depend on knowing how long a processor keeps data. Record the arrangement in your DPIA; see the DPIA Guide.
• Agent workloads: agents lean on exactly the stateful features ZDR excludes (files, threads, hosted containers, MCP connectors). An agent design decision can quietly move a workload out of ZDR.
• Shared responsibility: OpenAI's documentation notes that customers using ZDR or MAM are responsible for their users' compliance with usage policies and any moderation or reporting duties, because the provider sees less.

Common misconceptions

• "Enterprise means ZDR": enterprise terms usually guarantee no training, not zero retention. ZDR is a separate approval or configuration.
• "ZDR applies to the whole account": it is set per organisation, project or resource, and new organisations or projects may start without it.
• "If the endpoint is eligible, my app is covered": one call to a files, batch, assistants or conversation endpoint, or a hosted tool, stores data under that feature's rules.
• "ZDR means nothing is ever kept": trust and safety flags, legal holds and short-lived caches can still retain data, as each provider documents.
• "The model provider is the only retention point": your own logs, observability tools, gateways, vector databases and third-party MCP servers keep copies too. See the Log Management and Retention Guide.
• "Data residency and ZDR are the same": residency controls location; ZDR controls storage. Some providers require extra approval to combine them in certain regions.

Related concepts

Rolling out and verifying ZDR

1. Classify workloads: decide which AI use cases handle data that justifies ZDR (regulated personal data, client confidential material, secrets-adjacent engineering data).
2. Request and record: apply through the provider, keep the approval or contract amendment, and note the organisations, projects or resources it covers.
3. Map features to eligibility: list every endpoint, tool and feature the application uses and mark each against the provider's eligibility list.
4. Enforce in code and gateway: block non-eligible endpoints for ZDR projects at an AI gateway or egress proxy, set store parameters explicitly, and keep separate API keys for ZDR and non-ZDR projects.
5. Verify the setting: check the provider's confirmation signal per project or resource after every new deployment, and alert if it changes.
6. Review on change: re-check after model changes, new features, new regions or contract renewal, since eligibility lists move.

Measures worth tracking

• Coverage: share of sensitive AI workloads running in ZDR-confirmed projects or resources.
• Drift: calls from ZDR projects to non-eligible endpoints, caught at the gateway.
• Confirmation age: days since each project's ZDR state was last verified.
• Key separation: API keys shared between ZDR and non-ZDR projects (target zero).

Where identity fits

ZDR is enforced per organisation, project, workspace or resource, and the API key or service principal decides which of those a call lands in. A developer key from a non-ZDR project used in a sensitive pipeline sends data outside the arrangement. Tie ZDR projects to dedicated keys or workload identities, store them in a vault and restrict who can create keys in those projects. See the Anthropic API Keys Security Guide, the Google Vertex AI Security Guide, the Azure OpenAI and Azure AI Foundry Security Guide and the OpenAI API Keys Security Guide.

Practitioner checklist

• Separate "no training" from "no retention" in procurement and DPIA records.
• Obtain written ZDR or modified abuse monitoring approval and list the organisations, projects or resources it covers.
• Inventory every endpoint, tool and feature each AI application calls and check it against the provider's current eligibility list.
• Block non-eligible endpoints for ZDR projects at the gateway and set store parameters explicitly.
• Issue dedicated API keys or workload identities per ZDR project and restrict key creation.
• Verify the provider's confirmation signal after each deployment and on a schedule.
• Account for retention that survives ZDR: trust and safety flags, legal holds, caches and third-party tools.
• Review your own logs, traces and vector stores so you do not keep what the provider no longer does.

Standards and references

• Anthropic: API and data retention
• Google Cloud: Zero data retention
• Microsoft Learn: Data, privacy and security for models sold by Azure
• OpenAI: Data controls in the OpenAI platform
• EUR-Lex: Regulation (EU) 2016/679 (GDPR)

Related NHI Mgmt Group resources: AI Data Retention and Deletion · AI and Privacy Guide · AI Vendor Security Questionnaire Template · DPIA Guide