AI 快讯Gemini被指泄露私密文档,谷歌否认
行业快讯

Gemini被指泄露私密文档,谷歌否认

2026-08-08T12:04:21.731Z
Gemini被指泄露私密文档,谷歌否认

一名游戏开发者称,Gemini说出了仅存在于私人Google Docs中的未公开角色。谷歌否认扫描私密文件或用其训练模型,但信息来源仍未查清。

Gemini说出了私人文档里的未公开角色

Gemini近日被指在搜索回答中泄露一份私人Google Docs文档里的未公开游戏角色,但谷歌否认扫描用户私密文件,也否认使用这些内容训练Gemini。截至2026年8月8日,双方公开说法之间仍缺少一条能够闭合的证据链:开发者尚未证明信息只能来自该文档,谷歌也没有解释Gemini究竟从哪里获得了对应名称。

IT之家援引Windows Report的报道,一名独立游戏开发者发现,有玩家通过谷歌Gemini搜索其工作室正在开发的游戏,回答中意外出现了名为“Vantage Tripod”的未公开角色。开发者称,这个角色此前只存在于一份私人Google Docs文档中,没有发布到公开网站,也没有被放进游戏文件。

**私人Google Docs文档是访问权限未向公开互联网开放、通常仅限文档所有者或指定协作者查看的在线文件。**如果开发者的描述准确,而且“Vantage Tripod”确实是足够独特、无法通过常见词语组合猜出的专有名称,那么Gemini给出这一结果就值得严肃调查。

Gemini回答中出现未公开角色“Vantage Tripod”,旁边展示私人Google Docs权限设置的示意图

谷歌给出的回应很明确,但范围也相当有限。谷歌表示,公司不会扫描私人Google Docs文档,也不会使用这些文档训练Gemini;只有在用户主动提出请求时,Gemini才会访问相应的Google Workspace文件。

谷歌同时把另一种可能性指向了文档权限设置。谷歌称,如果有人把公开文档链接发布到互联网上,网页就可能被搜索引擎爬虫发现并建立索引,而Workspace文件的访问权限由用户控制。

这起事件目前更准确的定性不是“Gemini已经被证实拿私人文档训练”,而是“Gemini输出了被开发者认定为私密的信息,但来源未知”。这一区别非常重要,因为模型训练、运行时读取、搜索索引和第三方泄露是四条完全不同的数据路径,对应的责任主体和修复方式也不同。

谷歌否认了两件事,却没有回答最关键的问题

**模型训练是指模型在训练阶段从大量样本中学习统计规律,并将这些规律压缩进参数的过程。**如果私人文档被用于训练,意味着内容在用户没有明确发起调用时进入了训练数据管线,这将是严重的数据治理问题。

**运行时检索是指AI在回答当前问题时,经授权临时读取邮件、文档或云盘文件,再把相关内容加入上下文。**这种方式不等于训练:模型可能在本轮回答中“看见”文件,但文件内容并未因此永久写入模型参数。

**搜索引擎索引是指爬虫发现可访问页面后,提取内容并建立可检索记录。**一份文档即使被所有者称为“私人文档”,只要权限曾经设置为公开、被嵌入网页,或者链接落在可抓取页面上,就可能进入搜索索引或第三方网页存档。

谷歌此次回应否认的是“主动扫描私人Docs”和“将私人Docs用于训练”,但没有直接解释“Vantage Tripod”为什么会出现在回答中。即便谷歌的两项否认完全属实,信息仍可能通过运行时授权、公开链接索引、协作者复制、浏览器扩展、历史对话或其他外部页面进入Gemini的上下文。

这种回应方式在法律和产品层面都很谨慎。谷歌只承诺其既定的数据处理规则没有主动越界,却没有公布该次回答是否调用了Google Search、Workspace连接器或其他检索来源,也没有提供回答引用、访问日志和文档权限变更记录。

五种可能路径,只有日志能排除

目前没有公开证据足以锁定单一原因,但可能的数据路径可以被拆成五类。

