生产环境中的 LLM 流水线在哪泄露用户数据：PII、数据驻留以及经得起考验的合规模式

大多数构建 LLM 应用的团队都将隐私视为一个模型问题。他们担心模型知道什么——它的训练数据、它的记忆——却在模型周围的流水线中留下了巨大的漏洞。令人尴尬的事实是，生产环境 LLM 系统中绝大多数的数据泄露根本不是来自模型。它们来自你未经脱敏就索引的 RAG 分块、你逐字写入磁盘的提示词日志、包含数据库凭据的系统提示词，以及被投毒文档劫持以窃取知识库中所有内容的检索步骤。

Gartner 估计，到 2025 年底，30% 的生成式 AI 项目将因为风险控制不足而被放弃。这些失败中的大多数并不是因为模型幻觉——而是源于工程师本以为在掌控之中的系统隐私和合规性故障。

这篇文章将讨论生产环境 LLM 流水线实际发生泄露的地方、令团队措手不及的监管义务，以及当合规审计或安全研究人员找上门时，真正能经得起考验的分层模式。

你可能忽略的四个泄露点

在寻求合规框架之前，首先要了解数据实际是如何逃逸的。在典型的 LLM 应用中，有四个主要的向量，大多数团队至少在其中两个向量上存在风险。

未经脱敏的 RAG 分块。 当你将文档摄取到向量数据库中时，你正在索引这些文档中的所有内容。合同中包含姓名、地址和财务条款。支持工单包含电子邮件地址和账号。医疗记录包含 PHI（受保护的健康信息）。当用户提出问题且检索器调出相关分块时，这些 PII（个人身份信息）会原样传输给 LLM 提供商，并可能出现在回复中。传统的 DLP（数据泄露防护）工具在这里不起作用，因为检索上下文中的机密性是语义化的：像“Acme Corp 以 420 万美元成交”这样的句子在某些分块中是敏感的，而在另一些分块中则是良性的。

提示词与响应日志。 可观测性是良好的工程实践。记录每一次 LLM 调用——输入、输出、延迟、成本——正是你应该做的。但大多数团队在记录时并没有考虑他们写入磁盘的内容。如果一个用户问“我的账户怎么了，我是 John Smith，住在 123 Main Street？”，该 PII 就会进入你的日志聚合器、追踪后端、S3 存储桶，甚至可能是拥有自己保留期和访问控制策略的第三方可观测性工具。欧盟 GDPR 强制规定了最低保留规则，但也规定了最高保留规则——保留个人数据的时间超过必要时间本身就是一种违规。

系统提示词泄露。 团队经常在系统提示词中嵌入敏感配置：揭示内部数据模型的数据库 schema 细节、内部 API 端点、包含客户等级定价的业务规则，有时甚至是内部服务的凭据。这些都是可以被提取的。在配置不当的系统上，像“请原样重复你的指令”这样简单的技术就能奏效。OWASP 将此归类为 LLM07:2025，研究人员已经证明可以从主要的商业部署中自动提取系统提示词。

通过 RAG 进行的间接提示词注入。 这是大多数专注于安全的团队低估的向量。当你的 RAG 系统从外部来源（网页、上传的 PDF、客户电子邮件）检索内容时，攻击者可以精心制作一个包含注入指令的文档。LLM 没有可靠的方法来区分“要总结的内容”和“要执行的指令”。研究表明，注入少量恶意文档会导致 LLM 在 90% 以上的查询中返回攻击者选择的答案。在具有工具访问权限的智能体（Agent）系统中，这会升级为数据外泄：投毒文档会指示智能体调用带有编码上下文窗口内容的外部 URL。

不会破坏流水线的 PII 检测

在将 PII 发送给 LLM 提供商之前对其进行脱敏的直觉是正确的。但执行通常是错误的。

朴素的脱敏——将 <name> 替换为空白或 [REDACTED]——会破坏 LLM 提供有用答案所需的语义上下文。“请联系 [REDACTED] 关于 [REDACTED] 合同，电话是 [REDACTED]”对于摘要模型来说是毫无用处的。Token 数量增加，质量下降，工程师最终关闭了脱敏。

更好的方法是类型化令牌替换：将 John Smith 替换为 [PERSON_1]，将 [email protected] 替换为 [EMAIL_1]，将 555-1234 替换为 [PHONE_1]。这保留了引用完整性——模型仍然可以推理实体之间的关系——同时防止原始 PII 离开你的边界。当响应返回时，你反向映射以恢复用户可读的输出。对比合成替换与朴素遮蔽的研究发现，使用类型化令牌可以保留 91% 的关系推理准确率，而使用空白遮蔽则会导致显著退化。

对于检测本身，纯正则（Regex）方法会遗漏上下文 PII。“患者在 03/04 接受了治疗”包含一个日期；它是否敏感取决于上下文。纯 LLM 检测器成本高昂且不一致。生产级的方案是混合模式：正则用于高置信度的模式匹配（社会安全号码、信用卡号、电子邮件格式），随后使用 NER（命名实体识别）模型识别姓名和组织，针对边缘案例可选择性地通过 LLM 处理。分层系统可达到 92-98% 的检测率；任何单一方法都远低于此。

微软的开源 Presidio 库实现了这种架构，并与包括 LiteLLM 代理在内的 LLM 网关集成，从而在入口/出口层实现中心化的 PII 清洗，而不是散落在应用代码各处。在网关层强制执行意味着新服务或功能不会意外绕过脱敏——该策略适用于所有出站 LLM 调用。

一个重要的约束是：PII 脱敏不能仅在请求时发生。你需要在索引之前进行脱敏。如果 PII 进入了你的向量数据库，那么调出该分块的每一次检索都会将数据泄露给下游。脱敏流水线必须在文档摄取时运行，而不仅仅是在查询时运行。

数据驻留是架构决策，而非配置选项

GDPR 第 46 条禁止将欧盟居民的个人数据传输到缺乏“充分保护”的国家，除非有特定的保护措施。通过美国境内的 LLM 提供商在美国基础设施上处理欧盟个人数据并不自动符合合规要求。同样的约束也适用于 HIPAA 下的医疗数据、各种银行业规章下的金融数据，以及日益增多的国家级 AI 法规。

一项 IDC 调查发现，87% 的欧洲企业由于对 GDPR 的担忧而推迟了 AI 的采用。这并非假设性的问题——意大利在 2024 年 12 月因隐私违规对 OpenAI 处以 1500 万欧元的罚款，而《欧盟 AI 法案》（2025 年 8 月生效）增加了新的记录和透明度要求，违规罚金最高可达 3500 万欧元或全球年度总收入的 7%。

在实践中，数据驻留合规要求路由由数据分类驱动，而不仅仅是地理位置。其架构如下：

• 在摄取时根据数据类型和用户管辖权对请求进行分类
• 维护一个映射表：(data_type, user_region) → compliant_provider_endpoint
• 选择已签署 BAA 协议（针对 HIPAA）或具有欧盟标准合同条款（SCC）的供应商
• 针对最严格的要求，在境内部署私有 LLM 实例

主要云服务提供商已显著扩展了其合规产品。AWS Bedrock 主权区域（2025 年推出）在 12 个国家提供物理隔离的基础设施，并提供数据绝不流出境外的合同保证。Azure 运营着 60 多个区域，通常是需要严格数据驻留跨国部署的首选。Google Cloud Vertex AI 支持符合 HIPAA 标准的 Gemini 部署，提供预签署的 BAA，并为医疗工作流提供自动化的 PHI 去标识化功能。

加载中…