模型通過一次測試還不夠：OpenAI 的訓練安全案例，把「安全」變成可查核的文件

一個模型通過了一次紅隊測試，就能支持繼續訓練、甚至上線嗎？OpenAI 於 2026 年 9 月 28 日發表前沿 AI 訓練安全案例的初步指引，給出的答案傾向否定。這套方法要求開發團隊把每一句「風險已受控制」拆開來看：證據是什麼、誰負責確認、條件改變時誰有權按下暫停。這項改變聽起來技術味很重，但它影響的是很日常的事，就像工地安全不再只靠「工人都有戴安全帽」這句話，而是要有檢查紀錄、複查時間和異常通報的窗口。

安全案例在做什麼事

OpenAI 自己把這套方法定位為發展中的方向，現階段只是初步指引。核心概念並不新：航空、核能等高風險產業早就有類似的結構化風險論證制度，把主張、控制措施與證據綁成一份可審查的文件。OpenAI 明言 AI 能力變動帶來的新興複雜度，讓這些領域的嚴謹程度難以直接移植，比喻提供的是組織文件與審查的參考，而非一套現成的認證制度。

一般安全簡報常見的寫法是「已完成紅隊測試」「訓練環境有沙箱」。問題在於，沒有測試範圍、結果、限制與後續責任，決策者無法判斷這些說法能支持到哪一步。安全案例追問的是：主張針對什麼風險？測試在什麼條件下執行？結果能不能重現？未被控制的殘餘風險由誰簽字接受？

範圍也要先劃清楚。這份指引聚焦前沿強化學習訓練階段，內部與外部部署還有更多對齊面向要處理。換句話說，訓練階段的安全案例不能代替產品部署審查，也不能證明模型在所有使用情境都安全。團隊應先寫明審查對象、訓練階段、模型版本、預期用途與排除範圍，避免一份證據被延伸解讀到沒測過的場景。這與我們先前分析的OpenAI 新安全政策把防線前移到訓練室方向一致，只是這次把焦點放在文件與審查的格式上。

技術防護的三個環節

指引把技術防護分成三層：對齊訓練、限制模型行動範圍、即時監控。每一層都要指定可檢查的測試、紀錄與觸發門檻，並確認層與層之間沒有縫。

對齊訓練與評估處理的是獎勵駭客問題。模型會順著訓練獎勵調整行為，如果強化學習環境有漏洞，模型可能靠鑽漏洞拿高分，錯誤策略就被強化下去。用個比喻，這像學生發現閱卷老師只看字數，就開始寫冗長廢文衝篇幅，成績很好，但能力是假的。OpenAI 建議以自動化代理和人工檢查訓練資料與環境，調整評分器使其能辨認鑽漏洞行為，並回頭檢查過去實驗軌跡，確認評分器真的照預期運作。驗收證據不能只寫「完成資料審查」，而要記錄抽查範圍、發現的環境缺陷、修正前後差異。評估還要以過往事件回測，確認方法抓得住已知問題，若模型能察覺自己正在受測，也要監看它是否因此改變行為，並事先定義何種跡象會阻止訓練。

限制模型行動範圍不只在外圍放一層沙箱。指引建議同時強化執行模型的沙箱與承載沙箱的研究基礎設施，反覆紅隊測試尋找逃逸路徑，測試範圍涵蓋訓練期間模型可能碰到的服務（例如網路快取），多樣本或代理之間的高頻寬通訊則限於核準管道。重要證據包括威脅模型、沙箱設定、紅隊案例、已修補弱點與未修補的例外。訓練、評估與內部部署的逐步紀錄要防止事後無痕修改，異常發生時才能重建當時的輸入與操作條件。

監控與應變是第三層。監控系統的價值取決於兩件事：能不能發現新舊風險，警報響了之後有沒有人動作。OpenAI 建議用過往事件保留測試集檢查召回能力，同時加入新一輪訓練可能出現的風險案例，避免監控評估只在反覆測量舊問題。模型是否嘗試躲避監控，本身也可設成評估項目與門檻。操作層的設計更實際：高優先級警報要連到值班人員或自動暫停機制，訂出回應時限；夜間警報無人確認時是否自動暫停訓練，要事先決定。驗收時可以實際演練警報，確認通知送達、暫停權限可用、紀錄完整。指引講得很直白：單有監控儀表板，無法證明組織會在傷害發生前處理問題。

對開發團隊的實際意義

這份指引真正要求的是把技術證據一路連到可執行的暫停決策。對在企業內部導入 AI 的團隊來說，同樣的邏輯可以縮小規模使用：供應商說模型「已做安全評估」時，可以追問評估範圍、測試條件與殘餘風險由誰承受；自己微調模型時，可以比照留下訓練資料抽查紀錄與異常處理紀錄。這不需要等到產業出現通用認證制度才開始做。

值得留意的限制也很清楚。指引自己承認範圍只到訓練階段，部署端的對齊與使用情境風險不在這份文件內；它也明言航空與核能的嚴謹程度難以直接複製。安全案例現在提供的是格式與審查思路，讓「模型安全嗎」這個問題，從形容詞變成一疊可以逐條核對的文件。下一步觀察指標是其他前沿實驗室是否跟進類似格式，以及監管機關會不會把這種證據結構寫進法規要求，這與我們先前討論的阿特曼的安全承諾與上市時間表屬於同一條線：安全主張最終都得變成可檢驗的東西，才站得住腳。