Claude Fable 5 的 30 天資料保留:ZDR、HIPAA、COPPA

目錄
  1. 政策的實際內容
  2. 30 天保留期限存在的原因
  3. 相同需求,三個雲端,三種機制
  4. 對企業部署的意義
  5. 這對面向消費者的產品意味著什麼
  6. 敏感資料產業:30 天保留期衝擊最深之處
  7. 醫療保健(HIPAA)
  8. 兒童產品(COPPA)
  9. 其他產業的相同模式
  10. 決策檢查清單
  11. 結論
  12. 常見問題
  13. 資料來源

如果您的組織在零資料保留(ZDR)協議下使用 Claude,那麼您對 claude-fable-5 的第一次請求不會回傳完成結果,而是回傳 400 invalid_request_error。這不是服務中斷——這是政策規定。Fable 5 是第一個正式上市、必須啟用 30 天資料保留才能使用的 Claude 模型,且此要求在每個平台上均適用:Claude API、AWS Bedrock、Google Vertex AI 以及 Microsoft Foundry,皆要求明確同意保留條款後才能存取。

對於那些將「我們不保留您的資料」視為 LLM 技術堆疊既定特性的團隊而言,這是一次架構層面的重大變動。本文將說明該政策的具體內容、保留期限存在的原因、各雲端平台的實作方式,以及這對消費者產品和敏感資料產業帶來的影響。

政策細節已於 2026-06-12 對照 Anthropic、AWS、Google 及 Microsoft 的公開文件進行核實。政策可能隨時變更,請以連結的原始資料來源及您自身的合約為準。本文為工程概述,不構成法律建議。


政策的實際內容

Anthropic 將 Claude Fable 5 和 Claude Mythos 5 列為涵蓋模型(Covered Models)。根據 API 資料保留文件Mythos 系列保留實務文章(自 2026-06-09 起生效):

  • 提示詞與完成結果將保留 30 天,之後自動刪除——除非被標記為進行中的安全調查,或依法須予保存。
  • 不提供退出選項。 資料保留是使用該模型的前提條件。若組織的保留設定不符合要求,請求將回傳 400 invalid_request_error
  • 存取範圍刻意受限。 自動化安全系統會篩查資料;只有少數經核准的人員可審閱被標記的對話,且無法匯出、複製或下載,每次存取均記錄於防竄改日誌中。
  • 現有 ZDR 協議不適用於涵蓋模型的流量——包括透過雲端平台的流量。

消費者方案(Claude Free/Pro/Max)不受影響——這些方案已依其自身的保留條款運作。此政策針對的是商業 API 層面,而「我們從不保留資料」的承諾恰恰多存在於此。


30 天保留期限存在的原因

涵蓋模型文章中的說明相當具體:這些模型在軟體工程、代理工作流程及網路安全方面具備大幅提升的能力,而**「某些形式的濫用只有在跨越多次請求後才能被偵測到。」** 所舉的例子——最優 N 次越獄攻擊(best-of-N jailbreaking)、國家級間諜活動——都是每個提示詞看似無害、只有整個序列才具診斷意義的攻擊模式。已刪除的序列無從偵測。

以下兩點是此保留期限不代表的意涵:

  • 不是訓練資料。 Anthropic 聲明,未經明確許可,保留的資料絕不用於訓練。其目的僅限於濫用偵測。
  • 性質上並非新規——強制執行才是新的。 約 30 天的濫用監控期限多年來一直是業界預設做法:OpenAI 將 API 濫用日誌保留最多 30 天(ZDR 需經核准);Azure OpenAI 除非獲准採用修改版濫用監控,否則提示詞最多保留 30 天。改變之處在於,此保留期限對特定模型類別變為不可協商——此前每家供應商都提供零保留的退出選項。

有一個讓人意外的既有注意事項:即使在 ZDR 條件下,Anthropic 仍會保留安全分類器的結果,且被標記為違反使用政策的內容可保留最多 2 年。零資料保留從來不等於零資料——它的意思是在正常流程中不保留未被標記的內容。


相同需求,三個雲端,三種機制

資料保留政策適用於模型運行的任何地方,但各平台的啟用方式各不相同——這些差異決定了誰來處理您的資料,以及您的控制權在哪裡。

