用户问我的身份证号别进日志、别被模型记住——shop-agent 一次请求内多次调 LLM敏感信息可能在任意一次进出。哪一层保证它不被泄露或落盘敏感信息治理要生效必须卡在唯一出口。核心论点LLM 网关是 LLM 数据面的唯一出口卡在这里 PII个人身份信息脱敏与 Guardrails护栏才能对发给模型的流量100% 覆盖但 PII 还散落在日志 / trace / 审计 / 缓存 / 用户内容向量 / 告警等平行落点所以脱敏必须是跨平面关注点网关只是其中一道闸——只靠网关必然有漏。为什么护栏必须卡在网关部署形态Agent 子调用多服务并发临时内部调用内嵌式各服务自加跨服务不共享、语言绑定各自补丁、必然有缝难覆盖独立网关唯一出口受控受控受控决策独立网关 LLM 数据面治理 100% 覆盖的前提是出口网络策略强制流量经网关。但网关只挡住了发给模型的流量PII 还散落在别处。PII 是跨平面关注点网关只是一道闸网关脱敏只保证发给供应商的 prompt 干净PII 仍明文存在于平行落点处置动作网关LLM 数据面前置脱敏 后置兜底语义缓存PII 命中整条不写用户内容向量记忆/画像/上传文档user-scoped 隔离存储 字段级脱敏/加密 可删除对话历史Redis保存短期 TTL 用户隔离Langfuse trace导出前脱敏应用日志导出前脱敏审计轨迹写入前脱敏告警 payload推送前脱敏关键判断网关脱敏是把 PII 从模型供应商处挪开不是消除——其余落点若靠每个开发者记得调脱敏就重演《LLM流量网关设计》批判的处处补丁、必然有缝。所有落点共用同一套脱敏引擎规则源统一。修改任一落点处置只改本表勿在分篇重复。按落点类型选切面关键决策统一引擎只消除了规则漂移没消除调用点分散——若业务在每个落点记得调脱敏就仍是处处补丁、必然有缝。但封装不是唯一解法要按落点类型选切面遥测类落点trace/日志/metrics→ 优先 OTel Collector 的redaction/transformprocessor配置式同一份 YAML 规则文件、跨语言、零业务代码——数据在导出/管道侧擦除无需业务封装。行为/数据类落点语义缓存、用户内容向量、审计写库→ 封装成写入门禁不是脱敏后存是命中即绕写/拦截这个行为——OTel processor 只做数据到了再擦表达不了不要进共享面必须在落点公共能力内部做门禁缓存、embedding、审计写库各自一处封装。LLM 数据面 → 网关 hook前置脱敏 后置兜底见下。接入点是切面的实现点每落点一处不是业务的调用点无穷多处业务依赖封装签名或管道配置零感知、零改动。注RAG 知识库向量由自提供文档 embed 而来、源头审查结构上无 PII靠 PII-at-source 即可无需运行时门禁。只有用户内容向量长期记忆/画像/上传文档/纠正中沉淀的知识才需门禁。两类护栏PII 脱敏 vs Guardrails类型目标动作处理时机PII 脱敏数据不外流改内容擦除/掩码请求进模型前 响应回写前Guardrails行为不越界拦请求/截断响应命中即拦不进模型关键区分脱敏是改内容护栏是拦请求/截断响应——处理时机不同。部署位置前置脱敏 后置兜底请求进网关 ↓ 前置脱敏请求进模型前→ 供应商侧不留存明文 ↓ 模型调用 ↓ 后置兜底响应回写前→ 防模型复读了敏感信息 ↓ 返回业务决策本项目选前置为主、后置兜底且顺序上先于缓存/embedding/存储——只做其一都有盲区仅前置 → 漏模型生成类泄露模型回吐敏感数据外泄仅后置 → 漏请求侧落盘敏感数据进模型/日志双落点互补跨平面延伸共享面语义缓存、共享知识库向量应含 PII 整条不写而非脱敏后存——共享其答案既泄隐私又语义错user-scoped 面对话历史、用户内容向量应保存但隔离对话历史按 conversation_id 隔离、短期 TTL 后过期用户记忆/画像/上传文档按用户隔离存储 字段级脱敏/加密 可删除right-to-be-forgottenPII 治理目标是不落明文进共享面/供应商不是用户自己的数据一律不写trace/日志/告警导出前先脱敏。策略集中配置业务零改动护栏规则哪些字段脱敏、哪些话题拦截集中在网关配置业务服务不感知。脱敏字段清单配置示意源自pii/pii.baseline.yaml字段类型掩码规则手机号phone保留后 4 位如138****8000邮箱email保留前缀 1 位 后缀 6 位域名身份证id_card保留前 6 位银行卡bank_card保留前 6 位掩码目标为可读但不可定位命中类型进审计列表不含原文。Guardrails 三通道已在 LiteLLM 中间件链的governance中间件中落地通道触发条件处置硬违规 deny明文身份证、违禁词直接拦不进模型模糊放行 human_review敏感业务话题边界放行但转人工复核空列表 allow无命中正常通过与人在回路的分工场景处置原则硬违规网关直接拦自动拦保底线模糊边界交人在回路审批人在回路保不误伤普通模糊内容置信度阈值自动放过不擅自放行也不擅自拦截触发门槛现实约束人在回路只兜底高不确定性 高风险的少数边界 case不是普通内容通道。海量正常对话若每条都人工审人在回路会变成吞吐瓶颈、也不现实——普通模糊内容靠置信度阈值自动放过或轻量降级处理只有跨过阈值且涉及资金/隐私/合规红线时才升人工。即人在回路是安全阀不是过滤器——与《自动操作回复与自愈闭环》运维 RBAC 的不闯祸同逻辑默认自动、例外才人工。治理钩子实现基于 LiteLLM 中间件链合规护栏通过 LiteLLM Proxy 的中间件链middleware chain实现在 request/response 管道中插入 PII 脱敏中间件与 Guardrails 中间件控制编排顺序先注入检测→后脱敏→再缓存。复用《脱敏引擎工程化》统一脱敏引擎而非各中间件各写正则避免规则漂移。所有定制通过 callback hook 中间件实现不 fork LiteLLM 源码详见《LLM流量网关设计》选型决策。核心要点合规护栏的价值不在功能多在卡对位置 跨平面唯一出口前置脱敏 后置兜底 各落点出口边界强制 人在回路兜底模糊区全靠同一套策略源驱动缺一都有漏。网关只是 LLM 数据面的一道闸——PII 散落在日志 / trace / 缓存 / 向量 / 对话历史 / 告警等平行落点脱敏必须是跨平面关注点且所有落点共用同一套引擎。人在回路是安全阀不是过滤器只兜底高不确定性 高风险的少数边界 case普通内容靠置信度阈值自动放过。防护层自身不能成为新单点——引擎形态、本地规则快照、双层级熔断降级见《脱敏引擎工程化》姊妹篇两篇合起来才是完整的合规设计。