待验证｜OpenAI公布第三方评估原则

OpenAI 9月22日发布了一套让第三方评估进入前沿模型安全流程的优先领域和操作原则。它没有给出新的评估报告；本次新闻增量在于，OpenAI把外部审查从“发布前请人测试一下”扩展为覆盖训练、评估、内部部署和外部部署的长期机制，并把访问边界、信息安全、修复窗口和责任发布一起写进原则。需要说明的是，采集阶段通过CDP脚本读取到官网正文；直接curl或严格新鲜度脚本访问该页会遇到Cloudflare 403，因此本文按低置信发布流程处理。

公告中最硬的数字是4个优先评估领域和7项有效评估原则。OpenAI还写明，不同评估可以并行推进，周期从数周到数月不等；这里讨论的工作通常是“longer-term and launch-agnostic”，对应中文应写为更长期、通常不绑定某一次模型发布。

结果状态必须单独降级。OpenAI没有宣布哪家机构已经完成新评估，也没有给出首批报告。它说的是“正在与多个第三方讨论符合这些优先领域的提案”。因此，今天只能写成“OpenAI提出第三方评估优先领域和原则”，不能写成“OpenAI通过第三方认证”或“已有独立评估背书”。

读者可以按角色理解影响。安全评估机构会拿这篇文章争取更清晰的访问范围；企业采购和治理团队会把第三方评估报告纳入模型准入材料；前沿模型实验室则会面对一个更具体的问题，哪些安全声明可以接受外部机构带着证据反问。

这次新增了什么

OpenAI把第三方评估的目标定义为检查具体、重要的问题：实验室的安全案例是否有证据支撑，评估是否真的测到了它声称要测的风险，防护机制在现实条件下是否有效。这里有两个关键词需要先翻译清楚。

第一是 safety claim。OpenAI将其定义为关于模型或系统能力、行为或防护的具体断言，且这些断言必须关系到安全，并能被证据评估。第二是 safety case。它是由证据支撑的结构化论证，用来说明某个模型或系统在训练、评估或部署等指定活动中的风险为何被充分管理。

把这两个概念放进第三方评估后，评估对象就不再只是“模型有没有危险能力”这一张测试表。外部评估方要问的是：实验室提出的安全声明是否成立，证据是否覆盖关键风险，训练和部署过程中是否真的遵守了安全案例设定的条件，未覆盖的风险是否被明确标出。

OpenAI列出的4个优先领域如下：

优先领域	覆盖范围	评估要回答的问题
safety case独立评估	训练、评估、内部部署、外部部署	安全声明和证据是否足以支持部署决策
关键防护评估	内部和外部部署	模型级防护、执行防护、安全防护和misalignment监控是否有效
能力与alignment评估	生化、网络安全、AI自我改进和misalignment风险	Preparedness阈值和严重失配风险是否被测到
关键失配事件调查	失控、规避监督、未授权行为等事件	事件原因、防护缺口和修复措施是否足以防复发

这里的“内部部署”很重要。许多前沿系统在公开上线前，已经进入公司内部研究、自动化、代码、监控或实验环境。如果第三方评估只盯外部产品，就会错过模型在内部工具链中获得更大权限、更多上下文和更少用户摩擦的阶段。OpenAI把 internal deployment 写进优先领域，等于承认安全评估需要进入更早、更靠近真实能力使用的位置。

七项原则定义了访问边界

第三方评估最容易卡在访问问题上。没有足够访问，评估方只能做黑箱测试，难以判断安全声明背后的证据；访问过深，又会触碰知识产权、模型安全、用户数据和未公开系统信息。OpenAI这次把“proportionate access”写成原则，意思是在法律、安全和IP限制内，评估方应获得与约定声明相称的访问。

这不是无限访问。官文明确保留了多种边界：如果直接访问不现实或不可行，评估方可以与公司指定代表合作，也可以探索间接或隐私保护访问机制。对外部审查来说，这是一种现实主义安排；对公众来说，它也意味着独立性必须靠方法透明、利益冲突披露和报告边界说明来补足。

OpenAI的7项原则可以压缩成三组约束：

约束组	对应原则	它解决的问题
评估设计	明确范围、透明方法、专业与独立	避免评估题目过宽、方法不可复核或利益冲突未披露
访问与保密	比例访问、安全和保密	在能挑战安全声明和保护敏感信息之间取平衡
修复与公开	可执行发现、修复时间、责任发布	让发现能被修，而报告尽量公开且可解释删节

责任发布是另一个关键点。OpenAI称报告应尽量基于证据公开，但也要保护敏感和保密信息；完整公开不可行时，可以向公司治理机构或董事会等适当监督主体做保密报告。它还提出应有原则性的删节政策，让实验室可以请求删除敏感信息，同时评估方可以注明实质性删节及其对报告的影响。

