潜伏在 Few-Shot 提示词模板中的客户记录

隐私审计员在 SOC 2 续期前两天提出了一个问题：“为什么你入门引导提示词示例中的电子邮件字段是一个真实客户的地址？”产品团队在脑海中回溯了整个流程。一年前，当他们发布 AI 摘要功能时，有人需要为 few-shot 模板找一个“看看它是如何工作的”示例。他们从预发布环境（staging）中选取了一条具有代表性的客户记录，清理了明显的字段——姓名、账户 ID、电话——并提交了文件。该客户在六个月后流失了。根据数据保留政策，他们的记录已从数据库中删除。但该记录并没有从提示词模板中删除，而该模板已发布到了生产环境中的每一个租户。

团队曾像大多数团队一样，认为隐私边界就是数据库。提示词模板是代码。代码要经过评审。评审并不会标记 PII（个人身份信息），因为评审人员不会在标记为 example_input: 的 YAML 字符串中寻找它。能在 Slack 消息和邮件附件中捕捉 PII 的 DLP（数据泄露防护）扫描器不会扫描提交的代码，即使扫描，它也不会将部分清理过的客户记录识别为个人数据，因为它知道要查找的字段已被移除。剩下的所有内容——公司规模、行业、稀有的职位名称、特定的城市——都是扫描器没有规则去处理的数据。

这就是“演示数据即真实数据”的陷阱，大多数 AI 功能在发布时至少带有一个这样的实例。从“我们需要一个 few-shot 示例”到“投入生产”的最短路径，往往经过预发布数据、经过 15 分钟的清理，再经过一个没人负责隐私审查的代码评审。这个陷阱并不是因为有人怀有恶意。陷阱在于，提示词模板是一个数据处理界面，而团队中没人将其视为数据处理界面，现有的数据控制措施也无法延伸到它。

为什么提示词模板能逃过所有现有的控制措施

传统的数据泄露防护（DLP）工具是为个人数据存在于数据库、文件、电子邮件和网络流量中的世界而构建的。它们扫描 SaaS 上传、邮件附件和云存储。它们不会扫描你单体仓库（monorepo）中的 YAML 文件、编译进容器镜像的系统提示词，或者是请求时从配置中组装的 few-shot 代码块。DLP 中隐含的架构假设是：个人数据是在网络中流动的“内容”，而不是作为应用程序二进制文件一部分发布的字符串模板中的“参数”。

关于提示词级别数据泄露的数字凸显了这一差距。2026 年的行业调查报告称，发送给生成式 AI 工具的提示词中有 46% 包含敏感客户信息，77% 的员工曾将公司信息粘贴到大语言模型（LLM）服务中。这些遥测数据大多关于运行时（runtime）提示词——即用户在聊天框中输入的内容——即便在运行时，现有的控制措施也会遗漏大部分内容。而躺在你提示词模板中的已提交示例甚至从未进入运行时流程，因为它们本身就是运行时流程。它们在任何 DLP 边界看到它们之前，就已经被写进了应用程序中。

第二个失效的控制措施是代码评审。评审人员阅读提示词模板的方式就像阅读配置一样：他们检查示例是否符合 schema、JSON 是否有效、输出格式是否正确。他们不会像评审数据库查询那样评审提示词示例。代码评审中出现的 SELECT * FROM customers WHERE id = 12345 会立即引起质疑；但一个标题为“示例发票”且包含相同客户购买历史的 few-shot 代码块则不会，因为对“few-shot 示例”的认知框架是“文档”，而不是“对生产数据的查询”。

第三个失效的控制措施是数据保留管道。当客户流失或行使删除权时，工程团队会在数据库中运行删除脚本。该脚本知道用户表、事件表、审计日志。它不知道 prompts/onboarding/v3.yaml。客户被从记录系统中删除了，但仍保留在推理系统中，在那里，他们的数据在每次提示词组装时继续被处理，发送给模型提供商，并可能记录在模型提供商的请求日志中。

匿名化剧场：为什么仅清理明显字段是不够的

在将记录用作示例之前进行“清理”的标准心理模型是删除直接标识符——姓名、电子邮件、电话、账户 ID。剩余字段被认为是安全的，因为它们不直接识别任何人。这种直觉是完全错误的，而且这个领域在二十年前就知道它是错误的。

马萨诸塞州州政府雇员案例是一个经典引用：该州的保险委员会发布了删除了姓名和地址的“匿名”健康记录，而一名研究人员通过将剩余字段与公开可用的选民名单进行关联，重新识别出了该州州长的医疗记录。发挥作用的字段是出生日期、邮政编码和性别。随后的分析显示，仅这三个字段就能唯一识别大约 87% 的美国人口。匿名化失败并不是实现过程中的 bug。它源于对什么是标识数据的错误模型。

提示词示例中使用的客户记录比马萨诸塞州的数据集要丰富得多。一个典型的经过清理的示例通常保留：行业、公司规模、地理区域、职位名称、产品配置、交易模式以及代表性交互的实际内容——支持工单、电子邮件、发票、通话录音。这些字段中的每一个都是准标识符（quasi-identifier）。这种组合不仅能识别出某个人，还能识别出他们所在的公司，这在企业合同中具有法律分量，因为这些合同通常禁止在未经明确同意的情况下披露任何客户特定的运营数据。

一个有用的练习：看看你最常用的提示词中当前的 few-shot 示例，问问如果有人能访问 LinkedIn、客户的公司网站以及你产品典型工作流的副本，能否将该示例缩小到一两个真实客户。对于大多数 B2B AI 产品来说，答案是肯定的，特别是如果示例包含稀有角色（“多伦多一家 50–200 人金融科技公司的营收运营副总裁”）、特定事件（“B 轮融资后的入职引导”）或独特的产品配置。“但是我们删除了姓名”这种辩解，与马萨诸塞州委员会给出的辩解如出一辙，只不过它是被应用到了一个维度更高的数据集上。

