一張能摧毀 AI 信任的截圖

信任常常是死在截圖上。

不是資安漏洞通報。不是監管機關的函文。也不是用「learnings（學到的教訓）」這種漂亮排版的事後檢討文章在緊急救火。只是一張截圖：在管理後台裡顯示了私人的提示詞；在客服討論串中出現了客戶的圖片；在共享畫廊裡展示了生成結果；或是「已刪除」的檔案仍可透過 URL 存取。

截圖之所以有力，是因為它把整個隱私承諾濃縮成一個清楚可見的矛盾。你說內容是私人的。它就在那裡。你說已刪除。它也在那裡。你說客服看不到。它就在那裡，像是付了房租一樣，端端正正地待在儀表板上。

AI 影像產品尤其容易被截圖。因為內容是視覺的；證據也是視覺的。使用者不需要理解封包擷取或資料庫取證。他們只要指著螢幕說：「為什麼我的圖片會在這裡？」這是一句很短的話，但殺傷半徑非常大。

風險面通常都很普通。管理後台。客服工具。錯誤追蹤器。分析事件。附在錯誤回報裡的瀏覽器截圖。Slack 預覽。CDN URL。物件儲存主控台。QA 資料夾。內部畫廊。產品團隊可能不會把這些視為「AI 影像系統」，但你的組織架構不會讓使用者感到安心。

要設計信任，就要降低「可能出現致命截圖」的地方數量。如果客服不需要影像預覽，就不要建。若錯誤記錄不需要原始提示詞，就把它移除。若交付後不需要保存生成結果，就不要為了「未來的產品想法」而留著。未來的產品想法，往往就是讓隱私承諾變成被幽靈附身的家具。

當內容可見性是必要的，就要讓它是有意圖、可稽核的。有時候產品確實需要使用者可控的歷史紀錄。有時企業採購方為了合規需要保留。有時安全審查會產生法律義務。可以。那就說清楚，把它寫進產品模型裡。不要因為除錯方便而不小心做出同樣的東西，然後還假裝截圖是不公平的。

最強的信任姿態是架構層級：即使有人想要截圖，產品也無法產生它，因為內容已經不存在，或從未在該系統中提供。這比一份說「員工不應該查看」的政策更好。政策當然重要，但「按鈕根本不存在」有一種直白而漂亮的優雅。

對 Unexposed 而言，我們用「不依賴內容的作業紀錄」語言來避免掉進這個陷阱。服務仍然需要知道工作確實發生了。但它不需要保存客戶的提示詞、來源圖片、輸出結果，或是任何能讓儀表板輕易把它們暴露出來的金鑰。

如果你想測試你自己的 AI 影像功能，不要先從模型開始。先問這個問題：哪一張截圖會讓我們看起來像是在說謊？

然後把那個畫面移除。

延伸閱讀：Unexposed data storage、Private image generation without prompt retention、以及 How to evaluate private AI image tools。