用户自填 API 密钥，AI App 就更隐私了吗？本地 AI、云端数据保留与自带密钥的真正边界

“用户自行填写 API 密钥，就意味着数据不会经过应用开发商”——这句话的成立条件非常具体，并非绝对。密钥由用户持有，不代表请求一定直接发送至模型厂商；请求未经过应用服务器，也不意味着模型供应商不会留存数据；关闭某个日志选项，更不代表缓存、临时文件、后台任务、第三方搜索和应用自身的数据库会同步清除。一款标榜隐私优先的AI应用，真正需要向用户说明的，并非是否标注了“本地AI”“自带密钥”“零数据保留”这类标签，而是每一次数据处理过程中，谁是数据控制者、数据流向何处、存储时长多久、是否具备删除能力，以及如何验证这些承诺的真实性。

这一点对个人知识库应用尤为关键。应用在本地检索出三段相关文档后，会通过用户自填的密钥向云端模型发起请求，用户的原始PDF可能并未上传至云端，但这三段文档片段、用户的具体问题、引用的文档标题，甚至应用附带的系统摘要，都可能成为云端模型的输入内容。对用户而言，核心并非“文件是否上传”，而是“哪些数据已经离开设备、流向何处、为什么要流向那里、谁还能留存这些数据”。

首先画出数据流，而不是先写隐私承诺

在讨论数据隐私之前，需要先理清数据流的走向，而非先做出模糊的隐私承诺。自带密钥的应用至少存在三种典型部署模式，还有一种本地推理路径需要单独考量。第一种是设备直连模型供应商：密钥存储在客户端的安全区域，本地完成文档检索后，向模型供应商的HTTPS端点发送经过授权的上下文内容。这种模式下，应用开发者理论上不会接触到问答内容，但模型供应商会按照自身的条款处理请求；不过客户端的密钥仍可能面临本地入侵、调试、恶意代理或被篡改应用的威胁。第二种是应用后端代理模型请求：用户虽填写了自有密钥，但请求和密钥（或临时凭据）会经过应用服务器；运维日志、应用性能监控、错误上报、反向代理和备份机制，都可能产生额外的数据副本。第三种是用户自托管网关：应用连接到用户或其组织运营的推理端点，组织可以控制日志和数据保留策略，但仍需核验网络配置、身份鉴别、版本维护和上游再调用等环节。不能将这三种模式简单归为“自带密钥”。

本地推理是第四种不同的路径：模型在设备上运行，数据和上下文无需发送至外部模型供应商，但如果应用仍启用了云同步、在线搜索、崩溃诊断上传或远程嵌入功能，本地模型本身并不能保证“所有数据永不离开设备”。负责任的应用设置页面，应将“本地问答”“云端模型”“联网搜索”“资料同步”“诊断日志”拆分为独立开关，在用户切换模式时，明确提示本次操作会传输哪些内容。对于类似知识库的应用，最好在生成回答前，向用户展示将要发送的摘要或选定证据片段，而非仅显示目标模型的名称。

2026年10月26日，Gemini API改变了一个值得重视的默认值

2026年10月26日，谷歌旗下Gemini API调整了一项值得关注的默认设置。根据官方文档说明，2026年10月26日及之后创建的新项目，生成内容API的请求默认会被存储（等效于store=true）；此前的旧项目默认仍为store=false，除非用户曾在AI Studio中启用过相关日志功能。交互API的请求存储则有自己的默认行为，因为服务端会话状态需要依赖它。项目管理员可以在AI Studio中分别控制生成内容和交互的存储设置，也可以对单次请求单独指定。需要注意的是，不能将这一变化偷换为“所有Gemini API用户从10月26日起都被默认存储数据”，更不能混淆旧项目与新项目、免费调用与付费项目的日志能力。

该文档同时指出，支持的API日志一般最多保留55天，可调整为7、14、28或55天；保存为数据集的记录有不同的生命周期，不会按普通日志期限自动过期。日志可以显示请求和响应内容，也可以选择将选定数据分享用于产品反馈。需要特别强调的是，项目私有日志、供应商的滥用防护监控，以及用户主动分享以改进模型的数据，是完全不同的处理目的：开启日志并不直接等同于“所有数据都用于模型训练”，关闭项目日志也不代表供应商侧的所有系统都不会留存数据。真正的隐私说明，必须逐层表达默认设置、请求覆盖范围、保留时间、分享机制、删除流程和例外情况。

因此即使应用对每次请求明确发送store=false，也不能孤立用这个字段承诺整个AI系统零存储。它通常只控制某类应用状态或项目日志，仍须核对具体端点的其他留存、文件和安全处理规则。更稳妥的实现是默认采用供应商允许的最小化保存配置，对需要持续服务端会话的功能解释其必要性，并用脱敏的测试项目实际核验项目设置与请求覆盖是否一致。

