5 篇博文 含有标签「data-residency」

你的驻留审计追踪了来自租户流量的每一个出站请求，观察它在法兰克福的一个主机名上终止，并签了字。审计对它所测量的一切都是正确的。但它也看错了层级。请求确实去了欧盟。但满足该请求的字节——即服务商哈希并从最近可用节点提取的缓存前缀——却存放在 us-east-1。你的区域端点向你承诺了一个目的地。而缓存什么也没承诺，因为缓存是一个不同的产品，受不同的 SLA 约束，是为成本而非合规而设计的。

客户的审计员发现了它。不是你的。另一个供应商的事件报告提到 Prompt 缓存的放置与推理区域是解耦的，于是客户的 GRC 团队提出了那个显而易见的后续问题：我们的前缀去了哪里？修补这一差距的合同修正案花了 90 天。续约被暂停了。根据他们拿到的文档，编写集成的团队并没有做错任何事。

一次客户审计发现，在 Redis 集群中存放了长达 11 个月的逐字记录的用户 PII，而数据驻留团队中没人知道这个集群的存在。系统并未遭到破坏。没有攻击者入侵。这些数据是推理团队为了性能优化而构建并命名为“Prompt 缓存”的服务故意写入在那里的。分析路径上的脱敏工具在此期间运行得非常完美。只是脱敏工具根本没在那条路径上。

尽管如此，违规行为是真实的。根据 GDPR，保留时间超过合同约定的 30 天就已经足够；数据无需泄露即可触发第 33 条规定的通知义务。数据驻留团队的清单列出了每一个日志、每一个仓库、每一个队列——但唯独漏掉了这个缓存，因为在组织架构图中，这个缓存位于推理团队的一侧。每个人都信任的隐私边界直接顺着分析流水线向下延伸，却在大模型（LLM）栈开始的地方止步了。

交付 “面向欧盟客户的 AI” 的团队通常只交付一种驻留控制：锁定在欧盟地区的推理端点。采购团队拿到 DPA，架构图在 “模型托管在法兰克福” 旁边打上绿色对勾，接着发布。架构图中没显示的是：客户的原始查询在前往模型的途中被美国托管的嵌入 API 向量化；查询与之匹配的向量存储的运维平面位于 us-east-1；重排序模型是部署在供应商自选地区的第三方 SaaS；提示词缓存在命中的情况下是按地区键入的，而在未命中的情况下则是全局的；记录检索块的追踪存储有一个 30 天的保留期存储桶，并为了冗余进行跨区域复制。

推理层遵守了驻留规定。而检索流水线甚至不知道自己也是参与者。

这就是大多数 “符合 GDPR” 的 RAG 部署在面临团队甚至没意识到会到来的审计时失败的缺口。修复方案不是针对模型调用增加另一个控制 —— 而是意识到数据驻留是客户字节所接触的每个组件的属性，并且拥有 “LLM” 的团队最多只拥有涉及到的六个表面中的一个。

合规审计总是从同一个问题开始，而你的团队也总是以同样的方式回答：“客户数据在哪里处理？”在欧盟（EU）地区。幻灯片是这么说的，SDK 配置截图证实了这一点，DPA（数据处理协议）也做出了承诺。接着，审计员提取了上个季度的请求日志样本，将其与服务商的每请求区域头信息（per-request region header）进行比对，房间里顿时安静了下来。在大约 40 分钟的容量事件期间，大约 4% 的欧盟企业 Prompt 由美国区域的推理节点提供服务，而团队对此一无所知。保存可重用前缀（prefixes）的缓存位于全球池中。支持团队查询的追踪存储（trace store）位于 us-east。DPA 成了幻灯片。合同成了一个路由提示（routing hint）。

这种事件不会出现在事后分析（postmortem）中，因为没有任何服务降级。模型返回了答案，用户得到了响应，延迟图表保持平稳。出故障的是仪表盘从未监测到的东西：请求穿过服务商基础设施的地理路径。那些绝不会将 us-east-1 的 URL 与“请求实际上在 us-east-1 执行”混为一谈的工程师，在 LLM API 层级却经常犯同样的错误，因为服务商的区域参数看起来像 AWS 的参数，在正常路径（happy path）下表现也像 AWS，但一旦首选区域的 GPU 耗尽，它就会静默降级为“尽力而为（best effort）”模式。

工程师为多区域 AI 部署做预算时，通常只考虑两个变量：每个区域的基础设施成本和复制开销。而真正被严重低估的，是上线之后才会暴露的三类成本：模型版本不一致导致欧盟集群与美国集群产出不同结果、KV 缓存隔离使 GDPR 区域内每个 token 的生成成本更高，以及重试逻辑将法国用户数据悄悄路由到弗吉尼亚时触发的静默合规违规。

一家德国银行为满足 GDPR 要求，花了 14 个月将一个大型开源模型部署在本地。这并不罕见。真正罕见的是，提出该架构方案的工程师从一开始就理解了合规约束。大多数团队直到事故报告出现才被迫面对这个问题。