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 數、延遲、模型、成本等請求中繼資料。
在 OpenRouter 上把 ZDR 變成硬性條件
供應商提供 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，強制執行就生效。請求層級只能確保 ZDR 開啟，不能覆蓋或放寬帳戶層級或 guardrail 的規則。
驗證供應商的 ZDR 宣稱
別只看行銷文案。OpenRouter 建議檢查五件事：
- ZDR 涵蓋哪些確切資料？是否包括 prompt、completion、上傳檔案、工具輸入、快取表示、識別碼？
- 政策是每個供應商一套，還是每個端點一套？模型功能與 API 端點可能有不同儲存要求，供應商層級的聲明可能隱藏排除項目。
- 哪些東西不在政策內？中繼資料、外掛、工具、prompt 快取、回應快取、日誌、batch API、有狀態功能都要問。
- ZDR 怎麼強制執行？要找帳戶政策、guardrail 或請求層級路由控制，而不是手動挑供應商。
- 怎麼驗證持續符合資格？資料政策會變。OpenRouter 維護端點層級政策資訊，並在
https://openrouter.ai/api/v1/endpoints/zdr發布目前的 ZDR 端點清單，讓路由決策跟著現行政策走，而不是靜態試算表。
把 ZDR 放進你的隱私控制組合
ZDR 是其中一個控制項，不是全部。它跟其他隱私控制回答不同問題：
- 「不訓練你的資料」：管你的輸入會不會改進模型。ZDR 管供應商是否在回應回傳後儲存那些輸入。需要兩者就都強制執行。
- 資料落地與區域固定：管請求在哪裡處理（例如 GDPR 的歐盟境內），ZDR 管資料之後是否被保留。供應商可能在歐盟處理並保留請求，也可能在別處處理 ZDR 請求。政策同時指明處理位置與保留要求時，兩個控制項都要用。OpenRouter 在 Business 與 Enterprise 方案提供美國與歐盟的區域路由，透過
us.openrouter.ai和eu.openrouter.aiAPI 網域，這跟 ZDR 強制執行是分開的。 - 自託管：把推論留在自己的基礎設施裡。選擇之前，先確認區域固定、ZDR 路由、per-key 或 per-workspace guardrails、自己的日誌記錄是否滿足需求。政策禁止所有第三方處理（包括暫時性推論）時，才需要自託管。
敏感推論流量要組合使用：ZDR 管保留、data_collection: "deny" 管儲存與訓練限制、區域路由管處理位置。然後檢查應用程式日誌、啟用的工具、快取設定，避免另一層把你從供應商端移除的資料又重建出來。
這跟把終端機交給任何模型：OpenRouter 的 Shell 工具如何改變代理的執行邊界裡討論的工具邊界問題是同一類：你以為資料只在模型與你之間流動，但每個啟用的工具、外掛、快取層都可能變成新的保留點。ZDR 只解決其中一層，剩下的要自己盤點。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。