AI Data Residency：跨境与主权数据架构
AI data residency 不是数据库部署区域选择，而是端到端数据路径控制。一次 AI 请求可能经过客户源数据、RAG 检索、prompt assembly、模型 endpoint、工具 payload、日志、trace、eval sample、人工复核队列、供应商 telemetry、备份和密钥服务。任何一个环节跨境，都可能改变 privacy、bank secrecy、outsourc
AI Data Residency / Cross-Border / Sovereign AI Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_DATA_RESIDENCY_CROSS_BORDER_SOVEREIGN_AI_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST Privacy Framework | https://www.nist.gov/privacy-framework | 用 privacy risk management 语言组织 data processing context、privacy control、communication 和 evidence。 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 把 residency、cross-border 和 vendor model risk 放进 AI lifecycle。 |
| FTC Safeguards Rule | https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know | 作为金融客户信息保护、访问控制、服务提供商监督和信息安全计划锚点。 |
| CFPB Personal Financial Data Rights | https://www.consumerfinance.gov/personal-financial-data-rights/ | 用于客户授权数据共享、开放银行、第三方访问和撤销的产品架构讨论。 |
| EDPB International Transfers | https://www.edpb.europa.eu/our-work-tools/our-documents/topic/international-transfers_en | 作为国际数据传输评估、补充措施和监管解释索引锚点。 |
| ISO/IEC 42001 | https://www.iso.org/standard/42001 | 用 AI management system 的思路落地政策、角色、供应商、监控、证据和持续改进。 |
Data residency is not only “where the database is”. In AI architecture, residency covers input data, retrieved context, prompt, tool payload, model endpoint, logs, traces, eval data, fine-tuning data, telemetry, backups, encryption keys and human review queues.
核心导读
AI data residency 不是数据库部署区域选择，而是端到端数据路径控制。一次 AI 请求可能经过客户源数据、RAG 检索、prompt assembly、模型 endpoint、工具 payload、日志、trace、eval sample、人工复核队列、供应商 telemetry、备份和密钥服务。任何一个环节跨境，都可能改变 privacy、bank secrecy、outsourcing、regulatory access、客户授权和供应商风险。
Sovereign AI architecture 的目标不是所有东西都本地化，而是在产品、数据、模型、工具、日志、key 和运营层面明确哪些必须留在本地，哪些可以跨境，跨境需要什么依据、补充措施、证据和降级方案。
问题定义
AI residency 风险常被低估，因为数据移动不只发生在显性数据库：
- 客户交易数据在本地数据库，但 prompt 被发送到境外模型 endpoint。
- RAG 索引在本地，检索结果和客户问题进入境外日志或供应商监控。
- 人审队列由另一区域团队处理，导致客户投诉和账户信息跨境可见。
- Eval team 抽样生产 prompt 做质量评估，样本被复制到全局 workspace。
- Vendor telemetry、abuse monitoring、support ticket 或 crash log 收集了敏感 metadata。
- 加密 key 在本地名义保存，但推理或日志解密发生在境外服务中。
- 跨区故障切换时，系统自动调用全球备用模型，绕过 residency policy。
因此，data residency decision 必须覆盖“where data is stored、processed、observed、logged、reviewed、backed up、decrypted and exported”。
核心原理/方法
Residency policy 应从数据路径和处理目的开始：
| 层次 | 需要判断的问题 |
|---|---|
| Data class | PII、账户、交易、投诉、信用、KYC/AML、员工、商户、聚合数据、脱敏数据 |
| Processing purpose | 服务、欺诈、投诉、营销、推荐、模型评估、训练、监控、法律保全 |
| Processing location | 数据存储、检索、prompt assembly、推理、工具执行、日志、复核、备份、密钥 |
| Transfer basis | 客户授权、合同、法律义务、内部集团传输、供应商处理、监管要求 |
| Safeguards | 加密、tokenization、pseudonymization、access control、SCC/TIA、local key、audit |
| Restriction | 禁止跨境、只允许聚合、只允许本地模型、禁止供应商训练、禁止远程复核 |
| Evidence | 路由决策、region、vendor、subprocessor、key use、policy version、approval |
常见部署模式：
| 模式 | 适用场景 | 代价 |
|---|---|---|
| Local-only AI | 高敏感客户数据、严格本地化、监管检查密集 | 成本高、模型选择少、能力更新慢 |
| Regional model gateway | 按客户/数据/用途路由到允许区域 | 架构复杂，需要强 policy 和 telemetry |
| Data minimization gateway | 跨境前脱敏、摘要、tokenize 或只传低敏字段 | 可能损失模型效果和可解释性 |
| Split processing | 本地检索和 policy，本地/跨境分层推理 | 复杂度高，需防止上下文泄露 |
| Sovereign cloud / dedicated tenant | 受控区域、密钥、运维和访问边界 | 供应商选择和成本受限 |
| Degraded local mode | 跨境不可用或不允许时使用模板、本地小模型或人工流程 | 能力下降但风险可控 |
系统/架构模型
Data / Purpose / Region Catalog
-> Residency Policy Engine
-> Region-Aware AI Gateway
-> Local RAG / Feature / Memory Stores
-> Model Routing & Vendor Control
-> Tool Payload Filter
-> Key Residency / Encryption Service
-> Logging / Eval / Review Residency Controls
-> Evidence Ledger & Transfer Review
关键组件：
| 组件 | 职责 |
|---|---|
| Data catalog | 标记数据类别、来源、客户地区、业务域、敏感度、purpose 和 retention |
| Residency policy engine | 根据数据、目的、客户、产品、区域和供应商决定 allow/deny/transform/route |
| AI gateway | 统一控制 prompt、retrieval context、model call、tool payload、日志和 telemetry |
| Regional RAG store | 确保本地数据、本地索引、本地 metadata 和本地 access policy |
| Model router | 将请求路由到允许模型、区域、tenant 和供应商配置 |
| Tool payload filter | 在调用 CRM、payment、case、marketing 等工具前执行区域和最小化规则 |
| Key service | 管理 key generation、storage、use、rotation、HSM/KMS region 和 decrypt boundary |
| Review residency control | 控制人工复核队列、QA 样本、support access 和运营地点 |
| Evidence ledger | 记录每次跨境或本地处理的 region decision、policy version、vendor 和 key use |
架构上的关键是建立单一 AI gateway。分散在各业务系统中的模型调用、日志和 eval 抽样很难统一执行 residency control。
关键机制与取舍
| 机制 | 取舍 |
|---|---|
| 全球统一模型 vs 区域模型 | 全球模型能力强、一致性好；区域模型降低跨境风险但增加成本和质量差异 |
| 本地 key vs 本地处理 | key residency 不等于 data residency；如果境外服务能看到明文，风险仍存在 |
| 数据脱敏 vs 业务效果 | 最小化降低风险，但可能损失上下文。高风险场景需评估输出质量和客户损害 |
| 中央日志 vs 区域日志 | 中央日志便于运营；区域日志更符合本地限制。可采用 metadata aggregation + local detail |
| 供应商承诺 vs 技术强制 | 合同条款必要但不足；gateway、routing、DLP 和证据才是运行控制 |
| 跨区容灾 vs 合规边界 | 故障切换不能自动突破 residency；应设计 local degraded mode 和预批准 route |
Sovereign AI 不是“全部自建”。实际架构通常是分层：高敏数据本地处理，低敏或聚合数据可跨境，客户可见高影响输出增加本地复核，全球模型通过 gateway 和 policy 控制使用。
证据与控制
Residency 证据要能重建数据路径：
| 证据对象 | 关键字段 |
|---|---|
| Data path record | data class、purpose、source region、processing region、destination、vendor |
| Policy decision | allow/deny/transform/route、policy version、reason、approval |
| Model call event | model、tenant、endpoint region、prompt data class、context ids、no-train flag |
| Retrieval event | corpus region、chunk id、customer region、access decision、filter |
| Tool event | payload class、tool region、write/read、minimization、approval |
| Key event | key id、KMS/HSM region、decrypt location、rotation、access |
| Review event | reviewer location、queue region、evidence viewed、redaction |
| Transfer review | transfer basis、risk assessment、supplementary measures、approval、expiry |
控制指标包括：cross-border call count by purpose、policy-denied transfers、unknown endpoint、log residency violation、vendor telemetry exception、key-region mismatch、reviewer-region mismatch、fallback route activation、transfer review aging。
金融零售/AI产品场景
全球银行客服助手：客户问题、账户数据和投诉上下文必须按客户所在区域路由。全球知识库可以共享产品通用内容，但客户交易、投诉和身份信息应通过区域 RAG 与区域模型处理。
开放银行数据分析：客户授权第三方数据用于预算洞察。跨境处理必须与授权目的、数据类别、供应商和撤回机制一致；eval 抽样也不能绕过授权边界。
信用卡争议文档处理：争议材料可能包含身份、交易、商户和医疗等敏感信息。可使用本地 OCR/RAG，本地人审；跨境模型只能接收脱敏摘要或禁止接收。
零售营销 AI：全球 campaign idea 可跨境协作，但客户分群、偏好、购买历史和本地监管 disclosure 应在本地或批准区域处理。
反模式
- 只确认数据库在本地，却忽略 prompt、日志、telemetry、eval、support 和人审队列。
- 认为加密 key 在本地就等于数据未跨境。
- 供应商合同写了 region，但 SDK 默认发送 usage telemetry 到全球服务。
- 生产样本被复制到全局 eval workspace，没有 purpose、region 和 retention 控制。
- 容灾切换自动调用境外模型，没有预先批准的 data path。
- 人工复核和 vendor support 可以跨区查看完整客户上下文。
- Residency policy 写在文档里，没有进入 AI gateway routing 和 logging。
最终心智模型
AI data residency 是一条完整数据路径问题，不是基础设施标签问题。要治理的是数据从源系统进入 prompt、RAG、模型、工具、日志、评估、复核、备份、供应商和密钥服务的每一步。
成熟架构能回答：某个客户数据在一次 AI 请求中去了哪些区域、被谁处理、用于什么目的、经过什么保护、由哪个 policy 允许、产生了哪些日志和证据、故障时会如何降级。如果只能回答“数据库部署在本地”，说明 residency 风险还没有被架构化。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。