Gemini 新项目默认存储请求：上线前，先核对你对用户的数据承诺

Google 在 2026 年 10 月 26 日调整了一个不太显眼、却可能影响上线承诺的默认值：新建的 Gemini API 付费层项目，默认会存储 Generate Content 请求，除非另行配置。既有项目保留原来的设置。如果你正准备把 AI 应用从原型迁到新建的生产项目，现在应该先确认：新环境的数据处理方式，还符合之前向用户作出的承诺吗？

官方更新日志明确列出了 generateContent、streamGenerateContent 和 batchGenerateContent，并提供两种退出方式：在单次请求中设置 store=false，或关闭项目的相关日志设置。这是有明确范围的默认值变化，不能解读成“历史请求全部突然被保存”，也不能解读成“付费用户的提示词默认拿去训练”。

我们的判断是：先把想要的存储行为写成上线要求，再沿实际请求路径验证。保留有明确用途的诊断记录，可以是合理选择；一边宣称对话不会保存，一边无意中继承新的存储默认值，则是另一回事。

这篇文章面向非技术创始人、AI 应用搭建者和小型产品团队。你可以直接使用文中的生产环境交接表、模拟数据演练和取舍方法，判断应保留多少排障证据、缩小哪些数据流。下文是一套建议采用的工作方法，不是我们亲自运行的 Gemini 实验，也不构成对你应用的任何认证。

1. 复制了应用，不代表复制了全部行为

很多团队的上线过程都很相似：先在应用搭建工具的预览环境接入 API key，得到不错的答案，把演示发给同事；准备正式发布时，再创建生产项目、更换密钥，让同一套界面连接新的后端。用户看到的功能可能完全一样，输入数据的处理方式却可能发生变化。

回答成功，不适合用来验证存储策略。一个留下诊断副本的请求，和一个关闭这类存储的请求，都可能生成有用的文本。如果验收只问“摘要写得对不对”，就会漏掉两者的区别。这也是为什么创始人即使从不编辑 API 请求，仍需要关注这次调整。

应把一个环境看成三部分的组合：应用行为、连接的服务，以及管理后台设置。只有提示词模板，描述不了完整环境。请搭建平台或开发者说明：生产流量进入哪个项目、使用哪一类 API，以及应用是否明确指定存储行为。旧项目的截图回答不了新项目的问题。

真正需要防范的是三个层面的错位：团队想要什么、上线后的系统实际做什么、用户听到了什么。即使日志策略本身经过认真设计，只要对用户的说明描述了另一套系统，仍然没有完成验收。反过来，不检查依赖就把所有存储一律关闭，也可能破坏原本想提供的功能。

这不意味着所有旧项目都要紧急迁移。此次更新明确保留了既有项目的当前设置。它提醒我们：创建项目、更换环境或切换服务商时，应当像审查其他客户数据处理变化一样，重新核对相关承诺。过去批准过一次，不等于今后每次部署都自动适用；当关键边界改变时，就应该重新检查。

2. 分开讨论存储、训练用途和对话状态

团队常把三个不同的问题都压缩成“隐私”，结果反而很难作决定。

存储，是指即时生成结束后仍保留某个副本，例如供日后查看的请求与响应。训练用途，是指拿数据改进模型或产品。对话状态，是指保留信息，让后续一轮能接续之前的交流。三者可以互相关联，但并不回答同一个问题。

Google 的付费服务条款区分了产品改进用途，以及为防止滥用和履行必要披露义务而进行的有限日志记录。API 是否属于付费服务，取决于调用所用项目是否关联有效的结算账户。不要仅凭同事说“我们买过 Google 的付费账户”就下结论；应确认具体项目和服务路径。

日志与数据共享政策又单独说明了开发者拥有的日志、可选择的数据集共享及保留期限。政策写明，日志默认最长保留窗口为 55 天，也可以选择更短的窗口；保存到数据集的副本则没有固定保留期限。把数据集分享给 Google，还会改变其适用的数据使用条款。因此，为排障建立样本集合，与把样本贡献给模型改进，需要分别有人负责、分别作决定。

落实到产品上，最好把承诺也拆开写。“我们不授权用于训练”，没有回答管理员能否查看保存的对话；“我们关闭服务商请求日志”，没有回答应用自己是否保存聊天；“你可以删除聊天记录”，也没有证明导出的副本会一并消失。