平台啟用機制範圍未啟用時的行為
Claude API隱私設定中的 30 天保留組織或工作區400 invalid_request_error
AWS Bedrockdata_retention_mode: provider_data_share帳戶或專案模型顯示為 unavailable;請求被封鎖
Google Vertex AIAnthropic 資料共享 + Model Garden 條款專案啟用前請求被封鎖
Microsoft Foundry部署時接受 Anthropic 條款訂閱/部署完全不在 Azure ZDR 計畫的涵蓋範圍內

AWS Bedrock 是最明確的。資料保留是一個可設定的模式default / provider_data_share / none),解析順序為專案 → 帳戶 → 模型預設值。Fable 5 宣告 allowed_modes: ["provider_data_share"]:提示詞與回應內容會與 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 策略的組織,通常會將 Covered Model 的使用隔離在專屬訂閱中,使保留邊界成為結構性安排,而非程序性安排。

三個平台的共同模式是:保留類別已成為一等、機器可讀的模型屬性——以模式、旗標或條款閘道的形式呈現——而非合約中的一段文字。您的基礎設施現在可以強制執行您的資料策略,而且應該這樣做。


對企業部署的意義

若沒有 ZDR 協議,機制上不會有任何改變——您原本就處於類似 30 天保留的狀態,只是可能沒有意識到。現在的工作是在您的供應商文件中將其明確化

若有 ZDR 協議,您有三種選擇:

  1. 跳過 Covered Models。 ZDR 保持一致;您放棄使用該模型。若您的工作負載不需要它,這是可行的選項——請參閱我們的 Fable 5 實測評估,了解其代價與差異所在。
  2. 依工作區或專案拆分。 每個平台都支援範圍化的啟用方式:指定的 Claude API 工作區(Console → Settings → Workspaces → Privacy controls)、設定了 provider_data_share 的 Bedrock 專案、獨立的 Vertex 專案或 Azure 訂閱。僅將可接受保留的工作負載路由至該處。
  3. 在整個組織範圍內接受保留。 操作上最簡單,但會悄悄降低所有工作負載的保障——包括那些因敏感性而需要 ZDR 的工作負載。這是資料保護負責人的決策,而非一個設定變更。

無論使用哪家供應商:您自己的日誌記錄是第二個保留面。 若您的閘道或可觀測性堆疊記錄了完整的提示詞,您實際上在自己的環境中執行著比供應商更長的保留窗口。供應商的保證只有在其前端層面同樣嚴謹時才有意義——我們在快取聲明稽核中採用的相同稽核邏輯,在此同樣適用。


這對面向消費者的產品意味著什麼

如果您服務的是一般消費者,並將其內容透過受涵蓋模型(Covered Model)進行路由,那麼無論是否簽有 ZDR 協議,這項變更都會延伸至您自身的法律責任範圍。以下是三個具體影響:

1. 您的隱私權聲明可能需要更新。 大多數法規要求揭露資料保留方式,而不僅僅是收集方式:GDPR 第 13(2)(a) 條要求在收集時告知儲存期限(或判斷標準);加州 CPRA 則要求收集時的聲明須按個人資訊類別說明保留期限。如果您的聲明明示或暗示對話資料不會在任何地方被保留,那麼當處理者持有一份 30 天的副本時,該聲明即屬不實。請更新隱私權聲明、處理活動記錄,以及資料處理協議(DPA)清單。

2. 您無法向使用者提供您自己都沒有的退出選項。 由於此保留機制沒有任何例外機制,因此在仍使用該模型的前提下,您無法建立任何開關來豁免特定使用者的提示詞。您實際掌握的槓桿是路由:一個具備同意感知能力的閘道,可將拒絕資料共享的使用者導向符合 ZDR 資格的模型,其餘使用者則導向受涵蓋模型——將法律限制轉化為一條普通的路由規則。這遠比一個毫無實際作用的偏好設定核取方塊要好得多。

3. 刪除請求需要精確的執行管道。 刪除義務(GDPR 第 17 條、CPRA 刪除規定及其對應法規)延伸至資料處理者。在 30 天內自動刪除的有限時間窗口,通常是處理者可站得住腳的立場——但您的資料主體存取請求(DSAR)處理手冊應明確說明這一點,而非承諾您無法執行的即時下游刪除。

