Google Private AI Compute 记忆功能挑战云端无状态隐私模式

Google 已为 Private AI Compute 加入持久化的服务器端记忆功能，突破了此前定义隐私导向云端 AI 的无状态设计。该系统旨在跨设备保留上下文，同时将解密密钥保留在由用户控制的硬件上。

这对 Google Private AI Compute 记忆功能而言是一次重要变化。此前，Google 和 Apple 都将“遗忘”视为核心隐私保护机制。每次云端请求都会进入独立环境，获得答案后离开，不留下持久化的个人上下文。

Google 现在认为，如果云端环境在每次请求后都遗忘一切，助手就无法实现真正的连续体验。其提出的解决方案是一个留存在云端的加密记忆库，但若没有从设备派生的密钥，任何人都无法打开它。

这一架构直接引出了连续性与数据最小化之间的矛盾。记住更多内容能让助手更实用，但也会形成无状态系统原本旨在避免的长期攻击目标。

Google 正在为 Private AI Compute 加入记忆功能

Google 正将一项私密推理服务转变为持久化的个人计算层。

Google DeepMind 于 2026 年 9 月 23 日披露了这一架构。其技术更新介绍了一层记忆机制，可跨会话和设备保留个人上下文。

Private AI Compute 最初的作用，是将高计算需求的 AI 工作扩展到手机之外。当本地模型的计算能力不足时，设备可将加密请求发送至受保护的 Google 基础设施。

该云端环境会在硬件隔离系统内处理请求，随后返回结果，而不会保留会话中的个人上下文。

Google 将此前的设计称为无状态。实际而言，该服务可协助处理单次请求，却无法在之后安全地延续同一段体验。

新的记忆层改变了这一限制。推理请求结束后，个人上下文可以保留在按用户隔离的数据库中。Google 表示，存储的信息始终处于加密状态，所需的解锁密钥则保留在用户设备上。

当获授权的模型需要这些上下文时，设备会与隔离的云端环境建立经认证的端到端加密连接。该安全 enclave 会在受保护的内存中临时解密所需信息。

安全 enclave 是由硬件强制隔离的区域，可将代码和数据与更广泛的服务器环境分开。即便是具备特权的基础设施软件，也不应能够随意检查 enclave 中正在使用的内存。

请求处理完成后，系统可以更新保留的上下文，随后在写回存储前再次将其加密。

这种结构支持了在无状态模型下难以实现的体验。例如，一段在手机上开始的对话，可以在笔记本电脑上继续，而无需手动重新补充背景信息。

Google 还举了智能眼镜的例子：用户可以通过眼镜查看说明，之后再从另一台设备调取相关上下文。

该公司尚未在披露中公布面向消费者的大规模上线日期。它将这项架构描述为一项可支持未来持久记忆体验的能力。

这一区别很重要。Google 已公布其安全模型，但读者目前还无法获得完整的产品清单，也看不到用于查看已存记忆的标准控制功能。

不过，这项公告仍标志着战略转变。Google 不再将私密云端推理和持久化个性化视为两个彼此独立的问题。

其早期的 Private AI Compute 平台侧重于运行规模更大的 Gemini 工作负载，同时避免对敏感请求采用传统云端访问模式。持久记忆则将系统的责任延伸至推理发生的瞬间之外。

该服务如今必须在传输、主动处理、长期存储、后续检索和删除的全过程中保护信息。每增加一个环节，就多一个可能因设计错误而影响隐私的位置。

这份更广泛的责任才是真正的重点。Google 提出，云端 AI 可以长期记住一个人，同时不让其运营方获得对这份记忆的常规访问权。

无状态云端 AI 为何已触及极限

让机密云端 AI 更易获得信任的隐私特性，也让它作为个人助手的能力受到限制。

无状态处理可最大限度减少留在服务器上的个人信息，但也限制了连续性，因为模型每次进入受保护会话时，都没有此前交互的持久记录。

开发者可以通过在其他位置保存部分偏好来绕过这一问题。例如，助手可以保留用户偏好的语言、饮食限制或常用目的地。

