为什么删除上传必须可验证

“删除我的上传”这句话听起来很简单，直到它遇到真实的系统。

从哪里删除？画廊？对象存储？CDN？缓存？队列？错误追踪器？支持工单？缩略图表？备份？模型提供方？分析流水线？以及某个人在调试时新建的文件夹 final-final-private-test——你就知道软件已经开始吞噬自己了。

对于 AI 图像产品，删除必须用“对象”来定义。源图像。提示词。遮罩。参考图像。生成输出。缩略图。临时文件。交付 URL。操作元数据。计费记录。每个对象可能都有不同的生命周期。一个强大的产品会理解这些生命周期。一个弱的产品只会说“已删除”，并且希望没人追问后续。

可验证的删除并不总是意味着用户能够在瞬间用密码学方式证明每一字节都已从每种介质中彻底消失。在许多系统中，备份、日志、欺诈记录、税务记录以及法律义务都会使删除变得复杂。诚实的产品会解释这些限制。关键区别在于：保留的记录是“承载内容”的，还是“内容无关”的。

如果一个产品删除了图像，但保留了一条计费记录，说明确实发生过一次图像生成，这可能是合理的。如果它删除了画廊条目，却把缩略图、提示词以及源图像保存在一个“质量”桶里，那就像是一段在监管灯光下上演的喜剧小品。

好的删除从删除之前就开始。它始于不要把私密内容复制到不必要的地方。内容流向的地方越少，删除就越不需要在之后用一把小扫帚和一张难过的脸去追逐。短数据路径比那些四处蔓延的路径更容易验证。

用户界面也应该足够精确。“从画廊移除”不同于“删除源上传”。“删除输出”不同于“删除账户”。“隐藏”也不是“删除”。“归档”当然也绝对不是“删除”，不管字体有多昂贵。

对于以隐私为优先的 AI 图像基础设施，更好的默认做法是首先避免持久化的上传存储。对源图像在一个短生命周期的会话中进行处理，返回输出，并且只保留内容无关的操作性记录。这样，删除承诺就不会显得那么“英雄主义”，因为等待被删除的私密内容更少了。

用户不需要一篇论文。他们只需要一个清晰的答案：我按下删除之后，哪些内容还会留下？为什么？

如果一个产品无法回答这个问题，“删除”就只是装饰。

延伸阅读：Unexposed 数据存储，如何思考 AI 图像的零保留，以及 OpenAI 的API 数据保留文档。