Google 黑客争论遇上私密 AI，但加密仍需证明自身价值

尽管多年来人们一直质疑这项技术能否高效运行有用的工作负载，Google 仍将同态加密重新带回私密 AI 的竞争中。如今，围绕 Google 黑客的讨论聚焦于一个更棘手的问题：加密计算能否从受控演示走向普通开发者可实际运维的产品？

该公司表示，同态加密可帮助 AI 系统处理敏感信息，而不会暴露底层数据。同态加密是一种密码学方法，允许软件对加密值进行计算。结果会始终保持加密状态，直至获得授权的一方将其解密。

这一承诺直接挑战了标准的云端 AI 模式。大多数服务会在数据传输和存储期间对其加以保护。但当模型真正使用信息时，这些信息往往会在内存中变得可读。

Google 认为，这种暴露已不再是实用 AI 无法避免的一环。如果其方案能够以实际可用的速度运行，开发者便可在无需让服务提供商访问原始输入的情况下执行特定计算。

这一消息之所以受到关注，是因为这个问题几乎影响到所有严肃的 AI 部署。医疗记录、法律文件、财务历史、私人消息和企业内部文件都包含有价值的上下文，但也带来了许多组织无法接受的风险。

Microsoft、Apple、云安全厂商和开源密码学项目都在探索相互交叠的解决方案。其方法包括可信硬件、本地处理、安全多方计算、差分隐私和同态加密。

这场正在形成的竞争并非 Google 与某一家公司的对决，而是加密计算与在受保护环境中处理可读数据这一运营简便性之间的较量。

Google 的私密 AI 推进有哪些变化

Google 正将同态加密定位为 AI 的工程选项，而不只是密码学研究课题。

这一区别至关重要。研究人员多年来一直在研究全同态加密，但其实际采用范围始终有限。这项技术可以对密文进行运算；密文是经转换后不可读的加密数据形式。

客户端可以在将输入发送至服务器前对其加密。服务器无需获得解密密钥，即可执行获准的计算。它返回加密结果，只有客户端或另一名获授权的持有者能够将其解锁。

这种设计建立了不同的信任关系。用户无需信任服务器会妥善处理原始输入。服务器仍会运行计算，但处理的是旨在隐藏底层数值的表示形式。

对于私密 AI，潜在用例很具体。健康应用可以对加密测量值进行分类；金融服务可评估加密账户特征；企业系统可以比较敏感记录，而无需将其可读内容置于通用云环境中。

这并不意味着整个生成式 AI 系统都必须在加密状态下运行。近期部署更可能是在更大工作流中保护有限但高价值的步骤，例如评分、匹配、筛选、聚合和紧凑型模型推理。

这种更窄的范围很重要。对大语言模型中的每项操作进行完全加密，其要求远高于保护一个分类阶段。因此，Google 无需立即解决加密通用生成的问题，也能让私密 AI 更具实用性。

Google 此前已在这一基础上开展工作。其公开的 FHE repository 包含相关工具，旨在帮助开发者表达加密计算，而无需手动实现每一项密码学操作。

这类工具解决了一项障碍：大多数应用开发者并非密码学家。传统同态加密开发要求谨慎决定方案、参数、数值表示和噪声管理方式。

噪声是一种受控的数学失真，会随着加密操作的累积而增长。如果噪声过大，密文可能无法再被正确解密。某些方案会使用引导（bootstrapping），这是一项成本高昂的过程，可刷新密文以便继续进行更多计算。

编译器和更高层级的库可以隐藏部分复杂性。它们可以将熟悉的代码转换为同态方案支持的操作，也能帮助选择在安全性、准确性和性能之间取得平衡的参数。

然而，抽象并不会消除底层成本。编译器可以让加密编程更容易，但无法让每一种算法都同样适合加密。分支逻辑、非线性函数和大型模型架构仍然很难处理。

因此，最恰当的理解是，Google 的变化体现在工程姿态的转变。该公司正将私密计算视为工作负载设计问题。这促使开发者决定 AI 流水线中的哪些环节值得获得更强保护，以及哪些环节可以采用传统基础设施。

为什么 Google 黑客受众正在关注

私密 AI 已发展到这样一个阶段：隐私声明必须说明计算期间发生了什么，而不只是计算前后采取了什么措施。

静态加密保护已存储的文件。传输加密保护通过网络传递的信息。但这两种保护未必能阻止云运营商、被攻陷的进程或恶意内部人员在应用解密数据后查看数据。

随着 AI 产品要求获取更深入的个人上下文，这一缺口变得更加明显。助手在能够访问消息、文档、日历、浏览历史和过往决策时表现更好。同样的访问权限也会扩大数据泄露或过度保留政策的后果。

