GDPR 数据驻留控制需要证据，而非承诺

EU 区域选择器很有用，但它不能证明个人数据始终留在该区域。买方需要追踪每一份副本，以及每一位能够访问它的人：在线数据库、对象存储、日志、备份、向模型提供商发出的请求、遥测数据和支持会话。如果有任何路径离开承诺的边界，数据驻留声明就需要相应的传输机制和证据支撑。

因此，评估 GDPR 数据驻留控制措施时，应把它们看作一条由可执行事实构成的链。控制台截图只能显示一个设置，不能说明该设置覆盖什么、管理员能否覆盖它，或发生事件时会怎样。采购团队应要求针对每项重大声明提供合同承诺、系统说明和可重复的测试。

本文为买方提供评估 AI 应用构建平台的实用标准，不能替代律师针对具体传输、司法管辖区或风险状况提供的意见。

区域固定必须定义每类数据

只有当供应商同时定义地理边界及其覆盖的数据时，区域固定才可信。「EU 托管」可能意味着主数据库位于法兰克福，而提示词发送到其他地点的模型端点，日志进入全球分析服务，备份在多个区域间复制。在供应商绘制数据流之前，这个标签说明不了多少。

要求提供数据位置附表，列出每类数据允许存储或处理的国家或国家集合。至少应涵盖应用记录、上传文件、提示词和模型回复、嵌入向量、密钥、身份验证数据、日志、指标、追踪信息、崩溃报告、支持附件和备份。还应说明「EU」指欧盟、范围更广的 EEA，还是供应商自行定义且包含其他国家的群组。

控制措施需要明确范围。所选区域适用于构建平台工作区、生成应用的生产运行时，还是两者都适用？它是否涵盖预览环境、分支部署、临时构建工作器、队列、缓存、搜索索引、内容分发缓存和灾难恢复副本？应用构建平台可能把成品数据库留在一个区域，却在别处处理源代码、提示词和构建输出。

要求供应商以书面形式说明例外情况。如果买方了解数据、目的、目的地、保留期限和保障措施，范围有限的例外可以管理。未定义的「运营数据可能在全球范围内处理」条款则会破坏控制效果，因为运营数据常包含用户标识符、请求路径、提示词片段和错误负载。

最有力的证据由三层构成。合同或订单表应写明承诺区域和变更流程。架构文档应把每类数据映射到服务和地点。API 响应或部署记录等技术记录，应能证明买方自身租户的设置。

例如，要求供应商提供结构稳定的租户记录：

{
  "tenant_id": "acme-eu",
  "workspace_region": "eu-central",
  "runtime_region": "eu-central",
  "backup_regions": ["eu-central", "eu-west"],
  "support_access_policy": "eea_only",
  "effective_at": "2026-07-01T00:00:00Z"
}

字段名称会因产品而异，关键在于该记录区分工作区、运行时、备份和支持策略，而不是把它们合并成一个绿色的「EU」徽章。应询问谁能更改这些值、买方能否发现变更，以及迁移后现有副本如何处理。

备份需要独立的数据驻留承诺

备份必须遵循明确的位置、保留、删除和恢复策略。它们有独立的副本、基础设施、访问路径和生命周期。若供应商只承诺「静态客户数据」的存放地点，可能并未承诺其备份库、快照或灾难恢复副本也遵守同一边界。

询问每一份备份副本的存储地点，包括数据库快照、对象版本、复制卷、配置备份和由提供商管理的恢复副本。要求供应商说明复制是否始终在同一国家内进行、是否在 EEA 国家之间移动，或是否进入第三国。高可用架构可以合理地使用第二个区域，但不会让第二个地点变得无关紧要。

保留期限的回答需要具体数字和事件。采购团队应取得常规备份保留期、任何更长期归档层、过期介质变得不可恢复所需时间，以及合同终止后备份的处理方式。「按政策删除」无法测试。明确写明每日恢复点在指定期限后到期，终止租户的备份在指定时间内不可访问并逐步过期的附表，才可以验证。

