多云AI部署中的数据主权（第二部分）

多云 AI 部署中的数据主权，已经不再是法律条款里的一个脚注——它是一项架构约束，决定你的模型能在哪里运行、可以用哪些云、以及你能以多快的速度交付。有三股力量在此交汇。其一是监管：欧盟的 GDPR 框架、中国的《个人信息保护法》与《数据安全法》、印度的 DPDP 法案，以及金融与医疗领域的行业规则，都对数据处理施加了基于地理位置的条件。其二是地缘政治：对高端加速器的出口管制意味着你原本以为可以随意调度的 GPU 容量并非通用。其三是 AI 本身：一个在个人数据上训练或推理的模型，把"处理"可能发生的地点成倍放大，因此也成倍放大了你必须回答的合规问题。本系列第一部分讨论过整体格局，这一部分讲到底该建什么。

现实的困境在于，大多数企业发现主权问题的时间太晚。它们先标准化在一家超大规模云上，出于延迟考虑把工作负载铺到多个区域，然后才去问法务这些数据流是否合法。逆转这一步既昂贵又缓慢。另一种做法是从一开始就把主权当作设计输入——一套分类体系、一条放置策略，以及一个能自动执行二者的控制平面。做得好，它不是 AI 采纳的刹车，而恰恰是你能在受监管市场里推进 AI、而竞争对手还卡在法律评审里的原因。

驻留、本地化与主权三者有何区别？

这三个词在厂商材料里被混用，在合同里却有实质差异。把它们分清，是性价比最高的一项风险消减。

数据驻留（residency）是关于存储的承诺：字节落在某个具名地域的磁盘上。它是三者中最弱、也是被提供得最多的一种。一家供应商可以把你的数据放在法兰克福，同时把元数据、备份或支持访问复制在别处。

数据本地化（locality）同时覆盖处理与存储：计算在区域内完成，结果也留在区域内。这是绝大多数 AI 工作负载真正需要的层级，因为推理是处理，不是存储。

数据主权（sovereignty）是一个法律声明：数据始终受某个具名司法辖区的法律管辖，并由此受该辖区权力机关合法调取请求的约束。这是最强的一项主张，也是供应商最难做出的承诺，因为它取决于公司结构与控制权，而不只是机柜位置。

你要向供应商提出的关键问题是："谁能够强制你交出我的数据？"一家在欧洲运营区域的美国母公司供应商，对于它所控制的数据，仍可能落在美国法律程序的范围之内，无论磁盘在哪里。主权云产品——由本地合作方在本地控制下运营——正是为了给这个问题一个不同的答案，代价则是服务广度收窄。请按数据类别判断你究竟需要三者中的哪一个：在本只需驻留的地方为主权付费是浪费预算，而在确需主权的地方只拿到驻留则是制造责任。

如何为数据主权目的对数据进行分类？

下游的一切都取决于分类，而大多数项目把它设计得过于复杂。四个层级足够，每一级对应一条放置规则。

• 第 0 级——公开或合成数据。已发布材料、合成训练数据、匿名化聚合结果。任意区域均可。这一级覆盖的 AI 工作负载通常比团队预想的更多，正确归类它能释放真实的容量。
• 第 1 级——内部非个人数据。产品遥测、设备传感数据、非个人的运营指标。区域灵活，但受行业规则与底层技术的出口管制约束。
• 第 2 级——个人数据或机密业务数据。客户记录、员工数据、定价、合同。绑定于特定司法辖区，出境需经批准的传输机制，并要求使用客户自管密钥加密。
• 第 3 级——受监管或国家敏感数据。健康记录、支付卡数据、持牌金融数据，以及任何被列入国家安全或关键信息基础设施清单的内容。仅限境内，通常还要求本地密钥托管与审计权。

两条规则让它可操作。第一，在接入时分类，并把分类标签写入随数据一起流转的元数据——一份丢失标签的数据集，就是一份会被放错位置的数据集。第二，明确定义衍生数据的规则：如果第 2 级数据训练了一个模型，这个模型属于哪一级？站得住脚的答案是：在证明相反之前，模型继承其训练输入中的最高层级。这正是许多项目把敏感微调限制在境内算力上、而不是试图论证"模型是另一件东西"的原因。

哪些架构模式真正可行？

四种模式覆盖了现实的选择空间。成熟的资产组合通常同时采用其中两到三种，按数据层级选择。

按区域主权化（"每个司法辖区一个着陆区"模型）。每个辖区拥有各自隔离的订阅或账号、各自的密钥保管库、各自的日志与身份边界。数据默认不跨界。跨境流动需要显式、经过评审并被记录的导出。这是最昂贵、也最易审计的一种，是第 3 级数据的正确默认选项。

