「数据不出域」怎么被证明：Google TEE 联邦学习带来的验收口径

供应商在合同里写"数据不出域"很容易，难的是合规审计当天拿得出物证。2026 年 10 月初 Google Research 公布的下一代联邦学习系统，刚好给了一套可以照抄的验收思路。

Google 这次把"匿名化"做成了可核对的证据链

2026 年 10 月 2 日至 3 日，Google Research 公开了下一代联邦学习系统：训练逻辑被搬进可信执行环境（Trusted Execution Environment，TEE）里运行，官方给出的是"可验证、可审计"的数据匿名化保证，而不再只是隐私承诺。Gboard 的英语与日语"下一词预测"已经迁到这套系统上，训练周期相比过去每次 1 至 2 个月明显缩短。国内的 AI 行业早报与科技自媒体在 10 月 3 日前后对这条发布做了集中报道（微信公众号报道聚合）。

但真正值得企业 IT 决策者抄的，不是"用了 TEE"这四个字。联邦学习的思路早就成熟——数据留在本地、只上传梯度——问题从来不在架构，而在于外人没办法核实服务端到底有没有偷看、有没有落盘。Google 这次做的，是把过去只能靠合同和信任兜底的三件事，变成了可以被第三方独立核对的物证。

证据一：透明日志 Rekor，"谁能碰数据"是公开可查的

系统把访问策略发布到公共透明日志 Rekor。Rekor 是 Sigstore 体系里的签名透明日志，它构建在一个可验证的数据结构之上，审计方可以持续监控日志的一致性——确认它只增不改、条目永不被篡改或删除（Sigstore Rekor 文档）。翻译成验收语言：过去"这条数据只有 A 服务能读"是供应商的口头声明；现在它是一条写进公共账本、任何人都能回查的记录。

证据二：可复现构建，二进制能被外部重放

系统提供从开源代码可复现构建（reproducible build）的二进制。这条的价值经常被低估：如果跑在飞地里的程序只有厂商能编译，那么"我审计过源码"就没有意义，因为你无法证明线上跑的正是你审计过的那份代码。可复现构建把"源码 = 线上二进制"这个等式交到了外部审计者手里。

证据三：TEE 度量与远端证明，证明代码确实跑在飞地里

飞地内部运行的程序代码全面支持高精度的远端证明（remote attestation）。配合飞地内的密钥管理——只有访问策略里写明的工作负载才能拿到解密密钥——运维方和算力提供方理论上只能看到指标和经过差分隐私处理的模型权重。这也正是机密计算的通用定义：用硬件级的隔离执行环境（Intel TDX、AMD SEV、ARM TrustZone 等），让连虚拟化层和云厂商都无法窥探运行中的负载（Confidential Computing Consortium）。

需要给这套叙事泼一盆冷水：Google 自己也写明，当代 TEE 仍然存在侧信道等局限，"可证明隐私"是一条持续演进的路，不是终点。任何把 TEE 说成"绝对安全"的厂商，都值得你在技术尽调里多问两句。

迁移到企业知识库 AI：私有化交付的五个验收项

你不必自建 TEE 训练系统，但这套"用证据代替承诺"的口径可以直接搬进采购与验收清单。以下五项建议逐条写进私有化交付合同，并明确各自要交付什么：

1. 数据流向清单与驻留位置。要求供应商给出数据流图，标明每一跳的存储位置（境内/境外、哪个可用区），尤其要分清向量库、日志、缓存、微调数据分别落在哪。驻留位置要能对应到具体区域，而不是一句"境内"。
2. 训练与推理环境的区隔。推理环境按在线服务治理，训练/微调环境应当是独立网络域与独立凭证。企业级 AI 基础设施的实践已经说明，运行时隔离、网络隔离与身份隔离需要分层建设，传统容器隔离无法单独承担完整安全边界（InfoQ：企业级 Agent Infra 架构实践）。
3. 密钥托管与轮换。明确根密钥由谁托管、解密密钥能发给哪些工作负载（对照 Google 的访问策略机制），并给出轮换周期与至少一次轮换演练记录。密钥在谁手里，等于数据在谁手里。
4. 审计日志留存期。日志要覆盖"谁在什么时间、以什么身份、访问了哪份数据"，留存期需满足你所在行业的合规要求，且日志本身要防篡改——能进透明日志或独立只读存储更好。
5. 供应商退出后的数据处置证明。要求交付可核验的删除/销毁证明，而不是一封"已删除"的邮件。这一项在续约或更换供应商时最容易翻车。

这篇不碰切片与召回：和 RAG 架构篇的分工