一个实用做法是：每项承诺都必须说清对象。保存的是哪份副本？哪个组织能访问？由什么流程删除？哪项服务能出于什么目的使用它？如果团队连副本或流程都说不清，就还没有足够明确的承诺可供批准。

不必把讨论变成“日志究竟好不好”的争论。真正的问题是：这份副本是否有合理用途、是否受到适当控制、用户能否理解说明。使用同一个模型的两种产品，完全可能得出不同而合理的选择。

3. 用一个上线交接场景检验承诺

假设有一个三人团队，正在开发“把客服消息整理成回复草稿”的助手。预览环境使用旧项目，输入的都是虚构工单。创始人准备连接一个新建、已启用结算的生产项目，邀请小企业客户试用。落地页目前写着：“你的消息仅用于生成回复草稿，我们不会为诊断保存消息内容。”

这次交接可能走向三个分支。以下都是说明问题的虚构情境，不是实际客户结果。

第一个分支是保留新项目的默认值。草稿看起来没问题，团队便宣布可以上线。但生产配置是否符合数据承诺，根本没有被检查。即使没有人查看保存下来的记录，团队也已经接受了一项未经讨论的数据处理选择。

第二个分支是开发者为主要的草稿生成路径设置了预期策略，但“再试一次”按钮走另一套自动化。这样，常规路径和重试路径可能使用不同配置。这是一种可能发生的集成失误，并不是说 Gemini 会忽略传入的指令。创始人需要的证据，应覆盖客户实际能触达的路径，包括备用和重试路径。

第三个分支是团队经过讨论，决定在敏感度较低的试点中保留有限诊断记录，同时安排合适的客户约定、访问限制和删除责任，并在收集数据之前修改产品说明。如果选择确实符合数据类型和对外承诺，这可以是有依据的运营决定；它并不意味着所有客服工单都应该被保存。

创始人的职责是选择能接受的分支，并要求证明已经按这个选择实现。开发者的职责则是展示实际项目、发出的请求配置，以及次要路径如何处理。双方都不能只转发一份模型更新公告，就认为交接已经完成。

如果试点要求的保证超过团队目前能证明的范围，应继续使用模拟工单、缩小功能范围，或推迟敏感数据接入。晚一点连接真实数据，往往比上线后才发现销售承诺依赖某个预览设置更容易处理。

4. 把这张生产数据交接表放进发布工单

下面这张表可以直接复制到发布工单。它是本文建议使用的工具，不是 Google 官方清单。每行都要写明负责人，并附上带日期的证据引用。只有策略意图、没有落实证据的项目，仍应标为待解决。

把证据链接放在团队内部工作区。不要把带 API key 或客户对话的截图贴进公开 issue。这份交接记录应让另一位同事不用追问当初的实施者，也能看懂到底批准了什么。

例如，第四行只写“日志已关”是不够的。更有用的写法是：“本路径不应产生开发者可查看的服务商请求日志；检查记录 A 展示了请求控制项，项目设置记录 B 与其一致。”即便如此，第六行仍要等应用和其他服务的副本都查清，才能关闭。

还要分清决策责任与操作权限。创始人可以批准产品希望如何处理数据，但未必有权修改生产设置；工程师可以落实配置，但未必有权扩大对客户的承诺。表格的作用是把两种责任接起来，避免双方都以为另一人已经完成了审查。

待解决项应该保持可见。若确实需要临时例外，要记录范围、理由、审批人和到期时间。临时例外悄悄变成永久默认值，本身就是另一种配置漂移。

5. 用模拟请求演练，而不是拿真实数据试错

日志与数据集指南说明，请求级 store 的优先级高于项目设置。指南还列出了支持该控制项的最低 SDK 版本，例如 Python 的 google-genai 2.33.0、JavaScript 的 @google/genai 2.31.0。搭建工具声称“支持 Gemini”，并不能证明其封装已经提供这个设置。

请实施者检查实际发出的请求，并去除密钥等敏感信息。搭建工具里的配置字段只能说明意图；确认部署后的集成在正确路径上真的传出了该值，才是更强的证据。不要把猜测的参数塞进另一套封装，再因为“没报错”就认定已经生效。

在模拟文本请求中放一个无害标记，例如 storage-rehearsal-20261027-route-a。记录环境、项目、时间、路径、策略选择和预期观察。不要把标记混进真实客户任务，以免搜索时暴露对话。

