OpenAI 在 ChatGPT 與 Codex 的資料控制頁提供「為所有人改善模型」開關,關閉後對話不會用於模型訓練。二零二六年十一月三日,一名企業使用者在 Hacker News 指出該開關在未經同意的情況下回到開啟狀態,貼文累積五百一十點與一百五十一則留言。同類回報在九月十日已經出現,顯示現象至少持續兩個月。

上一輪討論的貼文獲得四百八十七點與六十九則留言,作者表示已重設多次,並且刻意記下時間。

提出貼文的使用者描述了一個具體場景。其所屬公司對智慧財產外洩相當謹慎,團隊成員一直主動在 Codex、Claude Code 等工具中關閉資料分享,但同事在十一月二日發現設定再次處於開啟狀態,沒有人記得曾經重新同意。

貼文附上兩個檢查位置。第一個是 ChatGPT 設定頁的資料控制區,尋找「為所有人改善模型」選項;第二個是 OpenAI 私隱入口的「不要以我的內容訓練」申請表單,屬於獨立於前者的另一條路徑。

這次事件的核心是什麼?

核心是一項已經關閉的資料分享選項回到開啟狀態,且使用者沒有收到通知。爭議不在預設值本身,而在關閉狀態能否被系統穩定維持。

事件本身相當單純。使用者曾經關閉訓練選項,事後檢查卻發現它處於開啟狀態,過程中沒有任何提示、郵件或確認視窗。

七月至九月的討論串顯示這不是孤例。當時的貼文作者表示已重設多次,並且刻意記下重設時間,之後仍然發現選項被重新打開。

兩次討論的共同點是缺乏可觀測性。使用者無法在產品介面中查到「何時被改動、由哪個流程改動」,只能憑記憶比對當下的狀態。

Hacker News 討論頁面截圖,標題為「OpenAI seems to be silently re-enabling model training on Codex chats」,顯示五百一十點、一百五十一則留言與貼文正文的設定檢查說明

「改善模型」開關覆蓋哪些資料?

該選項控制對話內容是否用於改進模型,涵蓋網頁版對話與 Codex 工作階段。關閉後資料仍會保留一段時間以回應服務請求,與訓練用途分屬不同層級。

這個選項的適用範圍是討論中最常被誤解的部分。它管的是內容可否進入訓練流程,並不等同刪除紀錄,也不等同零資料保留。

使用者層級、工作區層級與企業層級各自擁有獨立設定。企業方案的合約條款通常另有約定,管理員可以在後台統一關閉,但個人帳號的設定不會被公司政策覆蓋。

討論中有人指出,關閉選項之後仍應到私隱入口提交「不要以我的內容訓練」申請。兩個入口的效力不同,前者是偏好設定,後者是一份可追溯的請求紀錄。

為何設定會自行回復?

目前沒有官方解釋。討論提出三種可能:前端顯示與後端狀態不同步、同意條款更新時一併重設、以及多個產品共用同一個帳號層級開關而互相覆蓋。

第一種可能是介面樂觀更新。使用者按下關閉後,前端立即顯示成功,但寫入請求其實失敗,之後重新載入頁面才顯露真實狀態。

第二種可能與條款更新有關。多名留言者提到,接受新版本服務條款或參與活動時,同意範圍可能一併被重設,而這類變動通常只出現在長篇文件中。

第三種可能是作用域重疊。ChatGPT 網頁版、Codex 桌面版與命令列工具共用同一個帳號設定,任何一個入口的變更都可能影響其餘入口。

需要說明的是,討論中存在相反證據。有人表示自己的選項維持關閉狀態,其中一位明確提到身處歐盟地區,暗示區域法規可能影響預設行為。

使用者可以如何檢查與關閉?

先到 ChatGPT 設定的資料控制區確認開關狀態,再到私隱入口提交不要訓練的請求,最後檢查組織後台與各代理工具的獨立設定,並記錄每次變更日期。

檢查應該由帳號層級開始。登入後進入設定頁的資料控制區,找到與模型改善相關的選項,確認當下狀態,並且在變更後截圖留存時間。

第二步是私隱入口。該頁面提供獨立的控制表單,可以針對內容使用提出限制請求,完成後會留下可供日後核對的紀錄。

