提示层中的个人信息：大多数团队忽视的隐私工程缺口

你的组织有一份隐私政策。它用合理的措辞描述了用户数据的谨慎处理、保留限制以及对 GDPR 和 HIPAA 的合规。但它几乎肯定没有说明：在任何策略控制生效之前，用户的姓名、电子邮件地址或病史是否以明文形式传输给了托管的 LLM API。

这个缺口——你能指出的隐私政策与你实际能证明的隐私保证之间的距离——正是大多数生产 LLM 系统悄然失守的地方。研究显示，提交给 ChatGPT 和 Copilot 等工具的提示词中，约有 8.5% 包含敏感信息，包括 PII、凭据和内部文件引用。在企业环境中，用户将邮件、客户数据和支持工单粘贴到 AI 辅助工作流程中，这一比例几乎肯定更高。

问题不在于开发者粗心大意。而在于 LLM 提示层从未被设计为数据处理边界。它从上游系统——用户输入、RAG 检索、智能体上下文——继承内容，却不执行治理整个技术栈其他部分的数据分类规则。

PII 如何在无人察觉的情况下到达模型

在传统的数据架构中，敏感数据流经可识别的存储和计算系统。你可以审计数据库、API、日志聚合器。添加新的数据处理步骤意味着更新数据流图和 DPA。

LLM 提示以几种特定的方式打破了这一模型。

用户输入是最明显的入口，但绝不是唯一的入口。 当员工将一张支持工单粘贴到聊天界面时，其中的电子邮件地址和账号直接进入推理调用。当聊天功能上线时，没有人将其标记为数据处理活动，因为"用户在聊天框里输入内容"并不像一个数据工程问题。

RAG 检索管道是无声的放大器。 当你将检索到的文档作为上下文注入提示时，你也注入了这些文档包含的任何 PII。分块文档存储通常具有不一致的元数据；来自医疗记录的分块可能携带患者姓名，来自 CRM 导出的分块可能携带客户联系信息。在检索时，这些文本未经进一步检查就流入提示。

多轮智能体工作流在对话轮次中累积暴露风险。 每次工具调用结果、浏览器抓取或 API 响应被追加到对话上下文时，都是另一个未脱敏 PII 进入模型输入的途径。在复杂的智能体会话的第五轮，上下文窗口可能包含来自六个来源的 PII，而这些来源中没有一个单独看起来是重要的。

在 GDPR 下，托管的 LLM API 是外部数据处理者。 向 OpenAI 或 Anthropic 的 API 发送请求是向第三方处理者的跨境数据传输。这需要一份包含标准合同条款的数据处理协议。大多数在过去两年部署了 LLM 功能的组织没有验证此协议是否存在，以及是否涵盖他们发送的特定数据类型。许多人认为勾选企业版复选框就满足了要求。

审计中会暴露的三个合规缺口

2025 年，隐私审计员审查 LLM 系统时，不再问"你有政策吗？"而是要求提供政策在真实条件下得到执行的证据。三个缺口会可靠地出现：

缺口一：没有脱敏记录。 政策说 PII 在模型处理前已脱敏。系统说脱敏已发生。但没有时间戳的日志条目记录在特定提示中检测到哪些实体、采取了什么行动以及置信度级别。没有这条记录，"我们脱敏 PII"只是断言，不是经过验证的控制措施。

缺口二：没有跨完整数据谱系的删除证明。 当用户提交数据主体访问请求（DSAR）并要求删除时，应用数据库会被清理。LLM 提供商的 API 日志可能会或不会根据协议清除。持有该用户文档嵌入的向量存储几乎肯定不会。接收 Datadog 转发的提示追踪的日志聚合器可能也不会。删除不是单一操作；它是跨每个接触推理调用的系统的工作流。

缺口三：没有证明日志遵守敏感边界。 提示可观测性在操作上是必不可少的。工程师需要追踪来调试模型行为。但如果这些追踪包含完整的提示文本，它们就会将原始 PII 复制到访问权限比应用程序本身更广泛的监控系统中。一旦原始提示出现在 Datadog 中，每个拥有可观测性权限的工程师都可以访问——这个群体可能比应用程序的数据管理员大得多。

根据 2025 年的合规调查，近 60% 的组织在没有正式 LLM 审计控制的情况下部署生成式 AI 功能。来自 GDPR（全球营收的 4%）和 HIPAA（每年每种违规类型最高 150 万美元）的罚款风险使这成为一个不对称的赌注。

真正将 PII 与推理解耦的脱敏架构

核心模式是一个预处理管道，在内容到达模型之前对其进行转换。有四种脱敏策略，各有不同的实用性权衡：

编辑完全删除敏感实体，并用 [REDACTED] 等占位符替换。实现最简单，完全保护隐私，但会破坏任何需要对被删除内容进行推理的任务。适用于对模型没有语义价值的 PII——身份证号码、凭据、金融账户字符串。

令牌化将每个实体替换为稳定的、保留格式的令牌。电子邮件地址变成 EMAIL_001。人名变成 PERSON_001。同一实体在整个会话中获得相同的令牌，因此模型可以推理"第一条消息中提到的 PERSON_001 与第三条消息中引用的是同一个人"，而不会看到实际姓名。关键是，你维护一个可逆映射，让你能够在输出中恢复原始值。

合成替换用上下文合理但完全虚构的值替换检测到的 PII——"Jane Smith"变成"Michael Johnson"，真实电话号码变成有效但虚假的电话号码。模型接收看起来真实的数据，这保留了它自然推理姓名、联系方式和结构化实体的能力。不需要可逆映射；原始数据单独保留在应用层，并合并回响应中。

加密适用于下游系统需要对受保护的值执行精确匹配查找或交叉引用操作的情况。保留格式的加密产生在结构上与原始值相似的密文，使得数据库连接和一致性检查在不暴露明文的情况下成为可能。

在实践中，生产系统会组合使用这些方法。凭据和金融数据被编辑。姓名和联系方式使用会话范围的映射进行令牌化。模型需要自然推理的结构化实体进行合成替换。选择取决于任务实际需要的语义属性。

无持久 PII 存储的可逆令牌化

更棘手的实现挑战是可逆映射。如果你将"Jane Smith"令牌化为"PERSON_001"用于 LLM 调用，你需要在响应到达用户之前将"Jane Smith"恢复——但你不能将该映射存储在比必要时间更长的日志中。

干净的模式是具有有界生命周期的会话范围内存令牌化：

1. 在会话或请求开始时，创建一个以会话 ID 为键的临时映射。
2. 在发送给 LLM 之前，对完整提示（输入+检索上下文）应用令牌化。
3. 在将模型响应返回给用户之前，对其应用去匿名化。

加载中…