Prompt 中的 PII：你的 AI 流水线缺失的数据最小化模式

2025 年的研究发现，提交给商用 LLM 的 Prompt 中有 8.5% 包含敏感信息——PII、凭据和内部文件引用。这一统计数据可能低估了问题的严重性。它只计算了用户显式输入的内容，而没有计算系统静默添加的内容：检索到的客户记录、数据库查询的工具输出、从之前会话持久化的记忆，或者是训练前未经过清洗的微调数据。大多数 AI 流水线的 PII 泄露并非源于用户错误，而是源于没有单一工程师负责的架构盲点。

失效模式几乎总是一样的：团队发布了一个 AI 功能，认为“我们不发送个人数据”，但个人数据却从缝隙中进入了——在包含客户地址的 RAG 检索分块中，在返回完整用户档案的智能体工具输出中，或者在从 CRM 导出且未经脱敏（redaction）的微调数据集中。GDPR 的数据最小化原则要求你只收集特定目的所必需的数据。LLM 架构在默认情况下违反了这一点。

PII 是如何在无人决策的情况下进入 Prompt 的

最危险的 PII 流动并不是那些显而易见的。没有人会故意向第三方 LLM 发送社会安全号码（SSN）。泄露发生在组装上下文的系统边界处。

RAG 检索是最常见的罪魁祸首。当用户询问支持聊天机器人“我的账户状态是什么”时，检索系统会从你的知识库中提取最相关的分块。如果你的知识库是通过嵌入（embedding）客户邮件、支持工单或内部 CRM 导出的内容构建的，那么这些分块就会包含真实的姓名、电子邮件、账号和交易详情。嵌入模型会毫无怨言地对它们进行编码，检索步骤将它们提取出来，最终 LLM 收到一个包含陌生人个人数据的 Prompt。

**智能体工具输出（Agentic tool outputs）**引入了第二类隐形泄露。调用数据库查询工具的智能体会获得结构化数据——通常是完整的行，而不是过滤后的字段。如果智能体的上下文窗口现在包含了一条带有客户出生日期、家庭住址和付款方式的数据库记录，那么这些数据就成为了后续每一次推理的一部分。智能体可能会对其进行总结、转换、记录或转发给另一个工具。在整个过程中，没有任何人类决定过 LLM 是否需要所有这些数据。

会话记忆和长期上下文创建了第三种路径。持久化记忆系统通过保留用户跨会话的言论来提高个性化水平。但用户所说的话往往包含他们的职位、健康状况、家庭情况和财务状况。一条记录着“用户正在经历离婚并担心退休储蓄”的记忆条目，对于理财师智能体来说是有价值的上下文，但对于你的数据保留政策来说则是一项负债。

共同点在于：PII 是通过自动化而非用户意图进入 Prompt 的，并且是通过那些没人想到要添加隐私过滤器的组件进入的。

你可能忽略的分级问题

在进行数据最小化之前，你必须检测出你正在处理的是什么。大多数团队将其视为二元问题——是 PII 还是非 PII——并倾向于使用正则表达式（regex）列表。这种方法适用于格式良好的结构化数据（如 SSN、信用卡号、具有明显模式的电子邮件地址），但在其他方面都会失败。

单独一个名字的敏感度较低。但在 HIPAA 规定下，一个名字配上医疗诊断就属于受保护的健康信息。在某些管辖区，一个名字配上性取向可能存在安全风险。同样的字符串 "John Smith" 需要根据其相邻内容进行不同的处理。

有效的分类需要实体识别和上下文评估。当前的生产方案通常将这些技术堆叠使用：

• 预训练的 NER 模型（GLiNER-base 在多领域 PII 检测中实现了约 81% 的 F1 分数，基于 DeBERTa-v3 的模型如 HydroX 的 PII Masker 可以处理长达 1,024 个 token 的序列）用于识别实体类型。
• 正则表达式模式作为辅助校验，涵盖 NER 模型有时会遗漏的结构化格式——路由号码、护照格式、特定的国家身份证明方案。
• 敏感度分类将实体类型 + 上下文映射到一个风险等级，从而驱动执行决策：是脱敏、匿名化还是拦截。

执行决策与检测同样重要。在客户支持场景中脱敏电子邮件地址可能会破坏 LLM 路由工单的能力。用一个在处理完成时能映射回真实地址的伪名（pseudonym）来替换它，既能保留实用性，又能让原始值远离 Prompt。正确的选择取决于 LLM 是需要实际数值，还是只需要跟踪该电子邮件的存在。

你的流水线可能缺失 PII 处理的四个地方

RAG 源文件准备

大多数 RAG 流水线的问题不在于检索步骤，而在于源文档从未为检索做好准备。索引到向量数据库中的文档携带了它们在编写时所包含的一切：客户姓名、支持工单的引用、内部员工沟通记录。

解决方法分为两部分。首先，在嵌入之前对源文档进行清洗。对每份文档运行 PII 检测，并在生成嵌入之前进行脱敏或伪名化处理。作为一次性迁移，这可能成本较高，但作为持续的摄取门控，它的成本很低。其次，即使你的向量数据库目前还不是多租户系统，也要将其视为多租户系统。通过文档类型或访问层级来限定检索范围的元数据过滤器，可以防止查询在面向客户的场景中提取出仅限内部的内容。

一个经常被跳过的步骤是：当源文档包含 PII 时，嵌入本身也会携带其痕迹。研究表明，嵌入反演攻击（embedding inversion attacks）可以从向量中部分还原原始文本。当源数据敏感时，向量数据库的静态加密（Encryption at rest）不是可选的，而是必需的。

微调数据集

在不进行脱敏的情况下对敏感数据进行微调，会产生一个记住了私密信息并在特定提示条件下重现这些信息的模型。这种效应已有记录：研究发现，在不对敏感数据集进行清洗的情况下微调 LLM，会导致 19% 的 PII 泄露。记住的数据并非均匀分布——具有一致格式的结构化标识符（账号、政府身份证号）比自然语言描述更容易被可靠地记住。

最起码的干预是在微调前进行脱敏：在训练语料库上运行相同的 NER + 正则表达式流水线，并在微调开始前将识别出的实体替换为类别标签。这能显著减少泄露，但无法完全消除，因为模型仍然可以推断出模式。

更强的保护需要训练期间的差异隐私（DP-SGD 通过向梯度添加校准噪声来提供正式的隐私保证）或使用合成数据生成来替换真实的客户记录。两者都存在效用成本——DP-SGD 需要调整隐私预算，而合成数据必须经过代表性验证。合适的保护水平取决于训练数据的敏感程度以及模型的用途。

一个不明显的风险：一旦模型在没有足够保护的情况下对 PII 进行了微调，要满足 GDPR 的删除权（right-to-erasure）请求将变得极其困难。你无法从模型权重中通过手术式操作删除某个人的数据。唯一的干净选择是重新训练。预防的成本远低于补救。

AI 记忆系统

持久化记忆系统带来了一个全新的数据留存问题。当用户告诉你的 AI 助手一些私事——他们的健康状况、薪资、家庭情况——并且系统将其作为一条记忆条目持久化时，你就拥有了一个没有明确过期日期的数字记录，且通常是以一种针对检索而非审计进行优化的格式存储。

这里的攻击向量被称为 SpAIware：一种污染记忆系统的间接提示注入。如果攻击者能将恶意提示注入到你的智能体读取的内容（文档、日历条目、网页）中，该提示就可以指示智能体将其写入长期记忆。这些条目随后会在用户不知情的情况下影响未来的会话。

工程上的安全防护措施包括：

• 对所有记忆条目强制执行生存时间（TTL），并实现自动删除。
• 持久化前的数据分类——在写入记忆库之前应用 PII 处理规则，而不是在读取之后。
• 用户级分区，在存储层（而非仅仅是应用层）强制执行，确保无跨用户记忆访问。
• 审计日志记录所有记忆的读写操作，并支持通过用户 ID 进行查询，以满足 GDPR 删除请求。

智能体工具输出

调用外部工具（数据库查询、API 调用、文件读取）的智能体收到的输出，在设计时并未考虑 LLM 的上下文窗口。数据库查询返回完整记录，文件读取返回整个文件，API 调用返回完整的响应负载。所有这些都会在未经过滤的情况下进入智能体的上下文。

行之有效的模式是将工具执行包装在一个输出净化层中，在输出进入上下文窗口之前运行 PII 检测并应用字段级过滤。这需要针对每个工具明确哪些字段对智能体的任务是必要的，哪些是附带的。这种规范化工作是许多团队会跳过的开销——但跳过它意味着智能体的上下文窗口会经常包含它不需要的数据，从而扩大了任何提示注入或日志漏洞的爆炸半径。