演练主要操作、重试，以及产品真正提供的流式响应；如果产品确实使用批处理或后台路径，也把它们列入。这里要做的是盘点已有路径，不是为测试专门增加全部 API 功能。某条次要路径值得测，是因为客户能够触达它，而不是因为公告里提到了它的名称。

条件合适时，可以在隔离的测试项目中，用明确开启存储的模拟对照请求，先确认观察方法确实能看到记录，再比较预期不存储的路径。不要为了方便测试，在敏感生产环境中临时打开诊断存储。如果无法安全建立对照，应记录限制并结合其他证据，而不是把一次不充分的观察包装成完整验证。

日志面板为空有多种解释：没有存储记录、选错项目、可见性有问题，或输入类型不受支持。指南列出的日志限制包括含 PDF、GIF 或视频的输入。检查观察方法时，应使用支持的纯文本样本，并写明检查时间；本文没有建立日志必定在多久内出现的保证。如果找不到标记，应先确认项目选择和日志可见性。无法解释的缺失是待解决项，不是测试通过。

最后应得出有范围的结论：在这个环境、这条路径上，发出的请求包含预期控制项，现有观察与该选择一致。这样的结论比“隐私已测试”更有用，也比宣称证明后端不存在任何副本更诚实。

6. 给排障留下足够证据，也给收集范围设边界

关闭内容日志，确实有代价。客户可能反映回复草稿把退款条件改了，客服团队却没有原始提示词可供复现。如果解决办法是在每个错误处理器里加入完整请求采集，就可能在更隐蔽的地方重新建立了相同的数据副本。

OWASP 日志指南建议保留有用的事件信息，同时排除或保护密钥和敏感内容。实际应用这个原则时，应先明确要诊断什么，再决定需要复制什么，而不是先把所有内容都存下来。

以客服草稿助手为例，一套建议的最小运行记录可以包含：请求时间、应用发布版本、提示词模板版本、模型标识、路径、完成状态、错误类别、耗时，以及与产品任务有关的结果标签。但不要默认客户标识或工单标题只是“无害元数据”；很短的一段值也可能暴露某个人或某场争议。

排障问题越具体，越容易减少不必要的内容采集。如果只是确认重试循环是否失效，路径和状态记录可能就够用；如果要检查某个条件是否被遗漏，模拟回归样例可能比保留所有客户原文更合适。确实需要真实案例时，应有明确、合适的获取与处理流程，而不是悄悄扩大日常收集范围。

要把两种选择的运营成本都算进去。原文更少，意味着客服可能需要更清晰的问题反馈方式、可复现模板和持续维护的模拟测试集；原文更多，则意味着更多访问、删除、审查和解释工作。“以后也许有用”不是完整理由，因为它没有明确的结束条件。

创始人不必读服务器代码，也能参与这项取舍：问清每个保留字段究竟帮助解决哪类具体问题，以及没有这个字段时团队准备怎么办。答不上来，要么字段没必要，要么事故处理流程还没设计好。

7. 明确 store=false 能证明到哪里

最容易出错的捷径，是把一个设置扩大成“任何地方都不留数据”的承诺。Google 的零数据保留说明分别讨论了滥用监测、搜索或地图信息增强（grounding）、上传文件、显式缓存和会话恢复。关闭某一类请求存储，并没有替其他路径作出结论。

应把“零保留”视为需要服务特定证据及适当合同审查的主张，而不是切换开关后就能贴上的标签。本文不判断合规、数据驻留，也不判断某份客户协议是否允许特定工作负载。如果要求超过当前服务配置能够提供的证据，就应暂停那条数据流，调查合适的服务方案，而不是用营销文案掩盖缺口。

还要注意功能依赖。Interactions API 文档说明，store=false 与后台执行不兼容，也会阻止后续通过 previous_interaction_id 接续。这是 Interactions 的边界，不能反过来证明所有 Generate Content 请求都必须保存状态。先查清功能实际使用哪类 API。

如果产品依赖恢复长时间任务，“所有地方都关掉存储”可能意味着重新设计功能，或更换服务安排。与其为了演示继续运行而悄悄改变策略，不如明确返回失败。产品要求里应写清：关键控制项不受支持时，不得在另一种未经批准的策略下继续传送客户内容。