当表面是模板时，“数据处理”意味着什么

在 GDPR 及类似法规下，“处理”（processing）几乎意味着对个人数据进行的任何操作，包括存储。一个包含真实客户记录的提示词模板，在应用程序启动时、在提示词渲染时、以及在发送给模型提供商 API 时，都在处理该客户的数据。在大多数合同中，模型提供商的 API 是第三方处理者，这意味着必须签署涵盖它的数据处理协议（DPA），且该协议必须涵盖所发送的数据。

隐私审计会提出的实际问题，大致按以下顺序：

• 你的提示词模板中体现了哪些客户？
• 该用途是否获得了他们的同意，或者你是否有其他合法依据？
• 该用途是否涵盖在你与模型提供商签署的数据处理协议中？
• 当客户行使删除权或可携带权时，提示词资产中对他们的引用会发生什么变化？
• 你如何审计在任何给定日期生产环境中运行的是哪个版本的模板，以及其中嵌入了哪些客户记录？

大多数团队无法回答现有提示词资产的这些问题，原因是拥有提示词的团队（通常是产品或 AI 工程部门）与拥有答案的团队（通常是隐私或法务部门）在组织上是分离的。提示词在编写时没有经过法务审查，因为它被视为代码。它在没有 DPA 的情况下被处理，因为隐私团队根本不知道它的存在。违规披露的问题不在于是否造成了损害——通常没有损害发生——而在于组织是否在其声明的合法依据之外处理了个人数据，这本身就是 GDPR 下的一个可报告调查结果。

必须落地的规范

三项控制措施共同弥补了这一差距。它们在技术上都不是什么新鲜事；工作的重点在于将它们变为默认路径，而非例外流程。

合成示例生成作为标准化路径。 任何编写少样本（few-shot）示例的人，其默认操作应该是使用一个合成生成器，该生成器接收模式（schema）并生成一个合理的记录，而无需读取生产环境。生成器可以是一个使用 faker 库的小脚本，一个带有“生成虚构 B2B 客户记录”指令的模型提示词，或者一个专门的合成数据工具。限制在于合成路径必须比使用预发布环境（staging）数据路径更容易——如果开发人员抓取一条真实记录需要 30 秒，而启动合成生成器需要 10 分钟，那么真实记录就会胜出。将合成生成器视为提示词工程工具链的一部分，并让它成为新工程师询问“我如何添加示例？”时看到的第一样东西。

独立于训练数据注册表的示例数据注册表。 大多数进行过 AI 隐私工作的组织都有一个训练数据注册表——记录了哪些数据集被用于训练或微调哪些模型。很少有组织拥有示例数据注册表来跟踪哪些记录在哪些提示词模板中被用作上下文示例（in-context examples）。这两者是具有不同生命周期的不同表面：训练数据被消耗一次，模型是产物；示例数据在每次推理时都被消耗，提示词是产物。注册表应记录每个示例的来源（合成、公开、内部测试，或者——极其例外地——经过明确同意的真实客户）、添加日期以及负责重新脱敏（re-scrubbing）的所有者。

随着客户记录变化的定期重新脱敏审计。 一条在添加时是非识别性的真实客户记录，在相邻数据发生变化时会变得具有可识别性。客户从 50 名员工扩大到 500 名，那个“多伦多的小型金融科技公司”示例现在唯一定向到了他们。客户流失了，示例就变成了从未表示同意的非客户数据。客户要求删除，示例就变成了合规违规。解决方法是进行季度审计，针对当前客户群进行唯一性检查，标记已变得可重新识别的示例，并触发用合成等效项进行替换。这不是人工隐私审查——这是一个脚本化的任务，它将示例中字段的熵（entropy）与当前的客户分布进行对比。

第四种做法——提示词的内容溯源（content provenance）——即便不严格属于演示数据陷阱，也值得添加。如果你的提示词资产带有逐行溯源（“此示例于 2025-09-12 由 alice 使用合成生成器 v3 编写”），隐私审计就会变成一次查询，而非一次调查。大多数团队因为觉得这太繁重而跳过；而经历过一次隐私事件的团队则将其视为基本门槛。

将模板视为数据处理表面

这背后隐藏的架构认识是，提示词模板——每一个提示词模板，包括系统提示词（system prompts）、少样本区块、工具描述、带有示例值的输出模式，以及随二进制文件一同发布的回归测试固件——都是一个数据处理表面。它受监管你数据库的相同法规约束。DLP 不扫描它、代码审查不显示它、删除脚本不遍历它，这些事实并不会改变其法律地位。它们只会改变你在审计员发现违规行为之前自己发现它的概率。

经历过一次这种事情的团队不再将提示词视为代码，而是开始将其视为恰好以代码形式表达的数据资产。当更改涉及示例块时，他们会将提示词更改同时路由到代码审查队列和隐私审查队列。他们在需要之前就构建好合成生成器，而不是在审计之后。他们按计划运行唯一性检查，而不是在发生事件后才采取行动。这些做法在稳定状态下的成本很小，但事后补救的成本非常大，这与组织在第一份可报告调查结果之后重新发现的其他数据治理规范的模式是一样的。

你的团队交付的下一个 AI 功能将包含一个少样本示例。在交付之前，请问一个问题：“如果隐私审计员明天走进来问这个示例是谁，团队中有人能回答吗？”如果答案是“我们必须去深挖”，那么这个示例已经是一个风险隐患了。修复它的最廉价时刻就是现在，因为它还只是 YAML 文件中的一个字符串，而不是泄露披露中的一个分项。