ZDR 不是隱私萬靈丹：把「零保留」當成可強制執行的路由條件

摘要： Zero Data Retention（ZDR）這個名字聽起來像「什麼都不留存」，不過 OpenRouter 對它的定義收得很緊：供應商處理你的 prompt、把回應交回來，之後不保存這兩樣東西。它的效力只限於供應商那一端的保留政策，既不能保證資料沒離開你的網路，也管不到你自己的應用程式寫了什麼紀錄。

ZDR 能回答的問題，比你想的少

Zero Data Retention（ZDR）這個名字聽起來像「什麼都不留存」，不過 OpenRouter 對它的定義收得很緊：供應商處理你的 prompt、把回應交回來，之後不保存這兩樣東西。它的效力只限於供應商那一端的保留政策，既不能保證資料沒離開你的網路，也管不到你自己的應用程式寫了什麼紀錄。

換個角度，把 ZDR 當成一條路由條件來用，而不是一份看完就收起來的隱私保證，實務上會順手得多。OpenRouter 判讀資料政策時看的是端點層級，原因很簡單：同一家供應商底下不同模型的端點，保留規則未必一致。遇到無法確認政策的端點，他們的處理方式是從嚴——直接歸入「會保留、而且可能拿去訓練」那一類。

三個問題裡，ZDR 只回答得了第一個：

• 靜態保留：回應送出之後，供應商手上還留著 prompt 與回應嗎？這題歸 ZDR 管。
• 傳輸中的資料：請求照樣會離開你的環境、送到供應商，模型照樣會讀取它。ZDR 改不了這件事。
• 用於訓練：供應商會不會拿你的輸入回頭改進模型？這是另一組控制，即使供應商習慣把它跟 ZDR 講在一起。

「不訓練」跟「零保留」是兩回事。供應商可以承諾不訓練，卻仍為了濫用偵測或法律義務把資料暫時留著。反過來倒是站得住腳：端點既然不留資料，日後自然也無從拿它去訓練。

不在 ZDR 守備範圍內的東西

ZDR 的界線畫得很具體：符合資格的推論端點，它在供應商端保證不留存，其他系統則不在其中。只要還有別的環節碰過你的請求，那套政策不會自動跟著過去。

實務上常被忽略的幾個缺口：

• 你自己的應用程式日誌：一個符合 ZDR 的請求，照樣可能在錯誤追蹤服務、分析事件、資料庫欄位或應用程式日誌裡留下一份完整 prompt。供應商不留，跟你手上沒有副本，是兩件事。
• 外掛與工具：一旦開啟 web search 外掛或串接其他外部工具，這些工具會依自己的保留條款收到請求內容。流程對保留有嚴格要求時，這些政策得單獨審一遍。
• 快取：供應商在記憶體裡做的 prompt 快取不會與 ZDR 衝突，因為 prompt 從頭到尾沒進到持久儲存。但 OpenRouter 自家的回應快取是另一回事，它會把生成好的回應暫存起來；帳戶層級的 ZDR 會關掉回應快取，而請求層級的 provider.zdr 欄位對回應快取資格沒有作用。如果你的要求是每一層都零儲存，回應快取的設定要自己另外確認。
• 中繼資料：除非你主動開啟輸入輸出記錄，否則 OpenRouter 不留 prompt 或回應的內容；但 token 數、延遲、模型、成本這類請求中繼資料仍會保留。

讓 ZDR 在 OpenRouter 上成為硬規則

供應商有 ZDR，不代表你送出的每個請求都自動合規。這個條件得由你來開：可以下在帳戶層級、guardrail，或單一請求上。

帳戶層級：進到隱私設定，就能按模型群組（Anthropic、OpenAI、Google、SpaceXAI、非前沿端點）個別要求 ZDR，不必動到程式碼。guardrails 也是另一條強制執行的路徑。

