前沿模型，正在被大客户“分级使用”

据《The Information》报道，英伟达、Palantir Technologies 和 Booz Allen Hamilton 等大型企业，近期正在限制 Anthropic、OpenAI 前沿模型处理敏感业务数据。

这不是因为模型变差了，恰恰相反，是因为模型变得足够强，企业开始愿意把代码仓库、供应链信息、网络安全工具、内部知识库甚至生产系统交给它处理。模型能力越强，能接触的数据越核心，企业对数据边界的要求也越接近“不能离开我的控制范围”。

这正在改变企业采购 AI 的标准：模型排行榜上的性能分数仍然重要，但已经不再是唯一答案。数据是否留存、日志由谁管理、供应商能否提供不可撤销的零数据留存（Zero Data Retention，ZDR）承诺，以及模型能否部署在隔离环境中，开始成为同等重要的 API 选型条件。

英伟达没有全面停用，而是给模型划了“使用区域”

从目前披露的信息看，英伟达并非彻底封锁 Anthropic 的 Fable 模型，而是采取了按数据敏感度分级的策略。

开源软件开发等低敏感度任务仍可以使用 Fable；但涉及供应链监控、专有业务数据和核心运营信息的项目，则更倾向于调用英伟达自家的 Nemotron 模型。简单说，Fable 可以处理“公开代码”，但不能随意接触“公司命门”。

这一做法很有代表性。企业并不一定愿意为了数据安全，放弃所有外部模型。原因很现实：前沿模型在代码生成、复杂推理、长上下文理解和 Agent 任务上，通常仍有明显优势。全面禁用会带来效率损失，也可能让开发团队转而使用更难审计的个人账号或地下代理。

因此，企业更可能采用“模型路由”而不是“一刀切”：

• 公开资料、非核心代码和普通办公任务，允许调用外部前沿模型；
• 内部文档、客户数据和专有代码，需要经过脱敏、权限控制后调用；
• 国防、能源、金融、制药等高敏感场景，优先使用私有化部署或隔离环境中的模型；
• 涉及生产系统的 Agent，必须限制工具权限，并保留完整的调用审计记录。

这套分层策略的本质，是把模型当成不同安全等级的“外包员工”：能力越强，不代表权限越大；相反，权限要根据它能看到什么、能执行什么来单独配置。

争议焦点不是“拿数据训练”，而是“供应商能不能看到数据”

这次争议中，最容易被混淆的是“数据是否用于训练”。

OpenAI 和 Anthropic 都曾针对商业产品提供数据保护承诺，企业 API 数据通常不会默认用于训练或改进模型。对于很多普通 SaaS 使用场景来说，这一承诺已经足够重要。但对拥有高价值知识产权的企业而言，问题还在往前一层：即使数据不用于训练，供应商是否仍会暂时保存、处理或分析这些数据？

Anthropic 今年 6 月调整 Fable 相关政策后，允许为检测复杂攻击和新型滥用，在一定期限内保留部分客户使用记录。报道提到的期限为 30 天。Anthropic 强调，保留的信息并未用于训练模型，但这并没有消除部分企业客户的担忧。

因为“留存”和“训练”是两件不同的事：

1. 训练风险：数据是否进入模型参数，未来是否可能影响模型能力。
2. 运营风险：请求内容是否被写入日志，谁可以访问，保存多久，是否会被用于安全调查。
3. 供应链风险：供应商的员工、外包商、云服务商或其他系统是否可能接触这些数据。
4. 合规风险：数据跨境、行业监管、客户合同和政府审计要求是否允许这种处理方式。

企业真正想要的，往往不是一句“我们不会拿你的数据训练”，而是一份可以写进合同、能够接受审计、最好无法单方面撤销的完整控制承诺。

Palantir 要的，是“不可撤销”的 ZDR

Palantir 的要求更为强硬。据报道，Palantir 曾要求 Anthropic 为相关模型提供覆盖范围更广、且不可撤销的零数据留存承诺。在承诺满足之前，Palantir 暂停通过自有平台向客户广泛提供 Fable。

Palantir 本身是政府和大型企业使用 AI 的重要平台，接触的数据通常比普通互联网应用更敏感。它的客户可能涉及国防、情报、能源和关键基础设施，平台方很难只凭模型供应商的产品说明书来承担数据责任。