企业部署也面临类似冲突。公司希望模型分析客户记录、技术文档和机密通信；安全团队则希望严格限制这些信息的流向，以及哪些运营人员能够查看它们。

同态加密提供了一种异常强有力的回答。它试图让特定数据即使在远程机器处理期间也保持加密状态。这一承诺之所以具有吸引力，是因为它减少了对计算提供商的信任需求。

这正是 Google 黑客争论超越密码学性能的原因。开发者正在审视整个系统边界。他们想知道谁创建密钥、密钥存放在哪里、哪些操作在加密状态下进行，以及哪些元数据仍然可见。

元数据仍可能泄露敏感信息。服务可能会观察到请求何时到达、请求有多大、由哪个模型接收，以及处理耗时多久。同态加密不会自动隐藏这些信号。

它也不会验证周边应用是否可靠。有缺陷的客户端可能会加密错误的信息；被攻陷的设备可能在加密前或解密后截获数据；获授权的用户仍可能滥用合法结果。

这项技术只是缩小了一种特定暴露面。它可以阻止不受信任的计算服务读取受支持计算中使用的数值。这很有价值，但并不构成完整的隐私架构。

这种有限的表述有助于区分工程进展与营销语言。私密 AI 产品应明确哪些数据始终加密、哪个组件可以解密，以及服务器能获知什么。缺少这些细节，“私密”这一标签传递的信息很少。

标准可以让这些声明更易评估。行业主导的 homomorphic standard 记录了常见的安全考量和参数选择。共享术语为审查人员比较不同实现提供了基础。

安全性同样取决于实现质量。密码学软件可能通过时序行为、内存访问、错误消息或错误的参数选择泄露信息。数学上可靠的方案并不保证产品安全。

对开发者而言，Google 的参与既带来机遇，也带来审视。该公司可以将密码学整合到编译器、加速器、云服务和开发者工具中。它同时运营着庞大的数据驱动业务，因此明确的隐私边界尤为重要。

因此，这一宣布促使 Google 必须发布超越宽泛承诺的证据。开发者需要可复现的工作负载、威胁模型、源代码、安全假设，以及与现实替代方案的比较。

加密计算正在与可信硬件竞争

这场主要竞争存在于两种路径之间：通过密码学最小化信任，或将信任限制在受保护的硬件中。

云服务提供商已提供基于可信执行环境的机密计算系统。可信执行环境（TEE）会在受硬件保护的区域内隔离代码和数据。

服务器会在该区域内处理可读信息。硬件控制机制旨在防止云运营商、主机操作系统和无关软件检查受保护内存。

这一路径具有实际优势。开发者往往可以用较少的算法改动运行传统软件。为普通处理器设计的模型可能需要适配，但不必将每项操作都表达为加密算术。

同态加密将边界推得更远。远程服务根本无需接收可读输入。只要实现和密钥仍然安全，即使服务器遭到攻陷，所接触的也应是密文而非原始数值。

这一更强属性带来了更高的计算要求。加密值比对应的明文更大。基础操作可能需要大量底层计算。由于加密方案只支持特定数学结构，某些 AI 函数必须采用近似方式。

因此，正确选择取决于威胁模型。如果组织信任硬件厂商并能够验证受保护环境，TEE 可能提供有用的平衡。如果它不能允许远程处理器看到明文，同态加密则具备更明确的优势。

这些方法也可以协同使用。系统可能对最敏感的输入采用同态加密，对周边模型操作使用可信硬件，并在本地完成最终解密。

安全多方计算提供了另一条路径。它将信息分散在多方之间，使其能够联合计算结果，而无需让任何一个参与者看到所有输入。这种方法适用于多个组织持有彼此敏感数据的情境。

差分隐私解决的是另一类问题。它通过加入经过精心校准的随机性，降低输出对任意单条记录的揭示程度。它可以保护聚合统计数据，但与加密推理并不承担相同角色。

私密 AI 很可能依赖多种方法的组合，而非单一通用方法。本地助手可能将个人档案保留在设备上，对远程索引使用加密搜索，并只向模型发送经过最小化处理的提示词。

这一分层模型同样适用于个人知识系统。通过知识融合整理源材料，可以在调用远程服务前先筛选相关上下文，从而减少不必要的数据传输。

Apple 在部分云端 AI 任务上采取了以硬件为中心的路径。其私有云设计描述了专用服务器、可验证软件、数据最小化以及对特权访问的限制。

Microsoft 则通过 SEAL 维持另一条重要的密码学路径；这是一个用于同态加密的库。其文档强调加密算术，而非将这项技术描述为传统计算的通用替代方案。

这些替代方案带来了有益的竞争压力。Google 必须证明，在可衡量的工作负载中，其方法何时优于可信硬件、本地推理或数据最小化。泛泛而谈的隐私主张并不足够。

