跳到主要内容

你的 Token 夜宿何方:LLM API 调用的数据驻留

· 阅读需 12 分钟
Tian Pan
Software Engineer

一份客户支持记录离开位于法兰克福的服务器,被拼接成一段提示词 (prompt),然后跨越大西洋传输到位于弗吉尼亚州的 GPU。模型思考了 800 毫秒。响应返回。从用户的角度来看,什么都没发生 —— 聊天正常进行。从你的监管机构的角度来看,你将个人数据转移到了第三国,而你可能无法说明其法律依据。

这是 LLM 落地过程中演示版本会隐藏的部分。原型调用 api.openai.com 然后上线。接着,来自德国银行、法国医院或你公司法务团队的采购问卷会提出一个原型从未需要回答的问题:推理在哪里发生,谁可以强制访问这些数据? “供应商符合 SOC 2 标准”是下意识的回答,但这是错误的 —— 它回答的是关于供应商内部控制的问题,而不是关于哪个司法管辖区的法院可以触及你的提示词。

推理的数据驻留 (Data residency) 不是你最后勾选的一个选项。它是一种架构属性,要么你在设计时就考虑到了,要么就没有。好消息是,现在每个主要供应商都提供了构建块。坏消息是,它们彼此之间以及与域外法 (extraterritorial law) 的交互方式,并不是“我们在欧盟地区托管”这句话就能涵盖的。本文旨在监管机构找上你之前,帮你弥补这一差距。

驻留不等于主权,SOC 2 两者皆非

有三个词经常被混用,但它们的含义各不相同,而这种混淆正是大多数合规失败的开端。

数据驻留 (Data residency) 是关于地理位置的陈述:字节在你指定的边界内(例如欧盟)进行处理和存储。这对于大多数监管制度是必要的,但仅凭这一点显然是不够的。

数据主权 (Data sovereignty) 是关于司法管辖权的陈述:无论数据物理位置在哪里,哪个国家的法律可以强制访问该数据。存储在巴黎服务器上的提示词在法国驻留。如果该服务器的运营商是一家在美国注册的公司,那么数据仍受美国法律程序的管辖。没有主权的驻留只是一张画错了领土、却让人感到安慰的地图。

SOC 2 是关于运营控制的陈述:供应商拥有经过记录和审计的安全性、可用性和机密性流程。它告诉你供应商不太可能因疏忽而泄露你的数据。它不会告诉你数据存储在哪里,或者谁的传票可以调取这些数据。一个供应商可以完美地通过 SOC 2 Type II 认证,但仍然在你监管机构禁止的地区处理你的每一个提示词。

当一份问卷询问数据驻留,而你团队中的某人以 SOC 2 报告作为回答时,他们在无意中转移了话题。有趣的问题不是“这个供应商是否谨慎?”,而是“如果外国法院命令该供应商交出我客户的提示词,该供应商能否配合 —— 而我是否会被告知?”

为什么“在欧盟托管”并非盖棺定论:云法案 (CLOUD Act)

驻留与主权产生分歧的原因有一个名字:2018 年美国《云法案》(U.S. CLOUD Act)。它允许美国执法部门强制任何总部位于美国的供应商提供该供应商控制的数据,无论该数据存储在何处。管辖权随供应商走,而不是随服务器走。

具体来说:如果你的 LLM 供应商是一家美国公司,即使在他们的法兰克福区域托管推理,也无法让数据避开美国的搜查令。数据在德国;运营公司的实体要服从美国法院。微软在法国的法务官曾在宣誓证词中表示,公司无法保证欧盟数据不受美国访问请求的影响。这不只是微软的问题 —— 这是结构性的,适用于每一家总部位于美国的超大规模企业 (hyperscaler) 和模型供应商。

这与 GDPR 正面冲突。第 48 条规定,外国法院披露个人数据的命令只有在基于司法协助条约等国际协议的情况下,才能在欧盟执行。而《云法案》则持相反观点 —— 美国供应商必须直接遵守美国的命令。你的供应商可能会被夹在两个互不相让的法律体系之间。根据《云法案》,供应商可能会在法律上被禁止告知你该请求的发生,这违反了你根据 GDPR 第 13–14 条对数据主体承担的透明度义务。

随之而来有两个实际影响。首先,“数据存储在哪里”是错误的分析维度;“谁控制运营基础设施的实体”才是正确的。其次,这正是我们现在看到主权云 (sovereign-cloud) 服务和在欧盟注册实体激增的原因 —— AWS 在 2026 年初推出了欧洲主权云 (European Sovereign Cloud),通过一家在德国注册的公司运营,在物理和逻辑上与其其他区域隔离,正是为了切断司法管辖的纽带。美国母公司的“主权”子公司是否真的能避开《云法案》仍是一个悬而未决的法律辩论。请将营销标签视为尽职调查的开始,而非结论。

供应商究竟为你提供了什么

令人振奋的进展是,推理的区域化处理已全面从“企业销售电话阶段”转向了“文档化功能阶段”。其实现形式各异,而这些差异至关重要。

  • OpenAI 通过区域端点(eu.api.openai.com)和项目创建时的区域选择,为 API 流量提供欧盟数据驻留。你可以选择数据的存储和处理位置。
  • Azure OpenAI 引入了数据区(Data Zones)—— 美国区和欧盟区 —— 在这些区域内处理和存储数据,同时涵盖其中的多个区域。这是在单一固定区域(有控制力,但存在容量和延迟风险)与全球路由(价格低廉且速度快,但对驻留权无感知)之间的一种务实折中方案。
  • Google Vertex AI 开放了比利时、荷兰和芬兰等欧盟区域用于区域化处理。
  • AWS Bedrock 允许你将推理固定在特定区域,而新的欧洲主权云(European Sovereign Cloud)通过独立的运营实体,在管辖权问题上走得更远。

