一、项目背景

我们当时服务的客户是一家以合同履约和售后工单为核心业务的某省级国资集团。他们的客服、法务、运营团队在日常工作中大量使用大模型辅助处理业务——比如把工单内容丢给模型做归类摘要、把合同条款交给模型做风险提示、把客户投诉转写文本交给模型做情绪分析。这些请求的真实价值在于模型能力，但业务数据里夹带着大量不该出域的内容：客户手机号、身份证号、银行卡号、合同金额、商业谈判底价等。

问题很现实：商用大模型是第三方托管的，一旦敏感字段随请求出域，就构成数据泄露；而私有化部署的小模型算力有限，复杂任务又离不开大模型。另一个痛点是成本：大模型按 token 计费，集团十几个业务部门都在调，三个月下来账单是一笔糊涂账，谁在滥用、谁在浪费，财务和信息化部门谁也说不清。

我们当时面对的核心诉求就两条——数据不能乱出域，成本要能算到部门头上。这恰好是 AI 网关作为"统一出入口"能系统性解决的问题，而不是在各个业务系统里各自补校验逻辑能搞定的。

二、落地场景

我们把 AI 网关部署在业务系统和模型实例之间，作为所有模型调用的唯一出入口。业务系统不再直连任何模型，而是统一调用网关暴露的 REST/gRPC 接口（兼容 OpenAI 风格协议）。一条典型的请求生命周期是这样走的：

1. 业务系统发起模型调用，请求先进入网关接入层（Gateway-In）做鉴权和协议归一化；
2. 网关在请求真正出域（到商用模型）之前，先经过脱敏与合规策略关卡：命中敏感字段的先脱敏，命中"禁止出域"规则的要么改写要么拒绝；
3. 通过校验后，路由层（Routing）按模型能力画像、实时成本、延迟和部门配额，把请求分发到最合适的模型实例（私有小模型或商用大模型）；
4. 调用返回后，计量层（Metering）统一记录 token/耗时/费用，并把账单沉淀到对应部门和应用；
5. 全过程审计留痕，管控台（Console）和审计看板可随时回溯"谁、何时、调了哪个模型、输入输出摘要"。

在这个架构里，脱敏、审计、计量不是三个独立功能，而是同一条请求链路上的三道关卡。这一点很关键——我们后来复盘，治理之所以能真正落地，靠的就是"所有流量必须过网关"这个硬约束，而不是靠各部门自觉。

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

① 敏感数据识别与脱敏

我们采用"正则 + NER 双路识别"的策略。正则负责结构稳定的强特征字段：手机号（1[3-9]\d{9}）、身份证（\d{17}[\dXx]）、银行卡（\d{16,19}）、金额（(人民币|￥)?\s?\d{1,3}(,\d{3})*(\.\d{2})?）等。NER 负责非结构化文本里的弱特征实体，比如合同里"甲方：某某科技有限公司"这类主体名称、谈判底价等自由表述。识别命中后，按字段类型做差异化脱敏：手机号保留前三位后四位（138****1234），身份证保留前六后四，金额统一替换为 <AMOUNT> 占位符。脱敏后再放行出域。核心原则是"先脱敏、后出域"，脱敏动作发生在网关内部，明文不出网关内存边界。

② 审计留痕

审计日志采用结构化字段设计，每条记录至少包含：调用方身份（部门/应用/用户）、时间戳、目标模型、请求意图标签、输入摘要哈希、输出摘要哈希、是否触发脱敏、是否命中拦截、耗时与 token。输入输出的完整内容不落库（避免审计库本身变成新的泄露点），只存摘要哈希与命中标记，需要回溯时凭工单权限临时调取网关侧缓存。这样兼顾了"可追溯"与"不二次泄露"。

③ 配额与计量

