生成图片的信任成本

在应用里加入“生成图片”看起来就像一个按钮。很现代。很容易点。很“我们现在是 AI 公司了，请相应调整估值表”。

但按钮背后是一份与用户的约定。用户可能不会把它当作合同来读，因为正常人不会打开一个产品就想：“啊，是的，一个分布式托管图谱，且需要在计算侧满足删除要求。”他们只会想：我的照片去哪了？谁能看到？会被存储吗？我能删除吗？会不会因为某个仪表盘设计师兴奋过头，而出现在某个内部画廊里？

隐藏的信任成本从输入开始。文本提示可能包含私密的业务背景、个人幻想、机密的产品想法、医疗细节、客户姓名、尚未发布的活动、法律纠纷，或者仅仅是凌晨 1:13 打出来的尴尬胡言乱语。源图片可能包含面孔、儿童、住址、文件、工作场所、制服、元数据，以及其他并未同意成为你路线图一部分的人。

接着是输出。生成的图片并不会因为是合成的就自动无害。它可能泄露提示词、源内容、品牌意图、客户的简报、用户身份，甚至泄露工作流本身。如果你的产品把输出存进画廊、通过公开的 CDN 发送、把缩略图写入持久化对象存储，或把它们纳入支持工具，那么输出就会成为另一份客户内容，并拥有自己的生命周期。

大多数产品团队会低估支持面。用户会问：为什么图片失败了？为什么扣了积分？为什么拒绝了源照片？为什么输出消失了？他们能不能找回？你能不能删除？你们团队能不能查看？如果你唯一的回答是“让我查一下日志”，而日志里又包含客户内容，那么你就把支持变成了隐私例外。

更好的模式是把产品便利性与内容保留分开。让用户能快速生成，但不要让系统记住超过必要的内容。让计费记录与内容无关。让运营事件与内容无关。让支持流程如实说明操作人员能看见什么、不能看见什么。一个“看不见私密图片”的支持团队听起来可能不够方便，直到你想起“支持看到了我的私密图片”并不是一种令人愉快的保留功能。

因此，在上线之前就要评估隐藏的信任成本，而不是在第一个紧张的客户问“我的上传去哪了”之后才补救。你需要为队列载荷、临时文件、模型托管、重试、日志、缩略图、下载 URL、分析、错误上报、员工访问权限、删除时机以及第三方处理器准备答案。这对一个可爱的小按钮来说，管道工程量实在太大了。

以上并不意味着这个功能是个坏主意。它意味着这个功能是真实的软件。真实的软件有托管。真实的软件有故障模式。真实的软件需要隐私叙事，而且要落实到实现中，而不是只是在一个名为“Trust（信任）”的页面上贴一张“某人指着玻璃”的库存照片。

最强的产品文案往往对应最朴素的架构。“我们的系统仅为返回结果而处理你的源图片和生成输出，不会作为画廊存储，也不会发送给第三方图片提供商。”如果系统真的能支持这句话，那它就不只是文案。这就是产品优势。

按钮很小。它背后的承诺却不小。

延伸阅读：Your Data、Private AI Image Generator，以及 AWS 的 Amazon Bedrock 说明：在其部署模型中，模型提供商无法访问 Bedrock 客户端的提示词与补全内容（AWS 数据保护）。