英伟达限制前沿模型后，ZDR 到底证明了什么

这不是英伟达全面封杀两家模型

9 月 14 日，《The Information》报道称，英伟达、Palantir、Booz Allen Hamilton 等公司正在因为数据和知识产权风险，限制或重新评估对 Anthropic、OpenAI 前沿模型的使用；路透社随后转述了这条消息。《The Information》的原始报道受订阅限制，路透社的公开转述更适合用来确认事件框架，而不是把所有细节当成公司公告。路透社转述

把报道拆开后，证据强度并不相同：

对象	公开报道或资料中的动作	应该怎样读
英伟达	Fable 被限制在较低敏感度任务；敏感的供应链监控等内部项目使用 Nemotron	这是报道中的具体动作，不等于正式宣布封禁所有 Anthropic 或 OpenAI 模型
Palantir	据报道要求 Anthropic 提供不可撤销的 ZDR，才考虑通过自身软件开放 Fable	是客户和平台方的谈判要求，不是 Anthropic 已经给出的普遍承诺
Booz Allen Hamilton	据报道禁止员工在专有网络安全工作中使用 Fable	是单家公司针对高敏感场景的内部规则
Anthropic	Fable 5、Fable 5.1、Mythos 5、Mythos 5.1 等 Covered Models 默认要求至少保留 30 天	这是 Anthropic 自己公开的产品与数据政策，和新闻中的企业反应直接相关
OpenAI	被路透社转述为企业客户担忧的另一家模型供应商；同时正在推出前沿模型 ZDR 与 Private Safety Processing 预览	目前没有公开证据证明英伟达已经对 OpenAI 做出与 Fable 相同的具体禁用动作

所以，“英伟达限制 Anthropic 和 OpenAI”这句话至少要拆成两层：第一层是媒体报道所描述的企业风险审查；第二层才是英伟达已经公开确认的产品和内部部署动作。把两层合并，就会把“据报道”“正在谈判”“已经落地”误写成同一个事实。

这也不是一场简单的反 Anthropic 行动。英伟达在 2025 年 11 月曾与 Anthropic、微软宣布战略合作，英伟达还参与了相关投资安排。Anthropic 公布的合作信息说明，商业关系和数据边界是两回事：供应商可以是合作伙伴，敏感数据仍然可以不交给它处理。

转折点，是 Fable 的 30 天

这件事的时间线比一条新闻标题更能说明问题。

时间	发生了什么	对企业数据边界的影响
2025-11-18	英伟达、微软与 Anthropic 宣布战略合作	说明芯片、云和模型之间存在深度商业关系，不能把后来的数据限制理解为商业阵营切换
2026-04-23	英伟达称已有超过 1 万名员工提前使用 GPT-5.5 Codex；部署在获批云端虚拟机中，每名员工独享虚拟机，生产权限为只读，并由 ZDR 政策约束	外部前沿模型并非不能进入企业，关键在于调用架构、权限和审计边界；这些细节仍是英伟达自己的公开声明
2026-06-09	Anthropic 发布 Fable 5、Mythos 5，并为 Covered Models 引入所有流量至少 30 天的留存要求	过去可谈的 ZDR 不再自动覆盖最前沿模型；“默认不训练”与“请求不会被留存”被明确拆开
2026-08-19	OpenAI 公布前沿模型 ZDR 方案，并预览 Private Safety Processing	OpenAI 试图在不把原始内容交回 OpenAI 的情况下识别跨交互的安全信号，但截至本文写作时，完整技术白皮书仍是计划中的后续材料
2026-09-01	Anthropic 发布 Enterprise Frontier Safeguards，提出把安全信号放进客户自己的云存储，并让客户控制密钥、权限和审计	解决方向从“供应商承诺不留”转向“供应商没有原始存储位置”，但该安排处于分阶段推出和资格限制中
2026-09-10	英伟达与 Palantir 宣布从英伟达自身运营开始，将 Nemotron 用于主权供应链智能	自有模型、私有数据和本地或受控云部署可以放在同一治理边界内，代价是模型运维和安全责任回到企业自己身上
2026-09-14	相关企业因为 ZDR 是否可撤销、前沿模型是否需要留存安全数据而被集中报道	ZDR 从一个 API 选项，变成模型准入和供应链治理问题

