Private Safety Processing 是什麼?OpenAI 零資料保留

內容目錄 顯示

⚡ 站長快讀:核心重點

文章屬性:科技冷知識 / 規格解析
核心結論:Private Safety Processing 是 OpenAI 為了「繼續提供零資料保留」而設計的安全機制——自動化系統跨多次互動找濫用樣態,OpenAI 只收到「警示類別與嚴重程度」這種窄訊號,原始提示詞與回應不進 OpenAI 人員手上。
適用對象:用 OpenAI API 的開發者與企業 IT、關心 AI 供應商怎麼處理自己資料的一般使用者
查證基準:2026-09-14,依 OpenAI 官方公告與 API 官方文件、Anthropic 官方公告交叉查證(非第一手實測)

📌 快速答案

一句話答案:Private Safety Processing 是 OpenAI 相容零資料保留的安全機制,由自動化系統跨多次互動偵測濫用,只回傳警示類別與嚴重程度,OpenAI 人員看不到原始內容。

🔍 故事的起點

前沿 AI 供應商這兩年被同一道題卡住:要抓出用 AI 搞事的人,就得留下對話;可是金融、醫療、法律這些受監管產業的資安長第一句話往往是「我的資料不能離開我的環境」。兩邊都合理,而且直接互斥。

Anthropic 在 Fable 5 上線時導入 30 天保留,結果在企業客戶端撞得滿頭包;OpenAI 則在 2026 年 8 月 19 日發了一篇公告,標題是「Offering Zero Data Retention for frontier models」,重申零資料保留(Zero Data Retention,ZDR)不會因為模型變強就縮水,同時預覽了一套叫 Private Safety Processing 的機制。

這套機制想解的,就是上面那道題:在「不留內容」的前提下,還要能看出跨越多次互動才浮現的惡意。有趣的是,這件事之所以難,不是加密難,而是「安全監控」這件事本質上需要上下文,而零資料保留的定義就是把上下文丟掉。

這篇把三件事拆開講:ZDR 到底承諾了什麼(以及哪些東西其實仍然會留)、Private Safety Processing 用什麼設計繞開這個矛盾,以及一般 ChatGPT 帳號到底有沒有這個東西——最後這題的答案,和多數人直覺相反。

🧪 原理拆解

先分清楚:ZDR 承諾的是什麼、沒承諾什麼

先講結論:ZDR 承諾的是「請求處理完就不留提示詞與模型回應」,不是「OpenAI 什麼都不記錄」。 這兩件事在官方文件裡分得很清楚,但在轉述中經常被壓成同一句話。

依 OpenAI 官方公告,ZDR 給合格 API 客戶的承諾有三層:請求處理完後不保留提示詞與模型回應、客戶內容不提供給 OpenAI 人員審查、企業客戶資料除非明確選擇加入否則不用於訓練模型。

再往 API 官方文件挖,才看得到平常被略過的機制細節:

預設狀態不是零留存。 濫用監控紀錄(abuse monitoring logs)預設會針對所有 API 使用產生,並保留最多 30 天,除非法律要求更久、或為保護服務與第三方免於損害而有合理必要。
ZDR 要申請。 合格客戶可透過 Zero Data Retention 或 Modified Abuse Monitoring 兩種控制把內容排除在濫用監控紀錄之外,但這兩種控制目前都需要 OpenAI 事前核准並接受額外要求,核准後可在組織層級或專案層級各別設定。
它會直接改端點行為。 組織啟用 ZDR 後,/v1/responses 與 /v1/chat/completions 的 store 參數一律視為 false,就算請求裡硬填 true 也一樣。
不是每個端點都適用。 官方文件明載,未列為 ZDR 適用的端點或能力,即使組織開了 ZDR,仍可能保留應用狀態(application state)。
快取是另一回事。 提示詞快取可能把加密後的 key/value 張量放在 GPU 本機儲存作為應用狀態,官方說明是這份資料存放在本機 GPU 機器上、24 小時到期後不再保留。
有些功能乾脆被擋。 /v1/videos 目前對 MAM 或 ZDR 請求是封鎖的;要用得另外開一個把保留控制設成 None 的專案。

把這串讀完會有個直覺:ZDR 是一組逐端點成立的工程承諾,不是一句行銷口號。這也是為什麼它需要申請——供應商得先確認你的用法落在可保證的範圍內。

為什麼「一次只看一句」不夠

先講結論:真正嚴重的風險,通常不會在單一次對話裡露出馬腳。

OpenAI 在公告裡把理由寫得很直白:最嚴重的 AI 安全風險往往要把多次互動合起來看,惡意企圖才會顯形。官方舉的樣態有三類——反覆試探防護機制的邊界、跨多個帳號協同行動、把威脅包裝成例行研究。

