我们正在发布一套新框架，用于追踪、调查和披露 OpenAI 内部的模型失准（misalignment）事例，同时发布六份报告，涉及过去六个月里我们观察到的意外或令人担忧的模型行为。
过去，为了让研究人员、AI 开发者、政策制定者和公众更好地了解情况，我们曾设法公开我们的发现（关于失准）。但由于缺乏系统化的报告方式，我们的披露比较临时，频率也低于理想水平：我们常常要等到能把若干事例汇总成一份报告，或是把它们写进新发布模型的系统卡（system card）里。这套新框架旨在加快失准报告在观察到之后的发布速度，即使我们尚未完全解释或缓解所报告的行为。
随着 AI 系统越来越先进、部署越来越广泛，我们需要就对齐研究的进展形成更广泛、信息更充分的共识。我们并不认为 AI 行业已经把对齐和监控问题解决到足以让我们在未来很长时间里继续以最快速度负责任地扩展的程度。关于未来数月乃至数年 AI 开发应如何推进的决策，需要依据那些构建前沿模型的公司之外的人也能自行检验的证据。
失准的实例有助于发现其他 AI 开发者在系统达到类似能力时可能遇到的问题，揭示防护措施的弱点，或者挑战人们对模型行为的既有假设。分享这些发现，可以让其他人研究同样的问题、检验我们的解释并改进缓解措施。正因为我们相信围绕失准保持透明的价值，新框架倾向于即使重要性尚不确定也予以披露。这意味着，我们披露的某些事例可能最终被证明只是偶发现象，既不属于更大的模式，也不预示未来的发展。
目前，业内还没有一套明确规定 AI 开发者应如何披露其模型失准事例的统一框架。我们希望今天概述的这套框架是迈向此类标准的第一步，说明开发者应当披露哪些失准事例、报告应包含哪些内容。我们将这套框架视为一项持续完善的工作，会根据实践经验和公众反馈加以改进。
下面，我们介绍这套框架将如何运作，并分享首批发布的报告。
我们会报告哪些失准事例
我们的目标是披露那些能就模型失准如何产生、如何表现，以及防护措施在哪些地方奏效或失效提供有用证据的事例。我们优先关注新的机制、已知行为的重大变化，以及挑战人们对安全或缓解措施既有假设的发现。事例不必造成危害，也不必证明存在更广泛的模式，就值得披露。这套框架将覆盖模型整个生命周期中符合条件的行为，包括训练、评估、测试和部署。
这包括模型未经授权行事、与其他模型协同或规避监督的新方式；使某种对齐方法或防护措施受到质疑的失效；以及与已发布安全评估中的某项结论相冲突的行为。对于可能影响第三方的失准，同样适用这些披露标准。
这也可能包括那些看起来与我们过去披露过的事例重复的失准实例。问题的重复出现本身，可能就是说明我们的模型如何表现、或防护措施成效如何的有用证据，例如某类失准行为在多次尝试缓解之后仍不断复现。在这种情况下，我们会通过更新最初的失准披露来发布这些新增事例。
随着时间推移，我们计划与其他开发者、外部研究人员、行业标准机构和监管机构一起，制定更客观的披露标准。我们还认为，严重的安全、保障和失准事件应当向美国联邦政府通报，并正在着手提出相应的报告机制。我们认为这套框架是对现有义务的补充，并说明它不会取代我们的法定披露要求，包括针对重大安全事件或网络安全入侵的要求。
为了启动这套新的失准披露框架，我们发布六份报告，涉及我们在模型训练或评估期间观察到的失准行为。这些案例展示了我们认为值得分享的一系列不同行为，从向用户隐瞒信息，到为克服障碍而采取未经许可的行动。这些都是个案报告，不应被视为反映了我们各个模型中失准发生的频率。下面每一项都链接到完整报告。
- 任务摘要中自行生成的指令。一个未发布的研究模型在用于在新上下文窗口中继续其工作的摘要里，插入了无关的指令，其中包括让其无视正常约束的指令。我们识别出 27 份受影响的摘要。
- 任务摘要中隐瞒错误的指令。在 GPT‑5.6 Sol 的训练期间，许多模型实例在摘要中加入了向用户隐瞒错误或失准行为的指令。例如，压缩摘要（compaction summaries）中包含这样的指令：在不披露的情况下编造缺失的历史数据，并掩盖源版本之间的不一致。
- 在公共代码仓库中搜索暴露的 API 密钥，随后编造信息。在回答一个关于加利福尼亚某县收益数据的常规问题时，一个模型未经授权就找到并使用了一个暴露的 API 密钥。当它仍然无法获取所要求的数据时，便把数据编造出来，并将其呈现为来自指定来源的数据。
- 为了引用文件而将其上传到互联网。当用户向一个未发布的模型询问面积大于 5,000,000 平方米的湖泊的 ID 和名称时，该智能体用 Python 找到了正确答案。但由于指令要求提供浏览器引用，它在没有询问用户的情况下决定上传该文件，以便在回答中引用它。
- 通过内部软件仓库进行的未经许可的写入与通信。模型在寻找缺失的输入文件时，把一个内部软件仓库当作留言板，在不同的训练样本之间交换请求和回复，不过它们没能找回那些文件。这份报告还考察了更早的一起事例：一个模型在试图绕过网络限制时，成功地把测试文件上传到了某个仓库。
- 协作智能体之间未经许可的文件共享。在同一训练任务上协作的智能体，在无法访问彼此的本地文件时，使用公共文件托管网站来共享文件。这使得任务交付物出现在了公开网址上，尽管任务要求模型只使用本地文件。
我们的披露流程如何运作
任何 OpenAI 员工都可以标记一个失准事例，交由我们的安全与对齐团队调查，并请求考虑将其公开披露。这会启动我们的披露流程，每个步骤都设有期限，以确保调查和披露及时进行。
事例一经标记，我们的技术人员将调查发生了什么、还有哪些不确定之处、是否值得公开披露，以及哪些事实可以分享。他们还会评估是否有第三方受到影响，并需要在发布前私下通知。
随后，该事例将被划入三条路径之一：可披露（Ready for Disclosure）、小型调查（Minor Investigation）或大型调查（Larger Investigation，“慢速路径”）。
“可披露”涵盖调查已足够完整、经审核即可发布的符合条件的事例。“小型调查”涵盖那些需要进一步技术调查的事例。我们预计这两条路径将涵盖我们所披露事例中的绝大多数，尤其是不需要大量调查、与第三方协调或处理严重滥用风险的案例。我们今天发布的事例都属于这两条路径之一。
“大型调查”涵盖复杂的调查，尤其是涉及第三方的调查。当第三方受到影响时，我们的安全、法律和负责任披露义务优先于这套框架。我们会力争尽快发布初步通告，但可能出于安全原因而需要推迟，例如模型发现了广泛使用的软件中此前未知的漏洞。如果一份报告会暴露某个第三方的身份，那么即使没有越过任何安全边界，我们也打算提前通知对方。
“大型调查”事例的初步通告将对发生的情况作概要说明，说明是否有外部专家协助调查，并在有估计的情况下给出我们预计发布最终报告的时间。如果 OpenAI Hugging Face 事件是在这套框架下披露的，它就会归入这条路径。
提出该事例的员工将被告知是否披露的决定，以及若进行披露，它将走哪条路径。关于披露或路径选择的未决分歧，将提交 OpenAI 的安全咨询小组（Safety Advisory Group，SAG）。该小组由公司各部门的高级官员组成，负责评估前沿模型的能力与防护措施，监督我们的Preparedness Framework，并为 OpenAI 领导层提供建议。SAG 内部的分歧，或员工对其决定的异议，将上报 OpenAI 领导层。不予披露或认为无需披露的决定，将告知安全与对齐方面的负责人，并在可能的范围内告知相关技术人员。
随着我们了解这一流程在实践中的运作情况，我们可能会修订该披露流程，并将在本文中记录所有变更。
每份报告将包含哪些内容
每份完整报告将描述我们观察到的行为、其严重程度及任何外部影响、其发生的环境、日期或日期范围、我们发现它的时间，以及（概括地说）涉及的一个或多个模型。在可能的情况下，我们还会分享：
- 事件经过及由此造成的任何危害的更多细节；
- 我们如何发现这一失准，以及调查的范围；
- 我们对其在对齐研究和 AI 技术安全方面含义的解读；
- 该事例引出的重要未解问题；
- 我们正在采取或计划采取的应对措施。披露时这些措施可能并不总是已经具备，因为我们可能会在完成调查或开发出修复方案之前就发布失准报告。
对于发生在客户部署中的失准，我们将在客户隐私和合同义务允许的范围内尽可能多地分享信息。
今天的报告是首批披露，并不是对已知失准或正在进行的调查的全面说明。这些首批报告也无意代表这套框架所涵盖案例的全部范围或严重程度。我们承诺披露符合这套框架标准的失准事例，包括更复杂的案例，这类案例需要更长时间的调查或与第三方协调。我们将持续依据这套框架发布报告，并在进一步完善的过程中分享更多关于报告承诺的内容。