OpenAI 正為符合資格、採用零資料保留(ZDR)的 API 客戶預覽 Private Safety Processing,目標是在不讓 OpenAI 人員接觸底層內容的情況下,找出跨多次互動出現的濫用模式。[1] 有別於逐一檢查請求與回應的傳統 ZDR 安全機制,新系統會分析相關互動之間的關聯,例如將惡意程式開發工作拆分到不同請求,或試圖分散操作以規避防護措施。[1][7] 偵測到威脅時,OpenAI 收到的是活動類型、警報分類與嚴重程度等有限安全訊號,而不是完整對話、提示詞或模型輸出。[1]
研究答案

Create a landscape editorial hero image for this Studio Global article: What is OpenAI’s Private Safety Processing system, previewed in August 2026, how does it monitor coordinated misuse across multiple AI-model. Article summary: Private Safety Processing is OpenAI’s previewed safety architecture for eligible zero-data-retention (ZDR) API deployments: it is intended to detect harmful patterns spanning related requests without giving OpenAI staff . Topic tags: general, general web, user generated, news. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts w
OpenAI 正預覽一套名為 Private Safety Processing(私密安全處理) 的安全架構,對象是符合資格、使用 零資料保留(Zero Data Retention,ZDR) 的 API 客戶。它要解決的核心難題是:企業希望提示詞與模型回應不被保留,但 AI 濫用往往只有在多次、彼此相關的互動中才看得出來。
換句話說,攻擊者可能把一個有害目標拆散到不同帳戶、工作階段或請求中,讓每一次單獨查看的互動都不像明顯的濫用行為。Private Safety Processing 的設計,就是在維持 ZDR 保護的同時,讓自動化安全系統能看見這種較長期、跨互動的模式。
現有的 ZDR 安全機制主要逐一評估每次請求與回應。OpenAI 預覽中的新架構則會把安全分析延伸到多個相關互動,尋找可能代表協同濫用的訊號,例如企圖繞過防護措施,或把惡意程式開發步驟分散在不同請求中。
這裡最重要的區別,在於 分析不等於保留。OpenAI 表示,系統會為安全目的分析相關活動,但不會透過這套機制讓 OpenAI 人員取得底層提示詞與模型回應。
OpenAI 描述了 ZDR 部署的兩種資料控管方式:
在這兩種情況下,自動化系統都可以辨識潛在濫用,並回傳有限的安全訊號,而不公開底層提示詞或模型回應。
按照目前預覽內容,OpenAI 收到的是關於 活動類型 的狹義警報。OpenAI 的系統圖將輸出描述為警報分類與嚴重程度,而不是完整對話內容。
這項訊號可用於安全處置或執法決策,但不等於把完整工作階段紀錄交給 OpenAI。實際流程可概括為:
由於目前仍是預覽版本,實際門檻、部署方式、誤判處理及申訴流程,都會是企業客戶需要進一步確認的細節。OpenAI 表示,計畫在 2026 年 9 月開始更廣泛推出,並發布技術白皮書。
安全標記本身不會自動授予 OpenAI 員工查看對話的權限。按照 OpenAI 所描述的 ZDR 架構,客戶內容不會被保留;若採用 OpenAI 託管儲存方案,OpenAI 人員也不持有由客戶控制的解密金鑰。
客戶可以自行在內部系統調查,並可選擇分享相關資料,以申訴處置、說明正當用途,或協助調查已確認的濫用行為。在客戶沒有自願披露之前,OpenAI 收到的仍只是機器產生的安全資訊,而不是完整對話。
這形成一種「客戶控制證據,服務供應商取得風險訊號」的分工。它可能減少供應商必須處理的敏感資料,同時保留跨請求辨識濫用模式的能力,避免單純逐次過濾遺漏長期或分散式操作。
OpenAI 指出,Glean、Databricks、Abridge 與 Microsoft 都在協助塑造或測試這項預覽功能。 其他報導也將 Microsoft 與 Databricks 列為早期測試客戶。
這項功能並非一般消費者可以自行開啟的設定,而是針對符合條件的 API 部署。對需要使用先進模型、同時嚴格控制提示詞與輸出的企業而言,這種架構可望成為一種資料治理選項。
OpenAI 的方案把重點放在「偵測濫用,但盡量避免供應商接觸客戶內容」。Anthropic 針對 Covered Models 的政策則採取不同取捨:相關模型收到的提示詞與產生的輸出會保留 30 天,以支援安全工作,包括受控的人工審查。
Anthropic 文件表示,這項 30 天要求適用於 Covered Models,包括 Mythos 類模型;這些模型無法在 ZDR 條件下使用。Anthropic 同時表示,未經客戶明確許可,保留的資料不會用於模型訓練。
兩者的操作差異可簡化為:
這並不代表任何一種方案都能取代客戶自身的治理責任。企業在處理敏感工作負載前,仍需確認模型與部署是否符合資格、內容在哪裡處理、誰控制加密金鑰、資料保留條款、存取權限、地區要求、申訴流程及合約承諾。
金融、醫療及法律機構經常處理受合約保密義務、隱私控制、專業責任或產業規範約束的資訊。AI 服務供應商是否會保留提示詞、是否可能進行人工審查,會直接影響企業的資料最小化評估、內部核准、稽核設計與供應商風險審查。
這不代表 30 天保留政策必然違法,也不代表採用 ZDR 就自然符合所有法規;兩種架構只是會讓資安與法務團隊面對不同問題。Anthropic 的 Covered Models 條款要求企業將供應商保留及審查資料納入考量;OpenAI 則將 ZDR 與 Private Safety Processing 定位為限制供應商接觸內容的做法。
對企業採購方而言,幾個關鍵問題包括:
Private Safety Processing 的意義,不只是增加一道內容過濾器,而是把隱私本身納入 AI 安全產品的設計。當模型開始執行更長、更自主的工作流程,問題也不再只是「模型能否擋下單一不安全請求」,而是「供應商能否在不讀取每段客戶對話的情況下,辨識跨工作流程的協同濫用」。
OpenAI 的預覽方案提供了一種答案:讓底層內容留在客戶控制的基礎設施,或使用客戶持有的金鑰加密;再由自動化系統分析跨互動模式,最後只向供應商傳送狹義的風險分類。
Anthropic 的 Covered Models 政策則提供另一種答案:在限定期間保留相關提示詞與輸出,讓安全團隊可以直接調查,並搭配受控審查及不將資料用於模型訓練的承諾。
企業最後選擇哪一種模式,取決於工作負載的敏感程度、可接受的風險,以及企業認為先進模型供應商需要多少調查可見度。OpenAI 預計發布的技術白皮書與更廣泛部署,將是外界評估這套隱私主張能否在實際企業環境中成立的重要依據。
Studio Global AI
這個頁面包含附來源佐證的答案,你可以在 Studio Global 內繼續追問。
OpenAI 正為符合資格、採用零資料保留(ZDR)的 API 客戶預覽 Private Safety Processing,目標是在不讓 OpenAI 人員接觸底層內容的情況下,找出跨多次互動出現的濫用模式。[1]
OpenAI 正為符合資格、採用零資料保留(ZDR)的 API 客戶預覽 Private Safety Processing,目標是在不讓 OpenAI 人員接觸底層內容的情況下,找出跨多次互動出現的濫用模式。[1] 有別於逐一檢查請求與回應的傳統 ZDR 安全機制,新系統會分析相關互動之間的關聯,例如將惡意程式開發工作拆分到不同請求,或試圖分散操作以規避防護措施。[1][7]
偵測到威脅時,OpenAI 收到的是活動類型、警報分類與嚴重程度等有限安全訊號,而不是完整對話、提示詞或模型輸出。[1]