Data packets flowing through to a struck-out database labeled 'not stored' — zero data retention

Zero Data Retention: What ZDR Really Means for Enterprise AI

Zero Data Retention (ZDR) is the control enterprises demand before piping sensitive data through a third-party model — and often misunderstand. What it actually is, how stateless inference works, where 'zero' isn't truly zero, and how to evaluate it as a control (not a compliance guarantee).

The question every enterprise asks before shipping AI

"Where does our data go?" For a company piping customer records, source code, or patient information through a third-party model, that question decides whether an AI project ships at all. Zero Data Retention (ZDR) is the answer buyers increasingly demand — and, just as often, misunderstand. It's a genuinely powerful control, but "zero" is doing more marketing than engineering work in a lot of pitches. Here's what ZDR actually is, how it works, where it stops, and how to evaluate it.

---

What ZDR actually means

Zero Data Retention is an operational mode in which an AI provider does not store, log, or reuse your prompts, completions, or associated metadata beyond the immediate API call — not for model training, not for product improvement, not for human review. The request flows through the provider's infrastructure to generate a response, and the prompt-response pair is discarded within seconds, leaving no persistent record.

That last part is the whole point. Standard API tiers typically *do* retain requests for a window (often ~30 days) for abuse monitoring and debugging. ZDR removes that persistence layer for your traffic.

---

How it works

ZDR isn't magic; it's a different code path:

  • Logging-exempt routing. Requests flagged for ZDR are routed around the persistence layer. They reach the model inference layer, generate a response, and the prompt-response pair is dropped before any store writes.
  • Stateless inference. The model processes the request in memory and holds nothing after the response is returned.
  • Real-time abuse monitoring instead of log review. Because there are no stored logs to review later, safety enforcement shifts to happening in the moment — classifiers run during the request rather than on retained data afterward.

The net effect: the provider can still serve and (to a degree) police the traffic, but there's no durable copy of your content sitting on their systems.

---

"Zero" is rarely absolutely zero

This is the part that gets glossed over, and it matters. Even under a ZDR agreement, a few carve-outs almost always survive:

  • Safety carve-outs. Content flagged for a usage-policy violation is frequently retained anyway — reportedly up to two years at some providers even under a ZDR or HIPAA arrangement — and trust-and-safety classification scores can be kept far longer.
  • Legal holds and metadata. Providers may retain limited metadata or flagged data for a bounded window to meet legal obligations and safety requirements. "Zero retention" is not zero in *every* sense.
  • Model-specific retention floors. Some frontier models require a minimum retention window and are simply not available under ZDR. Anthropic's Claude Fable 5, for example, requires 30-day data retention — a request from a zero-data-retention organization returns a 400 error. If your ZDR posture is strict, it can rule out specific models.
  • Scope limits. ZDR usually covers the API only. Anthropic's policy, for instance, targets the Anthropic API and does not automatically extend to Console/Workbench, Claude for Work, beta products, or other services unless negotiated. OpenAI's ZDR is an enterprise-tier arrangement requiring an explicit agreement — it isn't a default checkbox.

None of this makes ZDR worthless. It means you have to read the contract, not the headline.

---

ZDR is a control, not a compliance certificate

The most common mistake is treating ZDR as if it *is* compliance. It isn't. ZDR alone does not make a deployment GDPR-, HIPAA-, or EU AI Act-compliant. Those regimes demand a whole framework — data-minimization, lawful basis, DPAs, access controls, auditability, breach processes. ZDR is one strong control *within* that framework: it shrinks the attack surface and the retention footprint, which helps with data-minimization principles. But you still need the rest.

The regulatory pressure driving ZDR adoption is real: GDPR in Europe, HIPAA in the US, and the EU AI Act all push toward data minimization and tighter privacy guarantees. For many enterprise buyers processing sensitive data, ZDR has moved from "nice to have" to a contractual prerequisite for deployment. That's exactly why it's worth understanding precisely rather than taking on faith.

---

A practical buyer's checklist