第四類更值得注意,因為它和「壞人」無關:agentic 任務跑歪。官方的例子是系統在被告知停止之後仍繼續動作,偏離了使用者原本的意圖。當 AI 開始接手更長、更複雜的任務,判斷「這是正常作業還是失控」就更依賴跨互動的上下文。

問題是,既有的 ZDR 相容安全機制是逐次互動各自評估的。每一次請求看完就丟,自然看不到跨越五次、跨越三個帳號的樣態。這就是 Private Safety Processing 要補的洞:把既有的自動化防護延伸到相關聯的互動之間。

Private Safety Processing 怎麼做到「看得到樣態、看不到內容」

先講結論:關鍵不在加密演算法多神,而在三個位置的重新安排——內容放哪、誰去看、回傳什麼。

第一,內容放哪。 在 ZDR 部署中,客戶內容留在客戶自己控制的基礎設施上。OpenAI 同時在開發另一個選項:內容存放在 OpenAI 的基礎設施,但以客戶控制的金鑰加密;官方明確寫道 OpenAI 人員沒有那些金鑰的副本,因此無法存取底層內容。

第二,誰去看。 兩種情況下,實際讀取內容的都是自動化系統,不是人。Private Safety Processing 直接在客戶內容所在之處運作,不需要把內容搬回 OpenAI 再分析。

第三,回傳什麼。 這是整個設計的樞紐:當自動系統識別出風險,OpenAI 收到的是一個範圍狹窄、只說明活動類型的訊號,用來判斷是否需要執法行動。官方在架構圖裡把這句話寫得更死——OpenAI 看到的只有警示類別與嚴重程度,沒有客戶內容;即使某段內容被標記,OpenAI 人員也不會因此取得存取權。

第四(其實是第四個位置):誰來調查。 客戶端拿到的是完整警示,可以用自己系統裡的資訊去調查警示與執法決定。如果客戶想申訴、想說明那是正當活動,或想協助調查已確認的濫用,才由客戶選擇性地把相關資訊分享給 OpenAI。主動權在客戶手上。

把四點連起來看,Private Safety Processing 的本質是一次信任邊界的搬家:原本「供應商持有內容 → 供應商判斷 → 供應商執法」的直線,被拆成「客戶持有內容 → 自動系統判斷 → 供應商只收標籤」。

OpenAI Private Safety Processing 與 Anthropic Enterprise Frontier Safeguards 架構對照表

仍然會留下的東西:三個例外先知道

先講結論:「零資料保留」不等於「絕對沒有任何東西被留下」,官方自己就列了例外。

例外一:CSAM 法定通報。 OpenAI 在公告的註腳明載,如同其他前沿模型供應商,依美國聯邦法 18 U.S.C. 2258A 必須通報疑似兒童性虐待材料;被分類器標記為疑似 CSAM 的圖片,即使在 ZDR 部署中也會繼續保留以供人工審查與通報。API 文件也對應寫明:圖片與檔案輸入在送出時即會掃描,命中就留存。

例外二:Safety Retention。 官方文件寫得很清楚:對已核准 ZDR 或 MAM 的客戶,OpenAI 保留權利在「為調查或防止嚴重風險活動而有合理必要」時,讓特定客戶的特定模型不再適用 ZDR/MAM,並事前以書面通知受影響客戶;在這種情況下,被分類器判定可能違反使用政策的內容可能被保留並經人工審查。

例外三:合規責任回到客戶身上。 這條最容易被忽略——官方明訂,啟用 Modified Abuse Monitoring 或 Zero Data Retention 的客戶,有責任確保其使用者遵守 OpenAI 的安全使用政策,並遵守適用法律下的審核與通報義務。換句話說,把監控搬進自己家,義務也一起搬進來了。

站長我的看法是:這三條不是小字陷阱,而是這類設計的必然代價。任何把監控責任下放給客戶的架構,都得在「法律硬性義務」和「供應商最後的緊急剎車」上留孔——真正該問的不是「有沒有例外」,而是「例外的觸發條件寫不寫得出來」。以這次的文件來說,前兩條都寫出了觸發條件與通知方式,這比含糊帶過好得多。

一般帳號有沒有?ChatGPT 與 API 的分水嶺

先講結論:沒有,而且分界線很清楚。 ZDR 從定義上就是 API 側的控制——官方公告的主詞是「合格 API 客戶」,API 文件則把它放在組織/專案層級的資料保留控制裡,且需要事前核准。個人用的 ChatGPT 帳號不是 API 組織,自然沒有這個開關,Private Safety Processing 這次預覽的對象也是既有的 ZDR 部署與早期企業客戶。

對一般使用者來說,真正能動的旋鈕在另一個地方:各家 AI 助理自己的隱私設定(要不要拿你的對話訓練模型、對話保留多久)。這件事我們另外寫過一篇對照與逐家關閉教學,想動手的直接看你跟 AI 說的話會被拿去訓練嗎?四大 AI 助理隱私設定一次關。