决定性的比较将包括延迟、吞吐量、内存使用、支持的模型操作、安全假设以及开发者工作量。还必须考虑密钥管理和故障恢复的成本。

这正是 Google 此举的真正意义。它让加密计算在那些过去常默认采用硬件隔离的架构讨论中，占据了更有力的位置。

“实用性”主张仍需经受压力测试

有价值的演示，并不等同于可部署的私有 AI 服务。

“实用”一词可以描述几种不同的成果。它可能意味着某项工作负载如今能在数秒内完成，而不再需要数小时。也可能意味着开发者无需具备专业密码学知识即可编写程序。

它还可能意味着系统能以可接受的基础设施成本运行。这些里程碑彼此相关，但没有任何一个能够保证其他目标也能实现。

一项基准测试可能看起来令人印象深刻，却只覆盖了小规模输入、紧凑模型或异常有利的操作。同一系统在更大批次、频繁请求，或需要昂贵近似计算的函数上，可能会面临困难。

模型准确率带来了另一项限制。许多加密推理系统会用多项式近似替代复杂的非线性操作。这种替换可能影响预测结果，尤其当模型并非为加密执行而训练时。

密钥处理仍然是产品问题。必须有人生成、保护、轮换、备份和撤销加密密钥。如果云服务持有揭示输入所需的全部密钥，原本希望降低的信任需求就可能消失。

客户端设备同样需要恢复方案。丢失密钥可能使加密信息永久无法访问。跨设备复制密钥会提高便利性，但每多一份副本，就多了一道安全边界。

开发者还必须审视输出隐私。服务可能永远看不到加密输入，但详细输出仍可能泄露敏感事实。重复查询有时会暴露比单次响应更多的信息。

因此，访问控制和速率限制仍然不可或缺。同态加密改变的是计算提供商能够检查什么，而不是决定谁应该被允许请求计算。

Google 黑客社区还会关注侧信道防护。服务器可能从请求大小、执行时间、内存行为或故障模式中推断出某些信息。部分泄露可以被减轻，但这会增加复杂性。

密码学参数需要独立审查。一种运行很快的配置，其安全性可能低于预期；另一种配置可能足够安全，却慢到不适用于交互式 AI 功能。

更广泛的领域已经认识到这些挑战。NIST 的隐私增强密码学工作涵盖了旨在支持有用计算、同时限制数据暴露的技术。其框架表明，私有计算包含多个方法家族和安全模型。

独立复现至关重要，因为厂商测量结果可能省略不利条件。研究人员应当能够复现硬件配置、软件版本、模型结构、批次大小、参数集和准确率结果。

开源代码有帮助，但仅有代码可用还不够。基准测试还需要稳定的测试数据和清晰的说明。安全审查人员需要一份明确系统不保护哪些内容的对手模型文档。

生产可靠性构成另一项考验。加密工作负载的故障方式可能不同于普通服务。运营人员需要监控和调试工具，同时这些工具不能暴露加密原本要保护的敏感值。

这带来了真实的矛盾。开发者希望在服务行为异常时具备可观测性；用户则希望日志、追踪和支持工具无法重建其私密输入。

Google 在构建开发者抽象和大规模计算平台方面拥有经验。这使该公司有能力改进围绕这些约束的工具链。但这并不能决定加密 AI 是否能达到用户期望的响应速度。

最稳妥的解读是，实用性正变得依赖于具体工作负载。同态加密不需要胜过明文计算；它需要在那些无法接受可读取云端处理、但又具有价值的任务中变得足够高效。

这一门槛因市场而异。面向消费者的助手可能需要即时响应；如果能提供更强的隐私边界，耗时更长的医疗分析仍可能有用。

最有可能率先部署的场景，或许会具有小规模输入、有限输出、可重复计算以及异常敏感的数据。它们不会像与大型通用模型进行不受限制的对话那样。

Google 黑客开发者应提出的问题

下一阶段应通过架构和测量结果来评判，而不是“私有 AI”这一标签。

第一个问题关乎范围。究竟哪些操作在加密数据上运行？产品应区分加密推理与预处理、检索、日志记录、审核和结果交付。

某个工作流可以宣传同态加密，却在其他环节暴露信息。如果客户端在加密匹配步骤后发送可读取的提示词，那么只有匹配步骤获得了更强保护。

第二个问题关乎密钥所有权。用户需要知道密钥是保留在其设备上、归企业管理员所有，还是会经过托管服务。

托管密钥可以让部署更容易，但也可能重新引入对负责保护或使用这些密钥的提供商的信任。产品的威胁模型应清晰解释这一权衡。

第三个问题关乎性能。开发者应要求端到端延迟，而非孤立的密码学操作。端到端测量包括序列化、网络传输、加密计算和解密。

