In brief
- ZDR is not a uniform legal or industry standard; each provider defines its exact meaning.
- The commitment often applies only to certain accounts, projects, models, APIs and features.
- No persistent content retention does not mean no processing, no metadata or no third parties.
- Contract, feature matrix, active configuration and actual data flows all need to align.
ZDR is a retention rule, not a privacy seal
A model must technically process an input to generate an answer. ZDR usually concerns whether defined customer content remains stored by the provider after that processing. The covered content and exceptions vary substantially.
- Processing of the current request still occurs.
- Inputs and outputs can be processed by covered features without persistent retention.
- Operational or billing metadata may fall outside the commitment.
- Legal or safety-related exceptions may apply.
- ZDR does not prevent storage controlled by the customer.
Six commitments that should not be confused
Providers use several statements that sound similar. Each needs a separate answer before an organisation can make a reliable decision.
| Commitment | What it actually answers | What remains open | Evidence that matters |
|---|---|---|---|
| No training | Defined customer data is not used to improve or train models. | Retention, support access, abuse monitoring and the customer's own logs. | Contract, product setting and documented scope. |
| Zero Data Retention | Covered content is not persistently retained by the provider after processing. | Processing, metadata, third parties, uncovered features and customer-side storage. | ZDR agreement, endpoint and feature matrix, and active account configuration. |
| No application state | Conversations, files or assistant state are not kept for later use. | Security and billing logs as well as external integrations. | Product documentation plus a test that history, files and state are actually absent. |
| Data residency | Certain data is stored and, where specified, processed in a selected region. | Support access, global metadata, subprocessors and model training. | Contractual region commitment and a list of excluded data categories and services. |
| No human access | Content is not routinely viewed by support or safety teams. | Automated processing and explicitly defined exception cases. | Contract clause covering roles, triggers, approval and logging of access. |
| Deletion | Previously stored data can be removed within defined periods. | Backups, derived data, legal retention and data in downstream systems. | A tested deletion process with scope, deadlines and confirmation. |
Scope often ends at a feature boundary
ZDR approval for one API does not automatically cover every feature from the same provider. Convenient features frequently require state or persistent storage.
- Is ZDR enabled for the organisation, project or individual agreement?
- Which models and API endpoints are covered?
- Do file uploads, batch processing, conversation history or prompt caching retain data?
- Do different rules apply to beta or preview features?
- Do web search, code execution, connectors or other third parties store their own data?
- Which safety, misuse-prevention or legal exceptions apply?
How to verify a ZDR commitment
A marketing page is not sufficient. The commitment must be traceable to the exact product and technical configuration in use.
- Step 1
Read the agreement
Define covered data, products, exceptions and deletion timeframes.
- Step 2
Review the feature matrix
Record whether every endpoint and tool creates application state.
- Step 3
Prove activation
Check the promised setting for the organisation, project and credentials.
- Step 4
Assess the whole system
Include internal logs, databases, observability tools and connectors.
- Step 5
Monitor change
Reapprove new models, features and provider terms before use.
When ZDR helps – and when it is insufficient
ZDR can remove an unnecessary storage location and reduce risk for short-lived model requests. It does not replace data classification, lawful processing, access control or secure application design.
- Helpful for bounded, stateless requests containing confidential information
- Insufficient if the customer application logs complete prompts persistently
- Insufficient if a connector sends documents to a third party outside the agreement
- Insufficient if too many people or systems can access the source data
- Insufficient if purpose, permission or transparency remain unclear
- Insufficient without export, deletion, incident and provider-exit arrangements
Example: confidential contract analysis through an API
A legal team wants to summarise individual clauses. The selected text endpoint is ZDR-eligible under the agreement and account configuration, but the provider’s file storage feature is not. The company application therefore reads the document, sends only relevant clauses statelessly to the approved endpoint and stores the reviewed output in its own document system. Content-bearing debug logs are disabled, and the endpoint and account configuration are recorded.
What to remember
Do not ask only, “Does the provider offer ZDR?” Ask, “For our endpoint, features and configuration, which exact data is stored where and for how long?” Only that answer is useful for an architecture decision.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed
General guidance based on official provider and authority sources. This is not legal advice; product terms and ZDR scope can change and must be verified for the actual configuration.