“Zero data retention” sounds like a simple procurement requirement: the provider processes a request and keeps nothing. In practice, enterprise AI systems contain several data paths, product surfaces and exceptions. A provider may offer ZDR for eligible API endpoints while a chat application, grounding feature, file store, cache, feedback tool or connected service follows different rules.

For companies in Saudi Arabia and the UAE, ZDR can support a privacy and security strategy, but it is not a substitute for understanding the complete workflow. Buyers need written answers tied to the exact product, configuration and contract they will use.

Separate training, retention and access

Three questions are often mixed together:

  1. Is customer content used to train the provider’s general models?
  2. Is the content stored, and for how long?
  3. Who or what can access it while it is processed or retained?

A “no training by default” commitment does not mean zero storage. A 30-day abuse-monitoring log is different from application state needed to resume a conversation. A deleted user chat may follow a different lifecycle from API input. Ask every question separately.

OpenAI’s enterprise privacy information says business data is not used for training by default and that eligible API customers with qualifying uses may request ZDR. Its API documentation also states that eligibility differs by endpoint and capability and that some features can store application state.

Anthropic’s privacy documentation says its standard API retention is generally up to 30 days, subject to stated exceptions. Its ZDR arrangements require approval and apply to the Anthropic API and products using the commercial organisation’s API key, not automatically to Claude for Work, Workbench, beta products or other surfaces unless agreed.

Google Cloud documents that managed Vertex AI models are subject to a training restriction without customer permission or instruction. Its ZDR guidance lists feature-specific conditions: some grounding services retain data for stated periods, session resumption creates temporary state, and customers may need particular configurations or exceptions.

These examples show why a product logo is not a retention policy.

Map the complete data flow

Draw the workflow from the user to the final record. Include:

  • Web or mobile application
  • Your server, logs and observability tools
  • AI gateway or orchestration platform
  • Model provider and exact endpoint
  • Prompt caching, files, vector stores and conversation state
  • Search, maps, browser, code execution and other tools
  • Human review interfaces
  • Backups, exports and support systems
  • Analytics and feedback sharing

Your own application may retain prompts indefinitely even when the model provider does not. A third-party connector may copy content into its logs. An agent may write a summary into a CRM. ZDR at one processor does not erase those records.

For every component, record the controller or processor role, region, encryption, access, retention period, deletion method, subprocessors and contractual evidence. Obtain specialist privacy and legal review for personal, regulated or cross-border data.

Ask these questions before signing

Scope and eligibility

  • Is ZDR available to our account, plan, region and use case?
  • Which named products, models, endpoints and versions are covered?
  • Which features are incompatible or create application state?
  • Does the commitment include inputs, outputs, files, embeddings, tool results and metadata?

Exceptions

  • What is retained for safety, abuse prevention, billing, support or legal requirements?
  • Are classifier results, hashes, identifiers or other metadata retained?
  • What happens if an employee submits feedback or opens a support case?
  • Can provider personnel access content, and under what approval and audit controls?

Configuration and verification

  • Is ZDR contractual, account-level or project-level?
  • Who can change it and how are changes logged?
  • Can we verify the current configuration through an admin screen or API?
  • Will new endpoints inherit the control, or require separate approval?

Downstream services

  • Do web search, maps, code execution, file processing and external tools follow the same terms?
  • Where is temporary state held and for how long?
  • Do subprocessors receive customer content?
  • What deletion and incident obligations apply to them?

Change management

  • How will the provider notify us about policy, subprocessor or feature changes?
  • What evidence can we retain for audits?
  • What happens to stored state when a feature is disabled or the contract ends?

Design for minimisation even with ZDR

ZDR should not become permission to send every internal record. Reduce the data before it reaches a model. Remove identifiers that are not needed, retrieve only the relevant passages, separate tenants, use short-lived credentials and prevent secrets from entering prompts.

Apply role-based access and least privilege. Encrypt data in transit and at rest in your own systems. Keep logs useful without copying sensitive prompt bodies. Define retention and deletion for your application, not only the provider. Test that deletion works across primary storage, search indexes and backups according to your policy.

For agents, control tool outputs as carefully as prompts. A customer record retrieved from a CRM is still sensitive even if the original user prompt was harmless.

Validate the chosen configuration

Before production, create a data-handling test plan. Confirm the exact model and endpoint, storage flags, cache settings, grounding options, file lifecycle and feedback controls. Review network and application logs to identify accidental copies. Test access removal and deletion. Repeat the check after major provider or architecture changes.

Maintain a one-page evidence pack containing the architecture, data classification, approved configuration, current provider documentation, contractual terms, internal owner, last test date and next review date.

Make a risk-based decision

Some workloads may be suitable under standard enterprise retention with strong minimisation and contracts. Others may require ZDR, private infrastructure or no external model use. The answer depends on data sensitivity, impact, legal obligations and the business benefit—not on a blanket belief that one deployment model is always safe.

Treat this article as a procurement and operating checklist, not legal advice. Confirm requirements with your privacy, security and legal specialists.

DEMA can help you map the AI data flow, define measurable requirements and translate vendor promises into a deployment checklist. Request a free growth audit or book a free consultation before sensitive data enters an unverified workflow.

Sources