反過來說,如果你是在企業裡負責評估 AI 導入的人,這條分水嶺就是採購時要問清楚的第一題:你們談的是「產品層級的隱私設定」,還是「合約層級的資料保留控制」? 兩者不是同一種東西,也不是同一個價位。

💡 總結:冷知識延伸

站長我讀完這兩份文件最大的感想是:2026 年前沿模型的競爭,已經從「誰的模型比較強」延伸到「誰能讓受監管產業敢按下部署鍵」。OpenAI 和 Anthropic 幾乎在兩週內前後腳端出結構相似的答案,不太可能是巧合——這是同一批客戶、同一套需求同時推出來的結果。

另一個冷知識是用語本身。「零資料保留」聽起來像個開關,實際上是一組逐端點成立的承諾:有些端點適用、有些不適用,快取有自己的到期規則,法律義務又在最上層另開一道門。下次看到任何服務宣稱「我們不保留你的資料」,值得多問一句:不保留的是哪一種資料、保留在哪一層、例外寫在哪裡?

最後提醒一句:本文所有事實均取自 OpenAI 與 Anthropic 的官方公告與官方技術文件,非站長第一手實測;Private Safety Processing 目前仍在早期客戶測試階段,實際行為以各家合約與最終文件為準。本文為技術解析,不構成法律或合規建議。

❓ 常見問題

Q:OpenAI 員工看得到我丟進 API 的內容嗎?

在 ZDR 部署下,官方承諾是「客戶內容不提供給 OpenAI 人員審查」,而 Private Safety Processing 的設計是即使內容被標記,OpenAI 人員也不會取得存取權,只收到警示類別與嚴重程度。但要注意上面講的例外:疑似 CSAM 的圖片依法仍會保留供人工審查;另外官方保留在調查嚴重風險時、經書面通知後暫停該客戶 ZDR/MAM 適用的權利。沒開 ZDR 的一般 API 使用,預設則會產生最多保留 30 天的濫用監控紀錄。

Q:一般 ChatGPT 帳號有 Private Safety Processing 嗎?

沒有。ZDR 與 Private Safety Processing 都走 API 組織/企業合約這條線,而且 ZDR 需要事前核准。個人版 ChatGPT 要管隱私,是走產品內的資料控制設定,兩者不是同一套機制。

Q:跟企業版差在哪?

差在「控制放在哪一層」。ChatGPT 企業版是產品層級的方案設定;ZDR 與 Private Safety Processing 是基礎設施與合約層級的資料保留控制,能決定內容存在誰的機房、用誰的金鑰加密、警示送給誰。企業要的是後者,因為稽核時要拿得出來的是後者。

Q:跟 Anthropic 的 Enterprise Frontier Safeguards 差在哪?

大方向同構、細節有別。Anthropic 於 2026 年 9 月 1 日發表 EFS,做法是把監控用的活動資料存進客戶自己的雲端帳號(Amazon S3、Azure Blob Storage 或 Google Cloud Storage),客戶自管加密金鑰與存取政策,旗標直接送給客戶、不需要 Anthropic 人員人工審查;客戶自有儲存、客戶自管金鑰、全自動審查三項各自可選,EFS 本身不收費(但客戶自存的雲端費用由雲端商計費),預計今年秋季分階段推出。OpenAI 這邊則是在 ZDR 部署中把內容留在客戶自控的基礎設施,另外還在開發「存在 OpenAI、但用客戶金鑰加密」的選項。想看 EFS 的完整拆解,可以讀 Enterprise Frontier Safeguards 是什麼?企業自管資料,Claude 還抓得到壞人嗎。

Q:技術白皮書出了嗎?

OpenAI 在 8 月 19 日的公告中表示,計畫於 9 月開始推出 Private Safety Processing 並同時發布技術白皮書。截至本文查證日(2026-09-14),該篇公告頁面仍維持此一預告寫法,尚未看到白皮書的公開連結;細節以 OpenAI 屆時公布為準。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Offering Zero Data Retention for frontier models(OpenAI 官方公告,2026-08-19) — 2026-09-14 查證
Your data(OpenAI API 官方文件:資料保留控制、ZDR/MAM、端點適用表) — 2026-09-14 查證
Developing Enterprise Frontier Safeguards with our customers(Anthropic 官方公告,2026-09-01) — 2026-09-14 查證

📖 第二級|權威技術媒體:

OpenAI previews privacy-focused system for detecting AI misuse(Help Net Security,2026-08-20) — 2026-09-14 查證

📅 本文查證戳記:2026-09-14 解析撰寫。
下次建議複檢:2026-10-14(觀察技術白皮書是否發布、Private Safety Processing 是否由預覽轉為正式推出、ZDR 端點適用表是否變動)