然而，一份孤立事实清单无法复现持续演进的对话，也无法完整表达未完成的工作、不断变化的优先级，或在不同设备上完成的活动之间的关联。

用户因此反复面临同一种选择：重新解释相同的上下文，允许普通云端账户存储这些信息，或者接受个性化程度较低的助手。

Google Private AI Compute 记忆功能旨在消除这种选择。它将持久化加密存储与使信息可读所需的密钥分离开来。

这种分离十分重要，因为先进 AI 模型依然需要大量服务器资源。手机和笔记本电脑可以运行能力日益增强的本地模型，但无法高效执行所有前沿规模任务。

云端基础设施提供更大的模型、专用加速器和更多可用内存，但也会将敏感信息转移至由其他组织控制的环境中。

机密计算试图缩小这一信任缺口。它保护的是数据正在被使用时的状态，而不仅是数据处于存储或网络传输中的状态。

传统加密能够保护静态数据和传输中的数据，但普通服务器在模型处理信息前，仍必须在某处将其解密。

可信执行环境（TEE）会限制这一暴露阶段。获批准的代码在隔离边界内处理可读信息，而周围的宿主环境依旧无法直接检查这些信息。

Google Cloud 将机密计算描述为一种在处理期间保护敏感工作负载的方式，其应用包括分析、机器学习，以及受保护数据集之间的协作。

这种方法并不能消除所有信任假设。它改变了必须被信任的组件，并让设备能够获得关于接收其数据环境的技术证据。

持久记忆进一步提高了这些保障的重要性。单次推理请求仅会在有限时间内暴露有限范围的上下文。

持久化 AI 记忆则可能累积对话、偏好、文档、位置和行为模式。它对助手越有价值，对攻击者也越有价值。

知识工作者会理解其中的吸引力。当个人助手能够跨时间关联会议、文件、决策和未完成任务时，其实用性将显著提高。

同样的原则也适用于个人知识库。有效检索依赖持久化上下文、清晰的所有权，以及防止无关人员访问的控制措施。

Google 正试图在云端规模上应用这些原则。它必须保留连续性，同时避免让服务提供商成为可读个人历史的保管者。

这种压力并不只存在于 Google。每一家主要助手供应商都希望拥有更长期的上下文，因为连续性能够提升任务完成率，并减少重复提示。

困难的问题不再是助手是否应当拥有记忆，而是用户能否在不接受传统服务器端可见性的前提下获得有用的记忆功能。

Google Private AI Compute 记忆功能如何运作

该设计将加密记忆置于 Google 的基础设施中，同时将实际解锁权限与个人设备绑定。

Google 将记忆存储描述为一个安全数字保险库。每名用户都会获得由与其设备相关联的加密机制保护的隔离存储空间。

该架构使用数据加密密钥，通常称为 DEK，来加密存储的记忆。第二把密钥则用于保护该 DEK，确保数据库并不持有可被直接使用的解锁密钥。

Google 的示意图将这一第二层标识为密钥加密密钥安排。设备参与派生或保护解封存储数据所需的密钥材料。

这种设计意味着，仅窃取加密数据库本身不应足以泄露其中内容。攻击者还需要获得经授权的密钥路径，以及获批准的处理环境。

当助手需要上下文时，客户端会先验证远程环境。这个过程称为远程证明。

远程证明让设备能够在释放敏感信息前，核查服务器硬件和运行软件的相关声明。一份有效报告应表明，获批准的代码正在预期的 enclave 内运行。

随后，设备会与该环境建立加密通道。只有在系统通过必要检查后，记忆才会在隔离内存中被解密。

模型可利用上下文回答请求，也可以生成由记忆服务保存、供后续交互使用的新信息。

Google 表示，管理员和普通云端服务均无法检查这些信息。该公司进一步声称，这一架构甚至让 Google 本身也无法访问数据。

这一说法依赖的不只是加密。设备必须正确验证服务器，enclave 必须有效实施隔离，软件也必须避免通过输出泄露数据。

密钥管理同样成为核心问题。即使是私密系统，也可能因账户恢复、设备更换、同步或撤销权限悄然引入替代访问路径而失效。