这里最关键的是 6 月 9 日。Anthropic 对 Fable 5 和 Mythos 5 的解释是，面对多轮滥用、跨请求关联、Best-of-N 越狱以及数据勒索等风险，只看单次请求不够，因此需要保留 30 天的提示词和输出，用于检测和防御复杂的新型攻击。Anthropic 对 Fable、Mythos 访问政策的说明

这 30 天并不等于“拿去训练模型”。Anthropic 公开说，Covered Models 的留存不是为了训练新的 Claude 模型或其他非安全用途；默认情况下，人工也不能直接读取这些对话，只有触发受控的信任与安全流程时才可能审查，并且访问会留下记录。Anthropic 的 Covered Models 数据留存说明

但对企业来说，风险问题已经发生了变化：原始数据是否会成为训练语料，只是一个问题；供应商是否能在未来 30 天内保留它、关联它、在安全事件中调取它，是另一个问题。企业要求“不可撤销的 ZDR”，针对的正是后一个问题。

先把四个“数据不碰”分开

供应商的隐私页面经常把多种承诺放在同一套企业方案里，读者很容易把它们压缩成一句“数据安全”。实际上，至少有四个不同问题：

承诺	它回答的问题	它没有回答什么
不用于训练	客户提示词和输出会不会被用于改进模型权重	供应商是否保留日志、做安全分析，或让安全团队在例外情况下访问
ZDR	在约定的组织、模型、端点和产品上，请求与响应是否会在服务端持久保存	元数据、滥用监测结果、分类器信号、缓存、文件、会话状态以及法律例外是否存在
无人工访问	模型供应商团队成员是否能直接打开客户的原始对话	自动化系统是否处理过数据；被标记的安全、违法或滥用事件是否适用特殊流程
客户控制存储	原始数据、密钥和审计记录是否掌握在客户自己的云或机房	模型服务是否仍在处理数据；客户是否真的有能力运行、审查和承担这套基础设施

OpenAI 的平台文档把这些区别写得很直白：API 数据默认不用于训练，但滥用监测日志通常最多保留 30 天；符合条件的组织可以申请 ZDR，使客户内容不进入滥用监测日志，而不同端点仍有不同的应用状态和存储规则。/v1/responses 和 /v1/chat/completions 在 ZDR 下会按不存储处理，但线程、向量库、文件和其他有状态功能不能因此自动获得同样的待遇。OpenAI 平台数据控制文档

Anthropic 的口径也类似，只是前沿 Covered Models 让例外变得更显眼：符合条件的 API 组织可以申请 ZDR，标准 API 通常在 30 天内自动删除输入输出；但 Fable 5/5.1 和 Mythos 5/5.1 默认要求至少留存 30 天，除非客户获得专门安排。Anthropic API 数据留存文档 Anthropic 的 ZDR 适用范围说明

因此，ZDR 不是一个脱离上下文的模型属性，而是一个带条件的服务合同和技术配置：谁的组织、哪条 API、哪个模型、是否有状态、是否触发安全或法律例外，都必须写出来。

以前各家是如何“证明”ZDR 的

严格说，供应商过去并没有给出“服务器上任何一个字节都从未落盘”的数学证明。它们提供的是一条可检查、可审计、可追责的证据链。企业通常按下面几层去验收。

证据层	典型材料	能证明的范围	不能直接推出的结论
合同与法律文本	DPA、商业条款、ZDR 或 Modified Abuse Monitoring 协议、保留期限、分包商清单、法律例外、审计权	供应商对数据用途、保留和配合审计承担了什么义务	不能单靠合同证明每一次请求都按约执行
产品与账户配置	组织级或项目级 ZDR 开关、审批状态、端点资格、`store=false`、数据保留控制台	某个客户、某个项目、某条调用路径当前采用什么规则	不能把一个端点的状态扩展到文件、线程、缓存或 Agent 记忆
服务端技术实现	无状态推理、自动删除 TTL、访问控制、密钥隔离、人工读取审批、不可篡改访问日志	数据在约定的服务路径上如何流转，谁能看到，多久删除	不能证明供应商所有内部系统、备份和安全分类器都没有任何例外
云平台边界	客户自有存储、客户管理密钥、私有网络、隔离虚拟机、只读生产权限	原始数据和操作权是否尽量留在客户边界内	客户也要承担配置错误、密钥管理、模型运维和内部权限泄露
独立审计与运行证据	SOC 2 Type II、ISO 认证、审计报告、访问日志、删除记录、客户抽查和年度审计权	控制设计和一段期间内的运行有效性	审计是抽样和期间性保证，不是对未来每次调用的永久背书

