客户上传一份文件，希望 AI 帮他整理。产品做完任务，顺手把文件留下，准备以后改进模型。听起来挺自然，却在“顺手”这一步里，改变了资料的用途。
完成当前任务、保存评测样例、训练模型、提供给别的客户检索，是不同的事情。能接触一份资料，不能直接推导出可以拿它做所有事情。
英国监管机构 ICO 的 AI 指导强调，应区分不同处理目的及其法律依据，也区分开发与部署阶段。该指导正处于审查更新中，属于英国法律语境，不能直接当成中国或其他地区的统一规则。资料：ICO
这个例子想说明的是：一句“为了改进产品”，并不能省掉对具体用途的解释。业务发生在哪里、涉及什么资料、与客户怎样约定，都会影响判断。
从产品角度看，改进也未必需要收藏全部原件。设想一个简历整理工具，总把双栏排版的内容读串。真正值得研究的可能是版式，而不是求职者的姓名、电话和完整履历。构造同样版式的虚拟样本，就有机会重现这类问题。
“反馈闭环”也可以讲得很简单：发现错误，理解原因，修改产品，再看同类错误是否减少。这个过程需要有用的线索，但不一定需要无限堆积用户内容。
例如，系统老把日期读错，错误类型、发生位置和经过妥善处理的必要片段，可能已经提供不少信息。相反，资料越留越多，却说不清来自谁、用于哪里，未来反而难以管理。
去掉姓名也不能自动算匿名。工作单位、项目细节、时间等信息组合起来，仍可能指向具体的人。资料还可能流入模型服务、日志、缓存和导出包；前台一句“不留存”，需要后台真实安排来支撑。
客户后来退出时，同样会关心哪些信息不再用于改进、哪些副本还在按什么期限处理。实际能回答这些问题，比一段宽泛的承诺更重要。
我理解的数据积累，应该包含来源与使用边界。否则，堆在一起的文件越多，无法解释的责任也可能越多。一个能持续学习的产品，需要让客户明白自己的反馈怎样帮到了产品，而不是让资料在他看不见的地方换了用途。