Before you rely on a "ZDR" label, confirm:

  • Get it in the contract. ZDR is a negotiated term (usually enterprise-tier), not an implied default. Verify it's written down.
  • Map the scope. Which products does it cover — API only, or also console/workbench/chat surfaces? Beta features?
  • Read the carve-outs. What's the retention window for flagged/abuse content? What metadata survives? What are the legal-hold terms?
  • Check model availability. Does ZDR exclude any models you want to use (retention-floor models)?
  • Confirm the enforcement model. Real-time abuse monitoring vs. retained-log review — and who/what can access data in flight.
  • Don't stop at ZDR. Pair it with encryption, access controls, DPAs, and the compliance framework your regulators actually require.

---

The bottom line

Zero Data Retention is one of the most effective single controls for reducing the risk of putting sensitive data through a third-party model — it removes the durable copy that would otherwise be the biggest liability. But it's a control, not a guarantee, and "zero" comes with well-defined exceptions for safety, legal, and specific models. Treat it as a precise contractual mechanism to verify and scope, not a magic word. Read the fine print, map it to your obligations, and it becomes exactly what enterprises need: a defensible answer to "where does our data go?"

---

日本語まとめ:ゼロデータ保持(ZDR)とは

企業が AI を本番投入する前に必ず問うのが「自社データはどこへ行くのか」です。顧客情報・ソースコード・医療データを第三者のモデルに通す以上、この答えでプロジェクトの可否が決まります。ゼロデータ保持(Zero Data Retention, ZDR)は、その答えとして買い手が求める強力な統制手段——しかし「ゼロ」という語が実態以上に独り歩きしがちです。

ZDR の定義

ZDR は、プロバイダがあなたのプロンプト・出力・関連メタデータを、その API 呼び出しの範囲を超えて保存・記録・再利用しない運用モードです(学習にも、製品改善にも、人間レビューにも使わない)。データは応答生成のために流れ、数秒以内に破棄され、永続的な記録は残りません。通常の API では乱用監視やデバッグのために一定期間(多くは約30日)保持されますが、ZDR はその永続化層を外します。

仕組み

  • ログ除外ルーティング … 永続化層を迂回し、保存前に破棄。
  • ステートレス推論 … 応答後は何も保持しない。
  • リアルタイム乱用監視 … 保存ログの事後レビューではなく、リクエスト中に分類器を実行。

「ゼロ」は完全なゼロとは限らない(重要)

  • 安全性の例外 … 利用規約違反として検知された内容は、ZDR/HIPAA 下でも最長2年程度保持されることがあり、分類スコアはさらに長期の場合も。
  • 法的保持・メタデータ … 法令・安全上の義務のため限定的に保持され得る。
  • モデル別の保持下限 … 一部のフロンティアモデルは最低保持期間を要し、ZDR では利用不可。例:Anthropic の Claude Fable 5 は30日保持が必須で、ZDR 組織からのリクエストは 400 エラー。
  • 適用範囲 … 通常は API のみ。Anthropic の ZDR は Anthropic API が対象で、Console/Workbench・Claude for Work・ベータ等は個別交渉が必要。OpenAI もエンタープライズ契約で明示合意が前提。

ZDR は「統制」であって「コンプライアンス証明」ではない

ZDR 単体では GDPR・HIPAA・EU AI Act 準拠にはなりません。これらはデータ最小化・適法根拠・DPA・アクセス制御・監査性など全体の枠組みを要求します。ZDR は保持フットプリントと攻撃面を縮小する枠組みの中の一つの強力な統制です。規制圧力(GDPR・HIPAA・EU AI Act)を背景に、機微データを扱う多くの企業では ZDR は「あれば良い」から契約上の必須要件へと移りました。

実務チェックリスト

契約に明記されているか/適用範囲(API のみか)/例外条項(検知コンテンツの保持期間・残るメタデータ・法的保持)/使いたいモデルが除外されないか/執行方式(リアルタイム監視か)/ZDR だけに頼らず暗号化・アクセス制御・DPA・規制枠組みと併用する。

まとめ

ZDR は、機微データを第三者モデルに通すリスクを下げる最も効果的な単一統制の一つですが、保証ではなく統制であり、「ゼロ」には安全・法的・モデル別の明確な例外が伴います。魔法の言葉ではなく、検証し範囲を定める契約上の仕組みとして扱うこと。細部を読み、自社の義務に対応づければ、「データはどこへ行くのか」への説得力ある答えになります。

---

Sources

---

Related reading