一个被认为在模型输出阶段已实现封闭的 AI 驱动支持系统，正通过将 CRM 记录喂入提示词（prompt）的“侧门”泄露客户数据。创作者的事后分析表明，仅保护模型生成的文本是不够的——入站请求、从内部工具获取的数据以及最终的输出（emission）都需要独立的防护措施，否则企业可能会在从未发生模型输出泄露的情况下，泄露姓名、电子邮件和 ID。

为什么这三个边界至关重要

大多数运营者认为，当语言模型重复其见过的秘密时才会发生泄露。但在实践中，最大的风险暴露发生在模型看到数据之前。一个 AI Agent 会接收三路信息流：

  • Ingress（入站） – 客户输入的原始查询。
  • Return path（返回路径） – Agent 从 CRM 等下游系统拉取的信息。
  • Emission（输出） – 模型返回给用户的文本。

如果其中任何一路信息流携带了未经保护的标识符，即使输出层经过了过滤，Agent 也可能会在回复中无意中嵌入这些信息。

从演示到生产：惨痛的教训

将原型投入实际客服工作台后，暴露出了一些简单的“先脱敏再发送”方法所忽略的具体故障。

  • 使用 Token 化代替脱敏 – 在姓名或电子邮件到达模型之前将其删除，会阻碍系统构建正确的答案。应将原始值存储在安全保险库中，在提示词中使用随机 UUID 替换它，并在模型处理完成后将 UUID 换回。这样既能让原始数据远离模型的上下文，又能保持功能完整。

  • 使用校验和（checksum）验证标识符 – 正则表达式可以识别看起来像账号的字符串，而校验和可以确认它是否为真实的 ID。校验和过滤器可以防止 Agent 将任意数字视为敏感数据，从而减少因误报而触发的不必要脱敏。

  • 合并重叠区域 – 客户记录通常包含姓名，其后紧跟电子邮件地址，两者可能共享字符（例如，“John Doe john.doe@example.com”）。如果仅对姓名进行 Token 化，电子邮件片段仍会以明文形式存在，并可能被输出。应将整个重叠区域视为单个 Token。

  • 测试正确的边界 – 如果测试仅检查输出层（emission layer）并通过，会给人一种虚假的安全感。一个能捕捉到返回路径（return path）泄露的失败测试才能迫使问题得到修复。应设计能够明确验证这三个边界的测试套件。

  • 追踪事实真相（ground truth） – 当人类在发送 AI 生成的草稿之前对其进行编辑时，模型其实已经产生了一个错误的响应。通过将 AI 草稿与最终经人工批准的消息进行对比，可以发现置信度差距，并防止系统学会重复错误。

企业面临的风险

客服 AI Agent 处于公共交互与内部数据存储的交汇点。

反方观点：为什么有些人仍然青睐脱敏

总结

保障 AI 驱动的客服 Agent 的安全并非“单门”问题。应将入站请求、从内部系统获取的数据以及出站文本视为独立的屏障；一旦任何一个屏障被攻破，整个服务都会受到威胁。对敏感字段进行 Token 化、验证标识符、合并重叠区域、测试正确的边界，并持续将 AI 草稿与最终的人工消息进行对比，这些都是将“Copilot”转变为值得信赖的 Agentic 服务的切实步骤。