留存被藏在细则里

故障模式

留存是一种产品行为,而不只是法律条款。AI 图像工具应当在用户做出上传决定时,清楚说明存储与删除。

Date
2026年7月3日
Author
Unexposed

一款 AI 应用漂浮在一份折叠的细则合同上方,旁边还有隐藏的存储金库

细则之所以让人失去信任,是因为它会让信任变得瘸腿。

AI 工具经常在某处提到留存:隐私政策里的一个段落、服务条款中的一条、数据处理补充协议中的一段,或者帮助中心里一篇最后更新的文章——作者的职位头衔里带着“operations”这个词,而他的咖啡也已经放弃了。

问题不在于法律文件的存在——它们应该存在。问题在于:当唯一有意义的“图像留存”解释,出现在离用户上传图像的时刻很远的地方。

留存是一种产品行为。它决定用户的照片是否会成为某个画廊的一部分、训练集、缓存、支持工具、审核队列、分析数据仓库,或备份周期。用户做出决定的地方,应该用产品语言把这种行为讲清楚。

这对 AI 图像尤其重要,因为用户往往会上传敏感内容来获得收益。创始人上传一个概念稿。家长上传孩子的照片。摄影师上传婚礼影集。机构上传客户素材。如果留存答案是“见第 8.4 节”,那产品一边要求用户信任,一边把收据藏起来。

好的留存文案要短、具体。“我们不保留提示词历史。”“上传的图像会在生成后删除。”“除非你保存,否则不会托管输出结果。”“临时任务文件在 24 小时后过期。”“我们不会在客户上传内容上训练模型。”这些句子并不是对法律文件的替代。它们是面向用户的、对实际行为的总结。

文案还必须与系统一致。没有什么比一个简单的隐私声明却被复杂的后台所推翻更能迅速摧毁信任。如果支持团队仍能看到“已删除”的图像,就不要暗示删除就等于消失。如果输出结果通过长期存在的公开 URL 才能访问,就不要把画廊称为私有。如果日志里包含提示词,就不要一本正经地宣称提示词隐私。

细则当然有它的用武之地。它负责精确表述、处理边界情况、说明司法管辖、列出处理方细节以及义务。但核心的留存承诺应该在上传之前就清晰可见,因为那时用户仍然可以选择。

如果一个 AI 图像工具需要进行一场“法律考古”才能回答“我的照片会怎样?”,用户会认为答案一定很糟。他们可能是错的。但产品没有给他们更好的选择。

延伸阅读:你的 AI 图像功能必须经得起的隐私政策问题在你的应用中添加“生成图像”带来的隐藏信任成本,以及 你的数据

Your prompt. Your model. Only your content.

Create private images with Credits, Access Tokens, and sealed requests. Encrypted in transit, run on ephemeral compute, deleted after delivery.