RAG 数据驻留控制：约束摄取、Embedding、检索与灾备地域

“向量库建在法兰克福”不能证明 RAG 数据留在欧洲。原文可能被其他区域的 connector 拉取、由全局队列解析，再发送给自动路由的 Embedding API；cache、trace 和跨区备份还会产生副本。企业知识库 RAG 描述接入链路，本篇只回答每个阶段允许在哪里读取、计算、存储和恢复。

数据驻留、跨境传输和 GDPR 第五章等规则如何适用，应由法务与数据治理负责人判断。工程侧不能把云服务认证直接翻译成租户可跨区，而要执行已批准、带版本的机器契约。

把地域要求表达为数据策略

不要从用户可伪造的 X-Region header 选择处理位置。租户注册表提供受信的 residency.policy.v1：

{
  "tenant": "t_eu_42",
  "policyRevision": 17,
  "homeRegion": "eu-central-1",
  "allowedIngest": ["eu-central-1"],
  "allowedProcessing": ["eu-central-1", "eu-west-1"],
  "allowedStorage": ["eu-central-1"],
  "allowedRecovery": ["eu-central-1"],
  "providerProfiles": ["embed-eu-v3"],
  "dataClasses": ["internal", "personal"],
  "effectiveAt": "2026-07-18T00:00:00Z"
}

地域 ID 使用固定枚举；providerProfiles 绑定 endpoint、部署模式、合同/文档 revision 和出站类别。策略 revision 单调递增，旧任务、cache 与 index release 都要重查。主体权限仍由 RAG 检索权限控制 决定，地域策略另行约束处理位置。

源资源和派生 chunk 携带 tenant、data class、home region、policy revision 与 source version。向量若仍与文档 ID、租户或可识别内容相连，就沿用原文标签。字段缺失、region 未知或 revision 过旧时进入隔离。

控制面编译，数据面只执行

控制面把策略编译为分区队列、对象桶、索引、KMS key、service account、endpoint allowlist、日志与备份计划。工作负载身份只能证明调用主体和配置归属，不能证明 CPU 的物理地域。客户可控资源的放置证据来自带 region 的资源 inventory、不可变部署配置、云控制面审计和网络边界，身份只用于关联这些证据。worker 仍拒绝 payload 自报 region，出口限制 DNS、重定向和最终 endpoint。

托管模型 profile 冻结供应商合同、官方处理范围与部署类型。同一产品可能有 regional、global 或 data-zone 路由；代码只能调用已审批 endpoint。普通 request ID 只能关联一次调用，不是物理 region attestation；供应商若不提供逐请求地域证明，实际内部处理位置就标为不可技术验证，只能记录 supplierAssuranceRevision，不能伪装成完整 actualRegions。说明变化时生成新 profile 复审。

消息只存对象引用和 policy digest，正文留在本区。worker 读取前鉴权并验 digest，输出只写允许目标。MCP 多租户隔离 的 tenant 上下文贯穿任务、重试与 cache key；多地域系统再加入 region 和 policy revision，禁止全局缓存串区。

Index release 也要证明放置位置

每个地域独立构建不可变索引，manifest 记录源摘要、policy digest、builder 配置、模型 profile、shard、备份和计数。promotion 前枚举客户可控对象的资源 region，证明 customerResourceRegions 是 allowedStorage 的子集；副本、快照、临时桶和死信队列都在范围。托管模型只绑定供应商保证 revision，不把不可见的内部副本写成已枚举事实。

检索按 tenant policy 进入固定区域，拥塞时也不转发到未批准集群。聚合结果只有经过重识别风险评估、最小化和治理批准后才可跨区，并记录批准 revision；聚合不天然匿名或不可逆。公共文档跨区同样作为数据产品审批，不能绕过血缘。

用资源清单和出站 canary 验收

验收分两张证据表。客户可控的对象存储、索引、副本、快照、队列、KMS、cache 和日志 sink 用 API inventory、不可变配置、控制面审计与 flow log 证明 customerResourceRegions - allowedRegions = 0，未知位置为 0。托管模型则证明 endpoint allowlist 与合同/官方说明 revision 当前有效，并明确列出无法逐请求验证的处理范围；账单、身份和 request receipt 只做关联，不能替代地域证明。

在隔离租户写 canary，执行摄取、Embedding、查询、日志、备份和恢复；客户资源只在允许地域可读。注入任务投错 worker、SDK 改用 global endpoint、复制规则误开、日志串区、旧快照恢复和 DNS 改址。托管供应商测试只证明路由与拒绝行为，不据此宣称看见其全部物理处理位置。

硬不变量是越界请求数与越界副本数为零。主区域不可用时，若 allowedRecovery 没有其他区域，就返回明确不可用或只提供不含受限数据的公共能力，不能为了 RTO 擅自跨区。云灾备与多区域架构 的热备选择必须受驻留策略约束，灾备演练也要记录处理位置而不只是恢复时长。

回滚路由，隔离已经越界的产物

发布先 shadow 计算旧、新 placement plan，比较将新增或移除的资源区域；再对测试租户创建完整索引和恢复演练，最后按 tenant 固定切换。发现误路由时立即停用对应 provider profile 和跨区 worker，推进 deny revision，冻结目标区对象与日志供安全调查，并从合法区域的源快照重建。不能把越界副本复制回来后就当作从未发生。

如果新策略误拒绝，可以恢复上一版经过批准的 policy 和路由代码，但不能回退已生效的法律或合同事实；治理负责人必须明确批准 revision。旧版本服务若不认识当前 schema，则保持受限租户关闭。LLM 灾难恢复 负责服务韧性，驻留门禁决定哪些恢复方式合法可执行。可靠的多地域 RAG 不是“离用户最近”，而是在正常、拥塞和灾难状态下始终只能走被证明允许的路径。

延伸阅读

• 企业知识库 RAG
• RAG 检索权限控制
• MCP 多租户隔离
• 云灾备与多区域架构