LLM 流水线中的 PII：那些你不知道直到为时已晚的数据泄漏
每个构建过 LLM 功能的工程师都说过类似的话："我们很谨慎——不会向模型发送 PII。"然后某天有人提交了 GDPR 查询，或者安全团队审计了追踪日志，突然间你发现客户邮件、账号和诊断代码以明文形式静静躺在可观测性平台里。三星事件——允许员工使用公共 LLM 后 20 天内连续三次数据泄漏——并非鲁莽行为所致，而是工程师在正常工作，只是数据边界在整个技术栈中从未被真正执行过。
问题在于，"不要向 API 发送 PII"是一项政策，而非一种控制手段。而政策会在你的系统做任何比单轮聊天机器人更复杂的事情时失效。
PII 真正进入 LLM 技术栈的五个地方
大多数团队只审计了显而易见的路径——用户的输入消息、系统提示——然后就此 打住。真正的暴露面要宽得多。
带动态注入的提示模板。 系统提示通常在构建时从用户上下文中提取数据：账号等级、历史交互、当前状态。当这个完整拼装好的提示被记录时——每个框架默认都会这样做——日志条目就包含了你注入的所有内容。你的错误追踪器、APM 仪表板、LangSmith 追踪：它们现在都持有你所注入内容的副本。2024 年的一项研究发现，8.5% 的生产 LLM 提示包含潜在敏感数据，而大多数团队并不知道这些数据就在那里。
RAG 流水线中的嵌入步骤。 当你为文档创建嵌入向量以供检索时，你将原始文本发送给嵌入 API——OpenAI、Cohere、Voyage。如果你的文档库包含员工记录、患者病历或客户合同，所有这些数据都会以明文形式作为嵌入调用的一部分传递给第三方服务商。大多数团队会对进入 LLM 上下文的内容进行 PII 审计，几乎没有团队会对发送到嵌入端点的内容进行同样的审计，尽管数据格式完全相同。
注入到上下文中的检索块。 当你的 RAG 系统执行 top-k 检索时，它可能会拉取包含其他用户数据的文档。如果块级别缺少访问控制，针对某个客户的支持工单检索可能会暴露另一个客户的订单详情。LLM 随后会在同一个上下文窗口中对来自不同访问域的混合数据进行推理。这就是 DEAL 攻击利用的向量：攻击者可以精心构造查询，诱使模型以接近 99% 的准确率浮现其检索到的私密文档。
工具调用结果和智能体记忆。 当 LLM 智能体调用数据库查询工具或外部 API 时，结果会落入上下文窗口，并像其他所有内容一样被记录。一个为回答福利问题而获取用户医疗历史的智能体，现在已将那些 PHI 数据存入你的追踪日志、向量记忆存储，如果你在收集反 馈数据，还可能存入你的微调数据集。2024 年 ACL 关于 LLM 智能体记忆中隐私风险的论文记录了敏感数据如何以违背用户合理预期的方式跨会话持久存在。
微调放大效应。 如果你在没有先进行 PII 清洗的情况下对生产数据进行微调，模型会记住这些数据。研究发现，在包含个人信息的数据集上微调的模型输出中，PII 泄漏率约为 19%。与数据泄漏不同，你无法给模型权重打补丁。
为什么检测比看起来更难
直觉上的做法是对出站请求运行正则扫描就完事了。正则表达式能很好地捕获结构化 PII——社会安全号码、信用卡、电子邮件地址——但它会漏掉生产环境中大多数重要的内容。
嵌入在句子中的姓名不匹配任何模式。"预约安排在 Sarah Chen 下午 3 点"通过正则过滤器不会触发任何标记。组织名称、职称、地点引用以及关系背景（"患者的丈夫"）在语义上都是 PII，但在句法上对模式匹配完全不可见。在医疗或法律流水线中，非 PII 标记的组合即使每个标记单独看都是安全的，也可能识别出某个人。
当前生产级别的方法是分层流水线：
- 第一层（正则）： 结构化实体的快速路径——电子邮件、电话号码、社会安全号码、通过 Luhn 验证的信用卡号、API 密钥模式（
sk-...、AKIA...）。亚毫秒级，确定性，能捕获结构良好输入中 60-70% 的 PII。 - 第二层（NER 模型）： 非结构化 PII 的命名实体识别。Microsoft Presidio 是标准的开源框架，将 spaCy NER 与正则层和金融标识符的校验和验证相结合。在 2025 年，从业者正在用 GLiNER 或 DeBERTa 微调模型替换 Presidio 默认的 spaCy 模型，在真实文本上获得 10-20% 更好的召回率。
- 第三层（LLM 消歧，可选）： 对于高风险流水线，轻量级 LLM 可以解决模糊情况——"Michael"是人名还是项目代号，"Apple"是公司还是食谱中的水果。这会增加延迟和成本，仅在处理受监管数据时才合理。
Roblox 在 2025 年底公布了他们的生产数据：使用 XLM-RoBERTa-Large 配合 GPU 推理，以每秒 20 万次查询的速度达到了 98% 召回率、1% 误报率、94% F1 分数。基准对比触目惊心——更简单的现成模型在同一语料库上的准确率仅为 13-27%。
真正可扩展的假名化架构
阻止所有 PII 到达模型通常过于严格。LLM 经常需要这些数据来完成工作——一个看不到诊断信息的医疗编码助手什么也编不了。解决方案是让模型看到数据，但看不到真实数据。
基于保险库的假名化工作原理如下：
- 检测层扫描入站提示并识别 PII 实体。
- 每个实体被替换为类型化令牌——
<PERSON_1>、<DATE_OF_BIRTH_1>、<MRN_1>——映射关系存储在会话级保险库中。 - 去识别化的提示发送给 LLM API。模型对令牌而非真实数据进行推理。
- LLM 响应中包含相同的令牌。
- 在将响应返回给用户之前，去匿名 化层还原原始内容。
LangChain 的 PresidioReversibleAnonymizer 实现了这一模式。对于生产安全要求，Skyflow 等商业保险库服务提供确定性令牌化（相同的 PII 值始终映射到相同的令牌，实现跨会话的引用完整性）和对谁可以去令牌化的细粒度访问控制。
一个不太显眼的实现细节：简单的占位符替换会降低模型质量。"医生给 [已编辑] 开了药"与"医生给 <PERSON_1: 女性, 34岁> 开了药"产生的推理不同。使用带轻量级元数据的类型化占位符，或 Faker 生成的逼真替代数据，能在保持模型推理链语义连贯性的同时，将真实数据排除在提示之外。
可观测性陷阱
这里有一个几乎每个团队最终都会遭遇的失败模式：你在发送给模型的数据上实施了 PII 控制，然后为了调试而记录所有出站内容，结果你的追踪日志变成了 RAG 系统检索过的每一份敏感文档的副本。
LangSmith 默认捕获每次链运行的所有输入和输出。如果你没有明确配置掩码，你的 LangSmith 工作区就有每条提示的完整记录，包括从 RAG 检索注入的上下文。Langfuse、Datadog LLM 追踪以及基于 OpenTelemetry 的 LLM 自动检测流水线也是如此。
Langfuse 在这里有最简洁的架构：它提供了一个原生掩码 API，你将掩码函数传递给客户端构造函数，所有追踪数据在传输前在客户端进行处理。这意味着 PII 永远不会以未掩码形式离开你的进程。Langfuse 还支持完全自托管，这将追踪数据完全保留在你的安全边界内。
对于 OpenTelemetry 流水线，2024 年的 GenAI 语义规范将提示内容存储在 span 事件而非属性中，这样做的目的正是允许在 OTel Collector 层通过自定义处理器将其丢弃，而无需修改应用代码。这是受监管环境的正确架构方法：在收集器处编辑，将结构性元数据（延迟、令牌计数、错误代码）与内容分开记录。
原则：像对待 LLM API 一样对待你的可观测性后端。你的 LLM 提供商有 DPA，你的追踪 SaaS 有吗？
监管环境的真实要求
意大利数据保护机构在 2024 年底以违反 GDPR 为由对 OpenAI 处以 1500 万欧元罚款，理由包括隐私通知不足、缺少年龄验证以及未报告数据泄漏。该案正在上诉中，但信号很明确：监管机构不再把 LLM 隐私违规视为新颖的灰色地带。
EDPB 2025 年 4 月的意见明确设定了标准：只有当从 LLM 中提取个人数据的可能性在考虑所有合理可能使用的手段后微不足道时，该 LLM 才被视为"匿名"。大多数生产 LLM 达不到这个标准。这意味着在包含个人信息的数据上训练的模型在 GDPR 下处理的是个人数据，部署该模型的数据控制者需要合法依据。
对于美国医疗行业，HIPAA 要求与任何处理受保护健康信息的供应商签订商业伙伴协议——包括 LLM API 提供商。Azure OpenAI、AWS Bedrock 和 Google Vertex AI 都提供符合 BAA 条件的企业版。消费级 API 访问不符合条件。在没有 BAA 的情况下通过追踪平台发送患者病历，无论是否有人实际访问这些日志，都是违反泄漏通知规则的未授权披露。
实际上，这意味着：
- 记录个人数据可能 接触 LLM 或嵌入 API 的每一个数据流，包括可观测性层。
- 使用带有签署 DPA 或 BAA 的企业级 API 产品。验证你的可观测性供应商也有相应协议。
- 不要对单个用户数据进行微调，除非你有明确的保留和删除策略——并且要理解，一旦数据进入权重，你就无法删除它。
- 在 PII 编辑之后对所有 LLM 交互进行审计日志记录，而不是之前。
整合起来：防御技术栈
LLM 产品的实用 PII 防御不是单一控制措施——而是一组相互联锁的层次：
- 在摄取时： 在所有用户输入和 RAG 检索块进入提示之前，对其运行分层 NER 检测。根据是否需要数据可恢复来应用编辑或假名化。
- 在嵌入时： 在将文档文本发送到嵌入 API 之前，应用相同的检测流水线。这一步通常被遗忘，因为它感觉像"预处理"，但数据暴露程度完全相同。
- 在检索时： 在块级别实施访问控制，范围限定于请求用户的权限。不要依赖 LLM 来执行访问边界——它做不到。
- 在可观测性层： 在导出追踪数据之前配置掩码，或自托管可观测性技术栈。尽可能记录结构而非内容。
- 在微调时： 永远不要对原始生产数据进行微调。先运行 PII 清洗，在训练前验证输出。
IBM 2025 年数据泄漏成本报告发现，影子 AI 事件——员工通过绕过企业控制的个人 LLM 账户路由敏感数据——每次事件平均增加 67 万美元的损失。LayerX Security 发现，上传到 AI 聊天机器人的文件中有 40% 包含 PII 或 PCI 数据。"我们有政策"和"数据实际上不会泄漏"之间的差距，正是大多数事件的发生之处。
弥合这一差距的团队并没有做什么特别的事情。他们应用的是针对 SQL 注入或 SSRF 同样有效的纵深防御原则：假设边界会被突破，在每一层构建控制措施，并验证它们确实在生产环境中运行。
"就是不发送 PII"的政策听起来是对的。但一旦你添加了检索、工具使用或任何形式的会话上下文，它在设计上就是不完整的。上述技术栈才是让那个政策成为现实所需要的。
