一、项目背景

我们网关团队在支撑企业内部 AI 平台时，合规团队提了一个硬需求：所有经过网关的模型调用，请求和响应都要留痕，且响应里的敏感内容要在出口处实时拦下来，不能等事后审计才发现违规。早期网关只管转发，既没审计也没护栏，出了事追不到是谁、调了什么、回了什么，责任界定全靠回忆。我们这个项目要把网关从"透明管道"变成"可审计、可守门"的合规节点，让合规从事后救火变成事前卡口。

二、落地场景

能力落在网关的接入层出口和计量层。每次调用，网关异步记录一条审计日志：谁（租户、用户）、调了哪个模型、什么时间、token 消耗、响应是否命中敏感策略。同时，在响应返回前，对生成内容做敏感词与风险模式实时扫描，命中高风险的直接拦截并返回安全提示，中低风险的打标留存供事后复核。管控台可按部门、应用、用户下钻审计，合规同学终于不用再跨系统翻日志。

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

第一难是实时扫描性能。审计和扫描不能拖慢主链路。我们把审计改成异步落库（fire-and-forget 加本地缓冲批量写），扫描放在响应流式输出的间隙做增量匹配，主路径几乎零额外延迟，用户无感。第二难是误拦截平衡。敏感词太严会误伤正常业务（如医疗场景谈"症状"），我们做了风险分级：高风险词硬拦，中风险词打标并触发人工复核队列，低风险仅记录，把"误伤"控制在可接受范围。第三难是审计存储成本。全量留痕量大，我们对请求体做摘要存储、保留原始响应抽样，既满足追溯又控成本，不因为合规把存储账单撑爆。

案例片段（已脱敏）： 审计日志片段： ts=2026-07-14T10:22:03 tenant=T01 user=u_4471 model=chat-13b tokens=1824 risk=medium rule=R_SENS_12 flagged=true action=review 拦截统计（周）： 硬拦 142 次, 打标复核 318 次, 误拦申诉 3 次 (误拦率约 0.7%)

四、效果数据

脱敏运行数据：审计覆盖率达百分之百（所有经网关调用均留痕）；敏感内容出口拦截率约百分之九十九点二（高风险命中几乎零漏过）；误拦率控制在约百分之零点七；因可审计，一起合规事件的定位耗时从原先的"跨多系统翻数小时"降到约十分钟。审计存储成本通过摘要加抽样策略下降约百分之六十五。合规团队从"出了事查不清"变成"随时能拉清单"，治理主动性彻底不同。

五、可复用经验总结

其一，网关天然是做审计和护栏的最佳位置——所有流量都过它，守在这里比事后补救省事得多，也拦得更早。其二，审计必须异步化，同步落库会把主链路拖死，得不偿失。其三，敏感词要分级，高风险硬拦、中风险复核、低风险记录，一刀切误伤业务还招骂。其四，留痕要兼顾成本，请求摘要加响应抽样足以满足绝大多数追溯，别为了完美埋单。其五，审计和计量同源，一次记录同时喂给合规看板和成本账单，别各做一套，重复采集既浪费又容易对不上。

附：规模化落地的几点工程取舍

审计拦截规模化后，第一关是实时扫描的开销。每字都扫太贵，我们对长响应做分块流式扫描，边生成边匹配，主链路几乎无感，这是能上生产的关键。第二是风险分级的维护，敏感词库要随业务和法规更新，我们把它做成可配置并支持热加载，合规同学自助维护，不必等发版。第三是误拦的申诉闭环，中风险打标复核如果只记不处理，等于没人看，我们给复核队列设了处理时限和抽检，确保分级不是甩锅。第四是审计存储，全量留原始响应太贵，我们存请求摘要加响应抽样，抽样比例按风险等级调高，既控成本又保追溯。第五是审计和计量的同源，一次记录同时喂合规和账单，避免两套采集对不上引发扯皮。合规能力要规模化，核心是把"守门"做成低延迟、可配置、有闭环的公共服务，而不是贴在链路上的补丁。

附二：给同行落地审计拦截的一点提醒

第一，审计必须异步化，同步落库会拖死主链路，这点没商量。第二，敏感词要分级，高风险硬拦、中风险复核、低风险记录，一刀切误伤业务还招骂。第三，实时扫描要流式做，边生成边匹配，主链路才能无感。第四，词库要可配置热加载，合规同学自助维护，别每次改词都发版。第五，中风险复核要有处理时限和抽检，否则打标等于甩锅，闭环断了。第六，审计存储要摘要加抽样，按风险等级调抽样比例，既控成本又保追溯。第七，审计和计量同源一次记录双用，别各做一套对不上。合规能力规模化的核心，是把守门做成低延迟可配置有闭环的公共服务，而不是贴在链路上的补丁，定位对了，合规和业务才不打架。

附三：踩过的坑

我们早期把审计日志同步写数据库，结果一次数据库抖动直接把网关主链路拖慢，教训很贵，改成异步后这个问题彻底消失。另一个坑是敏感词库一开始只配了硬词、中风险没分级，导致一批正常咨询被误拦引发投诉，补齐分级后才平稳。