全球層面的複雜性使情況更加棘手:相同的揭露義務與處理者邏輯,同樣出現在英國 GDPR、巴西 LGPD,以及日益擴展的美國各州隱私法規中。對於中國境內的使用者,《個人資訊保護法》(PIPL)更增添了兩項更嚴格的要求——將個人資訊提供給另一處理者通常需要單獨取得同意,而將中國使用者的內容路由至境外 LLM 端點,則屬於跨境傳輸,需要採用經認可的機制(安全評估、標準合約或認證)。一次改變了「誰保留什麼、在哪裡保留、保留多久」的模型升級,正是這些法規框架期望您重新完成書面合規作業的典型情境。


敏感資料產業:30 天保留期衝擊最深之處

對大多數產品而言,服務提供商的保留期窗口只是文件問題。但對於資料本身受到監管的產業來說,這是一個架構問題:被保留的副本是存放在供應商端的靜態受管制資料,而各行業法規正是針對這一點加以規範。

醫療保健(HIPAA)

HIPAA 並不要求零保留——它要求任何持有受保護健康資訊的供應商,必須在**業務夥伴協議(BAA)**的約束下,並配備適當的安全防護措施。您的提示詞在 30 天內的副本,是存放於業務夥伴端的靜態 PHI;問題在於您的 BAA 是否涵蓋這部分。兩大主要 API 供應商的處理方式不同,而這個差異現在至關重要:Anthropic 的 HIPAA 就緒 API 存取明確要求 ZDR——它建立在「保留加防護措施」的基礎上(加密、存取控制、稽核日誌、強制功能限制)。OpenAI 的 API BAA 涵蓋符合零資料保留資格的端點——而範圍限定於 ZDR 端點的 BAA,在結構上無法涵蓋強制要求保留的模型。

模型的保留類別現在是 BAA 資格問題。 在將 PHI 路由至特定模型之前,請以書面確認您的 BAA 涵蓋該模型——並記住雲端平台的責任鏈會有所不同:在 Bedrock 上,平台是您的業務夥伴;在 Foundry 上,Anthropic 直接處理資料。有一個值得注意的細節:PHI 絕不能出現在結構化輸出的 JSON schema 定義中——快取的 schema 與訊息內容所受的保護並不相同。

兒童產品(COPPA)

時機頗為尷尬:FTC 的修訂版 COPPA 規則於 2025 年 6 月 23 日生效,大多數條款的合規期限為 2026 年 4 月 22 日——第一個強制要求服務提供商端保留的模型,恰好在業者剛完成新保留義務實施之際推出。其中兩項規定與 30 天窗口直接相關:書面且公開的資料保留政策現已為強制要求(§312.10)——須說明收集了哪些兒童資料、原因為何,以及何時刪除——且禁止無限期保留,保留期限以收集目的所合理必要的範圍為限。

有明確終止時間且自動刪除的 30 天窗口,在形式上是相容的——但服務提供商保留資料是出於其信任與安全目的,而非您收集兒童資料的目的,您的隱私聲明必須如實描述這層處理者關係。對於專門採用 ZDR 以最小化資料足跡的兒童導向產品而言,路由選擇的答案同樣適用,但風險更高:兒童流量應保持在符合 ZDR 資格的模型上,否則 Covered Model 的保留窗口必須先納入您的 §312.10 政策。

其他產業的相同模式

一旦您理解了這個結構——受管制資料、存放於供應商的保留副本、行業規則規範保留——就會發現它反覆出現:

  • 生物特徵辨識(伊利諾州 BIPA): 業者需要針對生物特徵資料提供書面且公開的保留時程表及銷毀準則。包含生物特徵識別碼的提示詞,其服務提供商端的 30 天副本應納入該時程表。
  • 支付(PCI DSS / GLBA): PCI DSS 禁止在授權後的任何地方儲存敏感驗證資料。貼入提示詞的卡片資料,將在服務提供商端保留 30 天。乾淨的解決方案是上游遮罩,而非下游文書作業。
  • 教育(FERPA): 依學校官員例外條款處理學生記錄的供應商,必須持續處於學校的直接控制之下。學校無法存取或提前刪除的安全保留副本,與這項標準之間存在張力——在 EdTech 流量進入 Covered Model 之前,這是需要諮詢法律顧問的問題。
  • 金融服務——反向情況(SEC/FINRA): 券商必須依帳冊與記錄規則保留業務通訊。對他們而言,服務提供商的保留窗口不是問題;問題在於如何留存自己的合規副本。同樣是保留問題,方向卻相反。

