跳转到主要内容

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

阅读需 2 分钟Tian PanTian Pan

监管机构问了一个简单的问题:“对于上周二 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,因为假装知情比承认存在缺口更糟糕。

与运行时一致的合同边界

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 10 分钟

被反向代理剥离的 SSE Keep-Alive,以及你支付了两次费用的 Prompt

LLM 流式响应看起来像是从模型到用户的通畅管道 —— 直到一次 35 秒的工具调用导致反向代理断开连接,你的客户端针对无状态 API 重试整个 Prompt,最终用户的账单为同一个响应支付了两次费用。

insider
ai-engineering
阅读需 11 分钟

长出胳膊和腿的缓存提示词前缀

六个月前你的提示词前缀是 4k tokens,几乎可以摊销到免费。今天它是 11k tokens,你的缓存命中率是 31%,没有人能指出是哪个 PR 干的。

insider
llm
阅读需 10 分钟

物理隔离 LLM 蓝图:无出站流量部署的真正需求

云端 AI 栈将出站 HTTPS 视为一种免费的原语。拔掉网线后,每一层(从模型溯源、评估到集群管理和遥测)都必须被迫重新构建那些在云端版本中被悄悄隐藏的原语。

insider
ai
阅读需 11 分钟

供应商将你的模型标识符重定向到特定租户的微调模型,而其他人使用的却是基础模型

如果将 LLM 模型标识符视为权重的名称而非路由决策的标签,那么供应商可能会在评估套件仍保持“绿色”通过状态时,静默地将你的租户从微调模型切换回基础模型,导致客户最先察觉到问题。

insider
llm
阅读需 10 分钟

多区域 LLM 服务:没人警告过你的缓存局部性问题

在不同区域部署 LLM 推理会产生无状态 HTTP 服务所没有的一致性和延迟问题。本文将介绍一种既能解决这些问题,又不会让你的运维负担增加三倍的路由架构。

insider
llm