跳到主要内容

主权崩塌:记录你的 Prompt 究竟去了哪里

· 阅读需 11 分钟
Tian Pan
Software Engineer

监管机构问了一个简单的问题:“对于上周二 UTC 时间 14:32 提交的这个特定用户 Prompt,请证明该请求及其派生状态经过了哪些管辖区。”

你的应用日志显示 model=claude-sonnet-4-5, region=eu-west-1, latency=2.1s。你的网关日志也显示同样的内容。供应商的发票确认了请求确实发生了。但这些都无法回答上述问题。该请求进入了一个由欧盟托管的网关,被转发到美国区域的主端点,但在一次区域性故障期间故障转移到了新加坡,并预热了一个第三方 GPU 池上的 KV 缓存,而该 GPU 池的数据驻留声明仅存在于供应商的脚注中。你所需要的审计追踪存在于一个你的团队并不掌握的层级中。

这就是主权崩溃:即你的合同中关于数据位置的承诺与你的运行时在事后能实际证明的情况之间的差距。合规主张的强度取决于链路中最薄弱的那行日志。

驻留是指数据存储在何处,主权是指谁控制数据

大多数工程层面的讨论都会在术语上犯错,因为数据驻留(Residency)和数据主权(Sovereignty)常被当作同义词对待。其实不然。驻留是一个物理事实:字节存储在法兰克福的一个磁盘上。主权是一个法律事实:谁持有密钥,谁可以被强制披露,谁承担合同义务。

一家总部位于美国的供应商在法兰克福运营一个区域,可以满足欧盟 Prompt 的驻留要求。但如果其母公司受美国法律约束,且无论数据存储在何处都可以被强制披露,那么它就不满足主权要求。将于 2026 年 8 月起分阶段实施的《欧盟 AI 法案》(EU AI Act)以及 GDPR 第五章的传输规则都涉及这一区别。Schrems 裁决后的格局也是如此,其中《欧盟-美国数据隐私框架》的充分性认定已经面临来自 noyb 的新一轮法律挑战。

对于推理负载而言,这意味着单个请求可能在每一跳都满足驻留要求,但如果其中任何一跳是由法律风险跨越边界的子处理器运营的,则仍会违反主权要求。审计追踪必须捕捉这两个维度:字节去了哪里,以及在每一步中谁拥有法律管辖权。

大多数团队没有记录的四个跳点

如今,来自欧盟居民的 Prompt 到达典型的 SaaS 应用时,触及的层级比任何单个团队能看到的都要多。追踪一个请求,你会发现至少有四个潜在的主权转移点:

  1. 应用网关:你自己的入口,通常托管在美国,负责终止 TLS、附加身份验证并记录入站请求。
  2. AI 网关或路由器:像 LiteLLM、Portkey、TrueFoundry 或自研的等效层级,负责选择模型和供应商、应用速率限制并转发请求。
  3. 主推理供应商:你的网关选择的模型端点。可能是一个区域端点,也可能是一个全局端点。故障转移行为通常写在条款细则中。
  4. 后备推理供应商:当主端点服务降级时,请求去往的地方。通常是不同的区域,通常是不同的子处理器,且几乎从未反映在你的应用日志中。

每一跳都有自己的日志面。每个表面都使用自己的请求 ID。几乎没有人会将一个统一的关联 ID(Correlation ID)贯穿所有四个层级,这意味着事后重建单个请求的路径需要跨越四个具有不同保留期和不同访问控制的日志系统进行关联。当监管机构的问题到来时,网关的调试日志往往早已被滚动覆盖。

将单次请求的主权路径作为一级日志字段

解决方案并非大动干戈。而是将主权路径作为每条请求的结构化日志字段,在掌握路由决策的层级主动写入,并作为标头(Header)向下游传递。

一个可行的模式:

  • sovereignty.gateway_region:入站终止的地点。
  • sovereignty.router_decision:选择了哪个供应商和哪个区域,以及原因(缓存局部性、成本、容量)。
  • sovereignty.provider_advertised_region:供应商宣称的此端点所属区域。
  • sovereignty.provider_actual_region:供应商在响应标头中实际返回的区域(如果他们有暴露)。
  • sovereignty.failover_chain:如果请求在执行过程中发生降级,所触及的区域有序列表。
  • sovereignty.cache_layer:是否涉及 Prompt 缓存或 KV 缓存,以及在谁的硬件上。
  • sovereignty.subprocessor_chain:触及请求的法律实体,派生自供应商与子处理器的静态映射表。

难点不在于模式本身。而在于第三到第七个字段需要供应商暴露他们通常不提供的信息。Anthropic 的 Bedrock 端点会告诉你 AWS 区域。直接调用 OpenAI 则暴露得较少。KV 缓存层几乎从未浮出水面。诚实的日志条目必须在你无法观测的步骤记录 unknown_after_handoff,因为假装知情比承认存在缺口更糟糕。

与运行时一致的合同边界

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates