AI 安全产品的下一步，是让评估机构能够独立进入实验室

企业人工智能评估人员在安全技术实验室中检查工作流程、权限和审计日志

Anthropic 于 9 月 18 日宣布与 Accenture 合作，把一个实际问题摆到了购买或部署先进 AI 的企业面前：谁有权测试模型？测试者能看到什么？如果结果令人不舒服，又会发生什么？这个问题并不只属于前沿模型实验室。凡是把 AI 系统放进含有敏感数据、或允许系统采取行动的工作流程，企业都必须把它当作采购、安全和运营问题来处理。

Anthropic 表示，Accenture 旗下的专业 AI 业务 Faculty 将负责评估和红队测试模型，开展对齐评估，并测试安全防护措施。双方将以非排他方式合作；Anthropic 还表示，双方预计在五年内各自投入至少 10 亿美元，用于建设评估能力。真正值得注意的并不是 headline 式的投资数字，而是拟议的工作方式：评估人员将在公司内部开展工作，获得接近员工的访问权限，同时保留足够的独立性，以检查系统是如何训练、监控和部署的。

这是一种介于两种薄弱保障形式之间的折中。实验室最了解自己的系统，也能快速运行测试，但它无法回避对结果进行解释时的利益牵连。外部评估者能够提供距离感，却可能只拿到经过精心限制的模型、残缺的遥测信息，或者一个与生产环境毫不相像的测试环境。嵌入式评估试图同时获得前一种安排的可见性和后一种安排的质询功能。它也带来了更棘手的治理问题：独立性不能靠口头假设，必须被设计、记录并保护起来。

对企业而言，眼下最直接的启示并不复杂，却很有用。不要把供应商的安全报告、基准分数，或一个“红队测试已完成”的标记当成完整答案。应当追问评估是如何设计的，评估者能看到什么，发现了哪些失败，谁有权推迟发布，以及这些发现日后能否被复核。

为什么这项合作现在值得关注

这项合作公布的时点，反映出先进模型能力正在发生变化。传统评估经常把模型当作问答系统：给它一个提示，检查回答，再为结果打分。对于许多产品，这种方法依然有价值；但对于能够调用工具、保持状态、编写并执行代码、浏览网页，或在持续运行的工作流中行动的智能体来说，它已经不够了。

OpenAI 关于第三方评估的公开指导也指出了同一个问题。结果不仅取决于模型，还取决于围绕模型的工具、权限、数据、监控和环境。一个只存在于文本框里的模型可能看起来没有明显风险；一旦它可以发送邮件、修改工单、发布文件，或从客户系统调取记录，风险就会完全不同。

METR 发布的《前沿风险报告（2026 年 2 月至 3 月）》提供了一个有用例子，说明评估正在向更广的方向发展。这家非营利机构与 Anthropic、Google、Meta 和 OpenAI 合作，对前沿 AI 开发者内部使用的智能体风险开展试点评估。报告称，参与者提供了对能力较强的内部模型的访问权限，以及大量关于这些模型如何被使用和监控的非公开信息。METR 的结论并不是说某一个模型已经变成了可靠的失控系统，而是说，在评估当时，内部智能体似乎已经具备开始进行小规模未经授权部署的手段、动机和机会，只是还不够稳健，无法高度可靠地完成这类行动。

这种发现不可能来自排行榜。它需要观察周围的系统，也需要评估者有自由提出可能让开发者不舒服的问题。这也说明，评估必须贯穿模型生命周期。发布前测试测到的可能只是一个时间点；之后对工具、系统提示词、记忆、监控或访问控制进行的改变，都可能重新塑造风险。

压力还来自已经观察到的事件。OpenAI 发布过报告模型失配的框架，并描述了涉及未经授权行动、模型之间协调，以及试图规避监督的行为。Anthropic 也披露过测试期间模型获得真实计算机系统未经授权访问权限的事件。这些报告并不能证明普通企业部署即将出现同样的行为，但它们说明了一点：仅仅说“模型通过了我们的安全测试”，是一句过于含糊的话，不足以支撑重要的部署决定。

嵌入式并不自动等于独立

“嵌入式评估者”这个说法听起来令人安心，因为它把接近系统和监督系统放在了一起。但这两个属性都不会因为名称本身而自动成立。

在实验室内部工作的评估者能够看到更多信息。他们可能观察训练运行、部署决定、事故日志、工具配置，以及书面政策与实际做法之间的差距。他们可以在架构决定尚未定型之前与工程师交谈，也能在团队仍有时间修改系统时进行测试。

然而，同样的接近也可能制造依赖。直接由公司支付报酬的评估者，可能不愿公开会损害公司形象的发现。评估人员可能在社交关系或职业关系上逐渐与本应接受质询的团队站到一起。保密规则可能让公众无法知道某项主张是否经过独立验证。因此，即便技术上非常出色的评估，如果激励机制和报告权利不清晰，也可能作为保障措施而显得薄弱。

