目錄
本文資訊以 2026 年 8 月為準，Private Safety Processing 目前仍處於早期客戶測試與逐步推出階段。
OpenAI 公布一項對企業與 API 開發者影響相當直接的調整：公司會繼續為符合資格的 API 客戶提供 Zero Data Retention（零資料留存，ZDR），同時預覽新的 Private Safety Processing 安全機制。這兩件事被放在同一篇公告裡並不是巧合，因為它們處理的是同一個逐漸浮上檯面的矛盾：當 AI 從單次回答問題，變成可能持續數十分鐘甚至數小時執行 Agent 任務，某些風險只有把前後多次互動放在一起才看得出來，但跨互動安全分析通常又需要某種形式的狀態或紀錄，這剛好會碰上企業對資料留存的限制。
對一般 ChatGPT 網頁使用者來說，這不是突然多出一個新的隱私開關，這次公告主要碰的是符合資格的 API 與企業工作負載，尤其是會處理財務紀錄、健康資料、客戶合約、未公開產品資料或內部研究的流程。真正需要先搞懂的，也不是一句「OpenAI 不留資料」就能說完，而是哪些內容不會進入安全監控日誌、哪些功能本身仍需要保存 Application State，以及資料如果又被送到外部 MCP 或 SaaS，後面的留存政策是不是完全不同。
Zero Data Retention是什麼？先分清「不拿去訓練」和「不保存內容」
OpenAI API資料預設不拿來訓練，ZDR處理的是另一層留存問題
OpenAI API 傳入的資料預設不會拿來訓練或改善模型，除非客戶主動選擇分享，但「不拿去訓練」和「完全不保存」一直是兩件不同的事。一般 API 使用情況下，OpenAI 仍可能建立 Abuse Monitoring Logs，用來執行使用政策與偵測濫用，這些日誌可能包含 Prompt、Response，以及由內容衍生的安全分類資訊，預設最長可以保存 30 天。
Zero Data Retention 則是在這一層再往前一步。符合資格並經 OpenAI 核准的組織，可以讓 Customer Content 不進入這類 Abuse Monitoring Logs，而支援 ZDR 的 Responses API 與 Chat Completions 等端點，也會把 store 強制視為 false。因此，比較準確的理解是：一般 API 已經預設不拿資料訓練模型，ZDR 則進一步限制 OpenAI 為濫用監控與部分功能狀態保存 Customer Content。
但 ZDR 也不能理解成「OpenAI 系統裡從此一個 Byte 都不留下」。帳號資料、Billing、Usage Statistics、Support Requests 等 System Data 本來就和 Customer Content 分開處理，不會因為啟用 ZDR 就全部消失，所以企業在做資料處理評估時，還是需要把 Customer Content、Application State 與 System Data 分開看。
不是所有OpenAI API功能都適用ZDR
ZDR 也不是整個 API Platform 的總開關。Chat Completions、Responses、Embeddings、部分 Image、Audio 與 Moderation 類功能可以支援 ZDR，但 Conversations、Assistants、Threads、Vector Stores、Files、Fine-tuning、Batches 等能力本身需要保留 Application State，因此不能直接用同樣的零留存邏輯理解。
這其實不難理解，如果使用的是 Vector Store，就代表資料本來就要留下來供之後 Retrieval；如果 Conversation 下週還要延續，也必須存在某種持久狀態。因此，企業真正要確認的不是「OpenAI 有沒有 ZDR」，而是實際工作流裡用到的每一個 Endpoint 與 Tool 到底是不是 ZDR Eligible。
部分看似支援 ZDR 的功能也有自己的限制，例如 Background Mode 為了後續 Polling 需要暫時保存 Response Data，Code Interpreter 目前也不能直接搭配完整 ZDR 使用；某些 Prompt Caching 或 Hosted Container 功能則可能存在短期、功能性必要的暫存。這些暫存和「把完整 Prompt 放進 30 天可供濫用調查的日誌」不是同一回事，但也說明 ZDR 並不是所有資料從來沒有落地。
使用Remote MCP後，第三方留存政策要另外算
這一點在 Agent Workflow 裡特別容易被漏掉。即使 OpenAI 這一端使用 ZDR，只要 Responses API 再把內容送進 Remote MCP Server，後續資料怎麼處理就會受到那個第三方服務自己的 Retention Policy 約束，OpenAI 的 ZDR 不會自動延伸到 Notion、CRM、搜尋服務或自架 MCP Server。
因此，Agent 系統真正需要盤點的是完整 Data Flow：資料從哪裡進來、經過哪些模型、呼叫哪些 Tools、哪些第三方收到原文、每一站會保存多久。只檢查模型供應商其中一段，很容易漏掉後面真正有資料落地的地方。
為什麼Agent出現後，Zero Data Retention開始碰到新的安全難題？
單一Prompt看起來正常，連續很多次操作才可能看出風險
OpenAI 在這次公告裡特別提到，既有支援 ZDR 的安全系統主要逐次判斷每一次 Interaction，但 Agent 越來越能處理長時間、多步驟任務之後，真正有風險的模式不一定會出現在單一 Prompt 裡。有些操作拆開來看完全正常，例如查一段設定、詢問一組權限、再要求處理某種 Credential，只有把前後很多次互動放在一起，才可能看出它們其實正在組成一個高風險流程。
Agent 又把這個問題拉得更長。它可能先搜尋資料、重新規劃、呼叫工具、觀察結果，再決定下一步，而且整段流程不一定需要人在每一步重新下指令。OpenAI 提到的情境甚至包含 Agent 在使用者要求停止後仍繼續採取行動，這類偏離原本意圖的問題，也更適合從完整活動脈絡判斷。
矛盾因此變得很直接：安全系統希望看到更長的 Context，才能辨認跨步驟風險；企業則可能要求敏感 Customer Content 不要被模型供應商長期保存。Private Safety Processing 想做的，就是把這兩件事拆開。
Private Safety Processing怎麼運作？讓自動化系統看模式，人員不直接看內容
ZDR模式下，跨互動資料可以留在客戶控制的環境
依 OpenAI 目前公開的設計，Private Safety Processing 可以在不同資料儲存模式下運作。在 ZDR Deployment 中，需要跨互動分析的 Customer Content 可以留在客戶控制的 Infrastructure，由自動化安全系統針對相關互動判斷是否出現可疑模式，而不是先建立一份 OpenAI 人員可以直接閱讀的完整對話紀錄。
OpenAI 另外也正在開發另一種模式，讓資料存在 OpenAI 提供的 Storage，但內容會由 Customer-controlled Keys 加密，而且 OpenAI Personnel 不持有這些 Keys，因此不能直接讀到底層 Customer Content。這個方向和企業常見的客戶控制金鑰設計相近，但目前完整技術白皮書還沒公布，因此不適合先把 Confidential Computing、TEE、Key Lifecycle 等底層實作細節自行補進去。
安全團隊拿到的是有限Signal，不是Prompt摘要
當 Private Safety Processing 偵測到可能有問題的活動時，OpenAI 目前描述的是一個 narrowly defined safety signal，主要用來指出涉及哪一類活動，而不是把原始 Prompt、Response 或完整內容摘要直接交給人員。
換句話說，自動化系統可以分析多次相關互動，OpenAI Personnel 看到的是有限的風險訊號，底層內容仍留在客戶控制環境，或由客戶掌握的金鑰保護。如果後續需要 Appeal、澄清合法用途或協助調查確認的 Abuse，再由客戶自行決定是否提供相關資訊。
這也是 Private Safety Processing 最值得看的地方。它不是把安全監控拿掉，而是試著把「分析內容」和「人員能不能直接讀原文」分開。
Private Safety Processing現在可以用了嗎？目前仍在早期測試
Private Safety Processing 現在還不能當成所有 OpenAI API 客戶都已經可以直接打開的正式功能。OpenAI 表示，目前正在和 Early Customers 進行測試，預計從 2026 年 9 月開始逐步 Rollout，也會同步公開 Technical White Paper。
因此，現在可以確認的是幾個設計方向：Private Safety Processing 要支援跨多次互動的安全判斷、避免 OpenAI Personnel 因此直接取得底層 Customer Content、支援 Customer-controlled Infrastructure，並正在開發 OpenAI Storage 搭配 Customer-controlled Keys 的模式，最後輸出的則是有限 Safety Signals。
至於真正重要的底層問題，例如 Encryption Architecture、Execution Environment、Key Revocation、Signal Schema、Retention Lifecycle、False Positive 處理，以及第三方能不能驗證這些邊界，都還要等技術白皮書公開後才能完整判斷。因此，正在做採購或合規評估的團隊可以先把 Private Safety Processing 列進 Upcoming Capability，但不適合直接拿現在的新聞稿當成正式 Security Specification。
Zero Data Retention真正適合哪些資料？
敏感資料值得優先評估ZDR，但不是看到機密兩個字就一定要套最高規格
OpenAI 自己在公告裡列出的使用情境包括 Financial Records、Health Data、Confidential Business Plans 與 Proprietary Research，這類資料之所以特別在意留存，通常不是單純因為「很私人」，而是背後還可能有法規、客戶合約、NDA 或公司自己的 Security Policy。
例如一套工作流如果會把未公開財務報表、健康紀錄、客戶合約或研發資料送進 API，企業需要確認的不只是傳輸有沒有加密，而是模型供應商是否保留原文、保存多久、哪些人可能存取、是否拿去訓練、哪些功能會建立 Application State，以及資料離開模型後又去了哪些第三方服務。
ZDR 解決的是其中很重要的一塊，但它不是自動合規按鈕。不同產業、不同國家、不同契約對第三方處理資料的要求不一樣，所以比較合理的方式是先做資料分級，再決定哪些 Workflow 真正需要 ZDR，而不是把所有專案全部套上最嚴格條件。
ZDR也會換掉部分功能彈性
完整 ZDR 會限制某些需要持久狀態的功能，因此公開資料整理、一般 Brainstorming、已發布內容摘要等低敏感工作，不一定需要硬套最高等級的資料控制。企業更常見的架構會是把高敏感 Workflow 放進 ZDR Project，一般內容則使用另一套 Project 與資料政策，避免為了追求全部零留存，反而拿掉原本真正需要的功能。
Zero Data Retention也有例外，法律義務仍然存在
即使使用 ZDR，也不能理解成任何情況下都絕對不會保留內容。OpenAI 在這次公告中特別提到，疑似 Child Sexual Abuse Material 的圖片仍可能因法律義務被保存、送交人工審查並依法通報，這類要求不會因為客戶使用 ZDR 就消失。
OpenAI 的 API Data Controls 也保留 Safety Retention 相關機制。如果公司認為為了調查或防止 Severe Risk Activity 有合理必要，可以針對特定 Customer 與特定 Model 暫時調整原本的 ZDR 適用資格，但需要事前以書面通知受影響客戶。
這也是企業做 Compliance Review 時很值得看的地方。真正重要的不是產品名稱裡有沒有 Zero，而是 Scope、Exceptions、Notification Process，以及哪些端點、模型與工具實際受到這項條件保護。
OpenAI和Anthropic的差別，不只是誰比較重視隱私
OpenAI 這次的公告很容易被寫成和 Anthropic 的直接對決，因為 Anthropic 在 Fable 5 與 Mythos 5 等高能力模型上，採取的是另一種安全取捨：相關 Traffic 需要保留 30 天，用來找跨 Request 的 Jailbreak、Cyber Misuse 與其他複雜攻擊模式，而且 Anthropic 也明確表示這些資料不會拿來訓練新的 Claude Models。
兩家公司面對的其實是同一個問題，只是選擇把安全觀測需要的資料放在不同地方。Anthropic 的做法比較直接，由模型供應商保存一段時間的原始 Traffic，讓安全團隊可以做跨互動調查；OpenAI 的 Private Safety Processing 則希望把 Customer Content 留在客戶控制的環境，或未來用 Customer-controlled Keys 保護，只讓自動化系統產出有限安全訊號。
這不是簡單的「OpenAI 重隱私、Anthropic 重安全」。兩邊都想做跨互動風險偵測，只是對原始證據應該由誰持有，給出了不同答案。哪一套最後比較可靠，目前還沒有足夠公開資料可以下結論，尤其 OpenAI 的 Private Safety Processing 還沒全面推出，完整 White Paper 也要等 9 月。
ZDR之後，企業自己的Audit Trail反而更重要
如果模型供應商真的不保留可直接供人員查看的完整 Customer Content，事故發生時能從供應商端直接還原多少細節，自然會和保存完整 Prompt／Response 的架構不同，但這不代表零留存等於完全不能追查，而是更多責任會回到企業自己。
如果 Agent 已經開始碰內部資料、外部 Tool 或正式工作流程，企業最好本來就保留自己的 Activity Log，例如 Agent 收到什麼任務、讀過哪些內部資料、呼叫哪些 Tool、對外送出哪些資訊、修改哪些 Records，以及哪些動作經過人工批准。
ZDR 可以降低供應商持有敏感 Customer Content 的程度，但它不應該取代企業自己的 Observability。甚至可以反過來理解：模型供應商保留得越少，企業自己就越需要知道 Agent 到底做過什麼。
AWS AgentCore Web Search也在處理另一種Agent邊界
另一個可以放在一起看的例子，是 Amazon Bedrock AgentCore Web Search。AWS 目前已經讓 Web Search 支援由伺服器端限制特定 Domain，管理者可以設定 Agent 能不能從某些網站取得結果，而且這個限制不是寫進 Prompt 裡提醒模型，而是直接由 Infrastructure 強制執行。
這和 Private Safety Processing 處理的問題不一樣，但設計方向很接近。與其告訴模型「不要搜尋某個網站」，不如讓系統根本不回傳該 Domain；與其告訴安全人員「不要看客戶敏感 Prompt」，不如把架構設計成 Personnel 沒有 Key、拿不到底層明文。
對 Agent 系統來說，這種放在模型之外的限制通常比 Prompt 裡的一句規則更容易驗證。需要注意的是，目前 AWS 官方文件可以確認 Domain Filtering 等能力，但沒有足夠證據支持「發布日期 Filter 就是在 8 月 19 日同一天首次推出」這種精確時間說法，因此這部分不建議硬綁成同一天新聞。
API的ZDR不能直接套到一般ChatGPT網頁版
這也是實際使用時很容易誤會的一點。OpenAI 這次談的 Zero Data Retention 是 API Platform 提供給符合資格組織的 Data Retention Control，不是一般 ChatGPT Plus 使用者突然多出來的設定。
一般 ChatGPT 產品有自己的聊天歷史、刪除、模型改善與資料留存政策，所以如果只是打開 ChatGPT 網頁、上傳一份客戶合約開始聊天，不能因為看到 OpenAI 有 ZDR，就直接推論這次聊天也套用了 Zero Data Retention。
涉及敏感資料時，第一步始終是先確認資料到底從哪一個產品、哪一個 Endpoint 送出去，再查那套產品真正適用的 Data Controls。
企業評估AI資料留存時，可以先檢查四件事
第一件：確認實際使用的Endpoint是不是ZDR Eligible
不要只問帳號有沒有開 ZDR，還要把實際 Workflow 裡用到的 Responses、Chat Completions、Files、Vector Stores、Code Interpreter、Background Mode 與 Remote MCP 全部列出來。只要其中一段需要建立持久狀態，整條流程就不能簡單寫成「完全零留存」。
第二件：確認除了Prompt和Response之外，還有哪些資料會留下
Account Data、Billing、Usage Statistics、Application State、暫存資料與法律例外都應該另外確認。真正有意義的問題不是「供應商說不說 Zero」，而是 Zero 到底涵蓋哪一類資料。
第三件：把第三方Tool一起畫進資料流
Agent 如果會呼叫 Google Drive、Notion、CRM、Web Search 或外部 MCP，每一站都可能有自己的 Retention Policy。只有 OpenAI 端啟用 ZDR，不能直接推成整套工作流都是零留存。
第四件：等Private Safety Processing白皮書再確認底層架構
9 月 Technical White Paper 公開後，比較值得確認的包括 Customer-controlled Keys 如何管理、內容在哪個 Execution Environment 被處理、Safety Signal 到底包含哪些欄位、Signal 保留多久、Key Revocation 怎麼作用，以及 Critical Incident 發生後要怎麼進行 Forensics。
這些細節比新聞稿裡一句「兼顧 Privacy 與 Safety」更能決定企業是否真的能把這套機制納入正式環境。
Private Safety Processing真正的新意，是把安全訊號和原始內容拆開
OpenAI 這次真正新的地方，不是再次宣布 API 資料不拿去訓練，這項原則早就存在。真正的新問題來自 Agent：當模型可以自己連續做很多步驟，單一 Prompt 的安全檢查不一定看得到完整風險，但如果解法只是把所有工作內容全部留在模型供應商那裡，又會直接撞上企業對資料控制的要求。
Private Safety Processing 想嘗試的，就是讓 Automated Systems 保有跨 Interaction 判斷能力，同時把 OpenAI Personnel 能直接取得的資訊壓縮成有限 Safety Signals，底層 Customer Content 則繼續由客戶控制，或使用客戶掌握的加密金鑰保護。
這套架構最後能不能在真實 Abuse Investigation 中同時保住 Privacy 與足夠的 Forensics，目前還沒有答案，九月的 White Paper、實際 Rollout，以及後續是否有第三方 Security Review，都會比現在的公告更有判斷價值。
但有一件事已經很清楚：企業之後評估 AI 服務，不會只比較模型能力和 Token 價格，資料會留多久、誰能看到、金鑰由誰控制、哪些功能需要保存狀態、安全系統能取得多少資訊，以及外部 Tools 又會把內容送去哪裡，都會變成正式採購時需要確認的條件。
常見FAQ
Ｑ：Zero Data Retention是不是代表OpenAI完全不保存任何資料？
不是。ZDR 主要讓符合資格的 Customer Content 不進入 Abuse Monitoring Logs，並限制支援 ZDR 的 Endpoint 保存相關 Application State，但帳號、Billing、Usage Statistics 等 System Data 仍可能存在，而且不同 Endpoint 與功能有自己的留存條件。
Ｑ：OpenAI API的資料會拿去訓練模型嗎？
OpenAI API 傳入的資料預設不會拿來訓練或改善模型，除非客戶主動選擇分享。這項政策和 Zero Data Retention 是兩件不同的事，即使資料不拿去訓練，一般 API 使用仍可能存在 Abuse Monitoring Retention。
Ｑ：Private Safety Processing現在已經全面開放嗎？
還沒有。OpenAI 表示目前正與 Early Customers 測試，預計從 2026 年 9 月開始逐步推出，並同步公布 Technical White Paper，因此目前比較適合把它視為已公開設計方向、但尚未全面可用的企業安全能力。
Ｑ：Private Safety Processing會讓OpenAI人員看到客戶Prompt嗎？
依目前公布的架構，OpenAI Personnel 不會因為安全系統觸發而直接取得底層 Customer Content。Automated Systems 會分析相關互動，再輸出有限 Safety Signal；如果後續需要申訴或協助調查，客戶可以自行決定是否提供相關內容。
Ｑ：開啟ZDR後，Remote MCP收到的資料也不會被保存嗎？
不一定。Remote MCP Server 屬於第三方服務，資料送進第三方後適用的是該服務自己的 Retention Policy，因此 OpenAI 端的 ZDR 不能自動延伸到所有外部 SaaS、MCP Provider 或其他工具。
Ｑ：ZDR適合所有企業工作流嗎？
不一定。ZDR 比較適合敏感程度高、受到合約或資料治理要求限制的 Workflow，但它同時會影響部分需要持久狀態的功能，因此比較合理的做法通常是依資料敏感程度分開 Project 與 Data Policy，而不是所有工作都套用相同設定。