Anthropic推EFS，把ZDR和滥用监测并行
EFS把企业隐私控制、客户自有密钥和跨账号滥用监测合到同一方案。
本文要点
- 企业活动数据从模型厂商侧保留，转向客户自有云账户存储。
- 滥用检测从单次交互即时分析，转向跨时间和账号的滚动窗口。
- 人工复核从Anthropic员工查看，转向客户团队处理flags。
阅读辅助
先看数字、证据和来源，再读正文。
EFS在9月1日被宣布，但还没有全面可用。
2026-08-31 · Anthropic前一日复盘安全与对齐整改，给EFS的企业监测诉求提供背景。
新闻锚点
Anthropic在2026年9月1日发布Enterprise Frontier Safeguards，简称EFS。它面向需要使用前沿模型、又受监管数据规则约束的企业客户。公告给出的核心设计是：活动数据可以存放在客户控制的云基础设施中，密钥、访问策略和审计日志由客户掌握；Anthropic的自动系统仍可以分析滚动窗口里的流量，识别严重滥用信号，但这些flags直接交给客户团队处理。
这条新闻成立的增量很明确。Anthropic此前从Fable 5开始引入30天数据保留，用来做跨时间、跨账号的滥用关联检测；EFS给出的新答案是把保留数据的位置和复核权限拆出来，让受监管企业在不让Anthropic员工人工查看内容的前提下，继续接入更强模型和自动安全监测。公告同时说，EFS将从今年秋季稍晚开始分阶段推出，目标是更广泛可用，因此它不是已经全量上线的默认能力。
企业侧最关心的边界也写在公告里。符合条件的客户会在EFS准备好之前，在Fable 5和Fable 5.1上获得ZDR。这句话要按过渡安排理解：它不是说Fable 5和Fable 5.1已经永久恢复面向所有客户的zero data retention，也不是说EFS已经替代现有数据保留政策。Claude Platform的9月1日release notes仍写着，Fable 5.1和Mythos 5.1与Fable 5一样要求30天数据保留，除非Anthropic明确授权。
读者需要记住的判断是：EFS把“隐私承诺”和“滥用监测”从政策表述推进到部署架构。对银行、医疗、法律、公共部门和云平台客户来说，审查重点会落到日志位置、密钥持有人、复核人员、自动信号上报和合规流程适配上。
EFS拆开的三层控制
EFS先处理存储控制。Anthropic公告说，EFS works by storing data in cloud infrastructure controlled by the customer, not Anthropic。更具体的例子包括Amazon S3、Azure Blob Storage和Google Cloud Storage。换成企业采购语言，这相当于把监测所需的活动数据放回客户已有的云账户和审计体系里，减少客户把Anthropic列为新“受信数据保管方”的压力。
随后是密钥和访问控制。公告提到客户希望数据位于自己控制的基础设施下，使用自己的encryption keys、access policies和audit logging。EFS里的Customer-Managed Encryption Keys是opt-in选项。这并不等于每个客户自动获得同一套CMEK配置，也不意味着所有云平台已经有完全相同的按钮和模板；它说明Anthropic正在把前沿模型访问条件设计成客户安全团队可以审阅的云资源和权限问题。
复核控制则落到客户团队手里。Anthropic承认，自动审阅变得更有效，但人在查看flag时仍有价值，因为人可以确认真实滥用、清除误报。受监管企业的问题在于，能看这些内容的人必须是自己已经授权和培训过的团队。EFS的安排是自动系统分析rolling window of traffic，寻找严重滥用信号，包括offensive cyber或biological capabilities开发尝试，以及被盗或泄露凭据的迹象；信号直接发送给客户，由客户人员接手，Anthropic员工不需要做人审。
这三层合起来，回答的是Fable 5之后出现的企业矛盾：前沿模型能力越强，越需要跨会话、跨账号的滥用监测；但监测又要求一定时期的数据留存，而受监管客户往往要求ZDR或接近ZDR的数据边界。EFS保留监测需求，同时把可见性、存放位置和人工复核权重新分配。
状态语义和部署边界
这篇公告里最容易写错的是状态动词。EFS 的推出节奏仍是未来式：Anthropic 写的是 will be rolling out to customers in phases, starting later this fall，因此中文报道应写成从今年秋季稍晚开始分阶段向客户推出。符合条件客户在 EFS ready 之前获得 Fable 5 和 Fable 5.1 的 ZDR，属于过渡安排，不能扩写成长期默认豁免。
成本和行为边界同样要收紧。客户自有存储、Customer-Managed Encryption Keys 和 fully automated review 都是 opt-in 控制；Anthropic 原文说 none of them change model behavior, API pricing, or rate limits。也就是说，模型行为、API 定价和速率限制不因这些控制而改变，但客户自有云账户里的存储、读写和 egress 费用仍可能由云服务商收取。
企业数据训练承诺也需要保留归属。Anthropic 称未获明确许可不会用企业数据训练模型，这是一项厂商承诺；是否满足特定行业的审计要求，还要看客户合同、日志字段、访问记录和第三方审查材料。
同一段还要注意比较基准。Fable 5.1 release notes里写的是它和Mythos 5.1“Like Claude Fable 5”要求30天数据保留，并且“aren’t available under zero data retention unless expressly authorized by Anthropic”。这与EFS公告里的过渡ZDR并不冲突：前者是模型默认政策，后者是符合条件客户在EFS ready之前的授权安排。
EFS还没有给出一张完整的责任矩阵。公告说customers on Amazon Web Services, Google Cloud, and Microsoft Azure will get equivalent controls，活动数据会存在客户自己的云账户里；但它没有列出每个云平台的上线日期、支持区域、日志schema、密钥轮换方式、事故响应SLA或客户侧审计事件格式。对采购和安全审查来说，这些未公开项会直接影响落地速度。
数据保留矛盾怎样被改写
Anthropic解释引入30天保留的理由时，重点放在复杂滥用检测，而非模型训练。公告称，最复杂的滥用可能分散在多个任务、会话和账号之间，单次交互做完自动分析后马上丢弃数据，并不足以识别异常模式。尤其在企业场景里，滥用可能涉及被盗凭据、泄露身份、异常自动化链路或长时间横向移动，仅靠一次请求的内容很难判断。
这套解释对安全团队是合理的。许多内部风控、反欺诈和端点安全系统都依赖时间窗口、行为基线和跨主体关联。问题在于，大模型输入和输出经常包含代码、客户数据、法律材料、药物安全报告、非公开财务信息或业务机密。把这些内容交给模型供应商留存30天，在金融、医疗、法律和公共部门会触发合同、监管和数据分类要求。
EFS把争议点从“留不留”改成“留在哪里、谁能看、谁来处置”。客户可以把活动数据留在自己的S3、Azure Blob Storage或Google Cloud Storage；可以选择客户托管密钥；可以让自动系统继续跑检测，并把人工复核留给自己的安全、合规或产品团队。Anthropic仍坚持保留数据有助于监测复杂滥用，同时把数据控制权交回企业侧。
这也是为什么公告强调EFS与100多家客户共同开发，沟通覆盖约四分之一 Fortune 100、每一家美国全球系统重要性银行以及几乎所有受监管行业。这个说法来自Anthropic自报，不能当成已签约客户名单，但它能说明需求来源：前沿模型要进入系统性重要银行、支付、医疗和法律工作流，模型能力本身已经不是唯一门槛。
三种部署口径的差异
| 口径 | 数据位置 | 监测方式 | 人工复核 | 适用风险 |
|---|---|---|---|---|
| 传统ZDR | 请求后不保留或极短保留 | 难以做跨时间和账号关联 | 通常不依赖厂商复核 | 隐私强，复杂滥用发现弱 |
| Fable 5默认保留 | Anthropic侧按政策保留30天 | 可做滚动窗口检测 | 取决于平台规则和授权 | 安全监测强，受监管客户难通过 |
| EFS | 客户自有云账户 | 自动系统分析滚动窗口 | flags交给客户团队 | 试图兼顾高能力模型和合规边界 |
这张表的关键在于安全目标不同。ZDR最大化数据不留存，适合把供应商暴露面压到最低；30天保留强化滥用检测，适合把安全团队的可观测性放在前面；EFS则把监测和数据主权拆开，让企业在保留必要信号的同时减少外部人工可见性。
成本口径也要分开。Anthropic写明，客户自有存储、Customer-Managed Encryption Keys和fully automated review都是opt-in，并且“None of them change model behavior, API pricing, or rate limits”。这句话只覆盖模型行为、API定价和速率限制，不覆盖客户自有云账户里的存储、读取、写入和数据egress。公告也明确说，如果客户选择把数据存放在自己的云账户，云服务商会像计费其他资源一样收取这些费用。
支持范围目前只能按公告原文写。EFS将支持Claude Code、Claude Enterprise、Claude Platform、Amazon Bedrock、Claude Platform on AWS、Google’s Agent Platform和Microsoft Foundry，共7类入口。这里的“will be supported”也是未来和分阶段语气，发布表述应避免暗示所有入口今天已经完成配置。AWS和Microsoft公开文档可以作为云模型分发背景，但EFS是否在对应入口开放，仍要等Anthropic和云平台给出具体说明。
对企业买方意味着什么
对CISO和合规团队，EFS把审查问题从“是否信任Anthropic保管内容”转成“是否认可一套外部自动检测系统在客户云账户内读写监测数据”。这会让采购材料变得更工程化：密钥所有权、日志字段、保留周期、谁能读取、异常上报流程、人工复核责任和监管留痕都会成为合同条款的一部分。公告里的Wells Fargo、Stripe、Snowflake、Cognition、Factory等客户和伙伴引语，实质都围绕同一个诉求：模型要进生产，数据控制必须能讲清楚。
对开发者和平台团队，EFS不改变模型行为、API价格和rate limits，短期不应期待调用语义发生变化。真正会改变的是接入前的组织流程。使用Fable 5或Fable 5.1的团队，需要确认自己是否符合过渡ZDR、是否会接入EFS、是否接受客户云侧存储费用，以及内部安全团队是否准备好接收和处理自动监测flags。对于只是做原型或非敏感工作负载的团队，EFS可能不会立刻改变开发体验；对于要把agent接入代码库、客户数据或受监管流程的团队，它会进入架构评审。
对模型供应商竞争，EFS给出了一个新模板。过去，企业AI安全常被包装成“不用企业数据训练”“SOC2合规”“私有部署”这类静态承诺。前沿模型进入agentic coding、金融分析、医疗和法律工作流后，静态承诺不够用，因为风险发生在连续行为中。谁能在保留行为证据、保护敏感内容、处理误报和证明审计链之间取得平衡，谁就更容易拿到受监管行业的高价值负载。
EFS最值得关注的地方，是它把企业AI治理从“隐私条款”推向“控制面设计”。当模型能力还停留在问答和摘要时，ZDR几乎是最容易卖给企业的答案；当模型开始长时间执行任务、跨账号调用工具、处理凭据和代码，完全丢弃上下文会削弱滥用检测。Anthropic选择把这组矛盾公开讲出来，并给出客户自有云、客户密钥、自动监测和客户复核的组合方案。
这不是一个没有代价的设计。自动系统仍要看到足够多的活动信号，客户团队也要承担复核flags的责任。企业得到的是数据位置和人工访问权的控制，不是把安全工作外包出去。对受监管企业来说，这反而更符合现实：高能力模型的采购不会因为一句ZDR承诺自动通过，最终还是要落到日志、密钥、审计和事件响应。
早报判断是，EFS会成为后续前沿模型企业版的一类参照物。它如果顺利落地，会把“是否支持客户自有存储和客户侧复核”变成大客户采购清单里的标准问题；它如果落地困难，也会暴露前沿模型公司在多云、合规、误报处理和责任划分上的真实成本。短期看，这不是所有开发者都要立刻迁移的功能；中期看，它会影响高能力模型进入银行、医疗、法律和关键基础设施的速度。
接下来看什么
后续先看可用性。Anthropic给的是“分阶段推出、从今年秋季稍晚开始”的节奏，首批客户、地区、云平台和产品入口的实际名单会决定企业能否按统一方案采购。若公告里的7类入口不能同步落地，各云平台仍会被单独审查。
审计证据会决定EFS能否从高层承诺进入架构评审。客户自有存储、CMEK、访问策略和审计日志听起来清楚，但真正影响合规的是默认配置、字段级可见性、密钥轮换、删除策略、异常上报格式和客户侧留痕。
检测质量同样需要公开材料。公告没有披露自动滥用监测的误报率、漏报率、人工复核量和升级门槛。EFS把flags交给客户团队后，客户需要知道每天会收到多少信号、哪些是严重滥用、哪些只是异常使用，以及模型供应商是否会参与后续调查。
过渡期ZDR则关系到采购节奏。官方写的是符合条件客户在EFS ready前获得Fable 5和Fable 5.1的ZDR，核心变量包括资格标准、审批时长、覆盖产品、结束时间和EFS上线后的迁移路径。只有这些边界公开，企业才能把它当成可规划的部署选项，而不是个案豁免。