逻辑删除和物理到期并不相同。已删除的记录可能仍保留在加密备份中，直到该恢复点到期。这可以符合已记录的保留设计，但供应商应说明如何避免常规恢复悄然重新激活已删除数据。成熟的恢复流程会重放删除标记，或在系统恢复服务前进行恢复后核对。

要求提供一份近期恢复测试材料，并删除敏感细节。它应标明源备份区域、恢复目的地、参与人员或服务角色、审批记录，以及恢复副本的处置方式。通用灾难恢复政策只能证明有人写过政策，恢复记录则证明运营流程知道副本去了哪里。

加密不会消除地点问题。特别是在密钥与管理角色分离时，它能降低风险，但位于第三国的备份仍可能构成需要有效机制和评估的传输。采购团队应记录密钥所有权、密钥位置、恢复权限，以及提供商人员能否在恢复期间取得明文。

子处理者清单必须说明真实链路

有用的子处理者登记册会将每家公司与目的、数据类别、处理地点和传输依据关联起来。只有徽标或法人名称的列表只是库存，不足以说明买方数据如何流动。AI 应用构建平台通常依赖云托管、模型提供商、可观测性服务、邮件发送、身份验证、客户支持和滥用监测。每个角色都可能看到不同部分的数据。

GDPR 第 28 条要求处理者在委任另一名处理者前取得事先的具体或一般书面授权。采用一般授权时，处理者必须通知控制者拟议新增或替换的处理者，以便控制者提出异议。采购团队应把这一规则转化为运营要求：稳定的登记册、通过买方持续关注的渠道提前通知、明确的通知期限和说明异议流程的条款。

登记册应针对每个子处理者回答五点：

• 接收或可访问数据的法人实体
• 服务及其具体处理目的
• 个人数据类别和受影响的产品功能
• 存储和远程访问所在国家
• 适用的传输机制及后续子处理者路径

不要接受把「云基础设施」当作模型服务的位置说明。应询问提示词是否发送给模型提供商、提供商是否保留提示词、人工是否可审阅提示词，以及买方能否禁用某个提供商或选择端点。如果构建平台混用多个模型，路由逻辑就很重要：项目选定的区域无法控制路由层发送到未获批准端点的请求。

变更通知必须在变更生效前送达。可在不通知的情况下变更的网页，会让采购团队不得不持续人工监控。合同语言应说明通知包含哪些信息，以及提出合理异议后会怎样。供应商不必承诺其供应链永不变化，但买方需要时间在数据开始流动前评估新的传输。

尽职调查期间，应要求供应商核对三项内容：公开登记册、DPA 附件和当前架构或数据流图。供应商迁移后，文件中的名称和地点常会逐渐不一致。出现不一致不必然意味着控制措施失效，但在供应商解决之前，买方没有可靠记录。

DPA 应把设置转化为义务

数据处理协议应明确适用于已购买服务的处理指示、安全义务、删除条款、审计权和子处理者控制。产品文档可以解释功能，但 DPA 和订单文件决定供应商向这位买方承诺了什么。

GDPR 第 28(3) 条列明控制者与处理者合同必须涵盖的要素，包括处理事项和期限、性质和目的、个人数据类型、数据主体类别、保密、安全协助、删除或返还，以及证明合规所需的信息。欧洲数据保护委员会的《指南 07/2020》也提出有益提醒：处理协议不应只是重述 GDPR，而应包含关于如何满足要求和所需安全水平的具体信息。

这种具体性对数据驻留很重要。应附上一份附表，标明买方选定区域、覆盖环境、获准的远程访问国家、备份地点和获准的子处理者。写明未经约定的通知或变更流程，供应商不得实质性扩大这些地点。如果销售材料写着「仅 EU」，而 DPA 允许在供应商或其关联公司运营的任何地点处理，二者冲突时应以合同为准。

还应审查角色分配。对于仅按买方指示、为提供服务而使用的客户内容，供应商通常作为处理者。供应商可能就计费、账户安全、防欺诈或自身法定义务主张独立控制者角色。无需看到独立目的就一概拒绝，但应要求供应商列出这些目的、数据类别、法律依据、保留期限和共享方式，而不是把它们隐藏在广泛使用所有服务数据的权利中。

