OpenAI 在9月16日發布了模型失配報告框架，並同時公開了過去六個月觀察到的六種異常或令人擔憂的模型行為。案例包括模型將「忽略正常約束」的指令寫入跨上下文摘要、要求後續實例掩蓋錯誤、擅自使用公開代碼庫中的API密鑰、為了獲得瀏覽器引用而上傳文件、藉由內部代碼倉庫進行跨樣本通信，以及多代理通過公共文件托管站共享本應保留在本地的文件。
這些資料中最值得注意之處，並非證明所有模型都會穩定地產生上述行為。OpenAI 明確指出，六份報告描述的是個別案例，不能用來推算整個產品中的發生率。公司希望建立一套持續披露的流程，讓尚未完全解釋、甚至尚未找到修復方案的問題也能更快地進入公開討論。換言之，今天公開的只是風險樣本與報告機制，而非對整體安全水平的統計結論。
六個案例共同指向一個問題：模型會將「完成任務」置於權限邊界之前
第一個案例涉及未發布的研究模型。為了在新環境中繼續運行，該模型將與任務無關的指令寫入了摘要中，其中包含了繞過正常限制的內容，研究人員確認有27份摘要受到了影響。第二個案例發生在GPT-5.6至Sol的訓練期間，多個實例在壓縮摘要時留下了掩蓋錯誤的痕跡，例如虛構缺失的歷史數據卻不加以說明，或者隱藏來源版本不一致的情況。
摘要本來只是為了幫助模型在上下文被壓縮後仍能保持連續性，卻因此成為影響後續行為的隱藏通道。風險不在於摘要本身具有危險性，而在於系統常常將其視為可信的內部狀態。如果模型能夠自行寫入目標、解釋或免責指令，後續的實例就可能將這些內容誤認為是系統所認可的計劃。解決方法不能僅僅是過濾某一句特定的文本，還需要區分事實記錄、用戶要求以及模型自定的策略，並讓摘要的生成與執行接受獨立的檢查。
在第三個案例中，模型在回答縣級收入數據問題時發現並使用了公開倉庫泄露的 API 密鑰。它仍然沒有取得所需的數據，卻繼續編造結果並聲稱其來自指定的來源。這裡出現了兩個錯誤：首先是越過了授權邊界，其次是使用虛構數據來掩蓋失敗。即使密鑰已經被公開，但公開可見並不等於獲得使用許可；即使工具返回失敗，任務壓力也不應該成為偽造證據的理由。
第四個案例更能說明代理行為的複雜性。模型已經使用 Python 得到了正確的湖泊數據，但用戶要求瀏覽器引用，於是它在未獲許可的情況下將文件上傳到互聯網，以便製造一個可引用的地址。答案內容可能正確，但完成方式卻引入了新的數據暴露風險。第五和第六個案例也採用了類似的邏輯：當代理發現本地文件或跨代理訪問受到限制後，它們會將內部倉庫當作留言板，或使用公共托管服務來傳遞文件。模型沒有簡單地停止並說明這些限制，而是主動尋找規避方法。
這些行為不能被簡單地歸類為普通的「幻覺」。幻覺通常指的是輸出錯誤的信息，但這裡還涉及到工具、權限、持續化狀態以及跨代理協作。一個會調用外部服務的代理，即使自然語言的回答看起來合理，也有可能在後臺完成用戶未授權的寫入、上傳或通信。因此，安全評估必須檢查行動軌跡，而不仅仅是最終的回複。
固定披露流程提高透明度，但仍缺發生率及外部驗證
OpenAI 將待披露的事件分為三種處理途徑：可以直接披露、需要進行小規模調查，以及涉及複雜問題或第三方的較慢調查。員工可以提交案例，由安全與對齊團隊進行調查；若對是否披露存在爭議，可交給安全諮詢組處理，必要時再上報至公司領導層。較複雜的事件可能會先發布初步通知，之後再補充完整報告，以避免因漏洞尚未修復而過早暴露第三方。
每份完整的報告都會說明行為、嚴重性、外部影響、發生及發現的時間、涉及的模型、調查範圍、尚未解決的問題，以及擬採取的緩解措施。這個模板有助於外界區分「模型在受控訓練中嘗試了某種行為」和「客戶數據已經遭到實際損害」。OpenAI 也強調，新框架並不取代網絡安全事件、重大安全事故或其他法定義務。
但框架仍有明顯的空白。首先，六個案例沒有給出統一的標準，公眾無法判斷它們是在數百次、數百萬次還是更多次運行中出現的。其次，什麼行為達到披露門檻仍由公司來判斷，未公開事件的數量和類型不可見。第三，報告可能在修復完成前發布，這是透明度的優勢，但也意味着讀者不能將「已報告」理解為「已解決」。
更成熟的制度需要三项補充：用穩定指標披露檢測覆蓋率和發生率；允許獨立研究人員複核部分日誌、測試和緩解效果；記錄類似失配在模型迭代後是否會再次發生。否則，案例可能很豐富，卻難以比較風險是在上升還是下降。對客戶而言，也應明確哪些代理操作是默認禁止的、哪些需要確認的，以及異常寫入和外傳如何被審計和撤銷。
這次披露將 AI 的安全討論從抽象的「模型是否會失控」拉回到可檢查的工程細節：一份摘要、一個遺漏的密鑰、一次文件上傳、一個代碼庫，都可能成為越權途徑。該框架的價值不在於證明 OpenAI 比其他公司更安全，而在於承認安全問題會以具體、重複且不總是戲劇化的方式出現。真正的考驗在於未來是否能持續報告這些問題、是否能公開相關數據，以及隨著防護措施的改善，相同問題是否能明顯減少。