“不可撤销”这四个字尤其关键。普通的隐私政策可以修改，产品条款也可能随着模型升级而变化；但企业软件的生命周期往往长达数年，合同又涉及多个监管方。客户需要知道，今天签署的 ZDR 条款不会在下一次模型更新或政策调整后自动失效。

报道称，Palantir 目前已在 ZDR 条件下获得 OpenAI 某些模型的使用权。这意味着模型之间的竞争，开始出现一个此前不够显眼的维度：谁能提供更细、更稳定、更可验证的数据处理控制。

对模型公司而言，ZDR 并不是简单地把一个开关设为“关闭”。模型供应商仍需要处理滥用检测、故障排查、攻击调查和服务质量监控。完全不留存请求，会让安全团队失去取证材料；而保留太多，又会让企业客户觉得数据脱离了自己的掌控。

这是一道产品设计题，也是一道商业合同题。未来的企业 API 可能需要把留存时长、可访问角色、地域、加密方式、日志粒度、人工审核权限和安全事件取证流程都拆开售卖和配置。

Booz Allen 和诺和诺德，选择了更保守的边界

Booz Allen Hamilton 对敏感项目设定了更明确的禁用范围：涉及客户专有数据的网络安全软件工作，不允许员工使用 Anthropic 商业模型。对于国防承包商来说，内部代码本身就可能是关键资产，不能仅因为模型供应商承诺“不训练”就放宽限制。

诺和诺德则采取了另一种方式。该公司仍在部分任务中使用 Claude，但全面禁止把专有数据输入模型。这说明企业不会简单地在“全部使用”和“全部禁用”之间二选一，而是会把工作任务拆开：模型可以用来处理公开论文、通用资料和脱敏内容，但不能接触药物研发、临床数据或内部业务信息。

C Spire 的案例也说明，合同承诺并不等于零风险。据报道，该公司分别与 OpenAI、Anthropic 签署了禁止使用其数据训练模型的协议，但合同仍允许收集部分技术使用信息。对企业采购团队而言，接下来要问的就不只是“是否训练”，还包括：

• 收集哪些技术元数据？
• 请求和响应是否会被短期缓存？
• 安全审查人员能否查看原始内容？
• 数据是否会跨区域传输？
• 供应商是否会把故障样本交给第三方处理？
• 条款调整时，客户是否拥有退出或继续使用旧版本的权利？

这些问题会从法务附件，逐渐变成开发者和平台工程师必须直接面对的配置项。

Agent 让“数据留存”从隐私问题变成生产风险

早期企业使用大模型，任务大多是写邮件、总结会议记录、生成营销文案。数据当然也有风险，但权限通常比较有限，企业还能靠脱敏和人工复核兜底。

Agent 出现之后，模型的工作范围完全不同。它可能读取代码仓库，检索内部知识库，查询数据库，调用工单系统，修改配置文件，甚至推动一次部署。此时一次 API 调用不再只是“发一段文本、收一段文本”，而可能包含大量上下文、工具调用结果和执行轨迹。

如果这些内容被供应商保留 30 天，企业需要考虑的就不只是隐私泄露，还包括：

• 代码和系统架构是否暴露给外部服务；
• API 密钥、访问令牌或内部地址是否被写入上下文；
• 模型生成的命令是否可能被复用；
• 安全事件调查时，日志是否会扩大敏感信息的暴露面；
• 数据删除请求能否覆盖备份、缓存和监控系统。

这也是为什么模型能力提升后，企业反而可能更谨慎。模型不会主动“偷走”数据，但它能处理的数据越多，系统设计中的一个小漏洞，潜在影响就越大。

微软正在推销“完全隔离”的云环境

微软正在借此推广一种独立云环境：AI 模型运行在私有管理的服务器上，用户数据不传输给外部模型供应商。对于受监管行业和政府客户，这种方案能提供更清晰的数据边界，但代价也非常明确——部署和运维成本可能达到数百万美元。

这类方案并不适合所有团队。企业不仅要购买 GPU，还要承担模型托管、版本升级、推理优化、监控、安全审计和故障处理的成本。模型效果也未必能完全追上云端最先进版本，尤其是在复杂推理和 Agent 生态方面。