OpenAI的零数据保留不是整个代理系统“所有节点零存储”

OpenAI的零数据保留并非指整个代理系统的所有节点都不存储数据。根据官方数据控制文档，OpenAI区分了滥用监测日志和应用状态：常规API请求默认不会用于模型训练，除非客户主动选择共享用于改进模型；但这与日志留存属于两个不同的问题。符合条件并获批准的组织可以启用零数据保留功能：对于支持的响应/聊天完成调用，即便请求中设置store参数为true，也会按false处理。但需要明确的是，零数据保留并非所有普通开发者都默认具备的开关，更不意味着第三方远程调用服务、托管容器、缓存、文件、向量存储、后台执行、会话对象或组织自身的日志都会同步删除。

例如，远程调用服务是第三方：发送给它的数据服从第三方的保留政策；后台模式为了轮询任务可能暂时在磁盘保留数据；托管Shell或代码解释器的容器有自己的临时文件生命周期。对话与响应的状态维护方式不同，零数据保留的端点适用性和地域处理也需要逐项核对。对“已经通过自带密钥启用OpenAI零数据保留”的宣传，应要求应用能提供当前组织/项目的真实控制状态、使用的具体端点、工具清单及数据路径，而不是凭UI里出现一个“隐私模式”图标推断合同已生效。

在技术设计上，最好对不同供应商建立统一的数据策略契约：本次请求是否允许传资料、是否允许持久化、是否允许用于模型训练、是否有区域限制、是否启用外部工具、是否可删除、失败后是否允许自动重试。供应商没有提供相应保证时，应标为“不确定 / 不支持”，而不是静默按最严格选项处理。统一策略不是统一政策：同一个字段名称在不同API、不同账户等级上的语义可能不同。

从端侧检索到云端回答，五个地方最容易泄漏

从端侧检索到云端回答的过程中，有五个环节最容易发生数据泄漏。第一个是上下文组装环节：混合检索通常会先用全文检索、嵌入和重排序找到相关数据片段。即使用户仅询问“这份合同有哪些风险”，云端模型收到的也可能是多个合同片段。应用应按知识空间、文件权限、用户意图和令牌限制，控制能被组装的证据范围，默认不应传输整个文档，即便云端模型支持长上下文，也不应扩大数据暴露范围。第二个是密钥存储和日志环节：移动端应使用平台安全存储（如iOS钥匙串、Android密钥库），桌面端使用系统凭据或密钥保护设施。不要将长期密钥硬编码进可发布应用，不要向浏览器控制台、代理服务日志、崩溃上报和分析工具发送密钥、授权头或用户全文。若采用代理转发，需明确服务器是否收到完整请求和密钥，如何限定保留时长以及如何撤销密钥。第三个是隐式联网工具环节：模型供应商的网页搜索、远程调用服务、浏览器、计算机使用、文件搜索等功能，可能增加新的数据处理方。用户授权“调用云端模型”，不一定意味着授权“将本地合同再发送给第三方抓取工具”。应用应分别批准模型调用和特定工具的联网范围，审计工具调用链上的跨域出站流量，阻止模型用外部网页指令劫持高权限操作。第四个是数据删除环节：删除应用内的一份资料，仅能证明本地索引和记录发生变化；此前发送的摘要、API项目日志、供应商会话状态、工具缓存、代理后台错误快照和备份，可能需要各自独立清理。应将删除操作分为“应用本地失效”“服务端保存状态删除”“第三方保留期结束”三个不同承诺，不能在点击删除按钮后声称“互联网上所有副本均已永久删除”。第五个是跨设备同步与备份环节：本地优先不应被默认解释为“永远只有这一台设备有明文数据”。端到端加密与服务端可读同步是不同的隐私模型；密钥托管、恢复机制、设备撤销和备份过期，都需要纳入数据流管理，避免用户在手机端选择关闭云端模型后，桌面端仍继续外发旧对话上下文。

推荐的工程验收：用网络证据，而不是用营销措辞

对于自带密钥应用的隐私情况，应采用网络证据而非营销措辞进行工程验收。一款可审计的自带密钥产品，至少要证明四项行为：其一，在“本地模式+联网搜索关闭”时，生成和检索路径不会向外部模型或工具发送知识内容；其二，云端模式开启后，仅传送用户授权的选定片段，且请求目标、上下文大小和对应权限可解释；其三，应用自身的错误监控、运营分析、代理日志不会存储密钥或未经许可的用户全文；其四，切换供应商、停用某密钥或删除本地资料后，应用确实停止使用原凭据和已撤销的数据片段。验证这些内容时，应使用隔离测试项目、脱敏假文档和可控网关记录，检查请求目的地、HTTP请求体/头的脱敏摘要、云端项目日志设置、重新打开应用后的状态；不能在生产个人隐私数据上盲目抓包测试。

