很多团队第一次被客户追问 data residency 时，会本能地把它理解成一个部署问题：把数据库放在欧盟、把对象存储放在新加坡、把日志收集器也部署一份，本地化就算完成了。这个理解对普通 Web 应用已经不够，对 AI agent 更不够。因为 agent 真正的运行路径不是单点请求，而是一条跨多个系统的链：提示词、上下文、工具调用、模型推理、浏览器 runner、日志、trace、审计快照，任何一环跨区，都可能让你前面那句“数据不出境”变得站不住。
更现实的问题是，很多企业环境根本不存在“所有东西都在同一区域”的理想状态。客户数据在 EU，企业内部审批系统在 APAC，最合适的模型在 US，可浏览器自动化又必须进客户自有 VPC。这时真正需要的不是一句口号，而是一份明确的 residency envelope：哪些数据必须原地处理，哪些数据可以只传 redacted summary，哪些动作必须在本区 runner 执行，哪些控制信号允许跨区。
如果这层 envelope 不清楚，系统表面上可能还能跑，但越往企业客户推进，越像踩在薄冰上。因为你无法准确回答：到底是什么东西跨了区，为什么跨区，以及跨区之后有没有把最敏感的那部分也一起带走。
建议结合 AI agent 多执行环境路由、AI agent 多租户隔离与 Workspace 供给、AI agent 数据脱敏实践 和 AI agent 凭证委托与 Token Vault Proxy 一起看。
先不要谈部署，先把“哪类数据不能动”画出来
| 组件 | 常见内容 | 对 residency 最敏感的点 |
|---|---|---|
| Session / Context | 用户输入、业务事实、内部文档摘要 | 是否会被跨区加载进模型上下文 |
| Artifact / Evidence | 截图、草稿、审计附件、引用证据 | 是否长期落在非本区对象存储 |
| Model Request | prompt、工具结果、历史片段 | 传给哪个区域的模型 API |
| Runner / Browser | 页面内容、Cookie、内部系统交互 | 执行是否发生在客户要求的区域 |
| Logs / Trace | 调试字段、报错、tool I/O | 是否在跨区日志平台中暴露敏感数据 |
很多系统出问题，不是因为数据库放错区，而是因为上下文拼装、日志聚合或远程 runner 这三层没被当成 residency 组件来设计。
Residency 不是“全都本地”，而是“什么必须本地”
一味追求所有组件都本地，最终通常会把系统逼到不可维护。模型可用性、成本、生态工具和合作方 API 并不会因为你的数据政策就突然自动适配。更实际的做法，是把系统拆成几个不同敏感度的面：
- Control Plane：调度、状态推进、指标聚合。通常可以跨区，但要尽量只处理最小必要元数据。
- Data Plane：真实用户内容、证据、草稿、浏览器操作。往往更需要贴近数据所在区域。
- Policy Plane：决定什么能跨、什么不能跨，以及跨区前是否要 redaction。
这三层一旦拆开，很多原本像死结的问题就松了。例如，调度可以集中，真正读取客户文档和执行表单提交的 runner 必须本地；日志可以集中聚合，但敏感字段只能先在本区 redaction 后再上报。
真正难的是“模型不在本区”，不是“数据库不在本区”
大多数 residency 讨论最后都会走到这里：最合适的模型并不在客户要求的数据区域。这个时候不能只问“能不能调用”，而要问三件事：
- 送过去的到底是不是原始敏感内容
- 有没有一层本区 pre-processing，把上下文变成可跨区的 summary 或结构化字段
- 这个模型响应是否又会把敏感内容写回跨区日志或缓存
也就是说，模型调用本身不一定绝对禁止，但它一定需要更细的输入分级。比如：
- 原始合同正文不能直接跨区
- 经 redaction 的字段摘要可以在特定政策下跨区
- 模型生成的候选结论如果包含客户识别信息，返回后必须先落本区再分发
如果没有这套分级，所谓“跨区模型调用”最终就只是靠口头承诺维持。
一个常见翻车点：主数据没出境，日志却先出去了
某团队给欧洲客户部署 agent，主数据库、对象存储和浏览器 runner 都在 EU，表面上看一切合规。结果安全评审时还是被打回，原因很简单：
- 模型请求在本区做了 redaction
- 但调试 trace 默认把原始 tool input 和错误 payload 发到了美国区 observability 平台
- 某些失败样本里包含客户内部系统 URL、用户名和片段字段值
也就是说，团队守住了主链路，却在“为了方便排查”的旁路上把边界打穿了。
最后修复不是把 observability 整体关掉，而是把 trace 也纳入 residency envelope：本区先做字段分级和 redaction，只允许 minimal diagnostic signal 跨区。这个例子说明，真正危险的往往不是你天天盯着的主数据，而是默认配置的辅助系统。
Regional Placement 的关键，不是离谁最近，而是谁承担哪类责任
选 runner、日志、对象存储和控制面的位置时，别只看延迟，还要看责任。一个很实用的判断方法是：
- 谁直接接触原始用户数据，谁就更应该贴近数据区域
- 谁负责解释系统行为，谁就需要拿到足够的审计信息，但不一定拿到原始内容
- 谁只负责调度和聚合，谁就该尽量少碰业务 payload
这个判断方式会让架构更清楚。因为 residency 本质上不是“机房选择题”，而是“把哪种责任放在哪一层”的设计题。
如果你只能先画一张图，先画跨区链路，而不是资源部署图
很多团队会先画“哪个服务在哪个 region”，但对 residency 最有用的往往不是那张图，而是“哪类信息在什么时候跨了区”。只要这张跨区链路图没有画出来，你就很难判断：
- 哪一步最该做 redaction
- 哪一步本该本地执行却被路由到了远端
- 哪个日志或缓存系统在偷偷复制敏感数据
把这条链画清楚后，再谈区域部署、模型路由和日志平台，讨论才会从口号回到工程。
延伸阅读：
