Claude Fable 5 無法在 ZDR 下執行：強制保留資料 30 天

如果組織依零資料保留（ZDR）協議使用 Claude，第一次向 claude-fable-5 發出請求時，不會收到 completion，而是 400 invalid_request_error。這不是服務中斷，而是政策限制。Fable 5 是第一個正式上線、若不接受保留資料 30 天就無法使用的 Claude 模型。無論透過 Claude API、AWS Bedrock、Google Vertex AI 或 Microsoft Foundry 使用，都必須明確選擇接受資料保留。

對於原本將「供應商不會保留資料」視為 LLM 技術堆疊既定特性的團隊，這是架構層級的變化。本文將說明政策內容、保留 30 天的原因、各雲端平台的實作方式，以及這項變更對消費者產品和敏感資料產業的影響。

TL;DR

• Claude Fable 5 必須保留 prompt 與 completion 30 天才能使用；Claude API、AWS Bedrock、Google Vertex AI 和 Microsoft Foundry 均適用此規定（政策自 2026-06-09 生效）。
• 無法選擇退出：受零資料保留協議約束的組織會收到 400 invalid_request_error，既有 ZDR 條款不會延伸適用。
• 在 Bedrock 上，Fable 5 必須設定 data_retention_mode: provider_data_share；否則模型會顯示為不可用。
• 被標記為違反 Usage Policy 的內容，最多可保留 2 年，不受 30 天期限限制。

政策細節已於 2026-06-12 對照 Anthropic、AWS、Google 與 Microsoft 公開文件確認。政策可能變更，請查閱連結中的第一手資料及自身合約。本文是工程概覽，不構成法律意見。

政策實際規定

Anthropic 將 Claude Fable 5 和 Claude Mythos 5 列為涵蓋模型。依據 API 資料保留文件與 Mythos 系列模型資料保留實務說明（自 2026-06-09 生效）：

• Prompt 與 completion 會保留 30 天，之後自動刪除。但若內容因安全調查而被標記，或法律要求保留，則不在此限。
• 無法選擇退出。 接受資料保留是使用模型的必要條件。若組織的資料保留設定不符合要求，請求會回傳 400 invalid_request_error。
• 存取權限刻意設得很嚴格。 資料先由自動化安全系統篩選，只有少數經核准的人員能檢視被標記的對話。他們無法匯出、複製或下載資料，而且每次存取都會寫入防竄改日誌。
• 既有 ZDR 協議不適用於涵蓋模型的流量，即使透過雲端平台呼叫也一樣。

消費者方案（Claude Free／Pro／Max）不受影響，因為這些方案原本就適用各自的資料保留條款。這項政策針對的是商用 API，而「絕不保留資料」的承諾通常正是用在這裡。

為什麼要保留 30 天

涵蓋模型說明提出了明確理由：這些模型在軟體工程、agentic workflow 與資安方面的能力大幅提升，而且**「某些濫用行為必須綜合大量請求後才能偵測出來。」** 文件列舉的 best-of-N 越獄攻擊與國家級間諜活動，都屬於單看每個 prompt 並無異常、只有整段請求序列才能判斷的攻擊模式。刪除序列後就無從偵測。

這個保留期限不是：

• 不是訓練資料。 Anthropic 表示，除非取得明確許可，否則絕不會將保留資料用於訓練。用途僅限於偵測濫用。
• 概念並不新，強制執行才是新變化。 約 30 天的濫用監控期限多年來一直是業界預設做法：OpenAI 最多保留 API 濫用日誌 30 天（經核准後可採 ZDR）；Azure OpenAI 最多儲存 prompt 30 天，除非獲准採用調整過的濫用監控機制。真正的改變是，這個期限對某一類模型已無協商空間。此前，每家供應商都提供零資料保留的例外方案。

另一個早已存在、卻常讓人意外的限制是：即使採用 ZDR，Anthropic 仍會保留安全分類器的結果；被標記為違反 Usage Policy 的內容最多可保留 2 年。零資料保留從來不等於完全不留任何資料，而是正常流程中不保留未被標記的內容。

相同要求，三個雲端，三種機制

無論模型在哪裡執行，都適用相同的資料保留要求。但各平台採用不同的同意機制，而這些差異會決定由誰處理資料，以及控制措施設在哪一層。

AWS Bedrock 的規則最明確。資料保留是一種可設定模式（default／provider_data_share／none），套用順序為專案 → 帳號 → 模型預設值。Fable 5 宣告 allowed_modes: ["provider_data_share"]，也就是 prompt 與 completion 會與 Anthropic 共享，並保留最多 30 天。採用其他模式時會顯示：