AI 训练需要明确无歧义的条款。询问供应商或任何模型提供商是否会使用提示词、应用数据、源代码或输出，训练或改进通用模型。如果不会，应把这项限制写入 DPA 或有控制效力的产品条款，并延伸至子处理者。如果取决于某项设置，应记录其默认值、管理员、范围和审计轨迹。

审计条款应能产出有用证据，同时不要求对多租户设施进行无限制访问。独立鉴证报告、渗透测试摘要、安全文档和有针对性的书面回复可以满足日常审查。如果这些材料无法解决重大疑虑，或事件使控制措施受到质疑，买方应保留获取补充信息或进行适度审计的途径。

SCC 仅解决传输的合同部分

标准合同条款可以作为第 46 条的传输工具，但签署它们并不能证明每项传输都合法或得到充分保护。买方必须选择正确模块、完整填写附件、绘制后续传输链路，并评估这些条款在目的地和相关数据情境下是否有效。

欧盟委员会 2021 年 SCC 根据各方角色分为四个模块。典型情况下，将数据发送给 EEA 以外处理者的 EEA 客户可以使用模块 2。向第三国子处理者发送数据的处理者可能需要模块 3。正确选择取决于谁是出口方、谁是进口方，以及进口方是否已因该处理活动受 GDPR 约束。因此律师应确认整条链路，而不是把模块 2 粘贴到每份协议中。

完整填写的附件就是证据。它们应列明各方、数据主体、数据类别、敏感数据及保障措施、传输频率、目的、保留期限、主管监管机构、技术和组织措施，以及子处理者。空白附件、「所有客户数据」之类的笼统描述，或承诺以后再补充细节，都会让条款脱离实际服务。

EDPB 的《建议 01/2020》提出六步方法：了解传输、识别传输工具、评估第三国法律或实践、必要时采取补充措施、完成正式步骤，并在适当时间间隔重新评估。该建议还将从第三国的远程访问视为传输。这正是只关注存储地图的买方常忽视之处。

传输影响评估应与具体服务相匹配，不能只是通用法律备忘录。它应识别进口方和目的地、受影响的数据和人员、访问路径、适用法律和实践、政府访问风险、后续传输和补充措施。还应记录谁批准了评估，以及什么变更会触发重新审查。

只有加密设计解决访问风险时，加密才有帮助。如果服务需要在目的地国家向支持人员或模型端点解密提示词，传输中的加密无法阻止接收方读取数据。有效的补充措施可能包括严格的访问隔离、在接收方无法获得重新识别数据时使用假名化、对可保持不透明的工作负载使用客户控制密钥、记录访问日志，以及在法律允许时承担质询或通知义务的合同条款。

充分性认定可以改变某个目的地的法律路径，却不会免除了解目的地或控制处理者的必要性。采购团队应要求供应商说明哪些传输依赖充分性认定，哪些依赖 SCC 或其他机制。答案应写入传输清单，而不是用一句「供应商遵守 GDPR」的笼统表述带过。

支持访问发生在操作人员所在地点

如果 EEA 以外的操作人员可以查看个人数据，即使数据库从未离开 EU 区域，远程支持访问也是数据传输。应将支持地点、授权和会话证据视为数据驻留控制。存储地点和人工访问地点回答的是不同问题。

要求供应商区分常规支持和特权工程访问。一线客服可能需要账户元数据，但不需要生产内容。值班工程师可能需要在严重事件期间获得临时访问。控制措施应让每个角色只获得完成工作所需的最少数据和最短时间，对生产访问设置更严格的审批。

采购团队应要求具名的访问地点或可执行的区域策略，不能接受没有国家清单的「全球跟随太阳支持」。供应商应披露可获得生产访问权限的员工、关联方和承包商、他们工作的国家，以及每条非 EEA 路径适用的传输机制。如果紧急访问能够覆盖地点限制，应记录触发条件、审批人、时长和对买方的通知。