这就是过去各家“证明”ZDR 的基本方法：不是让客户相信一句宣传语，而是让客户拿到合同、配置、架构、日志和第三方审计之间的对应关系。任何一层缺失，承诺都可能只停留在营销语言。

Anthropic：组织级协议，加上产品资格表

Anthropic 过去最容易被理解的 ZDR 口径，是针对获批的商业 API 组织：输入和输出在响应返回后不在静态存储中保留，安全分类器的结果和法律、滥用、伤害相关例外另行处理。客户可以在组织设置中确认数据保留期限，但这并不等于所有产品都自动继承 ZDR。

Fable 5 把这套边界公开撕开了：Covered Models 的 30 天留存要求优先于普通 ZDR 预期，且 Anthropic 明确把它归因于前沿模型的安全防御需求。后来推出的 Enterprise Frontier Safeguards，则尝试把安全信号交给客户自己的 S3、Azure Blob 或 Google Cloud 存储，让客户掌握密钥、访问策略和审计日志。Enterprise Frontier Safeguards 公告

这套新方案的方向很有价值，但不能提前写成已经普遍兑现的 ZDR：官方说法是分阶段推出，适用于符合条件的客户；在方案准备好之前，部分客户暂时获得 Fable 的 ZDR 安排，而且 Anthropic 保留因滥用风险调整或撤回安排的权利。媒体所说的“不可撤销”，正好击中了这个治理缺口。

OpenAI：默认不训练、30 天滥用日志，以及端点级例外

OpenAI 的 API 企业口径长期围绕三件事展开：商业 API 数据默认不用于训练；滥用监测日志通常最多保留 30 天；符合条件的客户可以申请 ZDR 或 Modified Abuse Monitoring。企业还可以通过 DPA、数据处理条款、SOC 2 Type II 和 ISO 等材料，核对供应商的安全控制与审计机制。OpenAI 安全与隐私说明 OpenAI 数据处理附录

真正容易出错的地方在端点。聊天补全和响应接口可以按 ZDR 处理，不代表会话、线程、向量存储、文件和 Agent 状态也不存。OpenAI 近期公布的前沿模型 ZDR 方案，又加入了 Private Safety Processing：目标是在客户控制的基础设施或未来由客户控制密钥的存储中，提取跨交互的安全信号，尽量不让 OpenAI 团队成员看到原始内容。OpenAI 关于前沿模型 ZDR 的说明

不过，截至本文写作时，Private Safety Processing 仍是预览方向，技术白皮书计划在 2026 年 9 月发布。它可以说明 OpenAI 正在解决什么矛盾，却还不能替企业完成验收。企业要看的仍然是最终端点清单、数据流、例外规则和能否独立复核的运行证据。

云平台：把“证明”做成可执行的模式

AWS Bedrock 的做法更接近工程验收。它把数据留存模式区分为 none、default、aws_review 和 provider_data_share；其中 none 表示 AWS 不对请求和响应做持久化存储，也不与模型提供商共享。更重要的是，store=false 本身不自动保证零留存，模型还会根据允许的留存模式决定是否可用；当前 Fable 5/5.1 需要特定的审查模式，在严格的 none 或 default 下可能直接不可用。AWS Bedrock 数据留存模式

Google 的文档也要求客户自己处理日志、搜索 grounding、Maps 数据和会话缓存等例外；微软则提供 Modified Abuse Monitoring，在高敏感场景下减少人工查看，但同时承认这会降低滥用检测能力。Google Agent Platform ZDR 说明 Microsoft Foundry 滥用监测说明

这些例子共同说明了一件事：可信的 ZDR 不是“网页上有一个绿色开关”，而是系统在不满足条件时能够拒绝调用、缩小能力或明确暴露例外。能不能把模型挡在严格留存模式之外，往往比供应商说“默认不训练”更接近真正的证明。