| 可能路径 | 信息如何进入回答 | 是否等于用于训练 | 当前支持证据 | 需要核验的关键材料 | |---|---|---:|---|---| | 私人文档进入训练集 | 文档内容被训练管线收集并写入模型参数 | 是 | 谷歌明确否认,暂无直接证据 | 数据来源审计、训练集治理记录、可重复提示测试 | | Gemini获授权读取Workspace | 用户在提问时允许Gemini访问Docs或Drive | 否 | 谷歌称仅在用户主动请求时访问 | 账号活动日志、连接器授权记录、具体提问上下文 | | 文档链接曾公开并被索引 | 爬虫抓取公开页面或可访问文档 | 否 | 谷歌主动提示了这一可能性 | 文档权限历史、搜索缓存、网页存档、外链记录 | | 内容被协作者或第三方复制 | 角色名出现在聊天、工单、邮件、插件或其他页面 | 不一定 | 开发者尚未公开完整传播链 | 协作者列表、扩展权限、代码库与沟通平台检索结果 | | 模型猜测或名称碰撞 | Gemini根据上下文生成了相同字符串 | 否 | 理论上可能,但取决于名称独特性 | 原始问题、完整回答、重复测试、字符串公开出现频率 |

文档权限历史是判断索引路径最关键的证据之一。“现在是私人”不代表“从创建开始一直是私人”,一份文档可能曾短暂开放为“知道链接的任何人均可查看”,也可能被复制成另一份权限不同的文件。

**原始提示词是判断回答来源不可缺少的材料。**如果玩家的问题中已经包含角色描述、缩写、内部术语或其他暗示,Gemini可能据此生成名称;如果问题完全没有相关线索,且回答还给出了更多只存在于文档中的细节,泄露嫌疑才会显著上升。

**可重复性是区分真实检索和偶然幻觉的重要指标。**如果不同账号、不同地区和全新会话都能稳定得到同一未公开角色,并且回答包含多个相互关联的内部事实,那么纯粹巧合的解释会更弱;如果结果只能出现一次,则还要考虑缓存、个性化上下文和模型随机性。

这件事不能与今年3月的云端凭证漏洞混为一谈

今年3月曝光的谷歌云安全问题提供了一个危险背景,但目前没有证据证明它与此次Google Docs事件直接相关。前者发生在Google Cloud项目和Gemini开发接口层,后者指向消费级或企业级Workspace文档,两套数据边界并不相同。

**Gemini项目文件是开发者上传到谷歌生成式语言服务、供模型处理的数据集、文档或缓存上下文。**它们不等于用户Google Drive中的全部文件,更不代表攻击者拿到某个云项目凭证后就能读取任意人的Google Docs。

安全研究人员此前扫描约700 TiB的2025年11月Common Crawl公开网页数据,发现2,863个仍然有效、可能具有风险的谷歌云凭证。问题根源是一些过去被当作项目计费标识使用、长期嵌入网页前端的凭证,在同一Google Cloud项目启用Gemini服务后,可能获得访问项目内模型文件和缓存内容的能力。

受影响的数据面主要包括Gemini开发服务中的文件资源和缓存上下文,对应的技术对象涉及/v1beta/files/v1beta/cachedContents等端点。这里泄露的是特定云项目内上传给Gemini的资源,而不是对某个Google Workspace账号进行无差别扫描。

两起事件真正的共同点是权限边界随AI功能扩张而变得更难理解。过去只承担地图、视频或项目识别用途的配置,在接入生成式AI后可能触达更敏感的数据;过去只用于存放文档的Workspace,在开启智能功能后也多了一条运行时检索路径。

把两起事件直接串成“谷歌通过Gemini扫描所有私人文件”并不严谨。更合理的判断是,谷歌的AI产品正在把搜索、办公套件和云平台连接到一起,而权限说明、默认配置和审计能力没有同步变得足够直观。

“没有用于训练”已经不足以消除用户担忧