这套写法把“独立”和“保密”的冲突摆到了台面上。它没有承诺所有报告全文公开，也没有说实验室不能要求删节；但它要求报告区分直接发现和解释，解释不确定性，并说明证据支持哪些结论。未来如果评估报告只剩高度删节摘要，公众仍然很难判断评估强度；如果报告能列明哪些内容被删、删节理由是什么、删节是否影响结论，外部监督才有抓手。

关键措辞需要逐字保留

这篇公告容易被过度翻译。尤其要避免把“长期、与发布解耦”写成“OpenAI每次发布前都会做完整第三方评估”，也不能把“正在讨论提案”写成“已经确定合作方”。几个原文状态动词的中文边界如下：

“generally longer-term and launch-agnostic”应写为通常更长期、且不绑定单次发布；它不等于所有模型发布前都已完成第三方评估。“support multiple assessments in parallel”说明OpenAI愿意支持多个评估并行推进，不代表已经同时启动所有评估。“some lasting weeks and others several months”只描述可能周期，不是统一承诺固定评估时长。“in conversation with multiple third parties”是正在讨论提案，不是公布合作名单或评估结果。“as openly as possible”也只是尽量公开报告，不是承诺全文无删节公开。

这些措辞解释了为什么本文整体仍按 low/developing 处理。发布事实、原则条款和评估范围来自 OpenAI 官方原文，但外部新鲜锚点受限；评估有效性、访问深度、外部机构是否满意、报告能否公开，也还没有实证结果。

放在评估生态里看

OpenAI在官文中说，没有一个第三方能够或应该全面覆盖所有紧迫的前沿安全问题。这句话既是生态判断，也是责任分配。前沿AI安全问题横跨网络安全、生化风险、AI自我改进、对齐失配、监控可靠性、内部部署权限和事件响应。单一机构很难同时具备全部专业能力，也很难在同一报告里处理所有敏感访问。

背景源能帮助理解这个判断，但不能替代当天新闻。英国AI Security Institute与Meridian Labs维护的 Inspect Evals 文档，把评估拆成任务、模型和评分等可复用组件。这里引用它只为解释“评估生态需要工具和方法”，不代表OpenAI已经采用该工具。

这说明第三方评估正在从“找题测模型”变成“围绕声明、证据、访问、复现和发布的制度设计”。OpenAI这次发布的价值在于，作为最大模型实验室之一，它把第三方如何进入内部证据链写成了公开原则。真正困难的部分也在这里：外部评估既要足够深入，能挑战实验室自己的安全论证；又要足够克制，不能泄露会降低模型安全或暴露敏感系统的信息。

采购和监管该怎么读

企业安全团队可以把这篇文章当作未来模型准入材料的清单。采购时不应只问“有没有第三方评估”，还要问评估是否覆盖自己关心的部署场景：是公开聊天产品，还是内部自动化Agent；是普通文本任务，还是网络安全、生化信息或代码执行；是一次性问答，还是长期运行、可调用工具、可写入系统的工作流。

更具体的做法是把 OpenAI 的7项原则转成采购问题。评估范围是否预注册，报告是否说明哪些结论只是解释，评估方是否披露商业关系，实验室是否给出修复窗口，公开版本是否标注删节影响。这些问题比“模型在某个安全榜单得分多少”更接近企业风险控制，因为真实风险经常发生在权限、数据、工具调用和组织流程交界处。

监管者也会看到一个可对齐的语言。OpenAI官文提到未来法律和私人治理机构的共同标准，Inspect Evals提供了评估执行工具链的例子。它们之间还没有自动等价关系，但已经形成同一条问题链：谁提出安全声明，谁拿到证据，谁检查方法，谁决定哪些内容能公开，谁负责跟踪修复。

接下来要等三类证据

先看合作方和范围。OpenAI说正在与多个第三方讨论提案，但没有公布名单。后续最重要的是每个评估的具体 scope：检查哪个模型、哪个部署阶段、哪个 safety claim、什么访问级别，以及哪些内容排除在外。

再看报告质量。有效报告至少要给出证据、方法、不确定性、发现列表、修复状态和删节说明。如果只公开笼统结论，第三方评估就很难服务公众问责；如果报告能说明哪些发现经过修复、哪些风险仍残留，它才会变成采购和监管可用的材料。

最后看组织影响。launch-agnostic 的意义在于，评估不被单次发布窗口牵着走。后续要观察评估发现能否反过来改变训练过程、内部部署权限、外部发布节奏和监控设计。机制停留在公告层面时，它只是治理叙事；能够影响模型上线条件时，它才是安全基础设施。