Claude Fable 5 的 30 天数据留存：ZDR、HIPAA、COPPA

如果您的组织在零数据留存（ZDR）协议下运行 Claude，那么您向 claude-fable-5 发出的第一个请求不会返回补全结果，而是返回 400 invalid_request_error。这不是服务中断——这是策略。Fable 5 是首个正式发布的、必须在 30 天数据留存条件下才能使用的 Claude 模型，且该要求在所有平台上均适用：Claude API、AWS Bedrock、Google Vertex AI 以及 Microsoft Foundry 均要求用户明确选择启用留存功能后方可访问该模型。

对于那些将”我们不留存您的数据”视为 LLM 技术栈既定属性的团队而言，这是一次架构层面的重大变化。本文将介绍该策略的具体内容、30 天窗口期存在的原因、各云平台的实现方式，以及它对消费者产品和敏感数据行业的影响。

本文政策细节已于 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 年。零数据留存从来不意味着零数据——它意味着在正常路径下不留存未被标记的内容。

相同需求，三朵云，三种机制

保留策略适用于模型运行的任何地方，但每个平台的选择加入方式各不相同——这些差异决定了谁来处理你的数据，以及你的控制权归属于何处。

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 在结构上有所不同。微软的数据与隐私文档明确指出，Claude 模型属于第三方市场服务：你在部署时接受 Anthropic 的条款，Anthropic——而非微软——是数据处理方。Azure OpenAI 的 ZDR 和修改版滥用监控计划不延伸至 Claude 部署。在其他地方已有 ZDR 策略的组织，通常会将 Covered Model 的使用隔离在专用订阅中，从而使保留边界成为结构性约束，而非程序性约束。

三个平台呈现出共同的规律：保留类别已成为一等的、机器可读的模型属性——一个模式、一个标志、一道条款门槛——而不再是合同中的某段文字。你的基础设施现在可以强制执行你的数据策略，而且理应如此。

对企业部署意味着什么

如果没有 ZDR 协议，机制上不会有任何变化——你本来就处于类似 30 天的数据保留状态，只是可能没有意识到。现在需要做的，是在供应商文档中将其明确化。

如果有 ZDR 协议，你面临三种选择：

1. 跳过 Covered Models。 ZDR 保持统一；你放弃使用该模型。如果你的工作负载不需要它，这是可行的——参见我们的 Fable 5 实测评估，了解代价所在以及差异之处。
2. 按工作区或项目拆分。 每个平台都支持范围化的选择加入：指定一个 Claude API 工作区（控制台 → 设置 → 工作区 → 隐私控制）、一个配置了 provider_data_share 的 Bedrock 项目，或一个独立的 Vertex 项目或 Azure 订阅。仅将可容忍数据保留的工作负载路由至此。
3. 在整个组织范围内接受保留。 运营上最简单，但会悄然降低所有工作负载的保障级别——包括那些正是因为敏感性才需要 ZDR 的工作负载。这是数据保护负责人需要做出的决策，而不是一次配置变更。

无论选择哪家供应商：你自己的日志记录是第二个数据保留面。 如果你的网关或可观测性系统记录了完整的提示词，你实际运行的保留窗口比供应商的更长，且存储在你自己的环境中。供应商的保障只有在其前置层同样可靠的情况下才有意义——我们在缓存声明审计中应用的相同审计逻辑，在这里同样适用。

这对面向消费者的产品意味着什么

如果您服务于消费者，并将其内容通过受覆盖模型进行路由，则无论是否签署了 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天，意味着受保护健康信息以静态形式存放在业务伙伴处；问题在于你的 BAA 是否涵盖这一情形。两家主要 API 供应商在结构上处理方式不同，而这一差异现在至关重要：Anthropic 的 HIPAA 就绪 API 访问明确不要求 ZDR——它建立在”保留+安全保障”的基础上（加密、访问控制、审计日志、强制功能限制）。OpenAI 的 API BAA 覆盖符合零数据保留条件的端点——而范围限定于 ZDR 端点的 BAA，在结构上无法覆盖强制要求保留数据的模型。

模型的保留类别现在是一个 BAA 资格问题。 在将受保护健康信息路由到某个模型之前，请以书面形式确认你的 BAA 涵盖该特定模型——并记住，在云平台上责任链会发生转移：在 Bedrock 上，平台是你的业务伙伴；在 Foundry 上，Anthropic 直接处理数据。一个值得注意的边界情况：受保护健康信息绝不能出现在结构化输出的 JSON schema 定义中——缓存的 schema 与消息内容所受的保护级别不同。

儿童产品（COPPA）

