OpenAI 安全人員離職：企業採用 AI 要看治理證據

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-03

前 OpenAI 安全人員 David Robinson 本周離職後，透過《The Atlantic》文章批評 AI 業界文化「失靈」。據 The Verge 報道，他過去曾撰寫 OpenAI 每次重大模型發布所附的安全報告，並認為業界以高度自信和持續衝刺的方式開發更強模型，容易忽視或低估潛在問題。這宗事件影響的不只是模型公司內部員工；使用 ChatGPT、API、AI coding 工具或辦公自動化工具的個人與企業，同樣要面對供應商如何證明產品可安全部署的問題。

不過，現有報道主要是 Robinson 的個人說法，未有披露某一模型、某次發布或某項測試具體出了甚麼問題，亦未載有 OpenAI 的回應。因此，事件不能被解讀為已證實 OpenAI 的產品存在即時而特定的安全事故，更不應把對長遠災難風險的憂慮直接當成既成事實。較合理的閱讀方式，是把它視為一個治理警號：當模型能力、接入範圍和工作流程同步擴大，外界需要的已不只是公司聲稱「重視安全」，而是可以檢視的流程與責任界線。

安全報告的價值，在於讓風險可被追問

Robinson 曾負責的安全報告，按其職務描述，是伴隨重大模型發布的文件。這類文件若要對客戶和外部持份者有用，重點不在於羅列抽象原則，而在於交代測試的範圍、已知限制、適用情境，以及在甚麼條件下不應使用。報告可以令採購方追問：模型曾否在接近實際用途的情境受測？測試涵蓋的是文字輸出，還是包括可讀取資料、呼叫工具、執行多步任務後的行為？若答案只有概括承諾，企業便難以把供應商風險納入自身的內部控制。

這也反映「部署前測試」與一般產品 demo 的差別。demo 可展示模型能完成甚麼；部署前測試則應着眼於模型在出錯、遇上含糊指令、處理敏感資料或獲得過多權限時會做甚麼。對會自動整理文件、草擬回覆、寫程式或串接公司系統的 AI 工具而言，錯誤輸出未必只是答案不準，還可能令錯誤資料被傳遞、機密內容被納入工作流程，或令同事過度依賴看似合理的結果。這是由報道引出的風險管理分析，並非指任何個別 OpenAI 工具已發生上述情況。

「核電廠級」比喻，重點是冗餘與停機能力

Robinson 主張前沿 AI 實驗室應採取接近核電廠或繁忙機場的保障水平，以多重冗餘及審慎、耗時的規劃，減少人為失誤通向災難的機會。這個比喻未必直接等同某一套可照搬的技術規範，但對企業使用者頗有啟發：高影響流程不應把單一模型輸出直接視作最終決定，也不宜讓單一帳戶持有過闊權限，或容許一次指令同時觸及過多資料及操作。

實際採用時，企業可按用途劃分風險層級。低風險用途，例如初步構思或語句潤飾，可保留基本的人手覆核；涉及客戶資料、內部文件、程式碼或對外決策的流程，則應先界定可輸入資料、可連接系統和可執行動作，再安排覆核、記錄及停止機制。這不是要求所有人把 AI 項目變成冗長審批，而是把控制力度放在錯一次代價較高的位置。若供應商更新模型、改變工具能力或調整資料處理安排，原有評估也應重新檢視，不能假定首次批准後便一直適用。

供應商評估要由功能比較走向問責比較

The Verge 指出，Robinson 是近期多名離開知名 AI 公司並公開談論安全憂慮的人員之一；報道亦列出 Anthropic 和 Google DeepMind 的數名前員工。這種人事流動本身未能證明任何公司的制度必然不足，卻顯示安全、速度和商業競爭之間的拉扯，已成為業界公開爭論。對採購團隊而言，單看模型能力、成本和整合方便程度已不夠，還要問供應商在出現限制、事故或重大更新時，會如何告知客戶及提供處置渠道。

可供內部討論的問題包括：團隊能否取得足以理解用途限制的安全資料；公司能否控制哪些員工可使用哪些資料連接 AI 工具；輸出被用於客戶溝通、程式部署或營運決定前，誰負責覆核；以及發現異常時能否迅速撤回權限、停用整合並追查受影響內容。這些問題未必有一個放諸所有 AI 工具的答案，但可以把「相信供應商」轉化成可分工、可驗證的工作流程。

下一步值得觀察的，是 AI 公司會否把安全報告、部署限制和事件通報做得更具體，以及企業客戶會否把這些資訊列入續約和採購條件。對一般用戶來說，最直接的做法仍是把 AI 視為需要核對的協作工具，避免在不清楚資料流向和權限範圍時交付敏感內容。Robinson 的指控尚待更多資料與多方回應釐清，但它已提醒市場：模型愈深入工作流程，安全治理便愈不能停留在宣言層面。