个性化与最小化之间的张力是可以解决的

工程师从产品团队那里听到的反对意见是，数据最小化会降低个性化程度。如果你不能将用户的完整个人资料发送给 LLM，AI 怎么知道如何帮助他们？

解决方案是从原始数据转向衍生特征。与其发送“用户是芝加哥一名 42 岁的护士，年收入 80,000 美元”，不如提取 AI 实际需要的特征：“用户是一名医疗保健专业人士，偏好临床术语，并对税收优惠账户表现出兴趣”。衍生出的表示方式承载了个性化信号，且不包含原始 PII。原始数据在特征提取后被删除；衍生特征可以拥有自己的适当留存策略。

这并不是什么新模式——推荐系统已经使用了多年。新的是将其系统地应用于 LLM 上下文构建，大多数团队还没这么做，因为他们在仔细思考系统摄入内容之前，就先采用了 RAG 和记忆系统。

在架构的何处应用控制

实际的选择在于点对点解决方案（在每个应用程序中处理 PII）和集中式强制执行（一个处理脱敏的基础设施级 AI 网关）之间。

点对点解决方案在规模化时会崩溃，因为每个新的 AI 功能都会复制检测和脱敏逻辑，且无法保证跨团队的一致性。集中式网关——如 Kong AI Gateway 3.10+ 支持对 9 种语言的 20 多个类别进行基于策略的 PII 净化，既包括请求净化，也包括可选的响应恢复——在所有 LLM 流量中强制执行统一策略。这在大型组织中尤为重要，因为多个团队会按不同的时间表发布 AI 功能。

2025 年 4 月的 EDPB 指南明确指出，部署第三方 LLM 的控制者必须进行合法利益评估，并且不能假设模型提供商已代表其对数据进行了匿名化处理。实际的影响是：你的合规态势取决于你向 API 发送了什么，而不是 API 提供商承诺如何处理它。网关层就是你做出这种保证的地方。

无论你选择哪种方法，强制执行点都应该位于你的应用程序和 LLM API 之间。不要放在前端。不要放在某些请求可能会跳过的预处理步骤中。它应该位于组装好的提示和 API 调用之间，作为一个强制性的直通环节，记录它看到了什么以及更改了什么。

改变权衡逻辑的合规期限

欧盟《人工智能法案》（EU AI Act）针对高风险 AI 系统的合规期限将于 2026 年 8 月到期，这在现有的 GDPR 义务之上，又增加了额外的文档记录和治理要求。加利福尼亚州的 AB 1008 修正案扩大了 CCPA 的适用范围，使其涵盖了能够生成包含个人信息的输出的 AI 系统。这些并非遥不可及的政策讨论——而是会影响大多数工程团队目前正在构建的 AI 产品的具体要求。

对工程师来说，一个值得注意的细节是：GDPR 的“被遗忘权”（删除权）同样适用于通过 LLM 处理的个人数据。如果用户请求删除数据，而其数据曾被用于模型微调，那么你唯一彻底的选择就是重新训练模型。如果他们的数据存储在向量数据库中，删除操作则需要识别并移除受影响的向量嵌入（embeddings）。这两者都不是简单的任务。那些将来负责处理这些请求的工程师，可能并不是今天构建这些系统的人——这正是为什么“数据最小化”默认设置在当下至关重要的原因。你摄取的 PII 越少，你的删除工作量就越小。

务实的切入点

如果你正在审计现有的流水线，请从接缝处入手：在调用 LLM 之前，上下文是在哪里汇编的？每个 RAG 分块中包含什么？工具输出包含什么？内存存储空间中保留了什么？通过实际的日志记录来回答这些问题——从生产环境中采样 1,000 个提示词（prompts），并对其进行 PII 检测。其结果比任何架构审查都能更精确地告诉你差距在哪里。

如果你正在构建新系统，请从一开始就将 PII 处理视为基础设施。在实现工具之前先定义工具输出的 schema。明确 Agent 任务所需的字段。在向量嵌入之前对源文档进行脱敏处理。在数据模型中为内存条目设置生存时间（TTLs），而不是将其作为未来的增强功能。在发生隐私事故或 GDPR 审计之后再补救这些控制措施的成本，远高于最初就将其构建在系统中的成本。

法规约束和工程失效模式都指向同一个结论：LLM 并不需要你发送给它的大部分内容。数据最小化并不是一种合规税。它是一种能催生更优系统架构的约束。