LLM Zero Data Retention for the Enterprise: The Provider Landscape, the Cloud Layer, and the Architecture Behind the Guarantee

Zero data retention is a phrase that has quietly become table stakes in enterprise LLM contracts. Every prominent model provider — Anthropic, OpenAI, Google, Moonshot's Kimi, Zhipu's Z.AI — now publishes some form of ZDR arrangement. Every major cloud that hosts foundation models — AWS Bedrock, Azure Foundry, Google Vertex AI — exposes a control set that lets an enterprise dial retention down. The problem is not the absence of ZDR. The problem is that the offers are not equivalent, the exceptions are numerous, and the difference between a ZDR checkbox and a ZDR architecture is where audits, incidents, and regulatory queries are won or lost.

For an enterprise handling regulated data — healthcare records, financial transactions, source code, legal work product, personally identifiable information, sovereign customer data — the operational question is no longer does the provider offer ZDR. It is a longer list: which endpoints does ZDR apply to, who is the legal data processor, what happens under safety review, what happens under a subpoena, and — the hardest question — where in the pipeline does data actually persist beyond the moment of inference, regardless of the label on the primary API. Answering that list is what turns a stated privacy policy into a defensible privacy posture.

This is the landscape as it stands in mid-2026, the exceptions the security team should read, the cloud-layer overlay that changes the analysis, and the architectural pattern for building agent systems whose data footprint you can actually testify to.

---