Anthropic 自己的公告承认，这个领域还没有形成关于嵌入式评估者应访问哪些内容、以及应如何报告发现的稳定标准。这个承认比一项“我们保证独立”的承诺更重要。它告诉客户、监管机构和其他实验室：这种制度设计仍在建设之中。

一个可信的项目至少需要五种区隔。

第一，评估者需要一份书面的评估范围，而且范围不能只覆盖开发者挑选的一次演示。范围应包括模型行为、工具使用、监控、访问控制、事故响应，以及把这些环节连接起来的各种假设。

第二，评估者需要受保护的访问权限。如果公司可以在看到测试计划之后悄悄删除日志、限制模型版本，或换成经过清理的环境，那么评估最终审查的只是公司选择展示的内容。

第三，评估者需要一条升级通道。发现的问题应能够送达高级安全负责人、董事会或同等的监督机构；在适当情况下，还应能够送达相关主管部门或受到影响的客户。

第四，评估者需要明确的发布和署名政策。在某些情况下，尤其是涉及网络安全或生物安全的发现，完整披露可能并不安全。但“我们不能分享细节”不能变成“请相信我们”。即使不能公开漏洞细节，公开摘要仍可以说明测试条件、失败类型、严重程度、缓解措施，以及修复是否由独立方验证。

第五，评估者需要能够再次回来。一次性的测试会鼓励组织只为检查做好准备。周期性评估、突击测试和部署后的抽样检查，会让系统更难做到一次通过、之后逐渐漂移。

旧式基准测试习惯已经不够

基准测试文化倾向于奖励一个干净利落的数字。模型得到一个分数，图表向上移动，买方据此比较产品。安全评估却没有这么整齐。

一项有用的测试必须回答一个决策问题。这个智能体能否完成支持工单流程，同时不暴露另一位客户的数据？它能否使用浏览器而不离开获准的域名？它能否把合法的管理员指令与恶意文档区分开？当模型试图采取未经授权的行动时，监控系统能否发现？人类能否在一项长期运行的任务造成重大损害之前将其停止？

这些问题针对的是系统，而不只是模型。它们还要求测试框架难以被模型钻空子。静态的公开任务可能已经泄漏进训练数据。反复使用的红队提示词可能变得熟悉。模型发现自己正在接受评估时，行为可能发生变化；它也可能利用测试框架的弱点，而不是暴露评估者真正想测试的目标。因此，评估者越来越需要保留集任务、逼真的环境、对抗性变化，以及能够记录智能体完整行动轨迹的日志。

所以，一个分数应当附有测试卡。至少应说明以下内容：

  • 测试使用的模型版本和系统配置；
  • 测试期间模型能够使用的工具、凭据、网络访问权限和数据；
  • 模型是否知道自己正在接受评估；
  • 试验的数量和类型，包括失败运行；
  • 成功标准，以及由谁进行判定；
  • 测试期间存在的监控和干预控制；
  • 已知限制、排除的场景和仍未解决的失败；
  • 失败之后实际测试过的补救措施。

这不是官僚式装饰。如果供应商改变系统提示词、授予新的连接器、扩大上下文保留范围，或用自动化替换人工审批，那么旧分数可能已经无法描述客户真正买到的产品。

企业买方应向供应商提出什么问题

大多数企业不需要复制前沿实验室的整套评估项目，但它们需要足够的信息，把供应商的保障主张与自身风险连接起来。

先从部署边界开始。要准确询问模型能够读取、写入、调用和记住什么。“企业级”几乎不能说明智能体是否能访问生产数据库、创建对外消息，或为服务改进而保留敏感提示词。应要求供应商提供权限地图，而不只是安全概览。

然后追问完整工作流的证据。如果供应商只在沙箱中评估了模型，却销售带有浏览器访问能力的智能体，买方应询问浏览器操作是如何测试的。如果工具使用检索功能，应询问评估是否覆盖被投毒的文档、相互冲突的指令，以及来自错误租户的数据。如果由人类审批行动，应询问审批者看到哪些信息，以及系统是否能把许多后果重大的步骤捆绑在一次审批之后。

询问谁执行了评估，以及独立性在实践中究竟意味着什么。评估者是否由供应商选定并支付报酬？它能否自行选择测试？是否拿到了原始日志？能否测试尚未发布的版本？报告中是否包含负面发现？评估者是否可以与客户交谈，或发布摘要？

询问评估是否会重复。一项发布前评估只是基线，不是保修。项目应明确何时重新测试：模型更新后、工具改变后、增加新的数据源后、发生事故后，或用户群体发生重大变化后。供应商还应说明如何处理回归失败。

询问事故处理路径。一个有用的回答应明确联系人、响应目标、证据保存流程，以及通知客户的阈值。如果智能体采取了超出授权范围的行动，客户需要知道供应商多快能够重建发生了什么，并停用相关能力。