{
  "id": "anthropic.claude-fable-5",
  "status": "unavailable",
  "status_reason": "This model is not available under data retention mode 'default'.",
  "data_retention": {
    "mode": "default",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

Fable 5 之前的模型不受影響。也可以針對 bedrock:DataRetentionMode 條件鍵設定 SCP，在整個組織強制執行資料政策，避免有人為了嘗試新模型而私自切換帳號設定。另需注意：使用跨區域推論時，保留的副本位於目的地區域。若組織有資料落地承諾，這一點會直接影響合規。

Google Vertex AI 會先檢查專案層級的 Anthropic 資料共享設定（setPublisherModelConfig 搭配 dataSharingEnabledProvider: "anthropic"），並要求在 Model Garden 接受條款，詳見 Google 的 Fable 5 文件。一般資料處理方式依循 Vertex AI 資料治理政策。對資料落地位置敏感的工作負載，可透過 Vertex 的區域與多區域端點控制推論執行地點，而現在這也包含保留副本的存放位置。

Microsoft Foundry 的架構不同。Microsoft 的資料與隱私權文件明確指出，Claude 模型是第三方市集服務：部署時接受 Anthropic 的條款，而且資料處理者是 Anthropic，而非 Microsoft。Azure OpenAI 的 ZDR 與調整後濫用監控方案不適用於 Claude 部署。若組織在其他環境採用 ZDR，通常會把涵蓋模型隔離在專用訂閱中，讓資料保留邊界由架構保證，而不是只靠流程控管。

三個平台呈現出相同趨勢：資料保留類別已成為機器可讀的一級模型屬性，可能表現為模式、旗標或條款閘門，不再只是合約裡的一段文字。基礎設施現在能直接強制執行資料政策，也應該這麼做。

對企業部署的影響

如果沒有 ZDR 協議，系統機制上不會改變。原本就可能採用類似保留 30 天的政策，只是團隊未必意識到。現在要做的是在供應商文件中把這點寫清楚。

如果已有 ZDR 協議，有三種選擇：

1. 不使用涵蓋模型。 保持全面一致的 ZDR，但放棄該模型。如果工作負載不需要它，這是可行方案。模型成本及差異可參考我們的 Fable 5 實測評估。
2. 依 workspace 或專案切分。 每個平台都支援限定範圍的同意設定：指定 Claude API workspace（Console → Settings → Workspaces → Privacy controls）、採用 provider_data_share 的 Bedrock 專案，或獨立的 Vertex 專案或 Azure 訂閱。只將可接受資料保留的工作負載路由到該環境。
3. 全組織接受資料保留。 維運最簡單，但會在沒有明確提示的情況下，降低所有工作負載的資料保護承諾，包括原本因敏感性而需要 ZDR 的工作負載。這應由資料保護負責人決定，而不是當成一般設定變更。

無論使用哪家供應商，自有日誌是第二個資料保留面。 如果閘道或可觀測性系統記錄完整 prompt，保留時間可能比供應商更長，而且資料就在自己的環境中。供應商的承諾是否有意義，取決於前一層如何處理資料。我們在快取聲明稽核中採用的邏輯，同樣適用於此。

對消費者產品的影響

如果產品面向消費者，並將使用者內容路由至涵蓋模型，無論是否簽訂 ZDR 協議，這項變更都會影響自身的法律文件。具體有三項後果：

1. 隱私權聲明很可能需要更新。 多數法規不只要求揭露資料蒐集，也要求說明保留方式：GDPR 第 13(2)(a) 條要求在蒐集時說明保存期限或判定標準；加州 CPRA 要求蒐集時的告知內容，必須按個人資料類別列出保留期限。如果隱私權聲明明示或暗示對話資料不會在任何地方保留，而資料處理者實際保存副本 30 天，該聲明就是錯的。應更新隱私權聲明、處理活動紀錄及 DPA 清冊。

2. 不能提供自己也沒有的退出選項。 資料保留機制不設例外，因此無法在繼續使用該模型的同時，讓特定使用者的 prompt 不被保留。真正能控制的是路由：具備同意狀態感知能力的閘道，將拒絕資料共享的使用者導向符合 ZDR 的模型，其餘使用者才導向涵蓋模型。這只是把法律限制轉成一般路由規則，遠比提供一個實際不起作用的偏好設定勾選框合理。

3. 刪除請求的處理流程必須準確。 刪除義務（GDPR 第 17 條、CPRA 刪除權及其他同等規定）也延伸至資料處理者。資料在固定期限內保留，並於 30 天內自動刪除，通常是可合理說明的資料處理方式。但 DSAR 作業手冊應如實記載，而不是承諾無法執行的下游即時刪除。

全球法規會進一步放大影響：英國 GDPR、巴西 LGPD，以及愈來愈多美國州級隱私法，都有類似的揭露與資料處理者規範。對中國使用者而言，PIPL 還有兩項更嚴格的要求：向另一個資料處理者提供個人資料通常需要單獨同意；若將中國使用者內容路由至境外 LLM 端點，則屬跨境傳輸，必須採用認可機制，例如安全評估、標準合約或認證。模型升級一旦改變由誰保留哪些資料、保留地點與期限，就必須依這些法規重新處理相關文件。

敏感資料產業：30 天保留期影響最大的領域

對大多數產品而言，供應商的資料保留期限只是文件問題。但在資料本身受監管的產業，這就是架構問題：保留在供應商端的副本，屬於供應商持有的受監管靜態資料，而產業法規會直接規範這些資料。

醫療照護（HIPAA）

HIPAA 不要求零資料保留，而是要求任何持有受保護健康資訊的供應商，都必須在**商業夥伴協議（BAA）**下採取適當保護措施。Prompt 的 30 天副本屬於商業夥伴持有的靜態 PHI，關鍵在於 BAA 是否涵蓋這些資料。兩大 API 供應商採用不同架構，而這項差異現在很重要：Anthropic 支援 HIPAA 的 API 存取明確表示不要求 ZDR，其基礎是保留資料並實施保護措施，包括加密、存取控制、稽核日誌與強制功能限制。OpenAI 的 API BAA則涵蓋符合零資料保留資格的端點。若 BAA 的範圍限定為 ZDR 端點，結構上就不可能涵蓋強制保留資料的模型。

模型的資料保留類別現在會直接影響 BAA 適用資格。 在將 PHI 路由至特定模型前，應取得書面確認，確保 BAA 涵蓋該模型。透過雲端使用時，也別忘了資料處理鏈會改變：Bedrock 上的平台是商業夥伴；Foundry 上則由 Anthropic 直接處理資料。另有一個容易踩到的問題：結構化輸出的 JSON schema 定義中絕不能放入 PHI，因為快取的 schema 不享有與訊息內容相同的保護。

兒童產品（COPPA）

這項政策出現的時間很不巧：FTC 修訂後的 COPPA Rule已於 2025 年 6 月 23 日生效，多數條款要求在 2026 年 4 月 22 日前完成合規。業者才剛實作完新的資料保留義務，第一個強制要求供應商端保留資料的模型就上線了。其中兩項規定與 30 天保留期直接相關：現在必須提供書面且公開的資料保留政策（§312.10），說明蒐集哪些兒童資料、蒐集原因以及刪除時間；同時禁止無限期保留，資料只能在達成蒐集目的所合理必要的期間內保存。

設定明確的 30 天期限並自動刪除，形式上與規範相容。但供應商保留資料是為了自身的信任與安全目的，而不是業者蒐集兒童資料的目的，因此隱私權聲明必須準確描述資料處理者關係。針對為了盡量縮小資料足跡而採用 ZDR 的兒童導向產品，同樣應從路由著手，而且風險更高：兒童流量必須留在符合 ZDR 的模型上；否則必須先把涵蓋模型的保留期限納入 §312.10 政策。

相同模式，其他產業

只要掌握這個結構，也就是受監管資料、供應商端的保留副本、規範保留方式的產業法規，就會發現其他領域也有相同問題：

• 生物特徵資料（伊利諾州 BIPA）： 業者必須為生物特徵資料制定書面、公開的保留時程與銷毀準則。如果 prompt 含有生物特徵識別資料，供應商保留 30 天的副本也必須列入時程。
• 支付資料（PCI DSS／GLBA）： PCI DSS 禁止在授權完成後儲存敏感驗證資料，無論儲存地點為何。將卡片資料貼入 prompt，等於讓供應商保留卡片資料 30 天。正確做法是在上游遮蔽資料，而不是事後補文件。
• 教育資料（FERPA）： 依學校官員例外條款處理學生紀錄的供應商，必須持續受學校直接控制。學校無法存取或提前刪除的安全保留副本，很難與這項標準相容。EdTech 流量進入涵蓋模型前，應先徵詢法律顧問。
• 金融服務的反向情境（SEC／FINRA）： 券商必須依帳簿與紀錄規則保留商務通訊。對這類機構而言，供應商的保留期限不是問題，能否自行保存符合法規的副本才是。同樣是資料保留問題，方向正好相反。

共同點是：產業法規會從兩個方向規範資料保留，而且必須根據所在產業的要求，把無法自行控制的供應商端保留期限納入合規設計。

決策檢查清單

• ✅ 盤點流量實際經過哪些模型。 資料保留類別現在是模型層級，而不是供應商層級的屬性。
• ✅ 如果已有 ZDR，請明確做出選擇：不使用涵蓋模型、依 workspace／專案／訂閱切分，或全組織接受資料保留。不要讓這項變更在不知情下發生。
• ✅ 透過基礎設施強制執行政策，例如 Bedrock SCP、workspace 隱私權控制與獨立雲端專案，而不是只把規則寫在 wiki。
• ✅ B2C 產品應更新隱私權聲明與 DSAR 作業手冊；將不同意資料共享的使用者路由至符合 ZDR 的模型，而不是提供無法生效的退出選項。
• ✅ 處理受監管資料時，應逐一取得各模型的書面涵蓋確認，包括 PHI 的 BAA、兒童資料的 §312.10 政策，以及生物特徵資料的保留時程。確認完成前，不要將這類資料路由至強制保留資料的模型。
• ✅ 稽核自有日誌。 如果閘道無限期記錄 prompt，供應商的 30 天期限就沒有意義。

結論

Fable 5 的 30 天資料保留期限不是為了蒐集資料，而是有期限且限定用途的濫用監控。這與業界多數供應商原本的預設做法一致。由於刪除資料後無法跨請求偵測濫用，因此這項要求在特定模型類別上改為強制執行。對多數團隊而言，工程影響為零，治理工作只是在供應商審查文件中增加一段說明。

但對合規策略建立在零資料保留假設上的組織，例如限定 ZDR 範圍的 BAA、宣稱不會留存任何資料的隱私權聲明，以及以資料最小化為基礎的兒童產品，Fable 5 代表這項假設不再適用於所有模型。解法不是完全避開這個模型，而是把資料保留類別當成每個模型的明確路由條件，就像價格與上下文視窗一樣。

FAQ

可以在零資料保留協議下使用 Claude Fable 5 嗎？ 不可以。Fable 5 與 Mythos 5 都是必須保留資料 30 天的涵蓋模型。ZDR 組織必須為某個 workspace 啟用保留 30 天，並將 Fable 5 流量路由至該 workspace，否則會收到 400 invalid_request_error。

改用 AWS Bedrock、Vertex AI 或 Microsoft Foundry，能避開這項要求嗎？ 不能。各平台都會透過自己的資料保留同意機制限制模型使用：Bedrock 使用 provider_data_share；Vertex 要求 Anthropic 資料共享設定與 Model Garden 條款；Foundry 則要求部署時接受 Anthropic 條款，而資料處理者是 Anthropic，不是 Microsoft。任何平台都不會延用既有 ZDR 安排。

終端使用者能選擇退出資料保留嗎？ 不能，沒有任何退出機制。能控制的是路由：將拒絕資料共享的使用者導向符合 ZDR 的模型。不要提供實際上不會改變任何行為的偏好設定開關。

保留的資料會用於訓練模型嗎？ Anthropic 表示，未經明確許可，絕不會將保留資料用於訓練。資料僅供信任與安全審查使用：先由自動化系統篩選，被標記的對話只能由經核准的人員檢視，這些人員無法匯出資料，且所有存取都會記錄在防竄改日誌中。

保留 30 天會改變 prompt 快取的運作方式嗎？ 不會。快取項目仍採用各自的短 TTL（5 分鐘或 1 小時），Fable 5 的快取契約也沒有改變，詳見我們的實測評估。30 天期限是另一套平行機制，用於安全審查的資料保留。

延伸閱讀：Prompt 快取完整指南說明與資料保留政策互相影響的快取機制；平台定價則列出各模型的供應商牌價。

資料來源

• Anthropic — API 與資料保留
• Anthropic — 涵蓋模型
• Anthropic — Mythos 系列模型的資料保留實務
• AWS — Amazon Bedrock 資料保留
• Google Cloud — Claude Fable 5（合作夥伴模型）
• Google Cloud — Vertex AI 資料治理
• Microsoft — Foundry 中的 Claude：資料、隱私權與安全性
• OpenAI — 企業隱私權
• OpenAI — API 服務的 BAA
• FTC — COPPA Rule 修正案（新聞稿）
• Federal Register — 兒童線上隱私保護規則

以上資料均於 2026-06-12 查核。政策可能變更，請確認最新文件及自身合約。本文不構成法律意見。

← 返回部落格