OpenAI Private Intelligence 完整解析：ZDR、Private Safety Processing 與 Private Inference 差在哪？
OpenAI Private Intelligence 涵蓋 ZDR、Private Safety Processing 與 Private Inference。本文拆解可用狀態、資料邊界與企業導入檢查。
OpenAI 在 DevDay 2026 以 Private Intelligence 描述一組面向敏感資料的企業能力。核心訊息有兩個：第一，Private Safety Processing 讓符合零資料保留條件的 API（應用程式介面）流量也能接受安全審查，第二，Private Inference 預告在秋季推出預覽，目標是讓推論處理具備更強的隔離與隱私保證。
延伸閱讀：OpenAI DevDay 2026 完整整理：25 項更新、5 條產品主線與真正值得注意的轉向
這兩件事很容易被混成「OpenAI 已推出完全私密的 AI」。實際上，發布時一項是可用的安全處理機制，另一項仍是未來預覽。ZDR 不代表資料從不出現，它是在特定合格端點與組態下，不保留應用資料的資料控制。企業若把三個名詞視為同一個保證，可能在採購、法遵與架構上做出錯誤決定。
本文會先拆解三個概念，再說明何時適合使用、要向供應商確認什麼，以及如何建立可驗證的導入流程。我的判斷是，Private Intelligence 的重要性不只在技術，而是 OpenAI 正嘗試把安全監測與資料最小化從二選一改成可共同存在，但任何「私密」主張都必須落到明確端點、設定、合約和測試。
Private Intelligence 聚焦在敏感工作負載的安全處理與隔離推論。圖片來源：OpenAI DevDay 2026 官方回顧。
先把三個概念分開
ZDR 是 Zero Data Retention，也就是零資料保留。它通常指符合資格的 API 使用情境中，OpenAI 不保存應用資料。這是資料保留政策與技術控制，不等於請求完全不經處理，也不自動涵蓋所有產品、工具、端點或錯誤紀錄。
Private Safety Processing 是為 ZDR 客戶設計的安全處理方式。一般安全偵測可能需要保留或檢視部分內容，與零保留要求產生張力。官方說明的方向，是在不保留客戶內容的前提下執行安全分類，讓濫用防護不必依賴長期保存輸入與輸出。
Private Inference 則是另一層能力，重點在推論過程的隔離與可驗證隱私。DevDay 發布時，官方預告秋季推出預覽，而不是宣告全面可用。文章、簡報與採購需求都應保留這個時間與狀態，避免把路線圖當成已交付功能。
ZDR 能解決什麼，不能解決什麼？
ZDR 能降低供應商端長期保存應用內容的風險。對法務文件、內部程式碼、醫療資料或尚未公開的財務資訊，少一份持久副本就少一個外洩面，也比較容易符合公司的資料最小化政策。
它不能替代客戶自己的安全措施。應用程式可能把提示寫進日誌、監控平台、錯誤追蹤、資料庫或代理工具，員工也可能把結果貼到不適當的位置。如果整條資料路徑只有模型 API 宣稱 ZDR，其他元件仍會留下完整內容，整體就不是零保留。
ZDR 也不等於匿名。請求在處理時仍可能含有姓名、帳號、識別碼與商業機密。最穩健的做法是先刪除不必要識別資訊、只送完成任務所需的最小內容，再用 ZDR 降低殘餘風險。
另外要確認資格與例外。並非每個端點、功能、工具與客戶都自動具備相同條件。檔案、影像、背景工作、第三方連接器或需要保存狀態的代理功能，可能有不同資料生命週期。企業應以當下合約與官方文件逐項核對。
為什麼還需要 Private Safety Processing？
AI 服務要防止濫用，通常會做即時分類、異常偵測與政策執行。若安全系統必須把內容長期留存，ZDR 客戶就會面臨矛盾：想降低資料留存，卻可能因此失去某些安全防護。
Private Safety Processing 的設計目標，是讓安全判斷在不保留客戶內容的情況下發生。官方文件把它描述為以隱私保護方式處理安全訊號，並支援合格 ZDR 客戶。對企業而言，這意味著「不保存」與「不檢查」不必是同一件事。
但安全處理不代表業務輸出正確。它主要處理濫用與政策風險，不會替企業驗證模型是否洩露內部權限、產生錯誤財務決策或把資料送到錯誤工具。應用層仍需輸入驗證、輸出限制、權限控制與人工批准。
Private Inference 為何值得關注？
一般雲端推論需要信任服務供應商的基礎設施、存取控制與營運流程。Private Inference 想進一步縮小需要信任的範圍，讓敏感資料在隔離環境中被處理，並提供更強的技術性保證。
這類系統常涉及硬體隔離、加密證明、受控執行環境與可驗證部署。真正可用時，企業應直接檢查威脅模型：它防範哪些內部或外部攻擊者、哪些中繼資料仍可見、金鑰由誰管理、故障時是否降級到一般推論。
發布時只有秋季預覽承諾，因此目前適合做需求盤點與測試計畫，不適合在正式架構中寫成已存在的控制。採購合約也不應以未交付功能抵銷現有缺口。
三者如何放進同一套架構？
可以把 ZDR 視為資料保留層，Private Safety Processing 視為安全監測層，Private Inference 視為執行隔離層。三者處理不同問題，也可能有不同可用範圍。
一個敏感文件分析流程，首先在客戶端刪除不必要個資，再透過合格 ZDR 端點送出。請求接受 Private Safety Processing 的即時檢查，推論則在未來可用時進入 Private Inference 環境。結果回到企業系統後，仍要受既有權限、日誌與保存政策管理。
這條鏈中任何一環都可能留下資料。瀏覽器快取、代理追蹤、資料庫、通知與人工下載都在範圍內。安全審查不能只看 OpenAI 一段服務，而要看從資料產生到刪除的完整生命週期。
Private Intelligence 保護推論與資料生命週期，Codex Security Cloud 則處理程式庫弱點。兩者是不同安全層，不能互相取代。圖片來源：OpenAI DevDay 2026 官方回顧。
延伸閱讀：Codex Security Cloud 完整解析：Daybreak Blue、全程式庫掃描與 AI 修復怎麼用？
哪些工作負載最適合？
第一類是受監管資料，例如醫療、金融、法律與政府文件。這些場景通常已有明確的資料分類、保存與稽核要求，能具體判斷 ZDR 是否符合需求。
第二類是高價值企業資料，例如原始碼、資安事件、併購文件、未公開財務數字與產品路線圖。即使沒有法規強制，資料外洩成本也很高，值得減少供應商端留存。
第三類是多租戶 AI 產品。開發者同時處理許多客戶資料，必須確保租戶隔離、日誌遮罩與刪除一致。ZDR 可以降低一部分風險，但不能取代產品自己的租戶邊界。
不需要把所有請求都放進最高等級控制。公開資料摘要、一般客服與低敏感內容可能不需要相同成本。先做資料分級，再選擇處理路徑，通常比全有或全無更實際。
企業採購需要確認的十二項資訊
先確認可用範圍，包括符合 ZDR 的模型、端點、區域與工具。背景模式、檔案、圖片與代理工作的條件可能不同，資格也可能需要申請或合約附錄。
再確認資料生命週期，包括請求與回應是否保存、暫存多久，以及錯誤、濫用、安全與計費紀錄包含哪些欄位。刪除的延遲和備份處理方式也要列入合約。
接著確認安全處理產生的訊號、內容或分類結果的保存方式、客戶可取得的稽核證據，以及誤判申訴流程。
對 Private Inference，應問預覽日期、地區、模型、效能、價格、容量與服務等級。更重要的是取得技術威脅模型與驗證方法，而不是只接受「私密」這個形容詞。
最後確認事件處理與退出機制。功能不可用時，系統可能失敗、排隊或切換一般推論，行為必須預先約定。終止服務後還要有資料刪除證據，這些答案決定控制是否真的可依賴。
導入步驟：從資料地圖開始
第一步應先列出資料，不急著打開設定。把輸入、附件、工具結果、輸出、日誌與人工下載畫成資料流，標記敏感等級、擁有者、保存期限與處理地區。
第二步建立允許清單。只讓經核准的模型、端點與工具處理特定等級資料，沒有明確 ZDR 支援的功能先關閉。應用也要阻止使用者把敏感資料轉送到未核准外掛。
第三步做技術驗證。檢查自己的 API gateway、追蹤平台與錯誤日誌是否仍保存內容，並用測試識別碼追查每個副本。供應商承諾和自家系統行為必須同時成立。
第四步準備故障策略。若 Private Safety Processing 或未來 Private Inference 不可用，敏感請求應停止、排隊或改由人工處理，不能靜默降級到較弱的路徑。
第五步定期複查。模型、端點與產品會更新，今天符合的組態未必永遠相同。把官方文件、合約與實際設定納入季度審查，保存版本與日期。
如何驗證「零保留」不是口號？
企業無法只靠外部觀察證明供應商內部完全沒有副本，但可以建立多層證據。包括合約條款、官方資料控制文件、組態截圖、API 使用紀錄、第三方稽核報告與自家日誌掃描。
在應用端，可使用合成敏感字串測試是否進入監控、錯誤追蹤或資料倉儲。測試資料不能是真實個資，但應能被搜尋。若在不應保存的系統中找到，就表示整體流程仍有缺口。
還要測試刪除與撤權。停用帳號、撤銷金鑰、刪除專案後，哪些資料仍可見？誰可以匯出？供應商事故通知會送給誰？這些操作證據比宣傳頁上的一句話更能支撐風險判斷。
我的觀察：隱私能力正在變成產品架構，而非附加設定
過去企業常在模型選定後才討論隱私。Private Intelligence 顯示，推論隔離、安全監測與資料保留正在變成選擇模型與平台時的核心規格。對高敏感工作，最快或最聰明的模型不一定是最佳選擇。
另一方面，品牌把多個能力放進同一個名稱，容易讓市場過度解讀。內容創作者與採購人員都應把「目前可用」「有限資格」「預覽承諾」分開。這項區分會直接決定風險能否被控制。
我的建議是先用 ZDR 與 Private Safety Processing 解決當下可驗證的需求，同時為 Private Inference 保留試點位置。等正式文件、價格與威脅模型公開後再決定是否把關鍵工作遷移。
常見問題
ZDR 是否代表 OpenAI 完全看不到資料？
不是。請求仍需被處理，ZDR 的重點是不保留符合條件的應用資料。實際範圍要看端點、功能、合約與設定。
Private Safety Processing 會保留提示嗎？
官方定位是支援 ZDR 的安全處理，不保留客戶內容。企業仍應核對當時文件與自己的資格。
Private Inference 已經全面推出嗎？
沒有。DevDay 2026 發布時，OpenAI 預告秋季推出預覽。預覽條件與實際日期應以最新官方公告為準。
使用 ZDR 就符合所有法規嗎？
不會。法規符合還涉及目的、同意、跨境、權限、資料主體權利與客戶自己的系統。ZDR 只是其中一項控制。
Private Intelligence 能取代企業 DLP 嗎？
不能。資料外洩防護、身份權限、端點安全、日誌與人工流程仍需存在。
結論
Private Intelligence 把三個不同問題放到同一條企業 AI 路徑上：ZDR 管理保留，Private Safety Processing 管理安全偵測，Private Inference 目標是提供更強的推論隔離。理解差異，才能避免把單一標籤當成全面保證。
企業應從資料分類與完整資料流開始，核對每個端點與工具，建立不允許靜默降級的故障策略。現階段可驗證已提供的 ZDR 與安全處理，對尚未推出的 Private Inference，則保留預覽與實測，而不是提前宣告完成。