前沿模型为什么把旧答案逼到了墙角

传统 API 的安全假设很简单：客户发一个请求，模型回一个结果，平台在短时间内做滥用检测，然后删除内容。这个假设在单轮问答里还能成立，但前沿模型越来越像一个会持续读文件、调用工具、执行代码、维护上下文的 Agent。攻击者也不再只发一个越狱提示词，而是把许多看似普通的请求拼起来，慢慢取得权限、探测边界，再把结果组合起来。

Anthropic 对 Fable 30 天留存的解释，本质上是说：如果完全不保留跨请求信号，就很难识别这类模式。OpenAI 的 Private Safety Processing 则代表另一种答案：安全系统可以识别“发生过风险”，但尽量不接触客户的原始内容。这两种方案都在承认同一个事实——前沿模型的安全监测需要更多上下文，而企业的隐私要求又不允许上下文无限回到模型供应商手里。

英伟达把敏感供应链数据转到 Nemotron，解决的不是“Nemotron 一定比 Claude 或 GPT 更聪明”，而是信任边界不同。英伟达与 Palantir 公布的方案强调，专有数据、模型权重和推理服务可以放在同一个受治理环境里；英伟达自己的技术说明也把供应链决策和结果用于 Nemotron 的后训练。英伟达与 Palantir 的供应链公告英伟达关于 Nemotron 供应链部署的技术说明

代价也一并转移了：企业不再只需要审查供应商，还要自己负责模型更新、红队测试、权限分层、日志保存、故障恢复和安全事件响应。所谓“自家 AI 更安全”，更准确的表述是“原始数据不必跨出自己的治理边界”；安全性并不会因为模型名字里有自家两个字就自动增加。

企业现在真正要问的六个问题

如果把 ZDR 当成采购条件，下面六个问题比“你们支持 ZDR 吗”有用得多：

具体覆盖哪一条路径？ 写清组织、项目、区域、云平台、模型版本、API 端点，以及是否包含 Agent、文件、线程、向量库和会话记忆。
到底留什么？ 把提示词、输出、请求元数据、分类器结果、缓存、备份、错误日志和计费记录分别列出，不接受“数据”这个总称。
谁可以访问？ 区分模型提供商、云中间层、分包商、自动安全系统和人工审查员；要求给出访问审批、最短保留期和可导出的审计记录。
安全与法律例外是什么？ 询问滥用、违法内容、儿童安全、法律留置和服务故障时，ZDR 是否暂停，谁来决定，客户何时能知道。
政策能不能单方面改变？ 重点看模型升级、风险等级变化和新安全政策是否会自动改变留存；“不可撤销”要落在合同和通知期里，而不是销售口头承诺。
不满足条件时会发生什么？ 最理想的系统不是默默降级到默认留存，而是像 Bedrock 的严格模式那样拒绝调用，或明确告诉客户当前模型不符合 ZDR。

回头看英伟达这条新闻，真正的矛盾并不是“买芯片的公司为什么不用最强模型”，而是“当模型供应商为了安全需要数据时，谁仍然拥有拒绝和审计的权力”。英伟达 4 月公开介绍过用 GPT-5.5 Codex 的方案：批准的云端虚拟机、独享环境、只读生产权限、完整审计，以及公司声称的 ZDR 政策。这个案例的价值不在于它证明了一句口号，而在于它把外部模型放进了一个可观察的调用架构里。

过去的 ZDR 主要回答：客户数据会不会被拿去训练。现在企业要回答的，是更难也更具体的问题：供应商能不能看见，能保留多久，安全团队能不能调取，模型升级后规则会不会变，出了争议客户能不能拿出独立证据。

所以，ZDR 从来不是一个脱离范围的“绝对不留痕”证明，而是合同、配置、架构、审计和例外管理共同组成的控制面。前沿模型越强，这条证据链就越不能只靠供应商的一句话。

参考资料

写作附记

原始提示词

$blog-writer 详细梳理事情的来龙去脉消息称英伟达内部限制使用 Anthropic 和 OpenAI 的前沿模型，敏感数据改用自家 AI, 以前各家是如何证明 ZDR 的