為什麼刪除上傳內容必須可驗證

「刪除我的上傳」是那種聽起來很簡單的說法，直到它真的碰上某個系統。

刪除到哪裡？相簿？物件儲存？CDN？快取？佇列？錯誤追蹤器？支援工單？縮圖表？備份？模型供應商？分析管線？以及那個有人在除錯時建立的資料夾 final-final-private-test——你就知道軟體已經開始自我吞噬了。

對於 AI 圖像產品，刪除必須用「物件」來定義。來源圖像。提示詞。遮罩。參考圖像。生成輸出。縮圖。暫存檔。交付 URL。作業中繼資料。帳單紀錄。每個物件可能都有不同的生命週期。一個強健的產品會理解這些生命週期；弱一點的產品只會說「已刪除」，然後希望沒人追問後續。

可驗證的刪除不一定代表使用者能在瞬間用加密方式證明每一個位元組都已從每個媒介消失。在許多系統中，備份、日誌、詐欺紀錄、稅務紀錄與法律義務都會讓刪除變得複雜。誠實的產品會說明這些限制。關鍵差異在於：保留的紀錄是「含內容」還是「不含內容」。

如果產品刪除了圖像，但保留一筆帳單紀錄，表示確實發生過一次圖像生成，那可能是合理的。如果它刪除了相簿項目，卻在「品質」桶中保留縮圖、提示詞與來源圖像——那就像是一段在法規燈光下的喜劇短劇。

好的刪除從刪除之前就開始。從不要把私密內容複製到不必要的地方開始。內容流向的地方越少，之後就越不需要用小掃把和一張悲傷的臉去追著刪除。短的資料路徑比四處蔓延的路徑更容易驗證。

介面也應該精準。「從相簿移除」和「刪除來源上傳」不同。「刪除輸出」和「刪除帳戶」不同。「隱藏」也不是「刪除」。而「封存」——不管字型多貴——都絕對不是「刪除」。

對於以隱私為先的 AI 圖像基礎設施，更好的預設是從一開始就避免持久化的上傳儲存：在短暫的會話中處理來源圖像，回傳輸出，並只保留不含內容的作業性紀錄。如此一來，刪除承諾就不必那麼英雄，因為等待被刪除的私密內容更少了。

使用者不需要一篇論文。他們需要一個清楚的答案：我按下刪除後，還會留下哪些內容？以及為什麼？

如果產品無法回答，那「刪除」就只是裝飾。

延伸閱讀：Unexposed data storage、如何思考 AI 圖像的零保留，以及 OpenAI 的 API 資料保留說明。