為什麼「不拿你的資料訓練」還不夠

「我們不會拿你的資料來訓練」是一句不錯的話。它也同樣不是整頓大餐。它只是一顆豌豆，放在一個非常大的、略顯可疑的盤子裡。

訓練是一個風險。如果供應商在未經允許的情況下使用客戶的提示（prompts）、上傳的圖片或輸出內容來改進模型，這當然是問題。但客戶通常在意的是更廣泛的問題：我送出的內容之後會怎麼樣？訓練只是其中一個可能的去向。

內容可能會被保留用於濫用監控。它可能會被存成應用程式狀態（application state）。它可能會在對話串中暫放，直到刪除。它可能會被快取（cache）以提升效能。它可能會被寫入請求日誌（request logs）。它可能會被複製到錯誤報告（error report）中。它可能會被支援人員看見。它可能會被存到使用者的畫廊（gallery）。它可能會被路由到另一家供應商，而那家的政策完全不同。它也可能是「不用於訓練」，但仍被保留足夠久，讓一位重視隱私的買家慢慢退回房間外。

這不是在做理論上的細枝末節。主要的 AI 平台會公布詳細的保留表（retention tables），因為端點行為（endpoint behavior）會有所不同。例如 OpenAI 的資料控管文件會區分訓練用途、濫用監控的保留、應用程式狀態的保留，以及跨端點的「零資料保留」（Zero Data Retention）資格。那裡列出的影像端點並不會在每個模型與每種情境下都完全相同。這種複雜性不是邪惡，而是複雜；產品團隊不應該把它扁平化成一句讓人安心的話。

Google 的 Gemini Enterprise Agent Platform 文件也從另一個角度提出類似觀點：它把訓練限制與保留情境分開，例如濫用監控、資料落地（grounding）、請求-回應記錄（request-response logging）、會話續接（session resumption）以及快取（caching）。同樣地，重點不是「每個人都很糟」。重點是「細節很重要」。隱私是一張表，不是一種氛圍。

對於 AI 影像產品，這種區別會更尖銳，因為來源素材可能非常私人。提示（prompt）很敏感。臉部更敏感。臉部加上提示、再加上生成輸出、再加上帳單記錄、再加上一張支援截圖——這就不再只是「一次 API 呼叫」。它是一份不小心建立起來的小型檔案夾（dossier），而這是最像軟體的事情。

更好的隱私文案應該回答幾個直接的問題。你會拿客戶內容來訓練嗎？你會保留提示嗎？你會保留來源圖片嗎？你會保留生成輸出嗎？安全或法律是否有例外？員工能看到內容嗎？你會把內容送到外部影像供應商嗎？暫存檔案會存在多久？生成後還會保留哪些中繼資料（metadata）？

Unexposed 的立場刻意更狹窄、更具體：把提示、來源圖片、生成輸出以及金鑰（keys）保留在由 Unexposed 控制的基礎設施中，透過短暫生命週期的生成作業（generation sessions）處理它們，並保留「內容盲」（content-blind）的耐久性記錄。這並不代表「任何地方都不存在任何東西」，因為帳務與營運仍然存在。這表示耐久性的系統不應該變成一座帶有更好事件回應（incident response）的創意內容博物館。

如果某家供應商的隱私頁面只停在「我們不會拿來訓練」，那就問下一個問題。再問下一個。然後問那個惱人的問題。惱人的問題通常就是產品真相所在的地方：疲憊地站著，手上拿著一份日誌檔。

延伸閱讀：OpenAI 的 data retention controls、Google 的 zero data retention documentation，以及 Unexposed data storage。