Google 尚未在公开公告中完整说明这些用户生命周期场景。它们将影响实际部署的系统与其架构承诺之间的吻合程度。

例如，丢失所有受信任设备会带来艰难取舍。强设备专属密钥可能导致记忆永久无法恢复。

由服务提供商控制、但更方便的恢复机制可以降低这种风险，但也可能创造另一条让用户以外的人获得访问权的路径。

添加新手机也会带来相关问题。系统必须在不向中间方泄露密钥、也不接受未授权注册的前提下，将权限转移到该设备。

删除还必须涵盖移除可见记忆条目以外的内容。用户需要确信，已废弃的密钥、副本、备份、缓存和派生上下文无法在之后恢复那些据称已删除的信息。

这些都是正常的运营要求，并非证明 Google 的设计存在缺陷。它们说明，私密 AI 记忆并不只是把数据库放在 enclave 后面那么简单。

推理路径本身包含多个组件。早先一项独立评估描述了加密客户端连接、前端服务、编排系统、AI 安全模块以及经过加固的 TPU 基础设施。

这些组件彼此进行身份验证，并使用证明机制建立获批的通信路径。每项新增服务都必须处于预期的隐私边界内。

Google 还计划发布一份防篡改的服务器软件记录。客户端可在发送个人数据前，将服务器经证明的软件度量值与公开记录进行比对。

这一机制解决了一项隐蔽的云端风险：提供商可能发布可供审查的安全代码，却在生产环境中运行不同的软件。

仅追加式透明记录使未被察觉的替换变得更困难。研究人员可以检查已列出的构建版本，而设备会拒绝与授权度量值不匹配的环境。

这一机制并不能证明每一个获授权构建版本都不存在漏洞。它提供的证据是：经过检查的软件，与设备被允许信任的软件相对应。

这种区别很重要。透明度使审查成为可能，但审查仍需要可获取的工件、具备能力的研究人员和时间。

隐私承诺仍有硬件边界

Google 可以削弱云管理员的权限，但无法消除对 Google 设计的硬件和软件的所有依赖。

Google 委托 NCC Group 自 2025 年春季起评估 Private AI Compute 的部分选定组件。据称，十名顾问在架构与组件审查中共投入了 100 人天。

这项独立审查考察了 Oak Session 加密库、远程证明、IP 隐匿中继、透明度日志以及部分服务器代码。这项工作比未经审计的产品声明提供了更实质的依据。

不过，其范围同样重要。对选定组件的审查，并不等同于认证未来的每项记忆功能、客户端实现、硬件修订版本或运营流程。

该评估还指出了一项根本限制：实际的 AI 推理目前仍需在某个物理计算系统内，对可读取的数据进行处理。

因此，加密信息会在计算期间于受保护处理器内变为明文。硬件和获批准的代码能够访问它，因为它们必须执行被请求的工作。

NCC 的报告指出，硬件设计者在理论上仍可能在芯片中创建数据外泄路径。Private AI Compute 最终依赖于 Google 经过加固的 TPU 平台按其所述方式运行。

这一限制广泛适用于机密计算。安全隔离区可减少对虚拟机监控程序、管理员和遭入侵主机软件的暴露，但无法让物理计算完全不需要信任。

侧信道攻击带来另一项担忧。这类攻击会从时序、内存访问、资源争用或功耗等可观察行为中推断受保护的信息。

机密计算平台不断增加缓解措施，但新的硬件漏洞可能改变此前的安全假设。因此，系统的隐私论证必须随威胁态势发展而演进。

隔离区内的软件也可能出错。即使底层存储仍受到加密保护，模型或支持服务也可能通过输出暴露敏感细节。

提示词注入带来相关挑战。恶意内容可能操纵助手，令其检索或披露用户原本无意在该情境下分享的信息。

隔离区无法自动判断某项请求是否反映用户的真实意图。它只会按照开发者实施的策略，执行获授权的软件。

持久化上下文提高了风险，因为一次遭入侵的交互中可能会有更多信息可供获取。访问控制必须限制每项功能能够检索哪些记忆。

系统还需要防范从元数据中进行推断。存储大小、访问频率、设备时序和网络模式，都可能在不暴露记忆精确内容的情况下泄露信息。

