大模型调用审计企业后端要能回答谁问了什么一、审计不是事后补日志企业系统接入大模型后会出现新的审计问题谁发起了请求使用了哪个模型输入里是否包含敏感信息输出是否进入业务流程是否触发工具调用。如果这些信息没有记录出问题后很难追责和复盘。大模型调用审计要成为调用链路的一部分而不是上线后临时补几行日志。二、审计链路要覆盖全程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、工具、输出去向和策略拦截同时避免保存过多敏感原文。企业后端要能回答谁问了什么、模型做了什么、结果去了哪里。回答不出来就还没真正接入生产。