对应的接口设计可提供一份内部数据策略表：数据范围、本地证据ID、供应商/端点、存储偏好、工具权限、保留策略、日志策略、有效账户控制、用户确认时间、撤销状态。策略网关在发请求前校验这些条件，并把“缺乏官方保证”的字段真实传给UI显示。这些设计对个人本地知识库、企业检索增强生成、AI笔记、代码助手和法律文档产品都长期有效，远比追踪某个模型小版本更新更有建设价值。

给用户承诺隐私之前，产品团队应至少对四种模式完成相同口径的资料流向核查。设备直连：用户密钥需要在系统凭据设施保存，提示词与经授权的文档片段直接发送给模型供应商；应用开发者的后端理论上不经手内容，但需要验证遥测或额外同步路径。应用后端代理：客户端到开发商再到模型供应商，开发商具备接触请求正文和凭据的技术机会，必须定义日志、审计、备份、密钥生命周期。用户自托管网关：数据发往用户指定的服务端，仍须识别网关是否转发第三方、是否留存请求及谁有管理员权限。本地推理：模型可以不发生云端请求，但仍要检查独立的联网搜索、崩溃上报、云同步和远程嵌入是否开启。

四种模式对“密钥由谁保管、请求最终去哪里、哪方能读取上下文、日志是否启用、第三方工具是否允许、删除需要几步”必须逐项给出答案，不能只返回一个笼统的“安全/不安全”图标。尤其是云端请求中只包含三个数据片段，也不等于内容不敏感：一个片段可能包含身份证号、商业合同条款或跨租户资料。正确的流程是先按身份与知识空间过滤，再由用户明确授权特定云端模型与出站范围，组装提示词后记录脱敏的证据ID与目标域名。

可以用合成文档实现不触碰用户隐私的验收：写入一个不会出现在正常业务里的唯一测试标记，在本地模式禁用搜索/同步后核对设备出站请求是否包含该标记；在授权云端模式核对实际发送的片段是否与预期一致；撤销密钥、删除一份资料后验证后续请求不再使用该密钥或资料。此举只能证明被测试的版本、请求路径和网络观察窗口内的行为，无法证明模型供应商所有内部日志、备份或受法律约束的数据保留均已清零。因此本文把验收清单作为工程标准，而不是冒称完成某款应用的真机认证。

选型结论：三个“隐私优先”不是一个东西

本地AI优先解决上下文不必离开终端的问题，但不自动关闭同步、遥测和联网搜索。自带密钥优先解决用户对供应商凭据和模型费用的控制问题，但不自动授予用户零数据保留权限，也不保证应用自己没做中转。云端零数据保留/受控留存属于特定组织与端点的保留治理，需要资格、协议、设置和工具边界逐项符合。长期产品若要真正获得用户信任，就必须把这三者分别实现、分别验收、分别解释，尤其不要把“没有使用用户数据训练模型”“不会生成应用日志”“请求完全不出设备”混成同一个承诺。

本文为公开的工程架构研究，没有在真实应用上进行密钥泄漏、抓包、第三方日志清理与云端账号保留期的独立验收。因此这里提出的是可操作的验证标准，不是对某个已上架应用的完成声明。真正的下一步是把数据流图、项目配置与脱敏网络实验固定下来，允许每一种运行模式给出可以被复核的隐私行为。

常见问题解答

用户自己填API密钥，App运营方就看不到内容吗？ 只有直连供应商且没有其他同步/遥测/代理泄漏路径时，应用运营方才可能不接收原始问答。是否经过代理必须以真实网络架构为准。

Gemini在2026年10月26日之后是不是所有请求都强制留存？ 不是。变化针对新项目的生成内容默认设置，已有项目保留旧默认，且项目管理员和部分单请求配置可调整；其他日志和保留规则仍须分别核查。

OpenAI设置store=false是不是等于全系统零数据保留？ 不是。它不能替代组织级零数据保留授权，也不约束应用自己的数据库、远程调用服务及其他第三方或独立状态存储。

云端AI能否只收到本地检索出的三个片段？ 可以按产品设计控制上传范围，但前提是应用能够在调用前准确过滤授权空间、选择证据并审计最终请求，而非只在界面上显示“仅上传必要信息”。

删除本地资料能否同时删除所有供应商的日志？ 不能承诺。不同端点、项目、数据集、工具与备份都有独立保留和删除能力，必须逐层说明。