在批准前或概念验证期间进行支持访问测试：

1. 在合同约定的 EU 区域创建测试租户，并添加一条独特的合成客户记录。
2. 创建一个通常需要检查的支持工单，但不要把该记录粘贴进工单。
3. 要求供应商展示访问请求、审批人、操作人员所在国家、授予的角色和到期时间。
4. 确认会话日志记录租户、操作、时间戳和理由，同时不将敏感内容复制到日志中。
5. 撤销访问权限，然后要求提供证据，证明该角色或会话已无法再访问该租户。

应使用合成数据，因为尽职调查测试不应造成新的暴露。预期输出是一套小型证据包：工单标识符、审批事件、临时授权、会话审计条目和撤销事件。如果供应商无法在共享服务中进行实时测试，应要求其提供近期的脱敏样本，以及与已记录控制措施相关的演示说明。

紧急访问也需要同样严格的审查。它可以跳过常规审批以恢复服务，但绝不能跳过身份识别、日志记录、到期和事后审查。应询问供应商如何防止员工用紧急角色进行日常调试，以及买方如何得知此类访问已发生。

不要默认要求屏幕录制。录制内容可能产生另一份包含个人数据和凭据的高价值副本。结构化审计事件通常以更少暴露提供更好的证据：谁访问了哪个租户、来自哪个国家、依据哪个工单、使用什么角色、持续多久，以及进行了哪些类别的操作。

证据必须经得起变更和事件考验

采购团队应收集带有负责人、日期、范围和更新触发条件的证据。销售审查期间的漂亮答复，可能在供应商新增模型提供商、迁移支持团队、变更备份设计或推出新区域时过期。证据管理是控制措施的一部分，不是决策后的归档工作。

在审批记录中使用控制到证据矩阵。每一项设置四个字段：控制声明、合同证据、技术证据和更新触发条件。

1. 对于获准的工作区和运行时区域，将订单表和位置附表与租户区域记录、数据流图放在一起。区域或架构变更后更新。
2. 对于备份地点，将备份和删除附表与恢复测试记录配对。备份提供商或灾难恢复变更后更新。
3. 对于获准的子处理者链，将 DPA 授权条款与已和架构核对的登记册配对。收到新增或替换通知后审查。
4. 对于第三国传输，将 SCC 或充分性认定依据与传输清单和评估配对。目的地、法律或访问方式变更后审查。
5. 对于支持地点，将支持访问附表与审批、会话和撤销日志配对。支持国家或角色变更后更新。

每一行都要在双方指定负责人。供应商负责人应答复变更和证据请求。买方负责人决定一项通知是否需要隐私、安全、工程或法律审查。没有明确审核负责人的共享邮箱不是运营控制措施。

定义通知门槛。仅发送服务状态邮件的新子处理者，可能比接收提示词的模型提供商需要更轻的审查。新增备份国家、扩大支持地点、改变训练用途，或覆盖合同约定区域时，应在买方完成评估前暂停新的敏感部署。

事件证据应说明数据驻留边界是否得到遵守。要求供应商的事件流程保留相关区域配置、管理变更、支持访问、导出事件和子处理者参与记录。DPA 应规定通知义务和合作条款，事件运行手册则应列出能回答受影响数据在哪里存储和被查看的记录。

认证可以支持这份材料，但不能替代针对服务的具体答复。鉴证报告可能测试访问管理和备份控制，却未说明某个租户购买的确切区域。应将报告的范围和例外映射到控制行，再用合同或租户证据补齐剩余空白。

要求应产生可验证的答案

应编写让供应商能够回答「是、否或不适用」，并附上具名材料的数据驻留要求。宽泛问题只会引来宽泛保证。「说明你们的 GDPR 做法」会产生数页精美文字，却几乎没有审批证据。将要求与数据、地点、行为和证明关联起来，能迅速暴露缺口。

可行的托管要求可以这样写：「除附表 B 所列传输外，供应商只能在附表 A 所列国家存储和处理生产客户内容、提示词、生成的源代码和身份验证记录。」附表与这句话同样重要。附表 A 定义获准边界，附表 B 迫使双方明确列出例外，而不是依赖隐藏在其他地方的一般权利。

