AI安全報告，怎樣把等待中的個案講清楚

2026年10月30日，OpenAI宣布計劃在2027年初推出社區安全報告，並在未來幾週開始推出新的防護措施。這些仍是待落實的承諾，尚不能當作已經完成的效果評估。公告

這份預告提出了一個具體的AI治理問題：未來的安全報告，應該讓讀者判斷出什麼？干預總量可以說明做了多少事，但要判斷回應系統是否足夠，還需要了解它接收到怎樣的個案、處理需要多久，以及哪些後續結果根本無法觀察。以下是Open Market Notes提出的分析框架，並非對OpenAI內部流程的描述。

比較總量之前，先定義統計單位

同一個人可能觸發多個訊號，涉及多段對話，也可能經過多次審查。如果每一項都被算成一個個案，數字增長可能只是同一問題被反覆處理。只計算帳戶也有另一種缺陷：持續很久的個案仍然只有一個計數，實際佔用的人力卻可能大幅增加。

一種更有解釋力的披露方式，是分別記錄訊號、進入審查的個案和最終行動，同時說明相關記錄在什麼條件下合併。這不要求公開個人身分，而是要求統計規則穩定。當規則改變時，應當把規則變化的影響與實際工作量變化分開，讓讀者知道兩期數字是否仍然可比。

分母也需要服務於明確的問題。每活躍使用者對應多少次行動，可以描述營運規模，卻很難說明嚴重風險被正確處理的比例。每個已審查個案對應多少次行動，回答的又是另一個問題，而且僅僅調整進入審查的條件，就可能讓這個比例發生變化。任何一種比率都不宜獨自承擔「安全得分」的功能。

沿著同一批個案觀察等待過程

可以設想一個虛構的服務：報告期快結束時，新進入一批個案；同一週，團隊恰好完成了許多此前積壓的工作。儀表板上的新增量和完成量可能十分接近，但新個案仍在等待。只比較進出數量，就會掩蓋等待時間的差異。

按進入時間分組追蹤，可以觀察同一批個案經過不同時間後，還有多少沒有得到決定。不同緊急程度應當分開：少數時間敏感的個案，可能比大量迅速解決的低優先級事項更值得關注。一個平均回應時間，容易把管理層最需要看到的尾部情況藏起來。

這樣，資源安排才有更具體的依據。如果偵測系統帶來更多待審事項，機構就需要檢查專家可用時間、交接安排和決策權限是否跟得上。發現能力增加，而某個瓶頸沒有變化，等待時間就有可能延長。這是一種值得檢驗的營運機制，不是關於任何特定公司現狀的指控。

把糾正錯誤所需的工作計算進去

一項行動可能符合當時掌握的資訊，後來又需要調整。只統計首次決定，會遺漏覆核申訴、在適當情況下恢復使用，以及更正記錄的工作。反過來，決定被撤銷，也不能單獨證明最初的審查者存在失職。

更有幫助的說明，應當交代哪些決定可以重新審查、覆核需要多長時間，以及什麼新資訊改變了結論。政策變化與原政策下的錯誤糾正也應分開。否則，撤銷比例上升可能被誤讀為表現惡化，實際上卻可能來自更便利的覆核管道，或者更有效的錯誤發現。

NIST AI RMF把監測、回應時間和回饋納入風險評估。這是一個可參考的框架，並不構成對任何供應商結果的認證。本文提出的具體報告方法，仍需要結合使用目的進行檢驗。

觀察到的結果與因果判斷應分別呈現

完成一次移交或干預，是可以記錄的行動。要證明它阻止了多少傷害，還需要回答一個更難的問題：如果沒有這次行動，原本會發生什麼？這個反事實可能一直無法獲得。外部機構也未必能提供完整的後續資訊，而回饋延遲會使近期個案的結果成熟度低於較早個案。

可信的報告可以承認這些限制，同時繼續提供有用資訊。它可以區分已經完成的行動、得到外部確認的後續處理，以及仍然未知的結果；明確觀察窗口，在新證據到來時更新較早批次。缺失結果應該被明確標為缺失，不能默認為成功，也不能直接判定失敗。

隱私還會限制公開的顆粒度。人數很少的分組、過細的時間資訊，可能暴露個人或敏感流程。採用彙總區間、隱藏小樣本單元，並解釋無法披露的部分，有時比看起來精確的表格更合適。這些處理也會限制跨期比較，因此應當與統計結果一起說明。

評估未來報告時，值得關注的是證據能否支持具體決定：哪裡需要補充審查能力，哪個環節需要調整，哪些判斷還為時過早。一份主張較少、卻能交代未解決個案的報告，可能比更大的一組干預總數更有助於判斷。