同样，从界面移除一段聊天，不足以说明表格导出或客服附件也被清掉。选择删除措辞之前，先要有真实的副本清单。保留期届满、被标记为待删除、立即完成且已验证的清除，是不同的事件；不要把它们压缩成“即时彻底抹除”。

这项工作也能改善体验。用户知道保存什么、为什么保存，才更容易作出判断。没有证据支撑的宽泛保证，只会让以后的客服沟通更困难。

8. 上线前，分配好访问与变更责任

一旦决定记录内容，就同时决定了谁可能看到客户内容。需要检查谁能查看、谁能改设置、谁能创建数据集，以及谁能导出。即使服务商说记录仅对项目内部开放，也不能替代这些问题；“项目私有”不等于“内部只有必要的人能看”。

Google Cloud 的 IAM 安全指南建议采用最小权限、尽量缩小授权范围，并谨慎在生产环境授予宽泛的基本角色；文档也提醒权限会继承。可以据此要求检查实际生效的访问权限，但仍应另查 Gemini 具体功能所需权限。本文没有提供经过测试的日志面板角色配置方案。

对小团队而言，先指定一位负责对外承诺的产品负责人，一位负责实际配置的技术负责人，再指定能找到发布证据的备份联系人。同时记录谁能批准例外，以及例外到期后谁复核。这样的分工已经足以避免一次临时排障捷径变成无人负责的长期采集。

重新审查要绑定具体变化：新建项目、密钥改为指向另一项目、新增重试服务、升级封装、接入搜索增强（grounding）、开始使用对话接续，或把日志导出作评估。它们不一定具有相同风险，但都可能使过去的假设不再成立。关键是在答案可能改变时，及时重新提问。

如果发现既有路径产生了非预期存储，要把已确认事实与未知范围分开：明确受影响路径和时段，按情况阻止继续收集，保留不泄露内容的配置证据，并让负责事故处理及客户沟通的人参与。关闭今后的存储，并不能证明过去的副本已经消失。

一份有用的发布记录应说明：改了什么、检查了哪条路径、哪些证据仍不完整、下一步由谁负责。“隐私已改善”太笼统，无法帮助下一位维护者。

9. 决定继续、修改，还是暂停这条流程

如果预期行为已写清，生产环境实际路径已检查，观察结果支持选择，功能依赖已明确，对用户的说明也与副本清单一致，就可以继续。把证据与发布记录保存在一起。这是有范围的验收决定，不是保证未来任何新集成都不会改变它。

如果产品确实需要诊断记录，但当前承诺排除了这类记录；或者功能依赖某种存储，而团队原本打算关闭它，就应修改方案。可能的修改包括缩小输入范围、在采集前沟通并明确调整说明、建立模拟评估集，或更换架构。不能因为明天要上线，就自动批准一项数据策略例外。

如果封装隐藏了关键控制项、接收请求的项目不明、无法阻止被排除的客户内容进入，或严格的保留要求缺乏证据支持，就应暂停受影响流程。产品其他安全范围内的部分仍可能发布。针对某条路径暂缓开放，比笼统宣布整个应用“私密”或“不安全”更有操作价值。

已经使用旧项目的团队，应先查明现有设置和显式请求行为。不要为了让新旧环境看起来一致，就给旧项目打开日志。只有统一后的行为正是你想要的行为，一致性才有意义。

没有使用 Gemini Developer API 的团队，不需要把这次公告当作自家服务商的迁移指令。可以复用的经验更具体：环境默认值可能让原型阶段的假设失效。当自己的服务边界变化时，使用这套交接方法，再查对应服务的文档，而不是照搬 Gemini 参数。

眼下需要完成的交付物，是填好的交接表和依据明确的发布决定。创始人应能指出预期策略、已检查路径、尚存限制，以及用户会看到的说明。这样，上线审批才有具体对象，也能在真实流量把一个未被注意的默认值变成客户承诺之前，完成核对。

参考资料

1. Google：Gemini API 更新日志，2026 年 10 月 26 日。
2. Google：日志与数据集。
3. Google：数据日志与共享。
4. Google：Gemini Developer API 零数据保留说明。
5. Google：Interactions API 概述。
6. Google：Gemini API 附加服务条款。
7. Google Cloud：安全使用 IAM。
8. OWASP：日志指南。

资料核验日期为 2026 年 10 月 27 日。文中场景为虚构示例，交接方法为实践建议；本文没有实际操作服务商配置、执行删除审计或开展客户实验。