Google 先前的架构包含 IP 隐匿中继，旨在将用户身份与请求分离。持久化系统必须在记忆读取和更新过程中保留类似保护。

研究人员已提出更开放的机密 AI 路径。2026 年的 OpenPCC 论文认为，Google 和 Apple 的早期系统高度依赖专有基础设施。

其作者使用商用可信执行环境构建了一个开源原型。他们的批评凸显了 Google 面临的一个关键验证问题。

外部研究人员需要获得足够的代码、度量值和工具，才能检验有实质意义的隐私声明。仅有公开日志并不能实现完全可复现性。

Google 表示将发布更新后的架构细节、安全证明、验证协议和审计结果。这些披露的深度将决定研究人员能在多大程度上独立评估记忆层。

因此，用户应将“即使 Google 也无法访问”理解为由多层控制措施支撑的安全目标。它并不意味着无需信任 Google。

该架构减少了能够查看个人上下文的人员和系统数量。它也让未经授权的访问在技术上更困难、更容易被发现。

这比主要依靠政策和管理员访问控制保护的普通云数据库具有更高标准。但它仍不等同于将所有信息保留在断开连接的硬件上。

Apple 的无状态模型如今是主要参照

Google 押注于：私有持久化能够胜过严格遗忘，同时不会削弱用户实际的隐私边界。

Apple 的 Private Cloud Compute 提供了最清晰的对照。Apple 围绕无状态处理、受限的管理访问、不可定向性和可验证的软件透明度构建 PCC。

其安全架构称，用户数据不应在请求完成后保留。节点数据卷的加密密钥会在重启时更换，且不会被保留。

Apple 还从 PCC 节点中移除了交互式调试工具和通用日志记录功能。其公开模型将无法保存用户数据视为一项可强制执行的属性。

Private AI Compute 推出时，Google 在很大程度上也秉持这种无状态理念。如今，持久化的服务器端记忆在两种路径之间形成了明显分歧。

Apple 的模型尽量减少持久的云端状态。Google 的新设计则接受持久的加密状态，因为它认为跨设备连续性对个人 AI 至关重要。

两种立场都无法解决所有问题。无状态处理能防止长期累积，却限制助手自然地继续先前工作的能力。

持久化加密记忆支持更丰富的个性化。它带来了涵盖创建、检索、修改、传输、保留和删除的更大生命周期。

这种比较并不只是 Google 对比 Apple。它代表了对于私有云 AI 应当保证什么的两种定义。

一种定义认为，私有计算应在每次任务后遗忘。另一种则认为，它应当记住，但只能通过用户设备授权的密钥和软件来实现。

Apple 还将 PCC 扩展到 Google Cloud 基础设施上，以处理高要求工作负载。它表示，Apple 设备仍只信任经 Apple 加密批准的软件。

这一合作表明，硬件所有权和隐私控制并不总是属于同一机构。软件证明可让一家公司在另一家公司的基础设施上执行要求。

不过，Apple 仍将 PCC 描述为无状态。Google 的持久化层因此超出了 Apple 所提出的核心保障属性。

这种差异将通过产品行为变得具体可见。无状态助手每次进入云端时，都需要从设备或单独的用户控制存储中获取上下文。

Google 的方法则允许受保护的云端环境在设备授权后直接检索此前的上下文。这可能减少延迟、重复传输以及产品之间的断层。

它也可能增加对 Google 记忆格式和设备注册系统的依赖。用户可能会发现，针对内部助手优化的历史记录难以检查或迁移。

公告没有涉及可移植性，也未说明标准导出格式、保留默认设置，或在其他地方运行兼容记忆服务的能力。

这些问题与竞争的关系不亚于隐私。一项有用的记忆会成为会随时间增值的个性化资产。

若该资产始终绑定于一个助手，切换服务就意味着失去累积的上下文，或在迁移过程中暴露它。加密本身并不能防止锁定效应。

Google 可通过向用户提供清晰的检查、导出、更正和删除控制来强化自身立场。它还可以说明用户更换设备或账户时，记忆将如何迁移。

