一、项目背景

企业把大模型用在客服、合同审核、报销等真实业务里，请求体里常常带着身份证号、手机号、密钥等敏感信息。一旦直接把这些数据送出内网，就存在隐私外泄和合规风险，同时每一笔调用的成本也糊里糊涂没人核算。我们当时给网关增加了一道"出域前脱敏 + 全链路审计 + 按部门配额计量"的能力，让数据在进模型之前先过一道关卡，合规和成本都在网关后台兜住，而不是依赖各业务系统自觉。

之所以把这件事放在网关而不是业务代码里，是因为靠业务侧各自实现一定会有遗漏：新人写的脚本忘了脱敏、老服务改不动、临时接口图省事直接透传，任何一处缺口都会变成明文出域的口子。把脱敏收敛到出域边界这唯一一道闸门，才能做到"全覆盖、可审计、零例外"。

这个项目同样分阶段推进。我们先在测试环境镜像了一份真实流量的脱敏命中分布，确认误杀率可控才切生产；并且保留了"仅审计不改写"的影子模式，让安全团队先用一周数据校验规则覆盖度，再开启真正改写。这一步很关键，否则直接上线改写，一旦规则误伤了正常业务字段，排查成本远高于先影子运行。

二、落地场景

落地后，所有发往外部模型的请求都先在网关脱敏层做扫描替换，敏感字段被掩码后再出域；每一次调用都落审计日志，包含调用方、模型、脱敏命中、耗时与费用；管控台按部门和应用下发配额，超配额直接拦截。业务侧照常调用网关一个地址，不必关心背后做了多少合规处理，安全与成本都由网关在边界处统一收敛。安全团队不再需要逐个服务去推动改造，只要在网关上改一条策略就能覆盖全部流量。对财务而言，按部门拆出的账单也让每一分模型支出对得上责任人，过去那种"全公司一笔糊涂账"的局面就此结束。我们还在网关管控台配置了敏感字段命中的实时告警，一旦某个部门在短时间窗口内出现大量身份证号或密钥类请求，安全团队能在分钟级收到通知并介入核查，而不是等到月底拉对账时才发现异常，这让合规从"事后追溯"变成了"事中拦截"。

三、关键技术挑战与解决思路

第一是敏感字段识别与脱敏。我们用正则加字典双路识别，对身份证、手机号、API 密钥做掩码，密钥类一律整段替换，避免只打星号仍被拼接还原。识别顺序上先跑字典白名单命中高频模式，再做正则兜底，兼顾准确率和性能。脱敏策略片段如下：

mask_rules:
  - name: id_card
    pattern: '\d{17}[\dXx]'
    replace: '****************${last1}'
  - name: phone
    pattern: '1[3-9]\d{9}'
    replace: '1** **** ****'
  - name: api_key
    pattern: '(AKIA|sk-)[A-Za-z0-9]{12,}'
    replace: '<SECRET_MASKED>'

案例片段（已脱敏）：某制造企业对接工单系统时，网关在单日拦截并掩码身份证号约 1.2 万次、手机号约 0.8 万次、密钥约 30 次，未有一例明文出域，合规审计看板全程可追溯但绝不保留明文原文。

第二是审计留痕。我们把脱敏命中数、原始长度、目标模型、耗时、费用写入审计流，保留可追溯的证据链，但存储层只落掩码后的元信息，不保存明文。这样既能证明"哪次调用命中了什么类型的敏感字段"，又不会在日志系统里制造第二份敏感数据泄露点。审计日志片段：

{"ts":"2026-06-12T10:22:01Z","app":"ticket","model":"vendor-a-small","mask_hits":3,"tokens":412,"cost":0.0021,"status":"ok"}

第三是配额计量与超配额拦截。计量层按部门、应用、用户沉淀配额，超限返回 429 并在审计看板告警，既防滥用也防单部门把预算打穿。计量与脱敏共用同一调用上下文，避免重复解析请求体。配额片段：

quota:
  by: [dept, app, user]
  dept_daily_tokens: 2000000
  over_action: reject
  over_code: 429

第四是策略可配置。脱敏规则和配额都下沉到管控台，业务变更不用改代码，热加载即可生效，避免每次合规要求变动都要走发版流程，也减少了运维和研发的扯皮。

四、效果数据

五、可复用经验总结

经验有两点。一是"出域前必过脱敏关卡"：脱敏必须放在网关出域边界、而不是业务代码里各自实现，否则一定会有遗漏，且无法保证全员覆盖，缺口迟早会爆。二是"计量先于优化"：先把每一笔调用的成本和归属算清楚，才能谈降本，否则连浪费在哪都说不清，优化就成了盲人摸象。另外，策略可配置化让我们避免了为每次合规变更发版，这点对运维和安全团队都相当友好，建议从第一天就设计成热加载。最后补一句：脱敏正则要定期复盘误杀和漏杀，业务字段格式一变旧规则就可能失效，把它当成一个需要持续维护的资产而不是一劳永逸的配置。我们也沉淀了一个小机制——每月拉一次审计看板的"改写后人工复核抽样"，挑几十条约单看掩码是否影响模型回答质量，避免为了合规把模型喂成瞎子。合规和可用性之间要找平衡点，脱敏不是越狠越好，而是既要挡住泄露，又不能让业务跑不起来，这条线需要安全和业务一起画。