請求層級：在 provider 區塊中放入 zdr 欄位。填 true，這次請求就只會落到帶有 ZDR 政策的端點；填 false 或整欄省略，對路由沒有影響。

{
  "model": "meta-llama/llama-3.3-70b-instruct",
  "messages": [{ "role": "user", "content": "Hello" }],
  "provider": {
    "zdr": true,
    "data_collection": "deny"
  }
}

搭配使用的 data_collection 控制項可接受 "allow"（預設值）或 "deny"。填 "deny" 代表排除那些會以非暫時性方式儲存使用者資料、而且可能用於訓練的端點。

請求層級的 zdr 與帳戶層級、guardrail 的設定之間是 OR 關係：三者任一打開，強制執行就成立。反過來說，這一項只能把 ZDR 打開，無權覆寫或放寬帳戶與 guardrail 已經設下的規定。

怎麼查證供應商的 ZDR 說法

單看行銷文案不夠。OpenRouter 建議把五個問題問清楚：

1. ZDR 到底涵蓋哪些資料？prompt、completion、上傳的檔案、工具輸入、快取表示、識別碼，是否都在其中？
2. 政策是依供應商一套，還是依端點各有一套？同一個模型功能與 API 端點可能有不同的儲存要求，供應商層級的聲明底下可能藏著排除條款。
3. 政策之外還漏掉什麼？中繼資料、外掛、工具、prompt 快取、回應快取、日誌、batch API、有狀態功能，這些都要逐一追問。
4. ZDR 靠什麼機制落實？該找的是帳戶政策、guardrail 或請求層級的路由控制，而不是靠人工挑供應商。
5. 怎麼確認資格一直有效？資料政策會變動。OpenRouter 把端點層級的政策資訊維護起來，並在 https://openrouter.ai/api/v1/endpoints/zdr 公布當下的 ZDR 端點清單，讓路由決策依據現行政策，而不是一份過期的靜態試算表。

ZDR 在你整體隱私控制裡的位置

ZDR 只是眾多控制項裡的其中一個，並非全部。它與其他隱私控制各自回答不同的問題：

• 「不拿你的資料訓練」：處理的是你的輸入會不會被用來改進模型；ZDR 處理的則是回應送出之後，供應商還留不留那些輸入。兩者都必要時，就兩者都強制執行。
• 資料落地與區域固定：決定請求在哪裡被處理（例如 GDPR 要求的歐盟境內），ZDR 決定資料事後是否留存。供應商完全可能在歐盟處理請求卻把它保留，也可能在別的地方處理一筆 ZDR 請求。當政策同時規定了處理位置與保留要求，這兩項控制就都得用上。OpenRouter 在 Business 與 Enterprise 方案提供美國與歐盟區域路由，分別走 us.openrouter.ai 和 eu.openrouter.ai API 網域，這件事跟 ZDR 的強制執行是兩條獨立的線。
• 自託管：把推論整個留在自家基礎設施。決定走這條路之前，先確認區域固定、ZDR 路由、per-key 或 per-workspace guardrails、以及自家日誌記錄能不能滿足需求。只有當政策全面禁止第三方處理（連暫時性推論也不行）時，自託管才是非做不可的選項。

面對敏感推論流量，正確做法是多層並用：用 ZDR 管保留，用 data_collection: "deny" 管儲存與訓練限制，用區域路由管處理位置。接著回頭檢查應用程式日誌、已啟用的工具與快取設定，別讓另一層又把你從供應商端清掉的資料重建出來。

這跟把終端機交給任何模型：OpenRouter 的 Shell 工具如何改變代理的執行邊界談到的工具邊界屬於同一類問題：你以為資料只在模型與你之間往返，然而每一個啟用的工具、外掛或快取層，都可能變成新的保留點。ZDR 只能處理其中一層，其餘的得靠自己一一盤點。

參考來源

• Zero Data Retention (ZDR): What It Means for AI APIs — OpenRouter Blog