与此同时，Apple 面临证明其无状态设计能够提供可比连续性的压力。它可能更多依赖加密的设备存储，并仅为每项请求同步所需的最少上下文。

其他助手供应商面临同样的选择：将记忆保留在常规账户数据库中，采用机密基础设施，或将长期上下文留在用户控制的设备上。

Google 的设计让面向高度个人化助手的普通服务器端存储显得更难辩护。一旦更强的控制措施已存在，重视隐私的用户就可以追问，为何竞争对手没有采用它们。

用户和研究人员接下来应关注什么

该架构将通过已部署的控制措施和外部审查赢得信任，而非仅凭其示意图。

第一个信号是产品推出情况。Google 需要明确哪些 Gemini 体验使用持久化 Private AI Compute 记忆，哪些仍在使用其他存储系统。

应有清晰可见的标识告知用户，请求何时进入受保护环境。Google 已在受支持的 Pixel 设备上提供 Private AI Compute 网络信息。

持久化记忆同样需要明确的控制措施。用户应能看到保留了什么内容、为何被检索，以及哪台设备授权了该操作。

这一界面将揭示 Google AI 记忆隐私是否能在安全论文之外被理解。隐藏或过于宽泛的记忆会削弱该架构的实际价值。

第二个信号是独立验证。研究人员需要可用的软件记录、检查工具、证明证据以及新记忆组件的文档。

Google 的透明度日志应覆盖每一个能够检索或更新持久化上下文的安全关键服务。部分覆盖可能使重要代码处于公众审查之外。

未来评估应测试已部署的记忆路径，而不只是早期的无状态基础设施。它们应考察密钥处理、设备注册、删除、恢复以及抵御恶意输入的能力。

公开漏洞研究的重要性将超过已发布文件的数量。可信的发现、修复和披露时间线，将展示平台在压力下的表现。

第三个信号是竞争层面的回应。Apple 对无状态处理的承诺，如今构成了可据以评判 Google 设计的清晰替代方案。

如果 Google 能在没有实质性隐私失误的情况下提供有用的跨设备连续性，严格无状态模式可能开始显得不必要地受限。竞争对手将面临加入受保护持久化能力的压力。

如果恢复、删除或验证过程被证明不透明，那么 Apple 的“遗忘优先”架构将获得支持。同样的结果也会有利于将记忆保留在本地的助手。

企业采购方还应关注 Google 是否会将该系统调整用于组织数据。个人设备密钥并不能很好地对应员工流动、法律留存要求或共享工作区等场景。

企业可能需要管理员恢复记录或撤销访问权限。这些要求可能与“即使服务提供商也无法解密已存储上下文”的承诺产生冲突。

开发者应审视最终的访问模型。私有记忆层需要严格限定权限，以避免某一应用获取为无关用途创建的上下文。

用户不应假设每项 Google AI 功能都会自动获得这些保护。Private AI Compute 是一种特定架构，并非适用于所有云端处理的通用标签。

产品文档必须说明该系统何时启用，以及其不可用时会发生什么。若请求在未明确告知的情况下转移至保护较弱的服务，回退行为可能会削弱隐私保障。

Google Private AI Compute 的记忆功能解决了私有云助手的一个真实弱点。无状态系统通过遗忘来保护用户，但难以支持跨设备的持续工作。

Google 的替代方案在技术上雄心勃勃，在理念上却很直接：将上下文远程存储，将密钥留在用户手中，并且只在经过验证的软件内部进行解密。

真正困难的部分，始于这一设计离开示意图之后。账户恢复、设备迁移、访问边界、透明度、删除机制以及软件缺陷，都将决定其实际隐私水平。

对用户而言，眼下的行动很简单：关注未来的 Gemini 记忆功能是否明确标注 Private AI Compute、是否展示保留的上下文，以及是否提供直接删除控件。

对研究人员而言，测试标准更为严格：独立专家能否验证生产环境的软件、复现信任链，并在攻击者之前发现有意义的弱点？

Google 提出，云端助手不再需要在记忆与隐私之间二选一。接下来的版本必须证明，安全的服务端记忆能否长期兑现这一承诺。