谷歌的否认在技术上可能完全成立,却很难单独解决这次信任问题。用户真正关心的不只是数据有没有进入训练集,还包括AI能不能在当前会话读取文件、搜索系统是否保存过副本、第三方应用是否获取了访问权,以及回答能否把原本受限的信息交给无权限的人。

“训练”和“访问”之间的差别对开发者很清楚,对普通用户却经常被产品文案模糊处理。一个AI助手不需要拿你的文档训练模型,也可以通过检索增强生成在几秒内读取文档、总结内容并输出;从用户结果看,两者都表现为“AI知道了我的文件里写了什么”。

**检索增强生成是模型在回答前从外部数据源查找相关内容,再将结果放进当前上下文的技术。**这类架构能提高答案的时效性和个性化程度,但也把安全问题从“训练数据是否合规”扩展为“每一次检索是否经过正确授权”。

谷歌需要提供的下一步不应只是重复隐私政策,而应是针对该次回答的来源调查。如果回答来自Google Search,谷歌应说明命中的页面和索引时间;如果来自Workspace,谷歌应核查调用账号、授权范围和访问日志;如果只是模型生成,则应展示可重复性测试和名称碰撞分析。

对比之下,一句“我们不使用私人Docs训练Gemini”只回答了最容易回答的部分。它没有证明没有数据泄露,也没有证明存在数据泄露,只是排除了一条谷歌声称没有发生的路径。

开发者现在应该检查什么

开发团队不必等调查结论出炉才开始自查。未发布产品、游戏设定、客户资料和安全设计文档都不应只依赖一个“当前显示为受限”的共享状态。

  • **检查文档权限历史。**重点确认文件是否曾设置为公开、组织内可见或“知道链接的任何人可查看”,并检查是否存在副本。
  • **审计协作者和外部账号。**离职成员、承包商、测试账号和群组权限通常比文档本身更容易被忽略。
  • **核对Workspace智能功能。**确认Gmail、Drive、Docs及相关Gemini功能是否符合组织的数据处理政策,不需要的连接能力应关闭。
  • **检查第三方扩展。**浏览器插件、会议记录工具、写作助手和自动化服务可能拥有读取当前页面或云盘内容的权限。
  • **保留原始回答证据。**完整保存提示词、回答、时间、账号、地区、引用链接和截图,不要只保留一句命中的角色名。
  • **做跨账号复现。**使用无历史记录的新会话测试,避免个人搜索历史、已连接Workspace和旧对话影响结果。
  • **审计Google Cloud项目。**将公开网页使用的配置与Gemini开发项目隔离,并限制每项凭证只能访问明确需要的服务。

企业还应把“AI可访问”单独列为数据分类维度。传统权限模型通常只区分谁能打开文件,但在AI环境里,还要回答谁能让助手读取、概括、跨文件搜索,以及生成结果能否被复制到权限边界之外。

现阶段最合理的结论

截至8月8日,公开信息不足以证明Gemini系统性扫描了私人Google Docs,更不足以证明谷歌用私人文档训练模型。事件目前只有一个核心事实主张:开发者称Gemini说出了仅存在于私人文档中的未公开角色,而该主张尚未获得独立技术取证支持。

谷歌的回应同样没有让事件结束。否认训练和主动扫描,并不能自动排除错误授权、历史公开、搜索索引、第三方复制或运行时检索等路径;只有回答来源记录、文档权限历史和账号访问日志能够把这些可能性逐一排除。

这起争议真正暴露的不是一个已经坐实的“大规模扫描丑闻”,而是AI助手的数据来源仍然缺乏用户可见性。当模型把搜索、个人文档和生成能力揉进同一个对话框时,用户看到的是一句答案,却看不到答案背后调用了哪一层数据。

谷歌如果想消除疑虑,最有效的产品改进不是再写一页隐私说明,而是给每条涉及个人数据的回答增加可审计来源:读取了哪份文件、使用了哪个连接器、依据了什么权限、数据是否被保留。对正在进入企业核心工作流的AI助手来说,这已经不是加分项,而是最低限度的可信基础设施。

参考来源

相关推荐

查看全部