當企業在選擇 AI 平台時，最核心的考量通常不是模型強不強，而是資料會流向哪裡。對於許多使用 Amazon Bedrock 的工程師和架構師來說，Bedrock 的最大賣點在於它提供了一個中立的緩衝區，確保推論資料（Inference Data，即輸入的 Prompt 與輸出的結果）留在 AWS 的安全邊界內，不會被模型供應商（如 Anthropic）看到或用於訓練。
然而，隨著 Claude Fable 5 與 Mythos 5 這類頂尖模型在 Bedrock 上推出，這個遊戲規則發生了根本性的改變。
資料邊界的崩潰與 provider_data_share
在之前的模型版本（如 Opus 4.8, Sonnet, Haiku）中，資料完全留在 AWS 內部。但 Fable 5 引入了一個強制性的設定：provider_data_share。這意味著如果你要使用這款模型，必須同意將推論資料傳送給 Anthropic，且資料會被保留 30 天，期間可能會經過人工審核。
對於初級工程師來說，這可能看起來只是個設定選項，但對企業合規（Compliance）而言，這是災難性的。一旦資料離開 AWS 邊界，Anthropic 就從一個單純的模型提供者，變成了資料處理的次處理者（Sub-processor）。這會導致法律合約（如 DPA 資料處理協議）必須全部重新簽署，且所有涉及個資（PII）或醫療健康資料（PHI）的工作負載將面臨嚴重的法律風險。
安全審核與模型訓練的區別
Anthropic 的解釋是，這 30 天的保留期是為了安全評估（Safety Evaluation），目的是偵測新型的攻擊手段或越獄（Jailbreak）行為，而非將資料拿來訓練下一個版本的模型權重（Weights）。
雖然這在技術威脅模型（Threat Model）上有所區別，但對受監管產業（如金融、醫療）來說，只要資料離開了原有的安全邊界並被第三方人工審核，就已經觸發了合規紅線。例如，在醫療產業中，必須簽署 BAA（商業夥伴協議）才能處理健康資料，而目前的 BAA 僅涵蓋 AWS，並不涵蓋直接傳送到 Anthropic 的路徑。
隱蔽的技術陷阱：監控漏洞與 SCP
這次爭議最令安全工程師憤怒的是 AWS 的實作方式。首先，啟用資料分享的 API 隨模型同步上線，沒有給予企業安全團隊任何預警。
其次，AWS 在監控上存在一個巨大的盲點。一般的 Bedrock 活動會記錄在 bedrock.amazonaws.com 的 CloudTrail 事件源中，但這項資料保留設定（bedrock-mantle）卻記錄在一個完全不同的事件源：bedrock-mantle.amazonaws.com。如果你的雲端安全狀態管理（CSPM）工具只監控標準的 Bedrock 路徑，你將完全無法察覺公司內部有人開啟了資料分享功能。
針對此問題，實務上的解決方案是利用 SCP（服務控制策略，一種在 AWS 組織層級強制執行權限的機制），透過設定 bedrock-mantle:DataRetentionMode 條件鍵，強制禁止所有非零保留（Zero-retention）的模式，除非是經過審核的特定帳戶。
結論與企業抉擇
雖然 Fable 5 隨後因美國政府的出口管制指令而被暫時撤回，但這揭示了一個危險的趨勢：未來最高能力的頂尖模型（Frontier Models）可能會將資料分享作為強制前提。
對於架構師而言，現在面臨的是一個權衡選擇：是留在較舊但安全的模型版本（如 Opus 4.8）以維持資料邊界，還是追求最強性能但必須接受全新的資料治理姿態。這不再僅僅是技術選型，而是一個需要法律、合規與技術團隊共同決定的商業風險問題。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。