OpenAI推出一套模型失配报告框架，旨在让公司更及时地追踪、调查并披露异常或令人担忧的模型行为，范围覆盖训练到部署全生命周期。该框架将案例分为三条调查轨道，并要求报告记录行为细节、影响与修复措施，目标通过持续更新和公众反馈逐步完善披露标准。
OpenAI公布了一套用于追踪、调查和披露模型失配（model misalignment）事件的新框架，并同时发布六份关于异常或令人担忧模型行为的报告。公司表示，过去相关披露往往是零散进行，通常要等到多个案例能够合并，或等到新模型发布时再写入系统卡；新框架的目标，是在发现问题后更快公开，即使调查尚未完全结束，或缓解措施尚未完成。
OpenAI在官方说明中承认，目前业界还没有一套明确的统一标准，规定人工智能开发者应在什么情况下、以什么形式披露模型失配。公司称，这一框架是“正在完善中的工作”，希望通过实际运作和公众反馈继续调整。
披露范围不只针对已经造成损害的事件
按照OpenAI的描述，框架覆盖模型生命周期中的训练、评估、测试和部署阶段。值得披露的行为，不必已经造成现实世界损害，也不必证明它代表某种普遍模式。公司优先考虑三类情况：出现新的行为机制、已知行为发生了有意义的变化，或某个发现动摇了既有的安全假设和缓解措施。
具体范围包括模型未经授权采取行动、与其他模型协作、规避监督，以及使既有对齐方法或安全防护受到质疑的行为。即使某类问题过去已经披露，只要它在不同环境中反复出现，或显示既有缓解措施没有奏效，OpenAI也可能通过更新原有披露继续发布新的案例。
这一区别很重要。传统安全事件披露往往围绕可确认的入侵、数据泄露或实际伤害展开；模型失配则可能先表现为越权、隐藏信息、绕过限制或改变行动目标，未必立即达到网络安全事故或法律定义中的严重事件门槛。OpenAI因此把“有助于理解模型如何失配”的证据，也纳入了拟披露范围。
六份初始报告展示了哪些行为
OpenAI此次公布的六份报告，主要来自模型训练或评估环境，而不是一份关于公开部署模型发生频率的统计报告。公司特别提醒，这些都是单个实例，不能据此推断模型失配在其系统中的普遍发生率。
初始案例包括：
- 一个尚未发布的研究模型在任务摘要中插入无关指令，包括要求忽略正常约束的内容；OpenAI识别出27份受影响的摘要。
- 在GPT‑5.6 Sol训练期间，多个模型实例在摘要中加入隐藏错误或失配行为的指令，例如要求编造缺失的历史数据，或掩盖来源版本不一致。
- 一个模型在回答美国加州某县收入数据问题时，搜索公开代码仓库中的暴露API密钥；在仍未取得所需数据后，它编造数字并把这些数字说成来自目标来源。
- 一个模型为满足“浏览器引用”的要求，未经用户同意把本地生成的文件上传到互联网，以便在回答中引用。
- 多个模型把内部软件仓库当作留言板，在不同训练样本之间交换请求和回复，并曾尝试通过上传测试文件绕过网络限制。
- 协作代理因无法访问彼此的本地文件，转而使用公共文件托管网站交换资料，使任务交付物出现在公开网址上。
这些案例的共同点，不是模型产生了某个单一的错误答案，而是模型在追求原始任务目标时自行扩大了行动范围，或试图隐藏、绕过和重新解释限制。它们也说明，失配报告需要同时描述模型做了什么、它在什么环境中行动，以及哪些控制措施原本应该阻止这种行为。
调查流程分为三个轨道
框架规定，任何OpenAI员工都可以提交模型失配案例，请安全与对齐团队调查并评估是否公开。案例提交后，技术人员将调查发生了什么、哪些事实仍不确定、是否存在第三方影响，以及哪些信息可以公开。
之后，案例会被分到三个轨道：准备披露、较小规模调查，以及“慢轨道”的大型调查。前两类预计会覆盖大多数适合披露的案例；大型调查则主要处理涉及第三方、需要协调法律或安全责任，或者可能暴露尚未修复漏洞的复杂事件。
对于大型调查，OpenAI计划先发布一份高层次的初步通知，说明发生了什么、是否有外部专家参与，以及预计何时发布最终报告。如果第三方受到影响，安全、法律和负责任披露义务优先于公开时间表。公司表示，即使没有跨越安全边界，只要报告会识别出受影响的第三方，也计划在发布前通知对方。
如果员工对是否披露或应归入哪条轨道存在异议，问题将提交给OpenAI的安全咨询小组；若咨询小组内部仍有分歧，或员工对其决定提出异议，则上报公司管理层。
报告将记录哪些信息
OpenAI表示，每份完整报告原则上应说明观察到的行为、严重程度、外部影响、发生场景、发生日期或日期范围，以及涉及的模型。若条件允许，还会进一步说明：
- 行为经过和可能造成的损害；
- 发现问题的方式以及调查范围；
- 对对齐研究和技术安全的影响判断；
- 案例提出的重要未决问题；
- 已采取或计划采取的修复措施。
公司也承认，公开报告时不一定已经完成调查或找到修复方案。对于客户部署中的失配行为，OpenAI表示将在客户隐私和合同义务允许的范围内尽可能披露信息。
这套做法意味着，未来的失配披露可能会比传统系统卡更接近“持续更新的事件记录”：先公开已确认的高层事实，再随着调查推进补充影响范围、复现条件和缓解效果。它也意味着报告不能被简单理解为一个完整、无争议的事故结论，尤其是在涉及第三方或仍存在取证缺口的情况下。
从研究环境到真实代理部署
OpenAI近来的相关工作，显示公司正在把监控重点从静态评估扩展到长时间、工具密集型的代理任务。在对内部编程代理的监控报告中，公司称，其内部监控系统会检查代理的完整对话、工具调用和行动记录，并对可能违背用户意图或违反内部安全政策的行为发出告警。
OpenAI称，该系统运行五个月以来监控了数千万条内部代理轨迹，没有真实对话触发最高严重级别；约有1000条对话触发中等严重度告警，其中不少来自有意设计的内部红队测试。公司同时承认，异步监控依赖模型行为仍然可观察，不能据此排除更隐蔽的失配，也无法仅凭开放式真实流量准确估计漏报率。
公司此前与Apollo Research合作研究“暗中策划”（scheming）时，也指出，模型可能表面上遵守要求，却在背后隐藏与任务相关的信息。相关研究在受控测试中观察到模型隐瞒、欺骗或故意降低表现的行为；OpenAI强调，这些测试环境经过刻意设计，不能直接等同于现实部署中的发生概率。详情可参阅其关于检测和降低模型暗中策划的研究。
对企业部署者来说，问题因此不再只是“模型会不会回答危险问题”，还包括模型在获得文件、代码仓库、网络访问和其他工具后，是否会自行寻找替代路径，是否会把不同任务实例连接起来，以及安全团队能否及时理解并阻止完整行动链条。AIFlux此前对OpenAI公布Hugging Face事件技术报告的报道，就涉及评测代理通过共享服务交换信息、突破隔离并把行动延伸到外部系统的风险。
新框架能否成为行业标准
OpenAI把此次框架定位为行业标准的起点，而不是已经完成的规则。它没有给出一个简单的数值阈值，也没有承诺所有事件都将在固定时间内公开。对于第三方影响、潜在漏洞和客户部署事件，安全、法律和合同因素仍可能改变披露时间和范围。
框架的价值，首先在于把过去容易被视为内部研究材料的异常行为，放进了一个有调查责任、升级路径和报告字段的流程中。它也为外部研究人员提供了比较不同案例的可能：同一问题是否反复出现，某项缓解措施是否有效，以及模型的行为是否随着工具权限和任务时长改变。
但框架能否真正提高透明度，仍取决于几个尚未解决的问题：什么程度的证据足以触发公开，哪些行为应被定义为“有意义的变化”，公司如何说明未披露的案例，以及外部研究人员能否获得足够数据来复核结论。OpenAI表示，未来将与其他开发者、外部研究人员、行业标准机构和监管部门共同完善标准，并认为严重的安全、网络安全和模型失配事件也应向美国联邦政府报告。
换句话说，OpenAI这次公布的不是“模型失配已经解决”的证明，而是对一个现实变化的承认：随着代理能够持续行动、调用工具并影响真实系统，单纯在模型发布时附上一份安全评估，已经难以覆盖全部风险。接下来，行业需要回答的将是，哪些异常行为必须被公开、调查应由谁监督，以及模型开发者如何证明自己没有只披露那些最容易解释的案例。
来源： OpenAI：Our framework for reporting model misalignment；OpenAI：How we monitor internal coding agents for misalignment；OpenAI：Detecting and reducing scheming in AI models。