默认保存以后，AI应用的数据责任多了一层

2026年10月26日，Google调整了Generate Content的默认设置：新的付费项目默认保存请求，既有项目保持原设置。创建项目因此不只是选择账单归属，也是在选择数据如何留下来。更新说明

这一区别容易被忽略，因为应用可以给出相同答案，却留下不同记录。产品团队迁移服务时，通常先测试回答是否正确、业务流程是否仍能运行。这类测试并不能说明谁以后可以查看对话、哪些副本仍然存在，以及一条被保存的失败案例最终会用于什么。需要审阅的不只是模型调用，还包括调用结束后信息的去向。

功能没有变化，记录未必相同

设想一家零售商把客服助手迁移到新项目。提示词、顾客界面和退款规则都没有改变，功能测试也顺利通过。工程师仍需另行回答：新环境继承的是原有的数据设置，还是仅仅相同的应用代码？

这是假设情境，并非已发生的事故。它说明配置为什么应当进入发布检查。正常回复证明系统具备某一种能力，恰当的记录生命周期则证明另一件事，二者不能互相替代。只问助手“能不能用”，可能漏掉一个用户从回答中完全看不到的变化。

这里存在真实的取舍。顾客投诉助手误读订单时，保留的交互记录有助于还原错误。缺少足够证据，团队可能修复一个想象出来的问题，或者始终无法重现真正的故障。但对排查有用的记录，也可能包含与排查无关的信息。提高可观察性与减少不必要留存，并不是只能二选一的口号，而是需要针对具体流程协调的设计目标。

副本可能比最初的用途活得更久

Google政策区分普通日志留存、数据集留存与可选择的模型改进共享。日志政策

本文关注的是用途转换。假设工程师发现一段失败对话，移除明显的身份信息，再把它保存为评测样本。这个样本的价值，恰恰在于以后还要反复使用。即使文本看起来没有太大变化，原对话也已经从日常操作界面消失，这次转换仍需要明确的负责人和用途。

去掉姓名并不必然使案例无法关联到个人。订单细节、地点与特殊遭遇组合起来，仍可能让熟悉背景的人认出当事人。反过来，如果把所有细节都替换成通用占位内容，又可能抹掉造成错误的条件。一个有用的评测案例应保留需要测试的机制，而不是自动保留整段对话。能否做到，要看任务本身，不能预先假定。

因此，收集故障证据与维护可复用测试，是两个不同问题。前者问当时发生了什么，后者问哪些特征必须保留，才能发现同类错误再次出现。把两者分开，团队更容易作出具体判断。例如，地址校验失败的测试可能需要保留某种格式歧义，而不需要某位真实顾客的完整购买记录。

这也改变了“删除完成”的理解。业务人员看不到原始记录，并不自动回答评测样本是否仍有用途、谁可以访问、何时应再次审查。这里不是在推断某个系统存在漏洞，而是在指出：信息复制之后，责任也需要跟随复制后的对象。只盯着最初那一条请求，容易把后续使用当成理所当然。

一个开关解释不了所有用途

Google另有滥用监测流程。因此，关闭开发者日志不应被描述为消除服务商持有的所有记录。滥用监测文档

对评估AI应用的采购方来说，“数据会不会保存”只是起点。更有帮助的解释，是说明每一种留存副本的用途、责任人，以及什么事件会使该用途结束。同一份信息可能被用于调查故障、识别服务滥用或建立测试集合；即使它们来自同一次请求，也不意味着这些决定可以合并处理。

同样，不能因为请求被保留，就断言它一定用于通用模型训练。存储、访问与再次使用是不同概念。把它们压缩成一个隐私标签，虽然容易宣传，却不利于实际评估。合理的回应既不是预设违规，也不是预设绝对安全，而是把文档中的控制与应用的真实配置对照起来。

一种可行的审阅方式，是从日常工程边界入手：创建项目、迁移环境、导出排错案例，以及把案例纳入评测集。每经过一个边界，都需要有人确认当前用途和访问范围是否仍然合适。这是一种操作层面的分析框架，不代表完成这些步骤就能自动满足法律要求，也不意味着所有团队都需要相同的留存策略。

默认日志可能帮助发现原本悄无声息的错误。关闭日志可能减少部分留存，却也可能使团队无法解释失败。判断取决于需要什么证据、流程涉及哪些敏感内容，以及是否有更合适的替代办法。本文没有检查任何客户的配置，也没有发现或认定数据泄露事件。

这次变化带来的实际提醒，比支持或反对日志本身更具体：重新创建一个应用，并不必然复制它原有的数据处理假设。除了用户看得见的功能，这些假设也应当被重新核对。