很多团队给 LLM 应用加安全能力时，会先做一组规则：敏感词、PII、违规内容、输出审核。规则本身没问题，但如果不区分输入风险和输出风险，工程链路很容易出现错位。

输入侧要防的是风险进入上下文，输出侧要防的是风险交付给用户。两者不在同一个位置，也不应该用同一种治理方式。

风险链路先拆开

一个常见的大模型应用可以拆成这样：

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

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

模型规划 -> Tool Call 参数生成 -> 工具执行 -> 工具结果返回 -> 二次生成 -> 输出审查

输入风险发生在模型生成之前，典型问题包括提示词注入、越权请求、恶意代码、PII、密钥和诱导性问题。输出风险发生在模型返回之前，典型问题包括敏感信息泄露、违规承诺、内部规则暴露、错误知识引用和权限越界表达。

工程上不能只说“加一个安全模块”，而是要明确它接在哪个节点。

输入侧和输出侧的职责不同

这张表的重点是分工。输入侧防进入，输出侧防交付，审计侧防不可追溯。

一个客服知识库场景

假设企业用 Dify 或类似平台搭了一个客服知识库应用。用户输入订单号、手机号和退款问题，系统会检索售后政策，再生成答复。

如果只做输出审查，用户的手机号和订单号可能已经进入模型上下文。如果只做输入脱敏，模型仍可能从知识库召回内部补偿政策，并在最终回答里说出不该对外展示的规则。

更稳的链路应该是：

用户输入
  -> 输入侧识别 PII 和越权意图
  -> 必要字段脱敏
  -> 根据用户身份过滤知识库
  -> 模型生成
  -> 输出侧检查敏感字段、承诺话术和内部规则
  -> 命中风险时拦截、改写或转人工
  -> 写入审计日志

这套链路不追求把所有问题都挡掉，而是让每类风险在正确的位置被处理。

接入建议

工程团队可以按三步落地。

第一步，先画出当前 LLM 应用链路，标出输入、召回、模型、工具调用、输出和日志节点。

第二步，把风险按位置归类，不要把所有规则都堆在输出端。用户输入里的攻击意图要前置处理，知识库越权要在召回阶段处理，最终交付风险要在输出前处理。

第三步，把命中规则和处理动作写入日志。没有日志，护栏只能做实时拦截，不能帮助团队复盘策略是否有效。

唯客护栏适合接在这层运行时链路里：在 Prompt 到达模型前做输入检测和脱敏，在模型回复返回用户前做输出审查，并把命中规则和处理结果留下来。

总结

大模型护栏不是一个静态配置页，而是一组运行时控制点。

输入风险决定模型会被带到哪里，输出风险决定企业最终承担什么后果。工程团队只有先拆清楚这两类风险，才能把护栏接到正确的位置。

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