计量层对每个部门维护一个令牌桶（token bucket）。每次调用按预估 token 扣减桶内额度，桶空则触发拒绝或降级（降到私有小模型）。账单按"部门 → 应用 → 用户"三级维度沉淀，月底由管控台导出。我们特别强调"计量先于优化"：在还没看清各部门的真实消耗分布前，不做任何激进的限流，先把数据跑起来。等账单可视化后，滥用和浪费自然就暴露了。

④ 合规策略可配置

我们把合规规则从代码里抽出来，做成管控台可配置的策略。两类规则最常用：一类是"禁止出域字段"——比如某客户的商业底价字段，无论是否被识别为敏感，一律不允许进入商用模型；另一类是"模型可用域"——某些强合规数据只允许路由到私有化部署模型，路由层在分发前会强制校验。策略热更新，无需重启网关。

案例片段（已脱敏）： 网关脱敏与拦截策略配置（YAML 示意）：yaml policies:  - name: mask_pii_before_egress    match:      fields: [phone, id_card, bank_card]    action: mask    masks:      phone: "138****1234"      # 保留前3后4      id_card: "44030*********1234"  # 保留前6后4  - name: block_secret_price    match:      regex: "谈判底价[:：]\\s*\\d+"    action: deny    reason: "商业机密禁止出域"  - name: private_only_models    models: [legal-7b-private]    scope: internal_only        # 仅内网私有模型可用一次审计日志记录（脱敏后）：json {  "ts": "2026-03-18T10:22:05+08:00",  "dept": "法务部", "app": "合同审查", "user": "u_8821",  "model": "gpt-commercial",  "intent": "合同风险提示",  "masked": true, "blocked": false,  "prompt_tokens": 1820, "completion_tokens": 640,  "cost_cny": 1.27, "latency_ms": 3120 }

四、效果数据

上线约一个季度后，我们统计了脱敏示意数据（均为脱敏示意值，非审计级精确数字）：

• 敏感字段拦截/脱敏次数：月均约 4.2 万次请求触发脱敏，约 1,100 次因命中"禁止出域"规则被网关直接拒绝，未再发生任何明文敏感字段进入商用模型的事件；
• 合规审计：在后续一次集团内部合规自查中，模型调用链路通过率 100%，审计看板可完整回溯任意一条调用的"谁—何时—哪个模型—输入输出摘要"；
• 成本可视化与下降：账单按部门拆开后，信息化部门发现某两个部门占了总 token 消耗的近六成，其中相当比例是无业务价值的调试调用。推动治理后，整体商用模型 token 消耗约下降 38%，月度 AI 支出从约 6.8 万元降至约 4.2 万元；
• 配额治理：令牌桶上线后，原先偶发的"月底预算雪崩"现象消失，超配额请求自动降级到私有模型，关键业务不再因额度耗尽而中断。

五、可复用经验总结

• 出域前必过脱敏关卡：脱敏必须放在网关层集中做，而不是散落到各业务系统。集中才有强制力，分散必然有漏网之鱼。我们所有的商用模型调用，明文一律不出网关内存边界。
• 计量先于优化：别一上来就限流封杀。先把每部门、每应用、每用户的消耗跑清楚，账单可视化本身就是最强的治理工具，浪费会自己现形。
• 审计留痕但不留存明文：审计库如果存完整输入输出，就等于新建了一个高价值泄露点。只存摘要哈希和命中标记，需要回溯时凭权限临时调取，既满足合规又可防二次泄露。
• 合规策略配置化：哪些字段禁止出域、哪些模型仅内网可用，要能热更新，别写死在代码里。业务合规要求会变，网关得跟得上。
• 网关是治理的支点：数据防泄露和成本治理这两件事，本质都依赖"所有流量必须过网关"这一硬约束。只要存在绕过网关直连模型的口子，任何治理策略都是纸面文章。

结语：AI 网关在我们这个项目里不是"加了一层转发"，而是把原来分散在业务系统里、没人管得了的数据安全和成本核算问题，收拢成一个可观测、可配置、可追溯的统一控制面。对正在上大模型的企业来说，先立网关、再谈场景，往往比先堆场景、后补安全要省心得多。