谈 AI 数据驻留，先把一条请求拆成几段

供应商说“数据存放在指定区域”，采购团队便在表格中勾选了数据驻留通过。但员工上传文件后，解析、模型推理、错误日志和技术支持可能沿着不同路径处理资料。判断数据驻留，最好先追踪一条真实业务请求，再逐段确认处理位置和责任主体。

不要把存储位置当成整条链路的位置

数据驻留评估需要区分静态存储与计算处理，也要区分正文、提示词、回答、日志和元数据。本文参考的数据驻留指南建议分别询问这些问题。Google 的零留存说明进一步按功能列出日志、交互状态和缓存配置，说明同一家服务商内部也可能有不同数据处理路径。本文不据此推定任何其他供应商的实际位置。

用一张请求地图代替笼统回答

可以选择“上传一份合同并生成摘要”作为样本，用虚构合同走完整流程。每条连接标注发送对象、资料类别、处理位置、保留方式和证据来源。证据可以是配置记录、服务文档、合同条款与观察结果，但应分别注明，不能把网络观察到的地址直接解释为所有后端处理都发生在那里。

尤其要询问备用区域和故障切换。有的业务平时使用指定区域，发生容量不足时可能进入另一条路由；是否允许这种安排取决于组织要求与服务能力。若供应商无法说明，应把切换范围列为未解决项，先限制敏感资料使用，而不是在验收报告中补一个“默认不跨区”的假设。

支持访问与留存是另外两列

资料存放在某地，不等于只有当地人员能访问。技术支持、分包处理者及客户自行导出的日志都可能改变访问范围。另一方面，处理位置满足要求，也不表示数据不留存或不用于训练。采购问卷应把这些条件分开，分别找到可追溯依据，再由企业相关负责人判断整体是否适用。

对无法从外部验证的内部处理，应要求供应商给出清晰的服务承诺、适用功能和变更通知机制。一次抓包不能证明所有后台副本不存在，宣传图也不能替代实际配置。团队需要在证据不足的位置保留边界，避免把有限观察包装成完整保证。

完成评估后，维护的对象应是“业务任务、接口、模型、区域和配置”这一组合。新增联网搜索、切换模型或启用诊断日志，都可能需要更新请求地图。只有变化能被识别并重新判断，数据驻留结论才不会在上线后迅速过期。

参考资料

• AI Data Residency Guide - Regions, Retention, and Privacy Controls
• Gemini Enterprise Agent Platform and zero data retention