DLP 应存在于你的 AI 网关中，而非生搬硬套到每个应用里

第一个内部 LLM 网关的构建通常是出于那些枯燥的原因：成本归因，以便财务可以回答“哪个团队花了推理预算”；速率限制，防止某个失控的脚本烧掉月度配额；以及供应商故障转移，确保 OpenAI 的小故障不会导致助手挂掉。数据泄露防护 (DLP) 虽然出现在幻灯片上，但交付时却变成了“每个应用团队在调用模型前应自行脱敏敏感字段”。六个月后，生产环境中有九个应用，三个维护得半吊子的脱敏库（带有微妙差异的正则表达式集），两个完全绕过网关“仅用于测试”的原型，以及一起 Prompt 中包含客户数据的事故——而这本该是由每个人的中间件来防止的，因为并没有人的中间件是规范的出站口。

这不是工具问题，而是架构错误。DLP 是一种出站控制，而出站控制只有在路径强制执行时才有效。当你让应用团队负责脱敏时，你就放弃了让 DLP 发挥作用的特性——即敏感数据只能从一个地方流出，且你可以证明流出了什么。2025 年的 LayerX 安全报告用大多数团队尚未意识到的数据说明了问题的规模：2025 年初，与生成式 AI (GenAI) 相关的 DLP 事故增加了一倍多，目前占 SaaS 流量中所有数据安全事故的 14%，员工平均每天向 GenAI 工具粘贴 6.8 次内容，其中超过一半包含公司信息。影子路径默认在胜出。

为什么“每个应用自行脱敏”总是会失败​

“在应用中脱敏”的模式在白板上看起来有一种诱人的整洁感。拥有数据的团队知道哪些字段是敏感的。脱敏逻辑与生成数据的业务逻辑并存。延迟被分摊到应用已有的调用中。在观察实际发生的情况之前，这看起来像是正确的关注点分离。

应用团队发布了一个脱敏程序。三个月后，一个新的用例需要稍微不同的规则——也许内部员工姓名应该被允许，但外部客户姓名不应该——于是有人添加了一个标志。六个月后，出现了一个拉取请求，“为了复现 Bug，暂时为 QA 测试套件禁用脱敏”，且从未被撤销。一个新的应用发布，它从旧应用的仓库中复制了脱敏程序并将其冻结；旧应用的脱敏程序在演进；两者产生偏差。添加了一个供应商 SDK，由于直接调用模型比将网关 URL 穿透 SDK 配置更容易，它就直接调用了模型。孤立来看，这些决定都不是不合理的。但每一个决定都从墙上拆掉了一块砖。

对比成熟组织处理其他出站敏感流程的方式。外发电子邮件通过一个具有 DKIM、SPF 和退信处理能力的 SMTP 中继，这些是在中继层强制执行的，而不是每个应用。数据库访问通过连接中间件审计查询。受监管环境中的外部 API 调用通过正向代理。没有人会认真争论“每个微服务都应该做自己的 DKIM 签名”。模型流量的 DLP 也是同类问题，值得采用同类的解决方案：一个出站检查点、强制穿越、并在数据真正离开信任边界的地方执行策略。

“脱敏的 DRY 原则”框架也忽略了失败的不对称性。成本归因中的 Bug 只是 FinOps 团队下个月要对账的仪表盘上的一个错误行。DLP 中的 Bug 则表现为客户数据落在第三方模型供应商的存储库中，通常首先由监管机构或客户支持投诉发现，偶尔是因为发现预训练的补全建议将另一个客户的 PII 作为可能的自动填充内容。其破坏半径证明了中心化的合理性，这是纯粹的代码复用论据永远无法做到的。

作为出站检查点的网关真正拥有什么​

一个为 DLP 设计（而非事后修补）的网关具有四个特性，使其区别于带正则补丁的路由代理。

强制穿越，包括开发和 CI。 整个架构中最难的组织承诺是：没有第二条路。没有使用个人密钥直接访问供应商 API 的“开发捷径”。没有供应商默认基础 URL 为上游提供商的 SDK。没有研究员笔记本电脑上为一次性实验获取的 API 密钥（该实验后来变成了季度计划）。网络出站策略强制执行这一点——防火墙拦截模型供应商域名，除非通过网关的出站 IP。身份策略强制执行它——供应商 API 密钥颁发给网关，而不是个人。构建策略强制执行它——CI 环境获取网关凭证，而不是原始供应商凭证。这之所以是最难的承诺，是因为它会让工程师的生活变得稍微不那么方便，而且必须有高层愿意在沮丧的团队要求特例时维护这一策略。

按路由划分的分类器策略。 并非所有的模型调用都需要相同的 DLP 配置文件。客户支持摘要端点在发送到第三方模型前应脱敏客户 PII，并在返回时还原脱敏。内部代码评审 Agent 可能被允许发送专有源码，但必须从任何日志中剥离客户数据库快照。营销文案生成器如果输入包含任何客户字段，则应拒绝请求。按路由制定策略意味着网关公开命名的路由（而不仅仅是“模型 API”），每个路由都有声明的分类器配置、保留策略和供应商白名单。这就是让安全和产品能够针对同一个工件进行推理的模式。

带有可逆保管库令牌的结构化脱敏。 粗略版本的 DLP 将检测到的 PII 替换为文字 [REDACTED]。这会破坏模型输出质量，因为模型无法再分辨两个 [REDACTED] 令牌是否指代同一个人，并且当应用需要直呼用户姓名时，响应会变得不可用。2025 年 NoPII 基准测试的 109 项测试发现，像 [PERSON] 或 [SSN] 这样的占位符掩码使输出质量下降到 54-68%，而确定性令牌化（每个实体获得自己唯一且不透明的令牌，如 entity_7a3f）保留了 91-96% 的质量。架构模式是：检测 PII，将其更换为保管库令牌 (Vault tokens)，将映射存储在以请求 ID 为键的短期加密保管库中，将令牌化后的 Prompt 发送给供应商，然后在返回途中还原响应。供应商看到的是 entity_7a3f。用户看到的是他们的名字。审计日志记录了 entity_7a3f 对应于特定的客户记录。