站内已经用文章讲透了 RAG 的工程侧——切片策略、召回调优、常见坑与修复。本篇刻意不重复那些内容，只谈隐私层：数据在物理与逻辑上如何被约束、约束如何被证明。如果你还没定 RAG 的整体工程路径，建议先读《企业知识库 AI 私有化部署：RAG 落地的 6 个工程决策》；如果已经踩过召回坑，可以对照《企业知识库 AI 检索不到内容？RAG 落地最常见的 6 个坑与修复路径》。前者解决"怎么落地"，这篇解决"怎么证明数据没跑出去"。

为什么召回质量不在这篇射程内

因为它们是两个不同的失败模式：召回差导致"答不准"，隐私层缺失导致"答对了但数据违规了"。前者丢的是体验，后者丢的是合规资格。两件事的验收人、验收物、验收时机都不一样，混在一篇里只会两边都讲不透。

反面教训：合同写了"不出域"，审计时拿不出一件验证物

真实场景里最常见的翻车方式是这样的：合同白纸黑字写着"数据不出域"，供应商也确实做了本地化部署，但审计方一到现场就问三个问题——数据流经哪些组件？谁能解密？删除怎么证明？——结果一个都答不上来，最终被一票否决。问题不在技术没做，而在于从没想过要把技术动作落成可出示的凭证。

把这条映射回 Google 的做法就清楚了：透明日志、可复现构建、远端证明，本质上都是"把内部动作变成外部可核对的物证"。企业做不到 Google 那么重，但至少要做到——每一条隐私承诺，都能指向一个具体的、可被第三方查看的文件或日志。

什么规模该上 TEE，什么规模先做流程隔离

不是所有企业都该现在去买机密计算实例。可以按下面这条线来判：

判断维度	该考虑 TEE / 机密计算	先做流程隔离与最小权限
数据敏感度	强监管行业（医疗、金融、政务）	中等，无监管硬性要求
是否跨主体	多方联合建模、把数据交给外部模型服务	单主体自用
要证明给谁看	合作方 / 监管，需要第三方可核验	内部审计即可
优先投入	远端证明 + 密钥托管 + 可复现构建	网络分区 + 独立凭证 + 审计日志

一个务实的中间态：先把"证据链"建起来（数据流向清单、密钥台账、审计日志、销毁证明），即使暂时没有 TEE，这套证据本身就能扛住大部分合规审计。如果你同时还在定私有化底座，可以对照站内的开源大模型私有化部署实测与Dify 私有化部署的高可用架构，把"选型"和"取证"两件事分开推进。

常见问题

问：TEE 和我们常说的差分隐私、联邦学习是什么关系？
答：三者解决不同层面的问题。联邦学习决定"数据不离开本地"，差分隐私决定"上传的更新不含个体信息"，TEE 决定"服务端处理过程本身不被窥探、可被证明"。Google 这次是把三者叠在一起用，而不是替换关系。

问：用了 TEE 就等于数据不出域吗？
答：不等于。TEE 保证的是"使用中的数据"未被偷看；数据是否出域还取决于存储、日志、备份的驻留位置。验收时要分开核对，别被一个技术名词覆盖全部承诺。

问：可复现构建对采购方意味着什么？
答：它让你（或你委托的第三方）有能力验证"线上跑的二进制 = 审计过的源码"。没有它，代码审计只能停留在纸面。

问：远端证明需要企业自己验证吗？
答：不一定自己实现，但要在合同里约定"供应商需提供可被第三方核验的证明材料"，并写清证明的格式与获取方式。

问：国内有没有可对标的透明日志或证明实践？
答：Sigstore/Rekor 是开放标准，私有化部署可以自建实例。关键不是用哪个产品，而是"承诺必须对应可出示的凭证"这一条原则。

参考

• Sigstore Rekor 透明日志文档 — https://docs.sigstore.dev/logging/overview/
• Confidential Computing Consortium（TEE / 机密计算）— https://confidentialcomputing.io/
• InfoQ《企业级 Agent Infra 架构实践：从安全沙箱到网络管控与身份治理》— https://www.infoq.cn/article/bLB8RQ6sd3ZGQts0D4tP
• InfoQ《Agent 的记忆不在对话里：把企业数仓沉淀为可治理的共享语义记忆》— https://www.infoq.cn/article/M4mgbKf4RDv5AKTwQvFH
• Google TEE 联邦学习发布的中文报道聚合 — 微信公众号搜索结果

如果你需要针对自有数据的敏感度与合规要求做一次"数据证据链体检"，或者评估企业知识库 AI 的私有化落地路径，蓝曜炬辉 团队可以结合实际交付案例与你一起把验收项逐条对齐。