全局控制平面、区域数据平面。统一的管理体验，多个区域数据存储。部署、监控和模型注册表放在全局；客户数据永不离开其所属区域。这是大多数企业应当追求的模式，因为它在满足驻留与本地化要求的同时，把运维开销维持在可承受范围。难点在于纪律：控制平面上任何触及载荷数据（而非元数据）的功能，都是一个潜在泄漏点。

机密计算飞地。基于硬件的可信执行环境让数据在"使用中"也保持加密，因此连宿主机的运营方都无法读取。这是对"谁能强制你的供应商交数"这一问题最强的技术答案，而且在合理成本下已可用于推理。它本身并不解决法律问题，但能实质性强化你的论证。

联邦学习与拆分学习。在本地训练，只共享模型更新。当法规禁止集中数据时，联邦方法让你在不搬动记录的前提下跨辖区学习。代价是真实的——收敛更慢、调试更难，且存在梯度泄漏的实风险——但对医疗与金融联盟而言，这常常是唯一合法的路径。

跨云场景下的密钥与加密该如何处理？

加密是必要但不充分的；真正决定主权答案的是密钥托管。如果密钥在供应商手里，加密只能防住硬盘被盗，别的什么也防不住。

自带密钥（BYOK）指你生成密钥材料并导入供应商的密钥管理服务。供应商仍需在内存中使用该密钥来处理你的数据，但创建、轮换与吊销由你掌控。这是第 2 级的基线要求。

自持密钥（HYOK）指密钥永不脱离你的托管——通常是本地或境内的硬件安全模块（HSM）。云侧按次请求包装密钥。这是最强的模型，也是对运维要求最高的：一旦你的 HSM 不可达，工作负载就会停摆。必须为这种失败显式设计，并配备记录在案的紧急破窗流程。

外部密钥存储是正在兴起的中间路线：供应商的 KMS 前面挂一个你控制的密钥库，让你拥有吊销权，又不必为每次运算硬依赖自有硬件。

两条实操规则。按数据层级和司法辖区分离密钥层级结构，使吊销某一辖区的访问不会级联扩散。并且把每一次密钥操作记录到数据所属辖区的不可变日志中——当监管方问"谁在什么时候可能解密了什么"，那份日志就是你的答案。

主权对 AI 层究竟意味着什么？

AI 带来了四个传统数据体系不具备的主权面，而且每一个都已经让真实项目吃过亏。

训练数据来源可追溯性。如果你无法给出从模型回溯到其训练记录的血缘，你就无法回应删除请求，也无法回答"我的数据有没有被用过"。请为每个模型版本维护一份训练数据清单：来源数据集、分类层级、所属辖区、同意依据。

推理位置。模型在哪里运行，与数据存放在哪里同等重要。把一位德国客户的记录发到部署在美国托管的推理端点，就是一次传输，即使没有任何存储过程。请按辖区部署推理端点，或使用按数据分类路由的区域网关。

提示词与补全日志。这是最常被遗漏的泄漏点。用户把客户数据粘贴进提示词，提示词被记录下来，而日志又经常被复制到位于另一区域的中央可观测性栈。请把提示词日志按其输入数据的同一层级处理，在采集时脱敏，并保留在区域内。

供应商的次级处理与模型改进。在合同层面确认你的提示词与补全不会被用于供应商模型训练，并确认次级处理方被披露且范围受限。这通常只是一个配置项加一个合同条款——修复很便宜，发现得太晚则很贵。

这也正是架构与访问交汇的地方。蜂启咨询（Beehive Strategy）通过 MCP 连接器和语义层接入各辖区的系统，按角色执行行级与列级安全，因此在一个国家提出的问题只会解析到该国的数据上。查询留在辖区之内，只有治理元数据是全局的。由于平台原生嵌入即时通讯——运行在 Teams、Slack 或 WhatsApp 内——用户无需让数据离开本区域去填充中央看板即可获得答案；平台以托管服务方式交付，每个辖区约两周即可上线。

如何让跨境传输变得合法？

凡是数据必须流动的地方，你都需要一个机制，而机制因辖区而异。实践中重要的有三类：

• 充分性认定。当目的地已被认定为提供充分保护时，传输无需额外文书。这是最快的路径，但可能因政治变化被撤销——务必准备备用方案。
• 标准合同条款（SCC）配合传输影响评估。这是欧盟对外传输的主力工具。你必须书面记录目的地国家的法律、你所采取的补充措施，以及这些措施为何有效。交付物是那份评估，仅签条款并不足够。
• 明示同意或约束性公司规则（BCR）。同意适用于范围狭窄、确属可选的加工处理，在规模上很脆弱。约束性公司规则适合集团内传输，批准耗时较长，但一旦获批扩展性更好。