吞吐量同样重要。能够快速处理一个请求的服务，可能会在大量用户同时到来时变慢。内存消耗和密文膨胀会限制可同时处理的任务数量。

准确率应与速度一同报告。如果加密执行采用了近似计算，相关比较不应只是加密与明文的延迟对比，还应比较二者在同一任务上的准确率。

第四个问题关乎可移植性。开发者可能不希望私有 AI 功能被绑定到单一云、加速器或编译器。开放格式和文档完善的参数能够减少这种依赖。

第五个问题关乎安全审查。密码学构造、库代码、编译器、运行时和密钥管理流程都值得审查。任何一层的失败都可能削弱预期保护。

第六个问题关乎数据保留。密文隐藏了内容，但组织仍需要规定其保存时长。如果密钥泄露或密码学假设被削弱，加密记录日后仍可能变得脆弱。

这对使用寿命较长的高度敏感数据尤其重要。医疗、生物识别、法律和身份信息，在收集多年后仍可能造成损害。

第七个问题关乎模型机密性。同态加密通常侧重保护客户端输入。AI 提供商也可能希望保护专有模型参数不被客户端获取。

某些协议可以同时支持这两个目标，但这样会令系统更加复杂。开发者应询问该设计保护的是输入、模型、输出，还是某种特定组合。

这些问题让 Google 黑客讨论保持务实。该公告的价值取决于它是否能带来清晰、可测试的答案。

私有 AI 成为常态前应关注什么

三个信号将表明 Google 是否已将同态加密带入常规 AI 开发。

第一个信号是可在现实工作负载中复现的性能。开发者应关注包含模型准确率、延迟、内存使用、硬件、加密参数和并发性的基准测试。

一次表现有利的演示，只会在有限范围内增强技术论据。若独立团队能在多种工作负载上复现结果，才会支持 Google 更广泛的实用性主张。

不佳的结果并不意味着同态加密毫无用处。它们只会表明，其近期角色仍局限于隐私价值异常高的专业计算。

第二个信号是融入常规开发工具。当应用工程师无需成为密码学家也能使用某项技术时，它才真正变得实用。他们仍需要安全默认设置和清晰警告，而不是掩盖所有安全决策的抽象层。

编译器应识别不受支持的代码，并在部署前说明性能成本。库应指导参数选择并防止不安全组合。测试工具应比较加密和明文输出。

云集成很重要，但可移植性同样如此。如果 Google 提供托管服务，开发者应关注可导出的代码、已文档化的格式，以及验证远程运行内容的能力。

可用的平台还应支持运营任务。团队需要密钥轮换、审计追踪、错误诊断、容量规划和事件响应。这些功能必须维护隐私边界。

第三个信号是在具有公开威胁模型的真实产品中获得采用。生产部署会迫使公司明确哪些数据获得保护，以及哪些数据仍处于加密边界之外。

最佳的早期案例将涉及组织目前拒绝发送给云端 AI 的信息。在这类场景中的采用将表明，加密计算解锁了一项工作负载，而非只是为现有服务增加隐私措辞。

较弱的信号则可能是一项处理低敏感度数据，或只保护某个次要操作的功能。这仍可带来工程经验，但无法验证最强版本的私有 AI 承诺。

竞争对手的反应将让比较更加清晰。可信硬件供应商可能会改进远程证明，使客户端能够验证受保护机器上运行的软件和环境。本地 AI 系统则可能完全减少对远程计算的需求。

Microsoft 和开源团队可以通过兼容工具和独立基准测试向 Google 施压。Apple 则可以通过主张严格受控的硬件和可验证的云端软件提供了更实用的隐私路径，向其施压。

监管机构和企业客户还会提出另一项检验：加密处理是否会改变合规义务、数据泄露风险、审计要求和供应商风险。密码学保护并不能自动解决这些问题。

更可能出现的结果，并不是可读计算被完全取代。私有 AI 系统将根据敏感性、性能需求和可接受的信任程度来划分工作负载。

有些任务会留在设备端；另一些会在可信硬件中运行；还有一小部分虽规模较小却价值很高的任务会使用同态加密，因为服务器绝不应接收到原始数值。

这使 Google 的公告具有重要意义，但不应将其视为一场已经完成的胜利。该公司正在推动讨论从“加密 AI 是否可行”转向“它在哪些场景值得付出成本”。

Google 的黑客受众如今应当要求看到系统层面的证据。值得关注的是可复现的基准测试、面向开发者的现成集成方案，以及一个此前无法安全存在的生产级工作负载。

如果这些信号出现，同态加密将不再只是一项安全功能。它将让 AI 产品在收集更少可读数据的同时利用敏感上下文。如果没有，“实用的私有 AI”仍将是一项颇具前景、却尚未找到标志性部署场景的主张。