时机颇为微妙：美国联邦贸易委员会修订版 COPPA 规则于2025年6月23日生效，大多数条款的合规截止日期为2026年4月22日——第一个强制要求服务商端保留数据的模型，恰好在运营商完成新保留义务实施之际出现。其中两项规定与30天窗口期直接相关：书面的公开数据保留政策现已成为强制要求（§312.10）——须说明收集了哪些儿童数据、收集原因及删除时间——同时禁止无限期保留，保留期限须以收集目的所合理必要的范围为限。

有时限的30天窗口加上自动删除，在形式上是兼容的——但服务商保留数据是出于其自身的信任与安全目的，而非你收集儿童数据的目的，你的隐私声明必须准确描述这一数据处理方关系。对于专门采用 ZDR 以最小化数据留存的儿童导向产品而言，路由选择的答案同样适用，只是风险更高：儿童流量须保持在符合 ZDR 条件的模型上，否则须先将受覆盖模型的窗口期纳入你的 §312.10 政策。

其他行业的相同模式

一旦你理解了这一结构——受监管数据、存放在供应商处的保留副本、行业规则对保留的约束——就会发现它在各处反复出现：

• 生物特征识别（伊利诺伊州 BIPA）： 运营商需要针对生物特征数据制定书面的、可公开获取的保留计划和销毁指南。服务商对包含生物特征标识符的提示词保留30天的副本，应纳入该计划。
• 支付（PCI DSS / GLBA）： PCI DSS 禁止在授权完成后在任何地方存储敏感认证数据。粘贴到提示词中的卡片数据，将在服务商处以卡片数据的形式被保留30天。干净的解决方案是上游脱敏，而非下游补文件。
• 教育（FERPA）： 依据”学校官员例外”条款处理学生记录的供应商，必须始终处于学校的直接控制之下。学校无法访问或提前删除的安全保留副本，与该标准存在张力——在 EdTech 流量接入受覆盖模型之前，这是一个需要咨询法律顾问的问题。
• 金融服务——反向情形（SEC/FINRA）： 经纪自营商必须依据账簿与记录规则保留业务通信。对他们而言，服务商的窗口期不是问题；问题在于如何留存自己的合规副本。同样是保留问题，方向相反。

共同主线：行业规则从两个方向对保留进行约束，你无法控制的服务商端窗口期，必须被纳入你所在行业所指向的那个方向的合规框架中。

决策检查清单

• ✅ 盘点你的流量实际接触了哪些模型。 保留类别现在是每个模型的属性，而非每个服务商的属性。
• ✅ 如果你已启用 ZDR：请主动决策——跳过受覆盖模型、按工作区/项目/订阅拆分，或接受全组织范围的保留。不要让它在不知不觉中发生。
• ✅ 在基础设施层面强制执行安全态势——Bedrock SCP、工作区隐私控制、独立云项目——而非依赖一个 Wiki 页面。
• ✅ 面向消费者（B2C）：更新隐私声明和 DSAR 处理流程；将未授权用户路由至符合 ZDR 条件的模型，而非构建无法真正生效的退出机制。
• ✅ 受监管数据：在路由前，逐模型以书面形式确认覆盖范围——受保护健康信息对应 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 能绕过该要求吗？ 不能。每个平台都通过各自的留存选项来控制模型访问：Bedrock 上的 provider_data_share、Vertex 上的 Anthropic 数据共享加 Model Garden 条款、Foundry 上部署时 Anthropic 的条款（在 Foundry 中，数据处理方是 Anthropic，而非 Microsoft）。现有的 ZDR 安排在上述任何平台上均不延续适用。

我的终端用户可以选择退出留存吗？ 不可以——没有任何退出机制。你掌握的手段是路由：将拒绝数据共享的用户引导至符合 ZDR 条件的模型。不要上线一个实际上不改变任何行为的偏好开关。

留存的数据会用于训练模型吗？ Anthropic 声明，未经明确许可，留存数据绝不用于训练。其用途是信任与安全审查：自动筛查，被标记的对话仅可由经批准的人员审阅，且这些人员无法导出数据，所有访问均受防篡改日志记录。

30 天留存会改变提示缓存的工作方式吗？ 不会。缓存条目遵循各自较短的 TTL（5 分钟或 1 小时），Fable 5 上的缓存合约保持不变——详见我们的实测评估。30 天窗口是用于安全审查的独立并行留存机制。

参考来源

• 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 规则修订（新闻稿）
• 联邦公报 — 儿童在线隐私保护规则

以上链接均于 2026-06-12 核实。政策随时可能变更——请以当前文件及您自身合同为准。本文不构成法律建议。

← 返回博客