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 对应于特定的客户记录。

流向 SIEM 的允许/拒绝判定及 Prompt 指纹。 网关为每个请求记录路由、分类器判定、保管库令牌映射（通过引用而非内容）、Prompt 指纹、模型响应指纹以及归因于 DLP 的延迟。这些流通过与防火墙和代理日志相同的流水线进入安全数据湖，因为当监管机构询问时，调查该问题的将是那个团队。Prompt 本身不会进入 SIEM——那会造成二次泄露——但元数据足以重建发生的情况。

你必须向应用团队推销的契约

技术架构是容易的部分。与应用团队的契约是大多数平台出错的地方，因为平台团队编写契约时，假定工程师会阅读并遵守它，而实际上，工程师会绕过任何非运行时强制执行的契约。

该契约包含三个条款。首先，“如果不经过网关，就不进入模型”——这包括开发环境。一旦研究人员为了快速实验而获取了个人供应商密钥，该实验就会变成一项服务，服务会变成一种依赖，而绑定在网关上的策略在这一用例中就在架构上失效了。开发环境的豁免是所有影子路径的起点。要么你在开发环境中强制执行策略，要么你接受“策略适用于生产环境”这句话的真实含义是“我们将在发布后发现下一次泄露”。

其次，网关是一个稳定、快速、受支持的产品，而不是一种安全税。如果网关延迟为每次调用增加 200 毫秒，团队就会绕过它。如果网关每季度宕机一次，而模型供应商没有，团队就会保留一个“为了弹性”而永不移除的备选路径。将网关视为 SRE 级别的平台——包括 SLO、值班 (on-call)、事后复盘 (postmortems)、容量规划——是让契约变得可以忍受的关键。将其视为平台团队在“真实工作之外”拥有的副业项目，则是导致影子路径产生的原因。

第三，策略更新流程有专人负责且及时。应用团队会遇到网关分类器处理不当的情况。例如，临床病历摘要生成器需要将患者姓名发送给模型，以便摘要读起来自然；网关的默认策略会脱敏这些信息；团队需要一个具有不同策略的路由。如果该请求需要一周时间和三个 Slack 频道才能解决，应用团队就会绕过它。如果只需要一天时间通过自助工作流提交给安全团队审批，应用团队就会使用它。策略更改的吞吐量不是一个功能——它是整个契约的承重元素。

证明 DLP 确实生效的评估 (Eval)

没有评估 (eval) 的 DLP 只是演戏。行之有效的模式是建立一套模拟 PII (个人身份信息) 探测套件，从外部持续对网关运行，测试每个命名路由，并验证两个属性：一是模拟 PII 永远不会进入上游供应商的日志，二是网关的判定日志记录了脱敏操作。第一点通过注入可追踪的金丝雀标识符——模拟社会安全号码 (SSN)、模拟电子邮件地址、测试发行机构范围内的模拟信用卡号——并通过供应商自身的 API 日志（如果公开）或通过行为测试（模型永远不会在响应中补全金丝雀标识符，如果它从请求历史中学习或检索到了这些信息，它就会这样做）来确认金丝雀从未出现在供应商端的工件中。

第二点通过回放网关的判定日志并确认金丝雀触发了预期的分类器来验证。失败的测试是指网关识别到了 PII，但没有进行脱敏，且请求仍然发出的情况，因为该路由的策略配置错误。在 CI 中捕捉到这一点，而不是在生产环境中，这就是季度红队发现与公开披露之间的区别。

一个更微妙但经常被跳过的评估是：测试“重新注水 (re-hydration)”路径是否正常工作。如果网关在请求发出时对客户名称进行了令牌化处理 (tokenize)，模型在响应中使用了该令牌，然后网关将其换回，那么损坏的保险库条目或令牌碰撞错误就意味着模型的响应引用了错误的客户数据。这种失败模式虽然罕见但极具灾难性，在客户发现之前找到它的唯一方法是在评估套件中包含跨租户探测——来自“租户 A”的模拟请求，其响应绝对不应包含解析为租户 B 的令牌。

无人提及的组织失效模式

“网关处执行 DLP”架构失败最常见的原因不是技术问题，而是组织问题，且具有明显的特征。安全团队拥有 DLP 策略，平台团队拥有网关，但谁也不拥有决定给定应用是否真正触发策略的集成。当泄露发生时，安全团队指责平台团队的网关配置错误，平台团队指责应用团队绕过了网关，应用团队则指责安全团队在集成审查期间没有指出缺失的路由。每个人都有部分正确，而泄露在下个季度再次发生。

解决方法是明确指定集成负责人。由一个人——或一个轮值角色——负责每个使用模型的新应用的网关集成。他们签字确认应用使用了网关，路由分类器与数据敏感度匹配，开发环境策略与生产环境一致，且团队已经测试过故意违规操作以确认网关会拦截它。这个人必须在第一个应用发布前就存在，而不是在第一次事故发生后。这份工作并不光鲜，带有些许合规色彩，且在组织架构图中很容易空缺，这正是为什么必须指名道姓地填补它。如果没有这个角色，上述具备四种属性的网关架构只是一个保护不了任何东西的漂亮图表。

做对这一点的团队在第一个季度发布速度较慢，但在之后的每个季度都会变快。没做对的团队在第一个季度发布较快，但在随后的某个季度要向监管机构做出解释。在泄露替你做出选择之前，请先选好你的权衡。