企业把大模型接入业务系统之后，安全审计面对的对象已经从单一模型变成了一条调用链：用户或服务账号发起请求，应用通过 SDK 或代理层访问模型，模型可能再访问知识库和工具。只保存一份网关访问日志，往往无法回答“谁在什么时间，用什么权限，把什么数据送到了哪个模型”。
本文给出一套与云上应用兼容的通用方法。具体字段和保存期限需要结合企业行业、适用法规与供应商合同确定。
1. 先定义统一事件模型
不同模型供应商的请求格式和计费字段并不一致。建议在接入层建立统一事件模型，至少保留以下字段：
| 类别 | 关键字段 |
|---|---|
| 身份 | user_id、service_account、department、tenant |
| 资源 | project、environment、application、logical_model |
| 路由 | provider、actual_model、endpoint、region |
| 凭证 | key_alias、credential_scope、policy_version |
| 数据 | data_classification、redaction_action、knowledge_source |
| 结果 | status、latency、tokens、estimated_cost、trace_id |
| 事件 | detection_rule、severity、action、operator、closed_at |
logical_model 和 actual_model 要同时保留。业务代码依赖逻辑模型，平台根据策略将其路由到具体模型；审计时需要知道业务意图和最终落点是否一致。
2. 把证据分成四层
制度层记录 AI 使用规范、数据分类规则、供应商准入和职责分工；配置层记录身份映射、模型目录、权限策略、额度、脱敏规则和策略版本；运行层记录调用、路由、成本、凭证生命周期和审计查询；事件层记录告警、审批、阻断、撤销、复盘和整改。
四层之间要能够通过 trace_id、策略版本和时间范围关联。否则，审计材料看起来很完整，却无法还原某一次请求发生时究竟执行了哪条策略。
3. 在代理层执行轻量控制
云上业务可以在应用与模型供应商之间增加统一的代理或网关层。它不需要保存所有提示词明文，也可以先完成几类通用控制：
- 校验虚拟凭证和调用主体；
- 根据项目、环境和逻辑模型选择 Provider；
- 对密钥、个人信息等敏感内容执行检测、脱敏或阻断；
- 记录策略版本、路由结果、用量和成本口径；
- 对预算、速率和异常增长执行告警或限流。
控制动作需要记录结果，而不是只记录“规则已配置”。例如，redaction_action=masked、policy_version=2026-09-28.3 和 status=allowed 能够说明请求经过了什么处理。
4. 用抽样测试验证证据链
每月随机挑选一条真实调用记录，从调用主体开始，依次检查是否能找到凭证签发记录、当时生效的策略、最终模型、数据处理结果、成本事件和异常处置记录。如果其中一环只能靠人工回忆，说明审计链路仍有缺口。
这类抽样也适合用于上线验收。先用低风险测试项目验证字段和关联关系，再扩大到生产环境，避免等到合规检查时才发现日志无法关联。
5. 多模型环境中的治理边界
统一审计不等于把所有请求都改造成完全相同的格式。供应商的原始请求、计费明细和错误码仍应保留；统一层负责提供身份、策略、路由和事件的共同字段。这样既能横向比较不同模型的使用情况，也能在供应商切换时保持连续的审计记录。
从工程角度看，企业 AI 合规的重点不是堆积更多日志，而是让每一次调用都带有可关联的身份、策略和结果。只要证据链能够稳定生成，安全团队才有可能在异常发生后快速定位、限制影响并完成复盘。