共同主軸:行業規則從兩個方向規範保留,而您無法控制的服務提供商端窗口,必須對應到您所在行業所指向的那個方向。


決策檢查清單

  • 盤點您的流量實際接觸了哪些模型。 保留類別現在是每個模型的屬性,而非每個服務提供商的屬性。
  • 如果您已有 ZDR:請主動決策——跳過 Covered Models、依工作區/專案/訂閱分流,或接受整個組織的保留。不要讓它在無意間發生。
  • 在基礎設施層面強制執行策略——Bedrock SCP、工作區隱私控制、獨立雲端專案——而非依賴 wiki 頁面。
  • B2C:更新隱私聲明與 DSAR 處理流程;將未同意的使用者路由至符合 ZDR 資格的模型,而非建立無法實際運作的退出機制。
  • 受管制資料:在路由至需要保留的模型之前,以書面逐一確認涵蓋範圍——PHI 需要 BAA、兒童資料需要 §312.10 政策、生物特徵資料需要保留時程表。
  • 稽核您自己的日誌記錄。 如果您的閘道無限期記錄提示詞,服務提供商的 30 天窗口根本無關緊要。

結論

Fable 5 附帶的 30 天保留期並非資料蒐集行為,而是有明確範圍、目的限定的濫用監控機制,與業界大多數廠商的預設做法一致。之所以對這一類模型強制執行,是因為跨請求的濫用偵測在資料刪除後便無從運作。對大多數團隊而言,工程層面的影響為零,治理層面的影響不過是供應商審查文件中的一個段落。

然而,對於合規立場原本預設零資料保留的組織——涵蓋 ZDR 範圍的 BAA、聲明無任何資料持久化的隱私聲明、基於資料最小化原則建構的兒童產品——Fable 5 標誌著這項假設不再適用於所有模型的轉折點。解決之道不是迴避這個模型,而是將保留等級作為明確的、逐模型的路由決策輸入,就像你已經對待定價與上下文視窗的方式一樣。


常見問題

我可以在零資料保留協議下使用 Claude Fable 5 嗎? 不行。Fable 5 與 Mythos 5 屬於需要 30 天保留期的受涵蓋模型(Covered Models);ZDR 組織會收到 400 invalid_request_error,除非為工作區啟用 30 天保留並將 Fable 5 流量路由至該工作區。

透過 AWS Bedrock、Vertex AI 或 Microsoft Foundry 可以繞過此要求嗎? 不行。各平台均要求使用者先完成各自的保留選擇加入(opt-in)才能存取該模型:Bedrock 上為 provider_data_share、Vertex 上為 Anthropic 資料共享加上 Model Garden 條款、Foundry 上為部署時 Anthropic 的條款(在 Foundry 中,資料處理者為 Anthropic,而非 Microsoft)。現有的 ZDR 安排在上述任何平台均不延續適用。

我的終端使用者可以選擇退出保留嗎? 不行——目前沒有任何選擇退出機制。你掌握的控制手段是路由:將拒絕資料共享的使用者導向符合 ZDR 資格的模型。請勿推出一個實際上不會改變任何事情的偏好設定切換選項。

保留的資料會用於訓練模型嗎? Anthropic 聲明,未經明確授權,保留的資料絕不用於訓練。其用途為信任與安全審查:自動化篩查,被標記的對話僅供經核准的人員審閱,且這些人員無法匯出資料,所有存取均受防竄改的存取日誌記錄。

30 天保留期是否會影響提示快取的運作方式? 不會。快取項目遵循各自較短的 TTL(5 分鐘或 1 小時),Fable 5 的快取合約維持不變——詳見我們的實測評估。30 天保留期是獨立且並行的安全審查保留機制。


資料來源

所有連結均於 2026-06-12 確認有效。政策隨時可能變更——請以最新文件及您自身的合約為準。本文不構成法律建議。

← 返回部落格