企业部署大模型聚合平台时，审计日志不只是“记录一次调用”，还需要回答四个问题：谁在什么时间，以什么身份，通过哪个应用执行了什么操作；该操作涉及哪些模型或配置；系统如何处理；后续能否按用户、部门、应用或项目完成检索与追溯。
以下是一套用于部署评估的审计日志设计框架。具体字段、保存期限和访问规则，仍需结合企业内部制度、数据分类分级要求及适用法规确认。
一、先区分三类日志
- 模型调用日志
用于记录模型请求链路。建议评估的字段包括：请求时间、请求标识、用户或服务身份、所属部门、应用或项目、调用入口、目标模型标识、请求状态、响应耗时、用量统计、异常代码及链路追踪标识。
- 管理操作日志
用于记录平台配置变化。建议覆盖：账号与角色调整、权限策略变更、模型接入配置变更、路由规则调整、应用创建与停用、凭证创建或撤销、日志策略修改及数据导出操作。
- 安全与审计事件日志
用于记录身份验证失败、异常访问、权限拒绝、批量导出、审计日志查询及其他需要复核的事件。是否设置告警以及告警条件，应由部署方结合业务风险确定。
二、责任追踪需要哪些关键字段
部署前可重点核对以下维度：
• 主体：用户、服务账号、角色、部门及租户标识。
• 对象：应用、项目、模型、接口、配置项及数据资源。
• 动作：调用、创建、修改、删除、授权、撤销、导出或查询。
• 时间：事件发生时间、接收时间及处理完成时间，并统一时间基准。
• 结果：成功、失败、拒绝、超时及对应错误标识。
• 链路：请求标识、会话标识或关联事件标识，用于串联调用与管理操作。
• 来源：访问入口、客户端类型及必要的网络来源信息。
如果企业需要跨部门治理，建议在身份体系中提前明确部门、应用和项目之间的归属关系。仅记录用户名，通常不足以支持复杂场景下的责任定位。
三、是否记录提示词和模型输出
这不是简单的“记录”或“不记录”问题。提示词和模型输出可能包含业务信息、个人信息或其他敏感内容，部署方应先确定记录目的、访问范围、保存期限和脱敏规则。
可按风险分层评估：
• 默认记录请求标识、模型标识、状态、耗时和用量等元数据。
• 对内容正文采用脱敏、摘要、哈希或受控引用方式时，应确认其是否满足实际审计目标。
• 只有在确有审计依据时，才评估保存完整内容，并限制查询、导出和二次使用权限。
• 不应在日志中直接保存明文访问凭证、认证密钥或其他高敏感认证信息。
四、日志本身也需要治理
审计日志并非记录后即可结束。部署评估还应覆盖：
• 谁可以查询、导出和删除日志。
• 查询和导出行为是否再次留痕。
• 保存期限如何按日志类型和业务场景设置。
• 是否具备完整性校验、备份和恢复安排。
• 多系统时间是否一致，事件能否按统一标识关联。
• 员工离岗、部门调整或应用停用后，历史记录如何保留和检索。
• 日志中的敏感字段如何脱敏，导出文件如何控制访问。
五、部署前建议完成一次追溯演练
可以选择一条测试请求，从应用入口开始，依次核对身份、权限判断、模型调用、异常处理、管理操作和日志查询结果。演练重点不是日志数量，而是能否依据授权，在合理范围内还原事件链路，并明确各环节责任边界。
适用边界：本文提供的是通用设计与评估清单，不构成法律、监管或特定行业合规结论，也不代表任何具体平台已经具备上述字段和机制。企业应结合现有身份系统、组织结构、数据制度及实际部署方案逐项确认。
如需进一步梳理部署评估项，可下载相关资料，并结合贵司希望按用户、部门、应用或项目追踪的实际需求开展核对。
