---
service: "Publicasta"
schema_version: "1.0"
article_id: 762
title: "Google 可验证的联邦学习，正在改变 AI 买家的隐私问题"
language: "zh"
default_language: "en"
canonical_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=zh"
json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=zh"
api_url: "https://publicasta.com/api/public/v1/channels/ai_practice/articles/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=zh"
channel_url: "https://publicasta.com/api/public/v1/channels/ai_practice"
channel_articles: "https://publicasta.com/api/public/v1/channels/ai_practice/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-10-04T10:24:55+00:00"
updated_at: "2026-10-04T10:24:55+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=ar"
    markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=ar"
    json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=de"
    markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=de"
    json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=en"
    markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=en"
    json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=es"
    markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=es"
    json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=fr"
    markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=fr"
    json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=pl"
    markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=pl"
    json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=ru"
    markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=ru"
    json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=zh"
    markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=zh"
    json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=zh"
---

# Google 可验证的联邦学习，正在改变 AI 买家的隐私问题

> Google 基于 TEE 的联邦学习系统，让服务器端隐私声明更容易被审计。对处理敏感数据的团队而言，关键不只是数据是否留在原处，还要确认哪些行为由技术强制、哪些只是承诺，以及系统仍可能泄露什么。

Google 最新的联邦学习工作很容易被归入基础设施研究。如果只这样理解，就会错过其中的实际意义。真正重要的变化，并不只是模型可以在手机或不同机构各自保管的数据上学习，而是服务器端训练过程开始被设计成可供外部检查：哪些工作负载获准运行、软件身份是否经过验证，以及最终是否只释放匿名化输出。

 ![社论式可视化：手机与机构数据节点将加密数据发送到经过证明的安全计算飞地，用于保护隐私的联邦学习。](https://publicasta.com/storage/projects/8/pages/762/2026/10/d3e4cd7a-818f-4aa7-8478-47402f347374.webp)

 10 月 2 日，Google Research 宣布了一套基于可信执行环境（TEE）、公开透明日志、加密上传和差分隐私的新联邦学习系统。Google 表示，这套系统已经用于 Gboard 的英语和日语下一词预测模型；与此前的方案相比，它能够更快完成训练，并改善隐私与模型效用之间的平衡。配套论文介绍了该架构及其生产部署。

 这并不意味着联邦学习突然成为所有私有 AI 场景的通用答案。但它确实把采购讨论从一个熟悉的承诺——原始数据留在原处——推向了更难回答的问题：数据到达训练服务之后，组织能否证明该服务被允许对数据做什么？

 对于考虑在敏感文本、健康信息、金融记录、工业遥测数据，或机构之间共享的数据上使用 AI 的企业来说，这个区别很有价值。系统即使避免建立集中的原始数据仓库，仍可能通过更新、日志、参与模式、模型行为或薄弱的运营控制暴露信息。隐私是整个工作流的属性，不是给架构贴上一个流行名称后自然获得的结果。

 ## Google 实际宣布了什么

 联邦学习把模型训练的一部分分散到多个客户端。在常见的设备端设计中，手机或其他终端利用本地数据计算更新，将受保护的更新发送给协调器，然后接收修订后的模型。服务提供商不必把原始样本收集到一个传统训练数据库中。根据 Google 的[研究公告](https://research.google/blog/toward-provably-private-learning-from-federated-data/)，Google 于 2017 年引入了这种方法，并将其用于 Gboard 下一词预测、Smart Compose、回复建议和 Smart Text Selection 等功能。

 新设计改变了部分高成本工作发生的位置。客户端设备上传加密后的训练样本，服务器端 TEE 则执行训练程序。TEE 是一种由硬件支持的隔离环境，目标是在计算进行期间保护代码和数据的机密性与完整性。它还可以支持远程证明：在释放密钥或数据之前，验证者可以检查某个获批准的工作负载是否正在运行。

 Google 将这一能力与访问策略结合起来。策略规定哪些服务器端工作负载可以处理上传内容。设备会在发送加密数据前授权该策略，而密钥管理服务只会向符合策略的工作负载释放解密密钥。Google 表示，这些策略会发布到 Rekor 公开透明日志中，让审计人员能够观察设备可能参与了哪些服务器端工作负载。

 该系统还使用由 TEE 托管的密钥管理服务、一个根处理 TEE、用于并行任务的工作节点 TEE，以及用于容错的加密恢复状态。训练逻辑通过 Federated Language 表达。这是一种开源编排语言，源自 TensorFlow Federated。工作负载运营者按设计只能获得指标和经过差分隐私处理的模型权重，而不是单个训练样本。

 这比产品宣传册中的隐私声明提供了更具体的控制面。问题不再只是供应商是否表示自己不会查看数据，而是数据是否只能由经过证明的工作负载解密，获准运行的工作负载是否有记录，构建过程能否复现，以及释放机制是否限制了受保护环境之外的信息。

 ## “数据从未离开”为什么一直不够

 联邦学习常被概括为“把模型带到数据所在的地方”。这个说法有助于解释基本概念，却会掩盖多种失效路径。

 训练更新可能包含生成它的样本信息。聚合服务可能在合并更新之前查看单个更新。恶意或已经被入侵的协调器可能修改训练代码。日志可能暴露谁参与了训练、何时参与，或某个特定人群贡献了多少次。若发布模型缺少足够的隐私保证，攻击者可能从模型中推断训练集的某些内容。即便某种中间结构表面上受到保护，在反复查询或与外部知识结合后，也可能泄露信息。

 因此，保护隐私的联邦学习通常需要组合多种技术，而不是依赖单一机制。安全聚合可以阻止协调器看到单个客户端更新，但它本身不能保证最终模型不会泄露信息。差分隐私为个人或群体数据对发布结果的影响增加形式化限制，但效用损失取决于工作负载、数据量、采样设计和隐私预算。TEE 可以保护飞地内部的代码与数据，却不会自动消除硬件漏洞、侧信道、实现错误、密钥管理失败，或过于宽松的工作负载权限。

 Google 公告的重要性，在于它试图把这些层次连接起来。TEE 负责执行和密钥释放；策略与透明日志提供审计轨迹；差分隐私限制发布的模型权重；可复现构建则提供了比较源代码与已部署二进制文件的路径。设计目标是减少对运营者的信任，同时让剩余假设变得可见。

 其中的限制同样重要。Google 自己也说明，TEE 保证受到当前一代技术能力的限制。公司还表示，当专有模型架构或预处理细节以动态方式加载时，与隐私相关的逻辑必须继续硬编码在 Python 训练程序中。这构成了审计人员需要理解的边界：生产工作负载中的每个参数或组件，不一定都像隐私机制本身那样容易审查。

 ## 从信任服务器转向验证工作负载

 传统的托管式 AI 采购通常会询问：供应商把数据存在哪里，保留提示多久，是否使用客户内容训练模型，以及哪些管理员能够进入环境。这些问题仍然必要。但当服务需要对加密或分布式数据执行计算时，它们还不够。

 更严格的审查会追问：服务在技术上被阻止做什么？例如：

 - 哪些确切程序被授权解密和处理数据？
- 客户或独立审计人员能否在释放密钥之前验证工作负载身份？
- 一次训练运行的授权策略是否不可变，还是有特权的运营者可以在之后修改？
- 策略变更是否写入公开或客户可见的透明日志？
- 训练二进制文件是否能够根据审计人员可以检查的源代码进行可复现构建？
- 每个阶段会释放什么信息：单个更新、聚合更新、指标、检查点、嵌入，还是只有最终模型？
- 使用了什么差分隐私核算方式？它是否覆盖长期反复发布的结果？
- 工作节点失败、恢复快照还原，或模型回滚时会发生什么？

 这些是运营问题，不是理论装饰。能够精确回答这些问题的系统更容易治理，因为它的声明可以和具体证据相互核对：签名二进制文件、证明记录、密钥释放日志、隐私账本、源代码仓库和事故处理流程。只用一般性的保密保证来回答，则意味着客户仍然依赖供应商内部流程。

 Google 的设计使用 Rekor 作为透明日志，并表示密钥管理服务与数据处理二进制文件可以根据 Confidential Federated Compute 仓库中的开源代码进行可复现构建。这并不等同于对每个部署环境开展独立审计，但它至少给审查人员提供了一条比政策段落更有用的路径：检查被允许运行的工作负载，并将实现与公开设计进行比较。

 这类似于加密数据库与可验证数据访问策略之间的区别。加密可以在某些状态下保护内容；策略说明谁可以访问内容以及出于什么目的；验证则让另一方有机会检验系统是否遵守策略。成熟的隐私工程需要三者。

 ## 将计算移回服务器的实际收益

 Google 公告中最反直觉的部分，是更强的隐私保证可能伴随更多服务器端计算。早期联邦系统高度依赖设备可用性、本地计算能力、网络条件，以及与其他任务之间的资源竞争。如果一批有价值的设备不可用，训练轮次就可能耗时更长，或产生更弱的结果。

 Google 表示，早期某些 Gboard 联邦学习模型需要一到两个月才能完成训练。新架构先收集加密上传内容，再在受保护的工作负载内部选择服务器端参与计划。这样，系统可以在观察到设备可用性后优化设备选择和差分隐私参数，而不是让训练节奏完全由哪些手机恰好在线决定。Google 报告称，目前的瓶颈是 TEE 资源可用性，而不是设备端计算。

 这是一个有意义的工程取舍。把计算保留在终端，可以减少中央服务看到的内容，但也会限制模型规模、算法选择、能耗和调度。将计算转移到受保护的服务器环境，可能让训练更可预测，并支持更大的模型。隐私方面的结论取决于该环境周围的保护：证明、密钥释放、策略执行、输出控制，以及针对硬件的威胁模型。

 对于企业来说，这意味着“联邦”不应被当作“设备端”的同义词。生产系统可能包含分布式数据收集阶段、加密传输阶段、服务器端机密计算阶段，以及差分隐私发布阶段。每个阶段都有自己的失效模式和成本结构。

 ## 差分隐私能贡献什么，又不能解决什么

 差分隐私是一套量化隐私损失的数学框架。NIST 的[《SP 800-226》](https://csrc.nist.gov/pubs/sp/800/226/final)将其描述为一种分析某个实体的数据是否存在会如何影响输出的方法，同时也提醒实际实现包含多种风险和设计选择。

 在实践中，差分隐私训练系统会限制某个参与者的数据对发布结果的影响幅度。常见机制会裁剪单个更新的影响，并加入经过校准的噪声。较小的隐私预算通常意味着更强的形式化保证，但噪声过多会降低准确率。取舍受参与者数量、数据重复使用方式、隐私单位——记录、用户、设备或组织——以及发布输出数量的共同影响。

 最后一点很容易被忽略。一个模型可能只对一次训练运行提供隐私保证，但一系列检查点、分析面板、实验或模型变体都会继续消耗隐私预算。组织需要的是账本和发布策略，而不仅是研究论文中的一次性 epsilon 数值。组织还需要明确保护谁的隐私。用户级隐私与事件级隐私是不同的主张；保护一次按键，不等于限制某个人数月以来贡献的全部数据对结果的影响。

 差分隐私也无法解决训练前的数据治理问题。它不能决定组织是否拥有合法的数据收集依据，不能决定人们是否被告知数据用途，不能判断标签是否公平，也不能保证生成的模型适合部署。它不会自动阻止一个获授权的工作负载学习错误目标。它是对输出信息泄露的约束，不是目的限制、访问控制、保留规则或明确删除流程的替代品。

 因此，买家真正应该问的不是“这个系统使用差分隐私吗？”而是：“隐私单位是什么，预算是多少，哪些发布会消耗预算，谁负责审计核算，以及在我们的任务上测得了多大的效用损失？”

 ## TEE 能帮助什么，信任仍然留在哪里

 TEE 可以减少在处理期间信任云运营者接触明文数据的必要性。对于必须执行计算、但客户不希望普通主机管理员、相邻租户或服务运营者查看数据的工作负载来说，这很有价值。远程证明可以把密钥释放决定与经过测量的软件身份连接起来。

 但 TEE 不是万能的隐私盒子。买家至少应继续追问以下问题。

 第一，哪些硬件和固件属于范围？TEE 依赖处理器特性、固件、加密密钥和供应商安全更新。威胁模型可能排除某些特权角色，或假设特定侧信道无法被利用。

 第二，哪些代码会被测量和证明？答案应包括运行环境、密钥管理逻辑、训练程序、相关库，以及任何动态加载的组件。如果只测量一个小型启动器，而重要的隐私逻辑之后才被获取，那么证明声明的范围可能比听起来更窄。

 第三，秘密如何释放？密钥管理应当绑定到获批准的工作负载和明确的策略。能够绕过该决定的人类管理员，即使正常路径受到密码学限制，也属于威胁模型的一部分。

 第四，元数据能够推断出什么？时间、群体成员关系、请求大小、失败模式和发布时序，即使在载荷加密后仍可能携带信息。隐私审查应覆盖每个参与者能够看到的流量和运营元数据。

 第五，事故响应期间会发生什么？主机遭到入侵、测量值被撤销、飞地存在漏洞，或构建流水线被破坏时，系统需要有实际可执行的响应：停止释放密钥、轮换密钥、使工作负载失效、保留证据，并判断此前发布的输出是否仍然可信。只有在一切正常时才具备隐私的系统，还没有准备好用于敏感生产环境。

 NIST 早期关于隐私保护联邦学习的指导，从另一个角度说明了同一原则。在讨论私有集合求交和布隆过滤器时，NIST 指出，用于对齐数据的技术仍可能泄露匹配信息，而更强的保护通常会带来性能成本。结论不是拒绝这些技术，而是把它们的泄露纳入威胁模型，并明确决定这种泄露是否可以接受。

 ## 部署准备的阻力不小

 公司无法通过在普通 AI API 中打开一个隐私开关来采用这种架构。真正困难的工作发生在模型训练之前。

 团队必须定义数据所有者、隐私单位、允许的用途、保留期限，以及哪些输出可以离开受保护环境。团队还要决定客户端上传的是样本、梯度、特征，还是其他表示形式。随后，它需要建立或采用证明路径、密钥管理服务、策略格式、透明日志、可复现构建流水线和隐私核算器，并测试恢复与撤销流程。机密计算与法律或合同义务之间的关系也必须被记录下来。

 工程范围同样远不止一份模型训练脚本。生产部署需要客户端库、注册和更新机制、密码学身份、工作负载调度、不会过度收集敏感元数据的可观测性、软件供应链安全控制，以及把已测量部署与经过审查的源代码相互比对的方法。已经运营移动基础设施、设备群、机密计算集群或受监管数据管道的组织，比从单个笔记本开始的团队更适合承担这项工作。

 成本会出现在多个地方。TEE 需要兼容硬件，可能减少可用容量，或让加速器访问更加复杂。证明和密钥管理服务会增加运营依赖。公开日志和可复现构建要求发布流程更加严谨。差分隐私可能要求更多参与者、更多轮次或更多数据，才能达到可接受的准确率。审计和红队测试也会成为持续成本，而不只是上线前的一次性工作。

 当集中化数据会造成不可接受的法律、安全或合同风险时，这套架构仍可能比集中数据更便宜。但它并不会自动比传统训练更省钱。正确的比较对象，是一个成功且合规的模型所需的总成本：基础设施、工程、审计、性能损失、事故准备，以及保留那些无法以普通形式汇集的数据访问权所带来的价值。

 ## 哪些组织适合尝试

 当数据因为某种实际原因而分散，且学习任务能够从多个参与方的信号组合中获益时，这种模式最有前景。例子包括设备个性化、跨组织欺诈检测、机构无法共享原始记录时的临床研究，以及必须由本地保管的工业或现场数据。

 如果组织反对集中训练的原因并非单纯偏好供应商，而是存在明确的暴露风险——合同禁止、敏感人群、监管限制，或来自内部人员与遭入侵基础设施的可信威胁——那么它尤其值得考虑。在这些场景中，可验证的工作负载授权可能实质性改变风险评估。

 当买家需要向审计人员或合作伙伴给出可辩护的答案时，这种方案也值得评估。透明日志、可复现构建、证明记录和隐私账本能够形成事后可审查的证据。这些证据未必能解决所有问题，但可以改善工程、安全、法务和数据所有者之间的讨论质量。

 小规模试点应从隐私单位和成功指标都清晰的任务开始。下一词预测是一个方便的例子，因为系统可以在重复训练轮次中衡量准确率、训练速度、参与情况和隐私核算。企业应选择类似边界清楚的工作流：范围有限的分类问题、数量受控的参与机构，以及明确的发布节奏。试点应将受保护设计与传统基线进行比较，并报告效用、延迟、成本、泄露风险和运营负担。

 ## 哪些组织暂时应跳过

 如果组织根本没有分布式数据问题，就不应优先从这套架构开始。如果所有相关数据都已经获准集中使用，一个控制良好的私有云或隔离训练环境可能更容易保护和解释。联邦学习会增加协调和密码学机制，它并不会默认带来隐私升级。

 当数据过于稀疏或分布过于不均，无法支持有用训练时，它也不合适。差分隐私需要参与和谨慎核算。只有少数贡献者的系统，可能拥有形式化保证，却生成过于嘈杂、有偏或不稳定而无法部署的模型。

 无法运营软件供应链、密钥管理系统或事故响应流程的组织，不应把基于 TEE 的设计当作捷径。机密计算会转移责任，而不是消除责任。如果团队无法检查工作负载变更、撤销密钥、跟踪隐私预算或调查元数据泄露，那么这套架构可能制造出更复杂、也更难治理的故障。

 最后，当期望输出是对个人作出高影响决策时，团队应保持谨慎。隐私保护无法解决歧视、可申诉性、数据质量或人工复核需求。一个私密模型仍然可能作出不公正的决定。

 ## 可验证私有训练的买家清单

 在注册任何联邦学习服务之前，要求供应商书面回答以下问题，并尽可能附上证据：

 1. **究竟什么是私有的？** 这项保证针对原始输入、单个更新、用户级贡献、最终模型，还是覆盖所有这些对象？
2. **威胁模型是什么？** 是否包括服务运营者、云管理员、遭入侵的客户端、恶意参与者、串谋方和硬件攻击？哪些攻击明确不在范围内？
3. **哪些控制由密码学或硬件强制？** 将合同承诺与能够阻止运营者读取数据或更改工作负载的控制分开。
4. **证明如何工作？** 要求查看被测量的组件、验证流程、密钥释放条件和撤销机制。
5. **隐私逻辑能否审计？** 询问源代码、依赖项、构建过程、策略文件和已部署测量值是否可以检查。
6. **隐私预算如何计算？** 确认隐私单位、核算方式、跨发布的组合规则、采样假设，以及重试和恢复的处理方式。
7. **什么内容会离开受保护环境？** 范围应包括指标、检查点、嵌入、错误、日志、时序数据、群体统计和支持材料。
8. **参与会暴露什么？** 判断协调器或其他参与者能否推断某个设备、员工、组织或患者群体参与了训练。
9. **模型出错时怎么办？** 隐私和效用测试应包含子群体表现、分布漂移、投毒抵抗能力和回滚方案。
10. **目标规模下的成本是多少？** 对 TEE 容量、存储、密钥管理、日志、审计工作、客户端更新、重试以及更强隐私带来的准确率成本进行定价。

 如果供应商无法回答这些问题，该服务或许仍适合低风险实验，但不应被当作敏感生产数据的已验证控制措施。

 ## 对 AI 采购更大的启示

 Google 的公告并不是在宣告可信硬件已经解决了私有机器学习。它表明，隐私边界正在变得更具运营性。系统的价值来自多种机制的连接：加密接收、受约束的密钥释放、经过证明的执行、可审计策略、可复现软件、差分隐私和受控发布。缺少其中任何一项，隐私声明的范围都会变窄。

 这种变化也会改变企业应当衡量的内容。隐私保护型 AI 项目不应只报告模型准确率和基础设施成本，还应报告谁能够看到什么、哪些工作负载获准运行、释放了多少信息、隐私预算如何变化、系统在故障期间如何表现，以及独立审查人员能够验证哪些证据。

 这比“我们不会用你的数据训练模型”更严格，但也更有用。当数据所有者能够检查获准的计算，运营者无法静默替换另一套工作负载，最终输出又携带有记录的隐私成本时，分布式学习的承诺才真正可信。

 对 AI 买家来说，眼下的建议很简单：把联邦学习当作系统设计和采购决策，而不是模型功能。先定义必须保护的信息、不能信任的参与方，以及审计人员需要看到的证据；再检验拟议架构是否真的执行了这些边界。Google 新的 Gboard 部署表明，这种方法可以在生产规模上实现。对其他组织来说，更难的问题是：隐私收益是否值得承担这套复杂机制，以及组织是否准备好诚实地运营它。

 ## 来源

 本文依据并翻译改编以下来源：

 - [Toward provably private learning from federated data](https://research.google/blog/toward-provably-private-learning-from-federated-data/)，Google Research，事实来源，发表于 2026 年 10 月 2 日。
- [Toward provably private learning from federated data](https://arxiv.org/abs/2609.31494)，arXiv，事实来源，发表于 2026 年 9 月 25 日。
- [SP 800-226: Guidelines for Evaluating Differential Privacy Guarantees](https://csrc.nist.gov/pubs/sp/800/226/final)，美国国家标准与技术研究院，背景资料，发表于 2025 年 3 月 6 日。
- [Protecting Model Updates in Privacy-Preserving Federated Learning: Part Two](https://www.nist.gov/blogs/cybersecurity-insights/protecting-model-updates-privacy-preserving-federated-learning-part-two)，美国国家标准与技术研究院，背景资料，发表于 2024 年 5 月 2 日。