一个容易让人掉以轻心的细节是:存储区域并不等同于处理区域。即使数据在推理过程中仅存在几毫秒 —— 从未写入磁盘,也从未记录日志 —— 如果它是在你的边界之外处理的,仍会被视为跨境传输。监管机构采用的定义是“数据流向何处”,而不仅仅是“数据存储何处”。如果一种配置将日志存储在法兰克福,却将实际的 Token 生成路由到全球池,那么它并没有实现数据驻留,只是制造了驻留的假象。

数据保留(Retention)是另一个维度。了解供应商保留 Prompt 和补全结果(Completions)的时长是驻留方案的一部分 —— 更短的、固定在区域内的保留窗口既能缩小你的暴露面,也能减少传票可能调取的数据量。请阅读数据处理条款,而不是官网主页。

在网关处构建边界,并设置为故障关闭

你不能指望通过要求每位工程师都记住调用正确的端点来强制执行数据驻留。控制必须存在于基础设施中,而最自然的位置就是 AI 网关 —— 这是一个位于你的应用程序与每个模型端点之间的代理,它根据策略而非代码编写者的意图来做出路由决策。

具有驻留感知能力的网关可以完成一些单靠 SDK 调用无法妥善处理的工作:

  • 区域锁定路由。 网关根据数据的管辖权决定每个请求由哪个端点提供服务 —— 标记为欧盟的流量只会到达欧盟端点。应用程序没有决定权。
  • 严禁静默跨区域回退。 这是真正能救命的一点。当欧盟端点容量超限时,诱人的做法是回退到美国区域以避免阻塞用户。这种异常路径是大多数现实世界驻留违规发生的地方 —— 它们并非发生在稳定状态下,而是发生在没人测试过的凌晨 3 点的降级模式中。一个正确的网关应当故障关闭(fails closed):如果请求无法在边界内处理,它应该报错,而不是悄悄跨境。
  • 区域本地审计日志。 谁在何时发送了什么以及在哪里处理的记录也必须留在边界内。如果将审计追踪发送到美国的日志集群,就会重新引入你费尽心思想要避免的数据传输。
  • 统一的执行和记录界面。 无论流量最终到达 OpenAI、Anthropic、Bedrock 还是内部模型,策略和日志记录都是统一的。驻留权变成了平台的属性,而不是取决于每个团队的自觉性。

网关本身的部署位置也是边界的一部分。如果执行欧盟政策的代理运行在 us-east-1,那么 Prompt 在到达欧盟模型之前就已经在美洲大陆上穿梭过了。请在要求数据留存的地方运行网关。

当地理位置不足够时:加密与密钥控制

有时,管辖权问题无法通过迁移服务器来解决,因为唯一可接受的供应商是受外国控制的,或者工作负载确实需要一个仅在你想避开的区域运行的模型。在 Schrems II 案后的世界中,人们达成的补充措施是技术性的而非地域性的:在数据跨境之前进行加密,并将密钥保存在你控制的管辖区内。

如果 Prompt 是使用由欧盟控制实体持有的密钥加密的,那么加密数据可以存放在第三国的基础设施上,因为那里的运营商没有解密能力。针对美国供应商发出的《云法案》(CLOUD Act)调取令只能得到密文。这在推理中比在存储中更难应用 —— 因为模型必须看到明文才能生成补全结果 —— 但它塑造了围绕调用的架构:客户管理密钥、多方审批解密,并尽可能保持明文窗口狭窄且本地化。对于最高敏感度的工作负载,这也是在你自己的边界内自托管开源权重模型的理由,这样任何第三方都根本无法接触到明文。

传输影响评估(Transfer Impact Assessment)的意义在于准确地记录这种逻辑:哪些数据移动到了哪里、受谁管辖,以及采取了哪些技术措施使残留风险处于可接受范围内。这并不是为了本地化而本地化 —— 而是一个经得起推敲的书面论据,即使在两年后监管机构查阅时依然有效。

在发布产品前需要问的问题

市场正朝着一个方向加速演进。Gartner 报告称,2025 年上半年关于云主权的咨询量增长了 300% 以上;分析师预计,到 2026 年底,全球大部分国家将确立区域性 AI 基础设施规则;《欧盟 AI 法案》的核心义务已于 2025 年 8 月生效,违规罚金高达数千万欧元。数据驻留(Residency)不再是某种向主流靠拢的小众企业需求——它已经身处主流之中。相比从第一天起就为此进行架构设计,事后在假设单一全球端点的系统上进行追溯性改造的成本要高得多。

因此,在发布下一个功能之前,请问一个在 Demo 演示中从未被提及的问题:对于这条特定的 Prompt,请明确它是在哪个司法管辖区处理的、运营该基础设施的实体是谁,以及当欧盟区域负载存满的那一天会发生什么。 如果对其中任何一部分的诚实回答是“我不确定”或“它会回退到美国”,那么你拥有的并不是一份数据驻留方案——你只是做了一个延迟优化,而监管机构最终会将其重新归类为非法数据转移。现在就构建边界,将其置于网关中,并确保其在故障时处于关闭状态(fail closed)。你的 Token 应当存放在一个你能在地图上指出来,并能在法庭证词中据理力争的地方。

References:Let's stay in touch and Follow me for more thoughts and updates