I. What Zero Data Retention Actually Means (and Doesn't)

Zero data retention, in strict terms, means the model provider does not store customer prompts or model outputs at rest after an API response is returned. In practice, "ZDR" is used across the industry to cover four related but distinct claims:

• No storage of prompts and completions after the response. The narrow, technical meaning.
• No use of your data to train or improve the model. A different guarantee. A provider can retain your data for thirty days for abuse monitoring while contractually promising never to train on it.
• No human review of your content. A third layer, typically called "Eyes Off" or equivalent. Under standard terms, retained content may be reviewed by a human safety analyst; under enhanced arrangements, it is not.
• Data never leaves your legal jurisdiction or your infrastructure boundary. The most restrictive, and the only one that materially changes your exposure under the US CLOUD Act, GDPR Article 48, or the EU AI Act's Article 10 data governance obligations.

The most common misalignment inside enterprise procurement is treating claim one as if it delivers claims two through four. It does not. Every downstream compliance decision — from a HIPAA business associate agreement to a GDPR data processing addendum to an EU AI Act audit — depends on knowing which of the four your provider has actually committed to, in what document, for which endpoints.

---

II. The Model Provider Landscape

The following is the current stated posture of the six model providers most commonly encountered in enterprise procurement in 2026. Every claim traces back to the provider's own documentation.

Anthropic (Claude)

Anthropic offers ZDR as an opt-in arrangement per organisation, enabled by the sales team after contract execution.1 Under a ZDR arrangement, Anthropic does not store customer prompts or responses at rest after the API response is returned. Coverage includes the Claude Messages and Token Counting APIs for eligible features, Claude Code when used with API keys from a Commercial organisation or through Claude for Enterprise with ZDR enabled, and the Claude Platform on AWS. The company's baseline posture is that retained data is never used for model training without express permission, and only what is technically necessary for a feature is retained — conversation content is not retained by default, with one exception: certain "Covered Models" require a 30-day retention window for safety review.

Anthropic separately offers HIPAA-ready API access as a distinct arrangement with its own eligibility and terms. Importantly, on Amazon Bedrock and Google Cloud's agent platforms, the cloud provider is the data processor for Claude workloads, not Anthropic — the retention analysis moves to the cloud provider's control surface.

OpenAI

Since March 1, 2023, OpenAI has committed contractually that API data is not used to train or improve its models by default.2 The standard API tier retains inputs and outputs in abuse monitoring logs for up to 30 days. Enterprise customers can request one of two enhanced controls through OpenAI's sales team, subject to prior approval and additional requirements:

• Modified Abuse Monitoring excludes customer content from abuse monitoring logs across all API endpoints while preserving the full capability set.
• Zero Data Retention goes further: for eligible endpoints, no application state is stored at all, and the store parameter on the Responses and Chat Completions APIs is forced to false.

OpenAI additionally publishes two carve-outs the security team should read: Eyes Off allows BAA-eligible endpoints to process PHI even when data is retained (human review is excluded), and Safety Retention allows OpenAI to reserve the right to make specific models temporarily ineligible for ZDR/MAM in the event of severe-risk activity, with prior written notice.

Google (Gemini via Vertex AI)

Google Cloud offers Zero Data Retention for the Gemini Developer API and Gemini Enterprise Agent Platform, with the caveat that ZDR applies to request logs but that certain optional features have their own retention footprint.3 The two commonly overlooked ones are explicit context caching (via the cached_content feature, which stores content for a customer-defined TTL) and implicit in-memory caching (used by default for latency and cost reduction). Vertex AI's baseline posture is that customer prompts are not used to train Google's models, and the enterprise platform layers additional controls on top.

For enterprises seeking an absolute-zero footprint on Google, both caching mechanisms need to be explicitly disabled — the ZDR label alone does not cover them.

Moonshot (Kimi)

Moonshot's Kimi API — the interface to the K2, K2.6, K2.7 Code, and K3 model line — publishes an unambiguous no-training commitment: user data submitted through the API, including inputs and model outputs, is not used to train or improve Kimi's models.4 Data is stated as used solely to fulfil the current API request and is not persistently stored for training purposes. The security posture published for the API includes HTTPS/TLS in transit, strict per-user data isolation, API-key access control, content-safety review that does not store originals, and a delete-on-demand path for files uploaded via the file API.

The dominant caveats are jurisdictional: Moonshot is a Beijing-headquartered entity operating under the Personal Information Protection Law, the Data Security Law, and adjacent Chinese frameworks. That is a residency and legal-domain question, not a training or storage one, and it belongs in a separate part of the analysis (see Section VII).

Zhipu (Z.AI, GLM family)

Zhipu's Z.AI, the Tsinghua-spun lab behind the GLM-5.2 open-weight family, publishes the standard hosted API for enterprises using its managed platform. The more consequential fact for enterprise privacy architecture is that the GLM family ships as open-weight — meaning the model can be self-hosted inside a customer's VPC or air-gapped environment, and third-party providers (for example, Opper's EU hosting) offer GLM-5 with an EU residency posture and ZDR at the deployment layer.

Two considerations for procurement: Zhipu's inclusion on the US Entity List has export-control implications for US enterprises deploying the hosted API, and its January 2026 Hong Kong IPO clarifies its corporate posture. Neither prevents deployment in most jurisdictions — but both belong in the enterprise's risk register when the model choice is being made.

The strategic point is that open-weight GLM is a self-hosting escape hatch: the enterprise does not have to trust any provider's ZDR contract because the enterprise runs the inference on its own infrastructure. The same is true of open-weight releases from Mistral, Meta's Llama series, DeepSeek, and Alibaba's Qwen family.

The Landscape at a Glance

Every entry on the table is a contract question before it is an engineering question. The security team's job is to align the model choice to the acceptable data domain — not to accept any provider's ZDR posture as universal.

---

III. Where the Model Ends and the Cloud Begins

For most enterprises, the model provider is not the counterparty on the data-processing agreement. The cloud provider is. AWS Bedrock, Azure Foundry (formerly Azure OpenAI Service), and Google Vertex AI are all now offering Claude, GPT-class models (via Foundry), and Gemini respectively — and on those platforms, the cloud provider is the data processor and the retention analysis moves entirely to their control surface.

AWS Bedrock

Amazon Bedrock exposes an explicit data_retention_mode control, configurable at the account or project level and enforceable across the Messages, Chat Completions, and Responses APIs.5 The four modes are:

• none — zero data retention. No request or response data is written to durable storage by AWS or shared with the model provider. On the Responses API, store defaults to false and any attempt to set it to true is rejected.
• default — the model's own retention policy applies. Behaviour depends on the model.
• provider_data_share — Bedrock retains and shares inference data with model providers per their requirements. Required for access to certain models.
• inherit — defer to a broader account scope; the default for new accounts and projects.

The important architectural fact is that ZDR on Bedrock is enforceable at the AWS Organizations level via a Service Control Policy — the security team can guarantee that no account under the organisation can override the ZDR posture. If a model requires retention (for example, certain third-party frontier models available on Bedrock) and the account is configured for none, the request is blocked at the API. The retention posture becomes a hard constraint of the deployment, not a per-request setting a developer can accidentally invert.

For AWS-sold models specifically — Titan, Nova — the model provider has zero access to prompts or completions regardless of the retention mode. For third-party models sold on the Bedrock marketplace, the provider's EULA applies and provider_data_share may be required.

Azure Foundry (Models Sold by Azure)

Azure Foundry — the current umbrella for what was Azure OpenAI Service — publishes an unambiguous data posture for Models Sold by Azure.6 Prompts, completions, embeddings, and training data:

• Are NOT available to other customers
• Are NOT available to OpenAI or other providers of Models sold by Azure
• Are NOT used by providers of Models sold by Azure to improve their models or services
• Are NOT used to train any generative AI foundation models without your permission
• Are NOT used to improve Microsoft or third-party products without explicit permission

Foundry models are hosted in Microsoft's Azure environment and do not interact with OpenAI's own services (ChatGPT, the OpenAI API). Abuse monitoring runs by default at the Azure infrastructure layer, with an opt-out ("modified abuse monitoring") available to eligible customers who commit to independent moderation.

The consequence: for enterprises where the primary constraint is that the model provider (OpenAI) never sees the data, Azure Foundry is architecturally stronger than the direct OpenAI API by default — Microsoft is the counterparty, OpenAI is the model IP source, and OpenAI has no access to the deployment.

Google Vertex AI

Vertex AI does not use customer prompts to train Google's models by default, and offers ZDR via the Gemini Enterprise Agent Platform and the Gemini Developer API with the caching caveats described in Section II. The DPA and the Google Cloud Platform terms govern; the retention posture is enforceable via project-level configuration and organisation policy.

The pattern across all three hyperscalers is consistent: the cloud is the data processor, ZDR is a control-plane setting, and the enterprise's security team owns the enforcement via organisation-level policy rather than per-workload configuration.

---

IV. The Seven Places Data Actually Persists

An enterprise LLM deployment can be labelled ZDR at the primary model API and still leak data in a half-dozen other places. Every serious privacy architecture treats the following seven surfaces as the actual perimeter to audit.

1. Model inference itself. The obvious one. Covered by the provider's ZDR arrangement — or not.

2. Prompt and context caching. Both explicit (Anthropic's prompt caching, Google's cached_content, OpenAI's automatic prompt caching) and implicit in-memory caching. Each has its own TTL and its own retention posture. ZDR at the API layer does not automatically cover the cache.

3. Abuse monitoring and safety review logs. OpenAI's default is 30 days. Anthropic's Covered Models require 30 days. Azure's abuse monitoring runs by default. These logs may contain content classifier outputs derived from customer data even when the customer content itself is excluded. Modified abuse monitoring or ZDR eliminates the log; nothing eliminates the classifier's runtime pass.

4. Third-party model marketplace terms. On Bedrock's provider_data_share mode, the model provider (not just AWS) receives inference data. The enterprise's DPA with AWS does not cover what happens after the data crosses into the model provider's own retention regime.

5. Retrieval indexes and vector databases. RAG systems store customer content in embedding form. Vector representations are reversible in principle — the security posture of the vector DB (Pinecone, Weaviate, pgvector, OpenSearch, self-hosted FAISS) becomes part of the retention perimeter, and is almost never covered by the LLM provider's ZDR contract.

6. Logging, observability, and evaluation middleware. Application-layer telemetry — LangSmith, Langfuse, Arize, self-built logging — routinely stores full prompts and completions for debugging and evaluation. This is where the largest volume of enterprise LLM data typically ends up, and it is entirely outside the model provider's scope.

7. Agent tool outputs and code execution. When an agent calls a tool — a search API, a code interpreter, a database — the intermediate results and tool outputs may be logged, cached, or transmitted to third-party endpoints. Bedrock's code execution and Anthropic's code execution feature are called out explicitly as not covered by ZDR in their respective docs. Every tool integration is a separate retention question.

The security-review artefact that reflects this reality is not "is the model ZDR" — it is a data-flow diagram of every surface the data touches from ingestion through to purge, with the retention posture and legal counterparty documented for each.

---

V. The Contract, the Architecture, and the Difference That Matters

There are two paths to a defensible ZDR posture, and enterprises typically end up needing both.

The contractual path is what the provider offers on paper — a ZDR arrangement, a BAA, a HIPAA readiness attestation, a modified abuse monitoring commitment, a data-processing addendum. This is the layer that satisfies a regulator's initial question about who processes what data under whose law. It is necessary. It is not sufficient. Contracts define liability after the fact; they do not prevent data from persisting where it should not.

The architectural path is what the deployment enforces regardless of what any provider promises. Ephemeral processing. In-VPC or air-gapped inference. Retention set to zero at the cloud control-plane level with Service Control Policy enforcement. Vector DBs hosted inside the enterprise boundary. Observability that logs metadata but not content. Tool integrations that route through in-boundary proxies. Human-in-the-Loop protocols scoped so that any content that leaves the boundary is deliberately released, logged, and reviewed.

The architectural path is what makes the contractual path testable. An auditor looking at a ZDR contract sees a promise. An auditor looking at a network policy, an SCP, and a retention configuration sees evidence. Enterprises whose privacy posture depends on the first alone are exposed to any change in the provider's terms, any incident that requires the provider to reach into retained data for investigation, and any regulatory instrument (see the US CLOUD Act analysis in The Sovereign AI Enablement Framework) that compels the provider to produce data it technically holds.

Contracts define liability after the fact. Architecture prevents the fact. A defensible privacy posture needs both.

---

VI. Deployment Tiers From SaaS to Air-Gapped

Not every workload needs the strongest tier. Not every workload survives the weakest one. The following is the tiering enterprises should apply when placing a workload in an LLM stack — with the trade-off explicit at each level.

The right architecture is usually not "everything in T5." It is a tiered enablement plan in which workloads are placed in the tier that matches their data classification, with a jurisdiction registry (see The Sovereign AI Enablement Framework) governing the placement rule. A single agent programme may run some workflows in T2 with contractual ZDR, others in T3 on a hyperscaler, and the most sensitive in T4 or T5 — all inside the same governance framework.

---

VII. The Bespoke Architecture Question

For most enterprises, the ZDR posture cannot be assembled from any single provider's off-the-shelf offering. It is a composition problem: the right model at the right tier for each workflow, wired through middleware the enterprise controls, hosted inside a boundary the enterprise defines, contracted through the party the enterprise's legal team has assessed.

The composition typically requires:

• Contractual negotiation across three counterparties — the model provider (Anthropic, OpenAI, Google, Moonshot, Zhipu), the cloud provider (AWS, Azure, GCP, or an EU sovereign option), and any managed service or middleware provider in the stack. Each needs a DPA aligned to the enterprise's regulatory posture.
• A model portability layer so the same workload can shift from GPT-class on Foundry, to Claude on Bedrock, to self-hosted GLM in-VPC, without an application rewrite. This is the mechanism that protects the enterprise when a provider's regulatory status changes, when a Code of Practice is amended, or when a new sovereign regime restricts a specific provider in a specific market.
• A retention-enforced control plane — SCPs on Bedrock, tenant policies on Azure, project policies on Vertex, and network policies on the internal VPC — that makes the ZDR posture a property of the platform, not a per-application configuration.
• In-boundary vector storage, observability, and tool integrations so the seven surfaces enumerated in Section IV are each brought inside the perimeter, and the ZDR posture on the primary model API is not undermined by a middleware leak.
• Auditable evidence — SCP configurations, retention mode logs, provider ZDR enablement letters, DPA versions, network policies — assembled into the artefact set an external auditor or a supervisory authority will request.

This is not what a single procurement decision produces. It is what a designed enablement architecture produces, with the ZDR guarantee treated as an emergent property of the architecture rather than a line item in a vendor contract.

---

VIII. The Bottom Line

Zero data retention is now available in some form from every prominent LLM provider and every major cloud host. The important work is no longer getting ZDR — it is composing a deployment whose ZDR guarantee is real, provable, enforceable at the control plane, and durable against the provider term changes, safety-review carve-outs, and cross-jurisdictional exposures that a standard ZDR checkbox does not address.

The enterprises that will deploy agents against their most sensitive data in 2026 and 2027 are the ones treating ZDR as an architectural property to be engineered, not a feature to be procured. The composition — model, cloud, deployment tier, contractual counterparty, in-boundary middleware, retention-enforced control plane, auditable evidence set — is where the guarantee is actually made real.

Read against the seven surfaces where data actually persists, the tiered deployment model, and the multi-party contractual reality, an enterprise LLM programme has enough moving parts that a bespoke architecture becomes the default, not the exception. The alternative is a deployment whose privacy posture is defined by whichever surface was overlooked in procurement.