企业把大模型接入客服、知识库、CRM 或工单系统以后，数据防泄露的边界会发生变化。传统 DLP 主要盯文件、字段和外发动作，大模型应用还要处理自然语言输入、知识库上下文、模型输出和 Agent 工具调用。

如果工程团队只在文件上传入口做拦截，很容易漏掉运行时链路里的泄露风险。

风险链路已经从文件外发变成模型交互

典型的大模型应用链路可以拆成这样：

用户输入 -> 输入检测 -> 知识库召回 -> 模型生成 -> 输出审查 -> 返回用户 -> 日志审计

如果是 Agent 场景，还会继续扩展：

模型判断 -> Tool Call 参数生成 -> 工具执行 -> 工具结果返回 -> 二次生成

泄露风险不只发生在第一步。用户输入可能携带 PII，知识库召回可能拿到未授权文档，模型输出可能组合出敏感结论，工具调用参数可能把客户信息传给外部接口。

这就是传统 DLP 在 LLM 场景下不够用的原因：它擅长识别确定格式的数据，却很难理解上下文中的语义风险和权限边界。

工程上至少要放四类控制点

这四个点不是互相替代关系。只做输入检测，挡不住知识库泄露；只做输出审查，敏感内容可能已经进入上下文；没有审计日志，问题出现后无法复盘。

Dify 工作流里的接入位置

如果企业用 Dify 构建应用，建议把数据防泄露能力放进工作流关键节点，而不是上线后再补一个外部检查脚本。

更合理的接入方式是：

Start
  -> 输入安全检查
  -> 必要字段脱敏
  -> 知识库检索
  -> 模型生成
  -> 输出安全审查
  -> 返回用户
  -> 写入审计日志

在 Agent 或 Tool Call 场景里，还要加一层：

工具调用前参数检查 -> 工具返回内容过滤 -> 模型二次输出审查

唯客护栏适合补的是这层运行时安全能力：在 Prompt 到达模型前做输入检测和 PII 脱敏，在模型回复返回用户前做输出审查，并把命中的规则和处理结果留下来，方便安全团队后续复盘。

上线前检查清单

• 是否明确哪些字段不能进入模型，例如手机号、身份证号、客户名单、API Key。
• 是否区分了输入风险和输出风险。
• 知识库召回是否继承企业原有权限，而不是所有内容对模型可见。
• Agent 工具调用参数是否做了脱敏和白名单校验。
• 日志里是否能看到规则命中、处理动作和最终结果。
• 误拦截是否有反馈机制，避免安全策略影响业务可用性。

数据防泄露不是一个独立插件装上就结束。它需要和应用链路一起设计，跟着业务持续调整。

总结

大模型应用里的数据防泄露，本质上是运行时治理问题。工程团队要守住的不只是文件外发入口，而是输入、召回、输出、工具调用和审计这条完整链路。

只有把控制点放进真实工作流，企业才能在不牺牲可用性的前提下，把大模型应用推进到生产环境。

参考来源：
https://sec.jotoai.com/