第三步是組織層級。若帳號屬於工作區或企業方案,管理員應在後台檢視統一設定,並確認成員的個人偏好不會被覆寫。

第四步是工具層級。Codex 桌面版、命令列版與各類代理外掛可能各自保存資料分享設定,需要逐一確認,而不是假設與網頁版同步。

企業環境有哪些更穩妥的做法?

可考慮簽訂零資料保留合約、改用雲端廠商的託管模型服務、以硬體金鑰加固帳號,並建立定期稽核訂閱帳號設定的內部流程。

合約是最直接的一層。零資料保留條款把不訓練、不留存寫入具約束力的協議,違反時有明確的救濟途徑,比介面選項更容易在審計中說明。

第二層是改用雲端平台。透過主流雲廠商呼叫同系列模型時,資料處理條款由雲端合約管轄,訓練與保留政策通常寫得更清楚。

第三層是帳號加固。討論中有人指出,啟用進階帳號安全並綁定硬體金鑰後,資料分享會一併被鎖定關閉,這屬於產品層面的間接效果。

第四層是內部稽核。有團隊為此自行開發工具,定期掃描所有代理工具與訂閱帳號的訓練狀態,出現異常即通知負責人。

Hacker News 留言區截圖,多名使用者分別報告自己的開關維持關閉、在 Claude Code 遇到類似情況,以及建議改用雲端託管模型或簽訂零資料保留合約

這次爭議反映了什麼?

反映的是可驗證性缺口。使用者能看到的只有一個核取方塊,卻無法查核背後的寫入、同步與版本紀錄,信任因此建立在無法檢驗的假設上。

討論中最集中的批評並非針對訓練本身,而是針對「關閉」這個動作沒有對應的證據。使用者按下開關之後,沒有回執,也沒有歷史紀錄。

這種設計把驗證成本轉移到使用者身上。企業需要自行建立掃描工具、定期截圖、比對設定,才能勉強維持一個可審計的狀態。

同一時段的其他留言也提到類似經驗,包括另一個代理工具在組織已關閉回饋功能的情況下仍然觸發回饋流程。這些案例指向同一個結構問題,而非單一廠商的疏失。

出處連結有哪些?

資訊來自 Hacker News 於十一月三日發布的討論串,以及九月十日的同類貼文。兩者均為使用者自述經驗,OpenAI 未在串中作出官方回應。

常見問題有哪些?

以下四題涵蓋受影響範圍、關閉後的資料保留、企業帳號的處理方式,以及如何判斷設定是否真的生效,全部依討論串中的公開陳述整理。

這次問題影響哪些產品?

討論主要指向 ChatGPT 網頁版的資料控制設定,並延伸至 Codex 桌面版與命令列工具。由於三者共用帳號層級,任何一個入口的變更都可能反映到其餘入口,實際範圍仍待官方說明。

關閉訓練選項後,對話會被刪除嗎?

不會。關閉的意義是內容不進入訓練流程,服務仍可能保留對話以維持運作與處理濫用,保留期限依方案與地區而異。需要更嚴格處理時,應採用零資料保留合約或企業方案。

企業帳號應該由誰負責檢查?

應由管理員在組織後台統一確認,並把成員個人設定納入定期稽核。單靠員工自行關閉無法形成可審計的紀錄,也難以在事故發生時提供證據。

如何判斷設定是否真的生效?

變更後重新載入頁面再確認一次,並保留截圖與時間。若使用開發者工具,可以觀察寫入請求是否成功回應;出現失敗時介面未必會提示,這就是最常見的假象來源。

總結:這個開關還值得信任嗎?

短期內仍可使用,但不宜作為唯一防線。個人應定期重查並留存紀錄,企業則應以合約、雲端託管與內部稽核補足,把可驗證性放在介面承諾之上。

對個人使用者而言,實際可行的做法是養成複查習慣。每次更新工具或接受新條款之後,回到設定頁確認一次,並保留截圖。

對企業而言,一個核取方塊不足以構成合規依據。合約條款、部署方式與稽核流程三者結合,才能在爭議出現時提供可追溯的證據。

這次討論的價值不在於判定某一家廠商是否有意為之,而在於把「關閉之後如何證明仍然關閉」這個問題攤開來。當工具無法回答這個問題,使用者只能用自己的方法補上。