咨询热线：
0755-26643541
请扫码添加客服的企业微信进行沟通
日期：2026-09-25
某 AI 网关上线后调用量起来了，但谁在什么时间调了什么模型、花了多少钱、有没有越权访问别人的模型，全靠事后翻应用日志，而且日志还是分散的。合规审计来了要啥没啥，翻半天拼不出一条完整的调用链。更糟的是，有个调用方脚本刷接口，查出来时已经刷了一周，损失和隐患都发生了。我们进场时，这个网关的审计能力基本为零，财务和合规都在找它要数据，它给不出。
当时他们觉得网关能转发、能限流就够了，审计是后台的事。结论很清楚，网关是调用流量的总闸，审计得默认全量做在前面，事后补录既漏又慢，合规这事前端做比后端补省心。这个项目让我改了认知，审计不是合规的附加题，是网关的底座能力。
新方案在网关接入层对每一次调用做全量审计埋点，记录调用方身份、目标模型、输入脱敏摘要、输出token、耗时、费用和结果状态，写成一条结构化审计记录落库。敏感操作比如删除模型、改路由策略、导出账单，单独打敏感标记，强制二次确认并留痕。
调用方身份和 API Key 绑定，谁调的、属于哪个部门，一眼可查。审计看板按部门、应用、模型多维聚合，合规和财务自己就能拉报表，不用再找研发翻日志。上线后第一次合规检查，对方要三个月的调用明细，我们十分钟就从看板导出来了，而之前这类需求研发要排期一周。
全量审计最怕性能拖累，每请求多写一条记录，高并发下可能成为瓶颈。我们把审计写入做成异步批量落库，请求主链路不阻塞，审计丢了有重试补偿，性能影响压到忽略不计。敏感操作留痕要防篡改，审计记录一旦生成不允许改，我们对关键字段做哈希链，谁动过一查就知道。
调用方身份绑定难在 Key 管理混乱，一个 Key 多人共用的老毛病得治。我们强制 Key 绑定到具体应用和负责人，闲置 Key 定期回收，越权调用从根上少了。审计看板的聚合查询要快，原始记录量很大，我们按天预聚合加索引，报表秒开而不是等几分钟。
审计写入与防篡改的关键配置如下，主链路决不能因留痕变慢：
audit:
write: async_batch(buffer_flush_ms: 200, retry: on_fail)
block_main_path: false # 主链路不阻塞
tamper_proof: hash_chain(关键字段) # 改了能查出
key_policy:
bind_to: app + owner
idle_recycle_days: 30审计覆盖率做到满分，所有调用不论成功失败都留痕，事后翻日志拼链路的日子结束了。敏感调用留痕率同样满分，删除和改策略这类操作每一条都有二次确认记录。审计查询时长从原来的十几分钟人工拼，降到看板秒级，合规和财务自己就能拉。
越权调用发现数在项目期内抓到两起，都是闲置 Key 被误用，因为身份绑定清晰，定位到人和部门只用了几分钟，而不是像以前查一周。我们复盘时算过，光这两起如果晚发现一周，潜在的模型和账单风险都不小。上线半年，审计记录累计上亿条，查询看板从没卡过，异步写入扛住了峰值。
我们把审计记录也用在了成本分摊上，按部门和应用拆出的调用费用，第一次让各业务线看见自己烧了多少算力，几个滥用大模型的部门主动收敛了。审计从合规工具变成了治理工具，这个溢出价值我们当初没算到，算是顺手摘的果子。我们还把审计异常接进了日常巡检，越权调用不再等合规来查，运维自己就能在看板看到红点。我们复盘时一致认为，审计这事一旦做成默认全量，后面很多治理动作都有了抓手，反过来说，当初省那一步才是真贵。
我们还把审计数据接进了容量规划，哪个应用调用量在涨、哪个模型被集中打，提前一周就能在趋势线上看到，扩容不再被动救火。合规留下的数据，最后成了运维最想要的运营视图，这层溢出价值当初真没算到。我们事后承认，当初图省事没做哈希链，是合规方不认才补上的，但补完反而让审计更可信，算是因祸得福。
网关的调用审计得默认全量，事后补录既漏又慢，合规这事前端做比后端补省心，我们一开始也把它当后台活，吃了没数据的亏。审计写入必须异步，主链路不能为了留痕变慢，异步加补偿足够稳。敏感留痕要防篡改，哈希链比单纯入库靠谱，合规才认。Key 必须绑到人和应用，闲置就回收，越权从根上治比事后查强。我们当时图省事没做哈希链，是合规方不认才补上的。下一步想把审计异常直接接告警，越权调用实时弹而不是事后拉。
案例片段（已脱敏）： 网关接入层全量审计埋点：调用方身份、目标模型、输入脱敏摘要、输出 token、耗时、费用、结果状态，结构化落库。敏感操作（删模型/改路由/导出账单）强制二次确认并哈希链防篡改。审计异步批量落库不阻塞主链路。某周期统计：审计覆盖率 100%；敏感调用留痕率 100%；审计查询由人工十几分钟降至看板秒级；项目期内发现越权调用 2 起（闲置 Key 误用），定位耗时由约 1 周降至几分钟；累计审计记录上亿条查询不卡。