大模型调用审计：企业后端要能回答谁问了什么

一、审计不是事后补日志

企业系统接入大模型后，会出现新的审计问题：谁发起了请求，使用了哪个模型，输入里是否包含敏感信息，输出是否进入业务流程，是否触发工具调用。如果这些信息没有记录，出问题后很难追责和复盘。

大模型调用审计要成为调用链路的一部分，而不是上线后临时补几行日志。

二、审计链路要覆盖全程

flowchart TD
  A[用户请求] --> B[权限校验]
  B --> C[Prompt 组装]
  C --> D[模型调用]
  D --> E[输出校验]
  E --> F[业务落库]
  B --> G[审计记录]
  D --> G
  F --> G

审计不只记录模型返回。权限、输入摘要、模型版本、工具调用、输出去向都要进入审计。

ai_audit_fields:
  user_id_hash: true
  tenant_id: true
  task_type: true
  model_name: true
  token_usage: true
  output_destination: true

用户标识可以 hash，避免审计表变成新的敏感信息仓库。

三、不要保存完整敏感输入

record AiAuditEvent(
    String requestId,
    String tenantId,
    String taskType,
    String promptHash,
    int inputTokens,
    int outputTokens
) {}

审计需要可追溯，但不一定要保存完整 prompt。可以保存 hash、长度、数据类型、引用 ID 和脱敏摘要。高敏感原文应放在受控存储，按审批访问。

如果把所有 prompt 原文都写进普通日志，审计系统本身就会变成安全风险。

四、审计要能查询和告警

审计数据不是冷冰冰地堆着。异常调用量、敏感任务、失败率突增、高成本请求、越权拦截，都应该能查询和告警。

audit_alert:
  token_cost_spike: true
  sensitive_task_access: true
  repeated_policy_block: true

比如某个租户突然大量调用高价模型，可能是业务活动，也可能是配置错误。没有审计，很难发现。

审计还要支持回放。不是重新调用模型，而是回放当时的输入摘要、路由决策、模型版本和输出校验结果，帮助排查问题。

最后，审计保留周期要按风险分层。普通调用保留短一些，高风险任务和业务落库结果保留更久。所有数据都永久保存，成本和合规压力都会很高。

审计还要记录策略结果。输入是否命中敏感检测、工具调用是否被拦截、输出是否被脱敏，这些都属于安全链路的一部分。只记录最终成功或失败，会丢掉关键判断。

audit_policy_result:
  input_guard: pass
  tool_policy: blocked
  output_filter: masked

对于进入业务数据库的 AI 结果，还要记录人工确认人或确认流程。企业系统里，AI 生成内容一旦影响客户、合同、工单或财务，就必须知道最终是谁确认的。

审计查询也要有权限控制。不是所有研发都能查所有模型调用。审计系统如果没有权限边界，本身就可能泄露业务信息。

最后，审计数据要能导出给合规或安全团队，但导出也要留痕。审计链路的每一次查看和导出，都应该被审计。

审计系统本身也面临 Trade-offs。审计越详细，存储和查询成本越高；审计越精简，出问题时可追溯性越差。一个可行的方案是按风险等级分层：高风险任务（如合同审核、财务决策、客户数据访问）记录完整上下文，包括输入摘要、输出摘要、模型版本和工具调用序列；中等风险任务记录关键字段，如任务类型、token 消耗、成功/失败状态；低风险任务只记录聚合指标，如调用次数、成本、错误率。分层审计可以在合规要求和系统成本之间找到平衡，而不是一刀切地全量记录。

审计数据的实时性要求也值得单独讨论。审计事件产生后，是同步写入还是异步批量写入？同步写入会影响主链路延迟，异步写入可能在系统崩溃时丢失最近的审计记录。对于涉及资金、合同、个人隐私的调用，建议使用双写策略：先同步写入一条简化记录（包含请求 ID、时间、用户、任务类型），再异步补充完整上下文。这样即使异步链路出问题，至少能追溯到"谁在什么时间发起了什么类型的请求"，为进一步排查提供线索。

五、总结

大模型调用审计要覆盖用户、租户、任务、模型、token、工具、输出去向和策略拦截，同时避免保存过多敏感原文。

企业后端要能回答谁问了什么、模型做了什么、结果去了哪里。回答不出来，就还没真正接入生产。