AI Data Residency / Cross-Border / Sovereign AI Architecture Playbook

配对阅读：本手册的原理/架构解读版是 docs/ai-foundations/papers/120-ai-data-residency-cross-border-sovereign-architecture.md。先读 paper 建立机制与取舍，再用本手册落地为模板、RACI 与门禁，两者不需要重复精读。 核心导读: AI data residency / cross-border / sovereign AI architecture 把 data residency、cross-border transfer 和 sovereign AI 从法律和风险语言转成运行时数据路径、供应商控制、证据链、密钥治理和系统性 release gate。 学习主线: 从 residency decision tree、data classification、jurisdiction-purpose-processor matrix、RAG/tool/log/eval/vendor controls、sovereign deployment patterns、provider region register、key residency、transfer impact review 到 evidence ledger, 建立一条可路由、可最小化、可证明的 AI data-use architecture。 重点边界: 本 playbook 不讨论泛泛的云合规。它聚焦 AI RAG、tool calling、prompt/log/eval、model provider、vendor telemetry、encryption key residency、transfer impact review 和 sovereign deployment patterns。

---

0. Disclaimer

本文是系统学习和架构训练材料, 不构成法律、隐私、合规、审计、监管、税务、外包、数据保护、模型风险管理或安全意见。

正式项目必须由 Legal、Privacy、Compliance、Security、Data Governance、Model Risk、Third-Party Risk、Enterprise Architecture、Product、Operations、Customer Experience 和业务责任人共同确认适用要求。

不要把任何 source anchor 解读成 universal legal requirement。

适用性取决于:

• jurisdiction and regulator context。
• data subject: customer, prospect, employee, merchant, representative, household, business entity。
• customer segment: retail, wealth, SME, corporate, vulnerable customer, minor where applicable。
• product: deposit, card, lending, insurance, brokerage, wallet, loyalty, open banking。
• data class: personal data, financial account data, credit data, card data, KYC/AML, complaint, employee data。
• purpose: service, fraud, compliance, marketing, advice, eval, model monitoring, vendor support。
• vendor and processor/subprocessor chain。
• contract, transfer mechanism, outsourcing terms and customer disclosure。
• actual runtime data path, including logs, eval, support access and backups。

---

1. Executive Framing

AI data residency architecture 的目标不是在 cloud console 里选择一个 region。

它的目标是让组织能在运行时回答并证明:

This AI use of this data followed the approved jurisdiction,
purpose, processor, model, tool, log, eval, backup and key route.

金融零售 AI 的 residency risk 来自 context expansion。

同一个客户问题可能经过:

• mobile app 或 contact center。
• identity and consent service。
• customer profile。
• account and transaction systems。
• card dispute or lending system。
• RAG corpus and vector index。
• prompt assembly service。
• external or internal model endpoint。
• tool gateway。
• logging and tracing platform。
• eval sampling pipeline。
• human review queue。
• vendor telemetry。
• backup and disaster recovery system。
• KMS/HSM and break-glass workflow。

如果团队只问“数据库在哪里”, 会漏掉多数 AI processing path。

高级判断:

Data residency is a runtime architecture property. Cloud region is only one input.

本 playbook 的输出物:

• data residency decision tree。
• data classification model。
• jurisdiction-purpose-processor matrix。
• cross-border AI data path map。
• RAG/tool/log/eval/vendor control design。
• sovereign deployment pattern comparison。
• model/provider region control register。
• encryption and key residency design。
• transfer impact review workflow。
• evidence ledger schema。
• operating model and RACI。
• metrics and KRIs。
• 30-day lab。
• decision narrative。
• system evidence pack。
• design review questions。

---

2. Source Anchors

以下官方来源作为概念和控制设计锚点。访问日期按 2026-06-30 记录。

Standards-to-artifact:

---

3. Operating Principles

---

4. Data Residency Decision Tree

使用这个 decision tree 作为需求澄清和架构评审入口。

1. Who is the subject?
   -> customer / prospect / employee / merchant / representative / organization

2. Which jurisdiction and product entity apply?
   -> subject location, booking entity, branch, channel, product terms, contract

3. What is the AI purpose?
   -> service / fraud / compliance / marketing / advice / open banking / eval / operations

4. What data classes are used?
   -> public / internal / PII / account / transaction / credit / card / KYC / complaint / employee

5. Which AI artifacts are created?
   -> prompt / RAG chunk / embedding / output / tool payload / log / trace / eval sample / memory

6. Which processors and subprocessors touch them?
   -> cloud / model provider / vector DB / observability / annotation / support / DR provider

7. Which regions and access paths exist?
   -> compute, storage, logs, backup, admin access, support access, key access

8. Is cross-border processing necessary for the purpose?
   -> yes with review / no local route / minimize / pseudonymize / aggregate / deny

9. Which safeguards and evidence are required by policy?
   -> contract, encryption, key residency, access control, monitoring, transfer review, audit trail

10. What is the runtime decision?
   -> allow / deny / localize / minimize / pseudonymize / require review / human approval

Decision outputs:

---

5. Data Classification for AI Residency

Classification must cover source data and AI-derived artifacts.

5.1 Source Data Classes

5.2 AI-Derived Artifact Classes

5.3 Classification Rules

---

6. Jurisdiction / Purpose / Processor Matrix

This matrix is the core traceability artifact.

It converts legal/privacy/vendor review into an executable architecture table.

6.1 Matrix Fields

6.2 Example Matrix

6.3 Compatibility Rules

---

7. Cross-Border AI Architecture

7.1 Reference Architecture

User / Employee / API Client
  -> channel ingress and region resolver
  -> identity, consent and authorization
  -> purpose catalog and data classification
  -> residency policy decision point
  -> AI orchestrator
       -> prompt assembly service
       -> RAG gateway
       -> tool gateway
       -> model/provider region gateway
       -> memory service
       -> logging and evidence gateway
       -> eval sampling gateway
       -> vendor telemetry controller
  -> policy decision log
  -> evidence ledger
  -> dashboards and recertification workflows

7.2 Residency PDP Inputs

7.3 Residency PDP Decisions

---

8. Cross-Border RAG Architecture

8.1 RAG Data Path

Source system
  -> classification and jurisdiction labeling
  -> corpus manifest
  -> chunking in approved region
  -> embedding in approved region
  -> vector index with ACL and purpose metadata
  -> retrieval with subject/purpose/region filters
  -> prompt assembly with minimized context
  -> inference through approved model route
  -> retrieval trace and evidence ledger

8.2 Corpus Manifest

8.3 RAG Controls

9. Cross-Border Tool Architecture

Tool calling is often riskier than model inference because tools touch systems of record.

9.1 Tool Gateway Pattern

AI orchestrator
  -> tool intent
  -> policy decision point
  -> scoped token issuer
  -> payload minimizer
  -> region-aware tool gateway
  -> system of record
  -> tool result classifier
  -> prompt/log minimizer
  -> evidence ledger

9.2 Tool Control Table

10. Logs, Traces, Eval and Human Review

10.1 Logging Architecture

10.2 Eval Architecture

Eval is a product and risk control, but it can create hidden data reuse.

11. Vendor and Processor Architecture

11.1 Vendor Inventory

11.2 Vendor Route Decision

If provider endpoint region is approved
and retention setting matches policy
and no-training boundary is active
and subprocessor chain is approved
and logs/telemetry are minimized
and key policy matches matrix
then route may be enabled.
Otherwise route is denied, localized, minimized or sent to review.

---

12. Sovereign Deployment Patterns

Sovereign AI can mean different operating models. Define it before using it in strategy or marketing.

12.1 Pattern Selection Criteria

13. Model / Provider Region Controls

13.1 Model Gateway

AI orchestrator
  -> model request classifier
  -> data class and purpose policy
  -> provider/model region registry
  -> route selection
  -> payload minimizer
  -> provider endpoint
  -> response classifier
  -> log/evidence gateway

13.2 Provider Region Register

13.3 Routing Rules

14. Encryption and Key Residency

Encryption supports residency but does not replace routing and purpose controls.

14.1 Key Questions

14.2 Key Residency Patterns

15. Data Minimization Patterns

Minimization is the most practical cross-border risk reducer.

15.1 Minimization Ladder

15.2 Minimization by AI Artifact

16. Transfer Impact Review Workflow

This workflow is an architecture governance artifact, not a legal conclusion.

16.1 Trigger Events

16.2 Review Steps

17. Evidence Ledger

Evidence ledger is the production proof that policy became runtime behavior.

Ledger events cover residency decisions, RAG retrieval, model route, tool route, log retention, eval sampling, key access, transfer review linkage, vendor changes and kill-switch actions.

17.1 Ledger Schema

17.2 Evidence Query

Proof that a specific interaction used approved route:

SELECT
  event_time,
  interaction_id,
  purpose_id,
  artifact_type,
  processor_id,
  source_region,
  destination_region,
  endpoint_region,
  decision,
  reason_code,
  policy_version,
  review_ref
FROM ai_residency_ledger
WHERE interaction_id = :interaction_id
ORDER BY event_time;

---

18. Operating Model

18.1 RACI

Legend: R = responsible, A = accountable, C = consulted.

18.2 Governance Forums

18.3 Release Gate

---

19. Metrics and KRIs

19.1 Product Metrics

19.2 Control KRIs

19.3 Executive Dashboard

---

20. 30-Day Lab

目标: 30 天内产出一个 AI Data Residency / Cross-Border / Sovereign AI Architecture system evidence pack。Use case 建议: Retail Banking AI Dispute Assistant。

---

21. Decision Narrative

Residency, Transfer And Sovereignty

核心判断:

Data residency describes where AI artifacts are stored, processed and accessed. Cross-border transfer asks whether a jurisdiction boundary is crossed. Sovereign AI asks how much local control exists over data path, model route, keys, operators, support access, resilience and exit.

系统推演:

The architecture must decompose prompt, RAG, tool, log, eval, backup, telemetry, keys and support access. Applicability is determined by Legal, Privacy and Compliance based on jurisdiction, subject, product, vendor, contract and actual runtime path.

Cloud Region Is Not Enough

核心判断:

AI data path is broader than database region. A request may leave the intended boundary through model endpoint, global observability, offshore labeling, vendor support ticket, eval sample, backup, telemetry or key management.

系统推演:

Residency control needs a PDP, model gateway, RAG metadata, tool gateway, log policy, eval queue, provider region register and evidence ledger. Cloud region is one input to route decision, not the route decision itself.

Cross-Border RAG

核心判断:

Every corpus needs source region, allowed purposes, data classes, embedding/index region, ACL, consent/authorization dependency and deletion propagation.

系统推演:

Retrieval should filter before context assembly by jurisdiction, purpose, role, object scope, consent/authorization and policy version. Eval should use synthetic or region-local samples by default. Real failure samples require classification, redaction, local queue, reviewer control, lineage and retention evidence.

Jurisdiction-Purpose-Processor Matrix

核心判断:

The matrix contains subject jurisdiction, product entity, purpose, data class, processor, endpoint, tool/log/eval/key region, decision, safeguards, review reference and expiry.

系统推演:

This matrix is the bridge between governance and runtime policy. New vendor, data class, eval route, key route, support path or fallback route should trigger review. Approved rows should compile into policy bundles for model gateway, RAG filters, tool gateway and log/eval controls.

Provider Region Control

核心判断:

All model requests should pass through a centralized model gateway. The gateway enforces allowed model, endpoint, region, data class, retention, no-training, telemetry, subprocessor, key policy, fallback and approval rules.

系统推演:

Provider region register is not procurement inventory only. It must be executable enough to deny route mismatch, disable unsafe fallback, record policy decision ID and prove which model endpoint processed a specific interaction.

Key Residency

核心判断:

Encryption cannot replace route control. Key location, key owner, operator access and break-glass process affect sovereignty claims and evidence quality.

系统推演:

KMS/HSM region, BYOK/HYOK pattern, rotation, access log, backup encryption, recovery key path, emergency access and exit destruction should be part of the matrix. Data stored locally with external key control may still be unacceptable for high-sovereignty paths.

Eval Data Path

核心判断:

Eval pipeline is an independent processing path. It can silently move real customer prompts, model outputs, failure samples and human review notes across regions or vendors.

系统推演:

Default to synthetic first. Real samples require classification, minimization, redaction, local queue, reviewer region control, lineage, retention and approval. Eval route changes should trigger the same transfer impact review as production route changes.

Sovereign Or Private Route Selection

核心判断:

Choose sovereign or private routes when sensitive data, strict jurisdiction, key control, support access, resilience, public trust or auditability requires stronger control.

系统推演:

The decision should compare data sensitivity, purpose criticality, model quality, latency, cost, operator control, audit evidence, fallback behavior and exit feasibility. A stronger route is valuable only if it remains operable, observable and governable.

Boundary Proof

核心判断:

Proof of non-crossing requires evidence ledger events by interaction_id for RAG, model, tool, log, eval and key decisions.

系统推演:

Evidence can store manifests, source IDs, hashes, policy version, endpoint IDs, key IDs and review references instead of overcollecting raw payload. The proof query should show allowed, denied, minimized, redacted and escalated decisions across the full AI path.

---

22. System Evidence Pack

System narrative:

Data residency is a runtime AI architecture property.
Every artifact from user message to RAG, model, tools,
logs, eval, backup and keys must map jurisdiction,
purpose, processor and data class into executable policy and evidence.

---

23. Design Review Questions

---

24. Production Readiness Checklist

• Every AI capability has approved purpose, data class and route.
• Full data path covers RAG, prompts, tools, logs, eval, vendor telemetry, backups and keys.
• Jurisdiction-purpose-processor matrix and provider region register are reviewed.
• RAG corpus manifests include allowed purposes, regions, ACL and deletion propagation.
• Tool gateway enforces purpose, object scope, region and payload minimization.
• Logs and eval samples avoid raw payload unless justified and controlled.
• Vendor subprocessors, support access, telemetry and exit path are inventoried.
• Transfer impact review triggers on route, vendor, data class, purpose, eval or key changes.
• Encryption and key residency align with data path and evidence requirements.
• Fallback routes, kill switch, KRIs and evidence ledger are tested.
• Named owners exist across Product, Process Analysis, Architecture, Legal, Privacy, Compliance, Security, Data Governance, Model Risk, Vendor Risk and Ops.

25. Closing View

金融零售 AI 的 data residency 成熟度不在于说出“我们使用某某 region”, 而在于能证明哪些数据被使用、为什么被使用、经过哪些 processor/subprocessor、在哪些 regions 处理和记录、使用哪些 keys、哪些 route 被允许或拒绝、哪些 evidence 可以复核。

真正的目标不是把 AI 全部锁死在一个地方, 而是让每一次 AI data use 都能被设计、限制、路由、最小化、监控、撤销、退出和证明。