你的 AI 影像功能只有在其佇列同樣私密時才算私密

模型負責展現魅力。佇列負責提供證據。

這就是 AI 影像基礎設施令人不舒服的真相。人們會討論哪個模型更銳利、更快、更便宜、更聽話、更不會對手部感到怪異，或更擅長假裝燈其實不是融化的號角。這些都說得通。影像品質確實重要。但如果產品會處理私密提示詞、來源影像、遮罩、臉部、品牌工作或客戶素材，那麼隱私敘事通常會在 GPU 尚未開始運作前就已分出勝負。

佇列不只是等待室。它是一套保管系統。某樣東西進入它。某樣東西識別它。某樣東西決定何時能執行。某樣東西在主機掛掉時重試它。某樣東西會記錄是否成功。若這個「某樣東西」包含原始提示詞、上傳的影像、生成的輸出、存取權杖或解密金鑰——那恭喜你：你優雅的 AI 功能，已悄悄在上面加了一個載入旋鈕，建立起內容檔案館。

最安全的佇列設計，會把乏味的營運事實與敏感的創意內容放在不同的車道。系統可能需要知道帳號 A 申請了模型 B、保留了額度、啟動了生成作業並取得成功結果。這是營運中繼資料。系統不需要把精確的提示詞、來源影像、遮罩、輸出影像或私鑰以持久記錄的方式保存。它們應該存在於短暫的生成流程中，而不是佇列的記憶宮殿裡。

重試機制是許多隱私承諾最容易在「戴著一頂小小產品經理帽」的情況下走向死亡。失敗的影像任務很容易被「為了除錯」而存起來。糟糕的來源上傳很容易被「為了支援」而保留。怪異的輸出很容易被「為了品質審查」而保存。每個誘惑單獨看都合理。合在一起，就會形成那種沒人打算建、但之後每個人都會假裝「只是內部工具」的意外展覽。

好的佇列預設會對內容保持盲目。它們可以說：這個任務存在、這個帳號負擔得起、已請求某個模型、某個工作者接受了它、這個作業結束了、使用了這麼多容量。它們不應該能說：這是客戶的私密婚禮照片、這是提到尚未發佈產品的提示詞、這是生成的行銷活動概念、以及用來再次解密它所需的金鑰。

這並不代表什麼都不會發生。以隱私為先的系統仍然需要可觀測性、計費、濫用控管與可靠性資料。訣竅不是刪除問責。訣竅是讓問責對內容保持盲目。Unexposed 使用 Image Request Ledgers 與 Generation Sessions 這些術語，因為這個區分很重要：要能證明機器確實運作過，但不把客戶的創意內容當作紀念品保留下來。

文案的說法很簡單：「私密的 AI 影像生成」不應該意味著「除非某個背景工作者、支援畫面、除錯日誌、重試表或 CDN 快取剛好心情很奇妙，否則我們保證不會去看」。它應該意味著架構中能讓私密素材落地的地方更少。

如果你正在把 AI 影像加入產品，請先檢查佇列，再檢查主打示範。問清楚工作負載（job payload）裡放了什麼。問失敗時會記錄什麼。問重試機制會複製什麼。問佇列是否能被重放以重建內容。問問是否有一位只有唯讀生產環境存取權的初級工程師，可能不小心成為世界上最不合格的檔案保管員。

模型負責生成影像。佇列決定這個請求是否會留下可追溯的痕跡。

延伸閱讀：How Unexposed works、Unexposed data storage，以及 OpenAI 關於 API data retention controls 的文件。