在中国，《数据安全法》与《个人信息保护法》对特定出境传输增加了安全评估或认证要求，并设有触发强制申报的数量门槛。在印度，DPDP 框架把传输限制在已通知的地域之内。各地的实操含义是一样的：维护一份传输登记表——每条数据流一行，记录来源、目的地、层级、机制、评估日期与复核责任人。当规则变化时，登记表会准确告诉你该重新审视哪些流动，而不必启动一次全公司范围的考古工程。

如何持续证明合规？

时点式审计在多云体系里必然失效，因为体系每周都在变。三种机制可以把合规从一次事件变成一种属性。

策略即代码。用与基础设施定义相同的语言表达放置规则，并在 CI 与准入控制阶段强制执行。任何会把第 3 级数据放到辖区之外的部署，在它存在之前就会在流水线上失败。这是杠杆率最高的一项控制，因为它预防违规，而不是报告违规。

持续采集证据。把配置状态、密钥操作、授权授予与数据流事件采集到有明确留存期限的不可变日志中，并把每一项控制映射到能证明它的证据上——这样一次审计就是一次查询，而不是一个项目。

带告警的漂移检测。按计划比对实际放置与声明策略——第 3 级每小时一次，较低层级每日一次——并对偏离发出告警。大多数主权事件并非出于恶意：它是一位善意的工程师启用了新区域，或某项托管服务在悄悄复制。

然后度量它。有用的指标包括：实现自动化放置强制的工作负载占比、发现策略违规的平均时间、每季度发现的未登记跨境流动数量，以及持有有效传输评估的第 3 级数据集比例。把这些与 AI 交付指标一起汇报给董事会——对管理层不可见的主权建设，就是会被砍掉预算的主权建设。

需要付出哪些成本与取舍？

对账单要诚实，因为这里的意外会摧毁可信度。主权在四个地方花钱。

基础设施重复建设。按辖区建设着陆区，意味着日志、监控、身份与网络各有 N 份。受影响范围内的云支出通常上浮 15–30%；如果早期就投入模板化，上浮会更少。

服务广度收窄。主权区域与主权云产品落后于全球目录，有时落后数年。请按更少的托管 AI 服务、更多的自管组件来做规划。

运维开销。更多环境、更多密钥层级、更多访问复核。超过两个辖区之后，自动化就不是可选项了。

延迟与能力取舍。把推理留在境内，可能意味着比全局方案更小的模型或更慢的端点。请按用例量化这一点，而不是凭假设——对于大多数企业问答类工作负载，这个差异难以察觉，而规避掉的合规风险则不然。

团队反复犯的错误有哪些？

把驻留当作主权。"数据存放在新加坡"并没有回答谁能强制披露。要问的是公司控制权那个问题。

遗忘非生产环境。合规事故几乎从不发生在生产环境，而是某位开发者把真实记录复制到位于另一区域的测试租户里。请在所有环境强制策略即代码，并在低阶环境使用合成数据。

忽略日志、备份与遥测。它们默认就会复制，而且携带最多敏感的附带数据。从第一天起就把它们纳入分类。

假设模型不受辖区约束。模型权重可能编码训练数据，监管方也日益把它们纳入范围。请把敏感微调限制在境内算力上。

先采购、后分类。在还没弄清自己的层级之前就锁定供应商，等于为所有东西买最受限的那一档。先分类；省下来的钱通常就够资助整个项目。

没有退出计划。如果某个辖区的规则改变，或某家供应商失去资质，你需要一条记录在案的退出路径。容器化工作负载、基础设施即代码、以及供应商中立的数据格式，才是让这条路真实存在、而非停留在纸面的东西。

90 天计划应该长什么样？

第 1–30 天：分类与登记。清点数据资产与 AI 工作负载，划定层级，建立传输登记表。交付物：一份站得住脚的地图，说明有什么、在哪里、依何种机制流动。

第 31–60 天：强制最高层级。对第 3 级与第 2 级实施策略即代码，搭建按辖区的密钥层级，并切换风险最高的工作负载。交付物：自动阻断最要紧的那几类违规。

第 61–90 天：扩展与插桩度量。把强制范围扩展到第 1 级与非生产环境，部署持续证据采集与漂移检测，并针对一次监管调取开展桌面推演。交付物：可以按需出示、而非事后重建的合规能力。

把这件事做对的组织，会停止把主权视为强加在 AI 之上的约束，转而把它视为自己的 AI 能够进入竞争对手进不去的市场的理由。那才是真正的回报。