针对不同控制措施使用独立要求。以下提示适合用于 RFP 或安全补充协议：

• 列出所有不继承租户所选区域的服务组件，并说明其数据、国家、目的和保留期限。
• 识别人员可以从哪些国家访问生产内容，并附上此类访问的审批和日志标准。
• 说明每个备份和灾难恢复地点、保留期限、删除事件和允许的恢复目的地。
• 提供当前子处理者登记册，并标注哪些实体可以接收提示词、源代码、应用记录或支持附件。
• 将每项第三国传输映射到充分性认定、SCC 模块或其他依赖机制，并提供评估负责人和审查日期。

避免使用架构无法合理满足的绝对措辞。「任何数据都不得离开德国」可能意外禁止向身在国外的买方管理员发送邮件，或禁止获授权用户旅行时阅读应用。应定义要求涵盖供应商控制的存储和处理、网络传输、买方用户访问，还是所有情形。精确性会让保护更强，因为每个人都能识别违规行为。

在发出问卷前，将强制控制措施与偏好分开。如果仅限 EU 的支持访问是强制要求，就应明确说明，并拒绝冲突的设计。如果只是偏好，则应评估有传输工具和保障措施记录的第三国路径。当买方把每个问题都标为「关键」，却在商业谈判中放弃其中一半时，供应商给出的答复会不可靠。

要求证据保持时效性。架构图和子处理者登记册应标注生效日期。合同附件应说明其覆盖的服务版本或产品方案。运营样本应来自当前控制措施，而不是已退役系统。为可能变化的证据设定到期或事件触发的审查，而永久签署的条款则在修改前持续归档。

最后，应明确冲突之处。供应商应指出任何依赖高级套餐、可选配置、客户操作或计划功能的答复。采购团队随后可以将前提条件写入订单，并交给实施负责人。若没人知道谁必须开启某个设置，依赖该设置的控制措施就会失效。

评估声明，而不是销售语言

买方可以通过确认每条重大数据路径是否具备三种证明来评估数据驻留准备度：有约束力的承诺、最新的系统说明，以及租户专属或近期的运营证据。缺少任何一层，都会形成明确的后续问题，而不是围绕供应商是否「符合 GDPR」展开模糊争论。

使用四种决策状态：

• **已验证：**证据相互一致，覆盖已购买的服务，并有更新流程。
• **有条件批准：**有限缺口有负责人、截止日期和补偿控制措施。
• **受限：**服务只能处理适合已定义低风险用途的数据。
• **拒绝：**一条重大传输或访问路径仍然未知、没有边界，或合同允许的内容违背买方要求。

这种方法还能避免两种不良采购习惯。第一种是仅因为全球供应商在欧洲以外有员工就拒绝它，即使这些员工无法访问买方环境。第二种是未检查模型路由或支持访问，就批准「EU 托管」产品。司法管辖区分布只是背景，实际数据流和可执行控制措施决定暴露程度。

应把评分应用于所购买的确切版本和配置。安全材料中描述的企业级控制措施，可能在免费或自助套餐中不存在。区域选择可能只适用于托管生产环境，而预览或构建平台工作区遵循默认地点。应在订单表中记录前提条件、套餐限制和设置，确保获批设计与管理员实际可部署的内容一致。

Koder.ai 可以在不同国家的 AWS 基础设施上运行应用，但买方仍应要求将所选国家、覆盖组件和访问路径写入证据包。产品能力开启对话，采购证据完成审批。

对于个人数据进入服务前必须具备的控制措施，不要接受路线图承诺。路线图可以支持未来重新评估。在功能真正存在，且供应商能够承诺、说明并证明之前，应限制工作负载或选择其他设计。

审批记录应以剩余风险收尾，而不是营销结论。写明任何获准的跨境访问、法律路径、暴露的数据、补充措施，以及接受该风险的人员。这样的记录能让隐私团队有据可依，也能让工程团队获得真正可执行的边界。