新流程从设备端开始：设备在本地加密训练样本，并附上访问策略，说明哪些服务端工作负载可以解密和处理数据。这些策略会发布到公开透明日志。服务端则由一组 TEE 实现 KMS；在向根 TEE 发放解密密钥之前，KMS 会要求通过远程证明和策略匹配。根 TEE 运行 Python 训练循环，并将并行任务分配给工作节点 TEE。由于明文只会存在于经过证明的 TEE 内，且密钥受到策略约束，审计人员可以追踪从设备上传到 TEE 内处理的整个数据访问过程。

公开访问策略并支持可复现构建，是实现真正审计的关键纽带。审计人员可以检查公开日志条目，了解哪些工作负载获准访问数据；也可以根据源代码独立重新构建 KMS 和数据处理二进制文件，确认其与经过证明的镜像逐字节一致。这大幅缓解了早期服务端联邦学习方案中难以看清内部运作的“黑箱”问题，并建立公开记录，将设备同意、获准代码与 TEE 内运行的二进制文件关联起来。

即便代码执行经过证明且可审计，隐私保障仍取决于对发布内容的限制。Google 的系统仅允许外部看到指标和经过差分隐私处理的模型权重；设备明文数据和中间梯度则始终留在 TEE 内。这种双重保护——机密执行加上发布时应用差分隐私——有助于兼顾实用性与可证明的隐私保障，但前提是经过证明的程序能够正确实现差分隐私，并谨慎调整噪声、参与群体规模和抽样策略。

TEE 能增强机密性和完整性，但并非万无一失。当前一代 TEE 容易受到某些侧信道观测的影响；动态加载外部模块虽然可用于保护专有模型组件，但若缺少严格限制，也会扩大攻击面。Google 承认这些局限，并指出，必须将所有与隐私相关的逻辑保留在可证明的 Python 程序中，只允许将经过充分审计的输入通过外部加载方式引入。审计人员因此不仅要验证经过证明的程序，还应核查外部加载内容的来源及其预期用途范围。

对产品团队而言，这套架构提供了一套清晰可行的方法：无需盲目信任运营方，也能利用敏感数据训练实用模型。具体做法包括公开访问策略、支持可复现构建、通过证明机制控制密钥，并且只发布经过差分隐私处理的输出。审计人员应构建工具，自动比对日志条目、证明结果和重新构建的产物。评估类似设计的组织，则应为 TEE 算力预留预算、投入侧信道缓解措施，并建立治理机制，将设备同意与访问策略的具体含义对应起来。