那个脱敏了用户提问却遗漏了提示词缓存的 PII 脱敏器

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

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

这是双路径架构的典型失效模式：保护一条路径的清洗层被误认为能同时保护两条路径，因为架构图上在“数据进入系统”处画了一个统一的包围圈。这个包围圈其实是虚构的。入站的用户数据在触达边缘的那一刻就开始分流，每一个接触到原始字节的下游消费者都继承了其几乎肯定不知情的保留义务。

脱敏器完全是在按指令行事

标准架构中的脱敏层是一个 Presidio 或 AWS Comprehend 或内部构建的 NER 步骤，它拦截入站消息，将姓名、电子邮件、电话号码、账号替换为特定类型的占位符，并将脱敏后的版本转发给需要查看它的地方。转发目标是团队定义不明确的部分。在大多数技术栈中，脱敏器位于通往分析仓库和日志流水线的路径上，因为在一年前 GDPR 项目变得严肃起来时，隐私审查主要关注这些表面。

面向 LLM 的路径特意不进行脱敏，这有一个充分的理由。如果支持代理收到的是 <PERSON_1> 而不是客户的名字，生成的回答效果会变差；如果计费代理收到的是 <EMAIL_REDACTED>，则无法查询账户。模型需要原始值才能完成工作。拆分路径是正确的架构决策；缺陷在于模型处理完原始值后，这些原始值发生了什么。

提供商的 SDK 接收原始请求并对其进行签名。你的网关记录了排除 Body 的已签名请求——这很好。提供商返回响应。在这一往返过程中的某个地方，在你这一侧，一个 Prompt 缓存通过内容哈希作为键来存储请求，以便下一次语义相同的请求可以直接提供服务，而无需再次向提供商付费。这个缓存位于你的基础设施上。缓存的 TTL 是由部署 Redis 的工程师设置的。缓存的驱逐策略是 LRU，按内存预算大小设定，而不是按数据保留要求。没人告诉过这个缓存 GDPR 是怎么规定的。

无论你如何命名，Prompt 缓存都是数据存储

打破隐私边界的思维模型是将会话缓存视为临时性的。缓存给人的感觉是临时的，因为它们会驱逐数据，因为它们以内存大小衡量，因为代码中称其为缓存。但这些都不是 GDPR 所关心的。GDPR 关心的是欧盟居民的个人数据保留时间是否超过了合同允许的范围，无论出于什么原因，也无论存储层级如何。

典型 Prompt 缓存的实际保留行为并非临时性的。在高流量共享系统中的热点键可以在 Redis 中存放数月——LRU 驱逐的是冷数据，而不是核心热数据。为了通用的系统 Prompt 而在租户间共享的缓存会产生长尾的热点条目，因为变动点在用户消息端，这意味着用户消息内容（包括 PII）正是决定缓存键以及保留时长的部分。产生良好缓存命中率的工程决策，同样会导致随请求而变化的数据产生较长的保留窗口，而这正是隐私团队关心的。

主要提供商已经在这一领域发力。Anthropic 的托管型 Prompt 缓存文档规定了 5 分钟的默认 TTL 和 1 小时的可选层级，并明确声明缓存保存在内存中，不会进行持久化存储。OpenAI 的托管缓存与之类似，基准时间为 5 到 10 分钟，在扩展保留下最长可达 24 小时，且在组织层面进行隔离。两家提供商还提供零数据保留安排，其中缓存功能被排除在任何持久化之外。这些是提供商端的缓存。在上述事件中被数据驻留团队遗漏的缓存，是应用团队在提供商之前构建的那个，而那个缓存的运行时间取决于应用团队设置的任何 TTL。

两种缓存，两种风险

值得明确命名的架构区别：

• 提供商端缓存存在于 LLM 厂商的基础设施上。你可以影响它（缓存断点、可选的保留层级），但你不能配置它的 TTL 或手动驱逐条目。它的保留行为取决于厂商合同的规定。对于 Anthropic、OpenAI 和 Google，这都有明确的文档说明和范围界定。
• 应用端缓存存在于你的基础设施上，位于提供商之前。你构建它是为了在内容哈希匹配时完全跳过提供商调用，通常是为了节省成本而非降低延迟。它的保留行为取决于你团队的配置，而“你团队的配置”几乎总是“Redis 默认值加 LRU 驱逐策略”，因为发布缓存的工程师在优化命中率，而不是审计数据流。

第一种情况包含在厂商的数据处理附录中。第二种情况则在你的团队风险登记簿上，但通常它并不在那儿，因为构建缓存的团队向推理部门汇报，而维护数据清单的团队向隐私部门汇报，这两个部门在周三有一个会议，但会上任何一方都不会主动提起另一方从未询问过的基础设施。

加载中…