AGENTIC COMMONSAI 產業簡報

繁中EN

主題AI 安全與防護出版

返回文章列表

零資料保留不讓步:OpenAI 只看訊號,不看內容

本頁內容6 個段落
  1. 難題:零資料保留碰上跨互動安全監控
  2. 實際運作:內容不離開客戶掌控,回傳的只有有限訊號
  3. 對企業資料控制權意味著什麼
  4. 產品建構者該留意什麼
  5. 接下來:盯緊技術白皮書與實際部署
  6. 參考來源

摘要: OpenAI 在 2026 年 8 月 19 日將 Private Safety Processing 推入預覽,讓符合 ZDR 條件的客戶能進行跨互動安全監控,而不把客戶內容交給 OpenAI 人員。目前客戶內容留在客戶控制的基礎設施;OpenAI 另在開發由其儲存、但以客戶控制金鑰加密的做法。系統標記風險時,OpenAI 只收到狹窄的活動類型訊號,機制計劃在 2026 年 9 月推出並發布技術白皮書,此前的細節和誤報率仍不明確。

難題:零資料保留碰上跨互動安全監控

2026 年 8 月 19 日,OpenAI 宣布 Private Safety Processing 進入預覽階段,要解開的是一個很具體的結:零資料保留(Zero Data Retention, ZDR)承諾不留下客戶的提示詞與模型回應,但最嚴重的 AI 安全風險,往往要好幾次互動擺在一起才看得出來。

OpenAI 在公告中說明,ZDR 讓符合資格的 API 客戶能有明確預期:請求處理完之後,提示詞與模型回應都不會被保留;客戶內容不會被交到 OpenAI 人員手上審查;企業客戶的資料也不會拿去訓練模型,除非客戶主動選擇加入。

只是當模型承接的任務更長、更複雜,光看單次互動就可能失真。舉例來說,惡意行為者可能一再試探防護邊界、串連多個帳號協同動作,或把威脅包裝成例行研究;代理式任務同樣會出狀況,例如使用者已經喊停,系統卻照樣繼續行動,偏離了原本意圖。要辨識這類風險,非得靠跨互動的脈絡不可。

以往某些前沿模型部署,會要求客戶同意讓 AI 供應商保留敏感內容,以進行安全監控。對不少組織來說,這種條件與自身的安全義務、或對服務對象的承諾互相衝突。Private Safety Processing 要達成的,就是讓 OpenAI 一邊繼續提供 ZDR,一邊把安全偵測做得更強。

實際運作:內容不離開客戶掌控,回傳的只有有限訊號

Private Safety Processing 是架在 ZDR 原有的自動化防護之上。過去 ZDR 相容的安全系統一次只評估一次互動,新機制把防護延伸到彼此相關的互動之間,讓自動化系統能辨識出模式,而 OpenAI 人員無法取得被保留的客戶內容。

關鍵在於內容究竟放在哪裡。在 ZDR 部署下,客戶內容留在客戶自己控制的基礎設施上;OpenAI 也正在開發另一種做法:內容存放於 OpenAI 基礎設施,但用客戶控制的金鑰加密。OpenAI 人員手上沒有這些金鑰的副本,因此讀不到底層內容。

當系統辨識出風險時,OpenAI 收到的僅是一個定義狹窄的訊號,指出涉及的活動類型,形式與現有安全系統類似。這個訊號可用來判斷是否需要採取執法行動。內容就算被標記,OpenAI 人員依然不會取得客戶內容的存取權。

客戶可以拿自家系統裡的資訊,自行調查警報與執法決定。如果想申訴、澄清合法活動,或協助調查已證實的濫用行為,客戶可以選擇把相關資訊分享給 OpenAI。

對企業資料控制權意味著什麼

OpenAI 在公告中引用了 Glean 資訊安全長 Sunil Agrawal 的說法:「企業採用 AI 完全取決於客戶對資料的控制權,除了所選服務之外,不得有任何直接或衍生的使用。OpenAI 的無訓練承諾與 ZDR 讓 Glean 有信心以 OpenAI 為基礎建置。隨著模型能力提升,OpenAI 展現了安全可以進步,而不犧牲支撐企業信任的隱私與控制。」

這段話道出產品建構者常碰上的兩難:想用最先進的模型,往往就得接受供應商對資料的某種使用或保留。ZDR 加上 Private Safety Processing,等於試著把「安全監控」與「內容暴露」兩件事拆開,讓企業在合規與信任上多一點談判空間。

OpenAI 表示,Private Safety Processing 目前正與早期客戶測試中。他們提前公開預覽,是因為客戶明確表達了對可預測性的需求——在 AI 系統能力持續增強的同時,想知道自己的內容會如何受到保護。

產品建構者該留意什麼

如果你正在評估把前沿模型 API 整合進處理敏感資料的產品,以下幾個實務考量值得注意:

  • 先釐清你的合規要求:ZDR 是否夠用?還是你需要更細緻的金鑰控制?Private Safety Processing 的兩種儲存選項(客戶控制基礎設施 vs. OpenAI 儲存但客戶持鑰)各自對應不同的風險模型。
  • 安全訊號的粒度:OpenAI 回傳的只有活動類型訊號,而非內容本身。這表示你的團隊得有能力在自家系統中調查警報,否則可能無法有效回應。
  • 申訴與澄清流程:合法活動若被誤判,客戶可以選擇分享資訊給 OpenAI 來澄清。這代表你需要建立內部流程,決定何時、如何分享哪些資料。

OpenAI 計劃在 2026 年 9 月開始推出 Private Safety Processing,並發布技術白皮書。在此之前,它仍處於預覽狀態,細節可能調整。

接下來:盯緊技術白皮書與實際部署

Private Safety Processing 的核心承諾是:安全監控可以跨互動進行,而不必把客戶內容交給供應商人員。對處理金融、醫療、商業機密等敏感資料的團隊來說,這一點尤其重要。

但預覽階段能取得的資訊有限。具體的技術實作細節、訊號的精確格式、跨互動模式辨識的準確度與誤報率,OpenAI 都還沒公布。這些都會影響實際部署的可行性。

如果你正在規劃採用前沿模型 API,建議追蹤 9 月的技術白皮書,並在早期客戶測試階段向 OpenAI 提出你的合規與安全需求。資料控制權與安全監控的平衡,會是接下來企業 AI 採用的關鍵戰場。

參考來源

AGENTIC COMMONS由 PHLEGON LABS 經營
分享X電郵
支持我們

相關閱讀

  1. OpenAI 如何安全部署 Codex:從沙箱到代理原生日誌

    OpenAI 公開了內部部署 Codex 的安全控制框架,包括沙箱、審批策略、網路限制與代理原生遙測,為企業導入 coding agent 提供參考。

    AI Safety

  2. 批評 Anthropic 設閘之後,OpenAI 也限制 GPT-5.5-Cyber 存取

    OpenAI 宣布 GPT-5.5-Cyber 僅透過 Trusted Access for Cyber 計畫提供給關鍵資安防禦者,此分層機制已涵蓋數千名驗證防禦者。九天前 Altman 才批評 Anthropic 限制 Mythos 是「恐控行銷」,如今兩家實驗室走向同一結論。

    AI Safety

  3. xAI guidelines 參數:逐請求調整 Grok 內容審核

    xAI 讓開發者在每個 API 請求附上 guidelines,逐請求設定 nsfw、violence、profanity 三類內容的處理方式。

    AI API