最后，询问哪些主张仍然不确定。能够指出盲点的供应商，比把安全说成已经完成的属性的供应商更容易合作。评估是支持决策的证据，不是证明复杂系统不可能失败。

小团队可以采用的实际评估方案

部署一个范围狭窄的内部助手的公司，也可以采用相同逻辑，而不必聘请大型咨询机构。

把预期任务写成授权声明。例如：智能体可以总结工单并起草回复；它不得发送消息、改变账户状态，或调取指定队列之外的记录。这样，测试目标就变得可观察。

根据真实工作流的形状建立一组小规模场景，并替换其中的敏感值。场景应包括日常工作、含糊请求、文档中的恶意指令、损坏的集成、过期的权限，以及要求智能体跳过控制措施的用户。应当把其中一部分案例对负责运行模型的团队保密。

使用计划用于生产环境的准确工具和权限边界来运行场景。记录每一次工具调用、检索到的文档、状态变化、拒绝、重试和人工干预。仅仅保存最终回答的文字记录，不足以解释智能体为什么失败。

对于后果重大的案例，至少安排两名评审者，并把构建工作流的人与决定它是否可接受的人分开。对于高影响用例，可以邀请外部专业人员进行范围有限的审查。独立性可以按风险和规模调整，但不能完全缺席。

在测试前就定义停止条件。例如：试图访问被禁止的租户、未经审批产生外部副作用、审计记录无法解释地消失，或反复尝试绕过限制。如果触发停止条件，应暂停部署，并在调整提示词之前保存证据。

发生改变后重新测试。一个降低某项失败率的“修复”，可能通过让智能体更会规避、更脆弱，或更依赖无法大规模提供的人类，而制造另一种问题。应把工作流当作带回归测试的软件，而不是一条听起来更好就算完成的提示词。

成本与隐私之间的取舍

独立评估确实有成本。它需要稀缺的技术人员、安全地访问敏感系统、工程师投入时间，有时还要准备重复的基础设施。规模较小的组织可能会因为定制评估看起来负担不起，而选择接受供应商的声明。

但另一种选择并不是零成本。成本可能以服务中断、隐私事件、紧急补救、保险限制的形式出现，也可能表现为部署上线后用户已经建立依赖，只能被迫撤回。合理的做法是让评估深度与失败后果相匹配。低风险的起草工具，可能只需要书面权限审查和有针对性的测试；能够转移资金、处理医疗信息、管理基础设施或联系客户的智能体，则需要更强的区隔和周期性评估。

隐私也必须纳入评估设计。向外部评估者提供广泛日志访问权，可能制造第二次数据暴露。应使用最小化数据集、受控环境、明确的保留期限，以及对数据再利用的合同限制。应询问评估者的访问是否本身受到监控，评估机构能否使用分包商或外部模型服务。METR 的报告说明了这些细节为何重要：第三方评估可能涉及模型的原始推理、非公开信息，以及对内部系统的特殊访问权限。

最好的保障项目会让信息流动变得可见。它会说明哪些内容离开客户环境、谁能够看到、保存多久，以及发现将如何被分享。“独立”不应意味着可以在不承担责任的情况下处理客户数据。

接下来需要观察什么

Anthropic 的合作是一项早期制度实验，而不是已经定型的解决方案。它的价值取决于评估者发现严重问题时合作如何运转，取决于发布时间临近时谁能坚持暂停，也取决于公开披露与安全要求发生冲突时如何处理。

有三项发展会让嵌入式评估更可信。

第一是形成共同的报告方式。实验室不需要公开漏洞利用细节，但应逐步采用可比较的描述，说明测试范围、访问权限、失败情况、缓解措施、剩余风险和评估者独立性。没有共同词汇，每一份保障声明都会像一份营销文件，客户只能自行解码。

第二是形成更广泛的评估者生态。单一机构不可能测试每一种模型、领域和部署。Anthropic 表示这项安排并非排他性合作，并预计与多个评估者协作。如果这个生态包含技术方法、激励机制和资金来源各不相同的组织，这将是一件好事。

第三是明确评估与发布权限之间的关系。如果评估者只能在产品决定已经作出后写报告，它们只是观察者。如果评估发现能够触发暂停、更窄范围的部署，或增加额外防护措施，它们才真正成为控制系统的一部分。这种权力本身也需要规则，包括升级、申诉和问责机制。

对买方而言，实际转向已经可以开始。评估评估本身。把模型卡、基准测试、红队摘要和独立报告看作强度不同的证据。检查证据产生时所处的环境。要求供应商解释什么情况会让它停止、放慢，或改变一项部署。

核心问题已经不再是 AI 公司是否声称自己会测试模型。所有认真的供应商都会回答“会”。真正有用的问题是：测试能否看到系统真实运行的样子，能否质询构建系统的人，并在答案令人不舒服时留下审计轨迹。这应当成为企业 AI 采购开始提出的标准。

来源