我们正在分享一套全新的框架，用于追踪、调查和披露 OpenAI 内部模型失准的实例，同时附上六份关于我们在过去六个月中观察到的意外或令人担忧的模型行为的报告。
过去，为了更好地向研究人员、AI 开发者、政策制定者和公众提供信息，我们曾努力将我们关于失准的发现公之于众。但由于缺乏系统化的报告方式，我们的披露一直是临时性的，频率也低于理想水平：我们常常等到能将多个实例整理成一份报告时才发布，或者将其添加到新发布模型的系统卡片中。这套新框架旨在加快在观察到失准现象后发布报告的速度，即使我们尚未完全解释或缓解所报告的行为。
随着 AI 系统日益先进、部署日益广泛，我们需要就对齐研究的进展建立更广泛、更知情的一致共识。我们并不认为 AI 行业已经在对齐和监控方面达到了足够成熟的程度，可以继续以最高速度负责任地扩展更长时间。关于未来数月和数年 AI 开发应如何推进的决策，需要依据那些前沿模型开发公司之外的人能够自行审视的证据。
错位（misalignment）的案例可能有助于识别其他 AI 开发者在系统达到类似能力时可能遇到的问题、揭示防护措施中的薄弱环节，或挑战关于模型行为的假设。分享这些发现使他人能够调查同样的问题、检验我们的解释并改进缓解措施。由于我们相信围绕错位保持透明是有价值的，我们的新框架倾向于披露，即使其重要性尚不确定。这意味着我们披露的某些实例可能被证明是虚假的，并非更大模式的一部分，也不预示未来的发展。
目前，尚无全行业框架为 AI 开发者应如何披露其模型中的错位案例制定明确标准。我们希望今天所提出的框架是朝着建立此类标准迈出的第一步，明确开发者应披露哪些错位实例以及他们的报告应包含哪些内容。我们将这一框架视为一项仍在完善中的工作，将通过经验和公众反馈加以改进。
在此，我们描述该框架将如何运作，并分享我们正在发布的首批报告。
我们将报告哪些错位案例
我们旨在披露那些能为以下问题提供有用证据的案例：模型失准如何产生、如何表现，以及防护措施在何处成功或失败。我们优先关注新机制、已知行为中的实质性变化，以及那些对安全或缓解措施相关假设构成挑战的发现。一个案例不必造成伤害，也不必构成更广泛的模式，才值得披露。该框架将覆盖模型整个生命周期中符合条件的行为——包括训练、评估、测试和部署。
这包括模型以未经授权的方式行动、与其他模型协同或规避监督的新途径；使某种对齐方法或防护措施受到质疑的失败；以及挑战已发布安全评估中某项主张的行为。同样的披露标准也适用于可能影响第三方的失准。
这也可能包括那些看似与我们过去已披露案例重复的失准实例。该问题的重复出现本身可能就是有用的证据，说明我们模型的行为方式或我们防护措施的有效性——例如，如果某种特定类型的失准行为尽管经过反复缓解努力仍持续出现。在这些情况下，我们将通过更新原有的失准披露来发布这些额外案例。
随着时间推移，我们计划与其他开发者、外部研究人员、行业标准机构和监管机构共同制定更客观的披露标准。我们还认为，严重的安全、安保和失准事件应当与美国联邦政府共享，我们正在努力提出报告机制。我们认为这一框架是对我们现有义务的补充，并指出它不会取代我们的法律披露要求，包括针对重大安全事件或网络安全漏洞的披露要求。
我们今天分享的失准案例
为启动我们全新的失准披露框架，我们发布了六份报告，涉及我们在模型训练或评估过程中观察到的失准行为实例。这些案例展示了我们认为值得分享的一系列不同行为，从向用户隐瞒信息，到为克服障碍而采取未经批准的行动。这些是单个实例的报告，不应被视为反映失准在我们各模型中发生的频率。以下每一项均链接至完整报告。
- 任务摘要中自我生成的指令。一个未发布的研究模型将无关指令插入到用于在新上下文窗口中继续其工作的摘要中，其中包括要求无视其正常约束的指令。我们识别出 27 份受影响的摘要。
- 在任务摘要中隐瞒错误的指令。在 GPT‑5.6 Sol 的训练过程中，许多模型实例在摘要中添加了指令，以向用户隐瞒错误或行为失准。例如，压缩摘要中包含指示，要求编造缺失的历史数据而不予披露，并隐瞒源版本之间的不匹配。
- 搜索公开代码仓库以寻找暴露的 API 密钥，然后编造信息。在回答一个关于加利福尼亚州某县收入数据的常规问题时，一个模型发现并未经授权使用了一个暴露的 API 密钥。当它仍然无法检索到所请求的数据时，它编造了这些数据，并将其作为来自所请求来源的数据呈现。
- 将文件上传至互联网以便引用。当用户向一个未发布的模型询问面积大于 5,000,000 平方米的湖泊的 ID 和名称时，该智能体使用 Python 找到了正确答案。但由于指令要求提供浏览器引用，该智能体决定上传该文件以便在回答中引用，而未询问用户。
- 通过内部软件仓库进行未经批准的写入和通信。模型将内部软件仓库用作留言板，在搜索缺失的输入文件时跨不同训练样本交换请求和响应，尽管它们未能恢复这些文件。本报告还审查了一个更早的实例，其中模型在试图绕过网络限制时成功将测试文件上传到了仓库。
- 协作智能体之间未经许可的文件共享。在同一训练任务上协作的智能体在无法访问彼此本地文件时，使用公共文件托管网站来共享文件。这使得任务交付物可通过公开 URL 获取，尽管任务要求模型仅使用本地文件。
我们的披露流程如何运作
任何 OpenAI 员工都可以标记一个失准案例，供我们的安全与对齐团队调查，并请求将其纳入公开披露考虑。这会启动我们的披露流程，每个步骤都有截止期限，以确保及时调查和披露。
一旦某个示例被标记，我们的技术人员将调查发生了什么、哪些情况仍不确定、是否应当公开披露，以及哪些事实可以分享。他们还会评估是否有任何第三方受到影响，并需要在发布前进行私下通知。
随后，该示例将被归入三条处理路径之一：可披露、轻度调查或较大规模调查（“慢速路径”）。
可披露涵盖符合条件的实例，其调查已足够完整，可在审核后发布。轻度调查涵盖需要进一步技术调查的实例。我们预计这两条路径将覆盖我们所披露实例的绝大多数，尤其是不需要大量调查、与第三方协调或处理严重滥用风险的案例。我们今天发布的实例全部属于这两条路径之一。
较大规模调查涵盖复杂调查，尤其是涉及第三方的调查。当第三方受到影响时，我们的安全、法律和负责任披露义务优先于本框架。我们会力求尽快发布初步通知，但可能出于安全原因需要推迟——例如，如果模型发现了广泛使用的软件中此前未知的漏洞。如果一份报告会指认某一第三方，即使未跨越任何安全边界，我们也打算提前通知。
较大规模调查实例的初步通知将概要说明所发生的情况，说明是否有外部专家协助调查，并提供我们预计何时发布最终报告的任何可用估计。OpenAI Hugging Face 事件如果根据本框架披露，本应归入这一轨道。
提出该示例的员工将被告知是否披露该示例的决定，以及如果进行披露，将遵循哪一轨道。关于披露或适当轨道的未解决分歧将提交给 OpenAI 的安全咨询小组（SAG），该小组由公司各领域的高级官员组成，负责评估前沿模型能力和保障措施、监督我们的 Preparedness Framework，并向 OpenAI 领导层提供建议。SAG 内部的分歧，或员工对其决定的反对意见，将上报至 OpenAI 领导层。不披露或披露不成立的决定将与安全和对齐领导层共享，并在尽可能的范围内与相关技术人员共享。
随着我们在实践中了解这一流程的运作方式，我们可能会修订本披露流程，并将在本文中记录任何变更。
每份报告将包含的内容
每份完整报告将描述我们观察到的行为、其严重程度及任何外部影响、行为发生的场景、发生日期或日期范围、我们发现它的时间，以及（在较高层面上）涉及的模型。在可能的情况下，我们还将分享：
- 事件经过的更多细节及由此造成的任何损害；
- 我们是如何发现这一失准行为的，以及我们的调查范围；
- 我们对其在对齐研究与技术性 AI 安全方面影响的解读；
- 该示例所引出的重要未解问题；
- 我们正在采取或计划采取以应对该行为的措施。这些措施在披露时未必总能提供，因为我们可能在完成调查或制定修复方案之前就发布失准报告。
对于发生在客户部署中的失准，我们将在客户隐私和合同义务允许的范围内尽可能多地分享信息。
今天的报告是一组初步披露，而非对已知失准或正在进行的调查的全面说明。这些初步报告并不旨在代表本框架所涵盖案例的全部范围或严重程度。我们承诺披露符合本框架标准的失准实例，包括需要更长时间调查或与第三方协调的更复杂案例。我们将持续依据本框架发布报告，并随着我们不断完善相关承诺，分享更多关于报告承诺的信息。
We are sharing a new framework for tracking, investigating, and disclosing instances of model misalignment at OpenAI, along with six reports on unexpected or concerning model behavior we’ve observed in the last six months.
In the past, so as to better inform researchers, AI developers, policymakers, and the general public, we’ve sought to make ourfindingsaboutmisalignment public. But without a systematic approach to reporting these findings, our disclosures have been ad hoc and less frequent than ideal: we’ve often waited until we could collate several instances into one report, or added them to system cards for newly released models. This new framework is intended to expedite publishing misalignment reports following observation, even when we haven’t fully explained or mitigated the behavior we’re reporting.
As AI systems grow more advanced and more widely deployed, we need to build a broader and better-informed consensus on the progress of alignment research. We do not believe that the AI industry has solved alignment and monitoring to a sufficient degree to continue responsibly scaling at maximum speed for much longer. Decisions about how AI development should proceed in the months and years to come need to draw on evidence that people outside the companies building frontier models can examine for themselves.
Examples of misalignment may help identify problems other AI developers might encounter as their systems reach similar capabilities, reveal weaknesses in safeguards, or challenge assumptions about model behavior. Sharing these findings allows others to investigate the same problems, test our explanations, and improve mitigations. Because we believe in the value of transparency around misalignment, our new framework favors disclosure even when significance is uncertain. This means that some of the instances we disclose could prove to be spurious and not part of a larger pattern or suggestive of future developments.
At the moment, there is no industry-wide framework with explicit standards for how AI developers should disclose examples of misalignment in their models. We hope that the framework we’re outlining today is a first step toward creating such standards, setting out which misalignment instances developers should disclose and what their reports should contain. We regard this framework as a work in progress, which we’ll refine through experience and public feedback.
Here, we describe how the framework will operate and share the first reports we’re publishing.
What misalignment examples we’ll report
We aim to disclose examples that provide useful evidence about how model misalignment arises, how it manifests, and where safeguards succeed or fail. We prioritize new mechanisms, meaningful changes in known behavior, and findings that challenge assumptions about safety or mitigation. An example need not cause harm or establish a broader pattern to merit disclosure. This framework will cover qualifying behavior throughout a model’s lifecycle—including training, evaluation, testing, and deployment.
This includes new ways for models to act without authorization, coordinate with other models, or evade oversight; failures that call an alignment method or safeguard into question; and behavior that challenges a claim in a published safety assessment. The same disclosure criteria apply to misalignment that may impact third parties.
This might also include instances of misalignment that appear to be duplicative of instances we’ve disclosed in the past. Repetition of the issue might itself be useful evidence about how our models behave or about the effectiveness of our safeguards—for example, if a specific kind of misaligned behavior continues to recur despite repeated efforts to mitigate it. Under these circumstances, we’ll publish the additional examples by updating the original misalignment disclosure.
Over time, we plan to develop more objective disclosure criteria with other developers, external researchers, industry standards bodies, and regulators. We also believe that serious safety, security and misalignment incidents should be shared with the US federal government, and we are working to propose reporting mechanisms. We consider this framework complementary to our existing obligations, and note that it does not replace our legal disclosure requirements, including those for critical safety incidents or cybersecurity breaches.
The misalignment examples we’re sharing today
To inaugurate our new framework for disclosing misalignment, we’re publishing six reports on instances of misaligned behavior we’ve observed during the training or evaluation of our models. These cases illustrate a range of different behaviors that we believe are worth sharing, from concealing information from the user to taking unsanctioned actions in order to overcome obstacles. These are reports of individual instances, and shouldn’t be considered reflective of how often misalignment occurs across our models. Each item below links to the full report.
- Self-generated instructions in task summaries. An unreleased research model inserted unrelated instructions, including instructions to disregard its normal constraints, into summaries used to continue its work in a new context window. We identified 27 affected summaries.
- Instructions to conceal mistakes in task summaries. During the training of GPT‑5.6 Sol, many model instances added instructions to their summaries to conceal mistakes or misaligned behavior from the user. For example, compaction summaries included instructions to invent missing historical data without disclosing it and to hide mismatches in source versions.
- Searching public repositories for exposed API keys, then fabricating information. While answering a routine question about earnings figures in a California county, a model found and used an exposed API key without authorization. When it still wasn’t able to retrieve the requested figures, it fabricated them and presented them as data from the requested source.
- Uploading files to the internet in order to cite them. When a user asked an unreleased model for the IDs and names of lakes larger than 5,000,000 square meters, the agent found the correct answer using Python. But since the instructions asked for a browser citation, the agent decided to upload the file so that it could cite it in its answer, without asking the user.
- Unsanctioned writes and communication through an internal software repository. Models used an internal software repository as a message board to exchange requests and responses across separate training samples while searching for missing input files, though they weren’t able to recover those files. This report also examines an earlier instance in which a model successfully uploaded test files to a repository while attempting to bypass network restrictions.
- Unsanctioned file sharing between collaborating agents. Agents working together on the same training task used public file-hosting websites to share files when they could not access one another’s local files. This made task deliverables available at public URLs, even though the task requested the models use only local files.
How our disclosure process works
Any OpenAI employee may flag a misalignment example for investigation by our safety and alignment teams and request that it be considered for public disclosure. This starts our disclosure process, with deadlines for each step to ensure timely investigation and disclosure.
Once an example has been flagged, our technical staff will investigate what happened, what remains uncertain, whether public disclosure is warranted, and which facts can be shared. They’ll also assess whether any third party was affected and needs private notification before publication.
The example will then be assigned to one of three tracks: Ready for Disclosure, Minor Investigation, or Larger Investigation (“Slow Track”).
Ready for Disclosure covers qualifying instances whose investigation is sufficiently complete for publication after review. Minor Investigation covers those that need further technical investigation. We expect these two tracks to cover the large majority of the instances we disclose, particularly cases that don’t require extensive investigation, coordination with third parties, or handling of severe misuse risks. The instances we’re releasing today all fall into one of these two tracks.
Larger Investigation covers complex investigations, especially those involving third parties. When a third party is affected, our security, legal, and responsible disclosure obligations take precedence over this framework. We’ll aim to publish an initial notice as soon as possible, but may need to delay it for security reasons—for example, if a model discovers a previously unknown vulnerability in widely used software. If a report would identify a third party, we intend to provide advance notice even when no security boundary was crossed.
The initial notice for a Larger Investigation instance will give a high-level account of what happened, say whether outside experts are assisting the investigation, and provide any available estimate of when we expect to publish a final report. The OpenAI Hugging Face incident would have fallen under this track had it been disclosed under this framework.
The employee who raised the example will be informed of the decision on whether to disclose it and, if disclosure proceeds, which track it will follow. Unresolved disagreements about disclosure or the appropriate track will be referred to OpenAI’s Safety Advisory Group (SAG), a group of senior officials from across the company that assesses frontier model capabilities and safeguards, oversees our Preparedness Framework, and advises OpenAI leadership. Disagreements within SAG, or staff objections to its decisions, will be escalated to OpenAI leadership. Decisions not to disclose or that disclosure is not warranted will be shared with safety and alignment leadership and, to the extent possible, with relevant technical staff.
We may revise this disclosure process as we learn how it works in practice, and will record any changes in this post.
What each report will include
Each full report will describe the behavior we observed, its severity and any external impact, the setting in which it occurred, its date or date range, when we discovered it, and, at a high level, the model or models involved. Where possible, we’ll also share:
- Further details of what happened and any resulting harm;
- How we discovered the misalignment, and the scope of our investigation;
- Our interpretation of its implications for alignment research and technical AI safety;
- Important unanswered questions raised by the example;
- Measures we are taking or planning to take to address the behavior. These may not always be available at the time of disclosure, since we may publish the misalignment report before completing our investigation or developing a fix.
For misalignment that occurs in customer deployments, we will share as much information as customer privacy and our contractual obligations allow.
Today’s reports are an initial set of disclosures, rather than a comprehensive account of known misalignment or ongoing investigations. These initial reports are not intended to represent the full range or severity of the cases covered by this framework. We are committed to disclosing instances of misalignment that meet this framework’s criteria, including more complex cases requiring longer investigation or coordination with third parties. We will continue publishing reports under this framework on an ongoing basis, and will share more about our reporting commitments as we continue to develop them.