但对于一批客户来说，成本不是唯一指标。金融交易、国防项目、关键能源设施和药物研发数据的泄露代价，可能远高于一套隔离环境的采购费用。

因此，企业部署路径可能出现三种并行形态：

1. 公有 API

适合低敏感度任务，优点是接入快、模型更新及时、无需维护 GPU；缺点是数据处理链条较长，供应商条款变化会直接影响业务。

2. 私有云或专属实例

适合需要更强控制力、但仍希望使用商业模型能力的企业。它在安全、性能和成本之间做折中，但要仔细确认“专属”究竟覆盖计算资源、网络、日志还是全部数据链路。

3. 本地或隔离环境

适合高敏感度任务。优点是数据边界最清晰，缺点是成本高、维护复杂，且需要企业自己承担模型安全和能力衰减问题。

真正成熟的架构，很可能不是三选一，而是通过网关把三者组合起来：低风险请求走公有 API，中风险请求经过脱敏和策略引擎后路由，高风险请求则留在企业自己的环境中。

API 选型要从“哪个模型最强”变成“哪种控制最合适”

对于开发者来说，这轮变化最直接的影响，是模型接入层不能再只封装模型名称和价格。一个可用的企业 AI 网关，至少应该具备以下能力：

• 按数据分类自动路由模型；
• 在请求发出前检测密钥、个人信息、源代码和内部标识；
• 为不同模型配置独立的留存和审计策略；
• 对 Agent 的工具调用设置白名单、预算和人工审批；
• 在供应商政策变化时，快速切换到备用模型或私有部署；
• 记录模型版本、请求策略和输出结果，便于合规追踪。

一个简单的路由逻辑可以是：

if data.classification == "public":
    route_to(frontier_model)
elif data.classification == "internal":
    sanitize(data)
    route_to(model_with_zdr)
else:
    route_to(private_model)
    require_audit_log()

这不是说企业应该放弃 OpenAI 或 Anthropic。相反，前沿模型仍然是很多开发任务中最有效的工具。问题在于，企业不能把“模型能力强”误认为“适合处理所有数据”。模型选择应该与数据分类、业务权限和合同约束绑定，而不是由某个排行榜分数单独决定。

这对模型供应商意味着什么？

Anthropic 和 OpenAI 的企业客户正在要求更精细的产品分层。过去，厂商主要销售上下文长度、推理能力、吞吐量和价格；现在，数据控制也会成为产品规格的一部分。

未来的模型套餐可能会明确区分：

• 是否支持零数据留存；
• 是否支持区域级数据驻留；
• 是否允许客户自带密钥；
• 是否提供专属推理环境；
• 是否开放完整审计日志；
• 是否允许锁定模型版本；
• 是否支持客户自行运行安全过滤和滥用检测。

如果供应商只给出模糊的隐私承诺，却无法说明数据到底经过哪些系统，企业客户会倾向于把高敏感任务迁移到自有模型或竞争对手平台。

英伟达转向 Nemotron，既是安全策略，也带有明显的供应商替代意味。它说明拥有 GPU、模型和部署能力的基础设施厂商，正在尝试把最核心的数据留在自己的技术栈里。微软推广隔离云环境，同样是在争夺企业 AI 的控制面，而不只是卖一个模型接口。

结语：前沿模型进入企业，最后拼的是“可控性”

这轮限制措施还不能简单解读为企业全面拒绝 Anthropic 或 OpenAI。更准确的说法是：企业正在拒绝让任何外部模型无条件接触最敏感的数据。

模型能力仍然重要，但它解决的是“能不能做得更好”；数据治理解决的是“出了问题谁负责”。当 Agent 开始连接企业系统，后一个问题的权重会持续上升。

对开发者和技术负责人来说，选模型时至少要同时看四张表：能力、成本、延迟，以及数据控制。只看前三项，可能能做出一个漂亮的 Demo；把第四项补上，才有机会把系统真正部署进生产环境。

前沿模型的下一场竞争，也许不再只是更强的推理和更低的价格，而是谁能让客户放心地把最重要的数据交给它处理——或者明确保证，根本不会碰到这些数据。