大模型服务审计、访问控制与敏感数据保护，关键不是把每次对话原文都存下来，而是能够回答：谁在什么时间，通过哪个应用调用了哪个模型，系统作出了什么处理，以及出了问题能否追查。日志要足以还原操作链路，同时避免成为新的敏感数据仓库。
审计日志应记录什么
建议把审计事件与运行调试日志区分管理。每条事件至少包含唯一事件编号、时间戳、操作者或服务账号、认证方式、调用应用、模型及版本、操作类型、授权结果、策略版本、请求关联编号、响应状态和耗时。时间统一使用 UTC，方便跨服务核对；像 OpenTelemetry 的 trace_id 可用于关联网关、模型服务和工具调用日志，但关联编号本身不应含用户信息。
根据用途补充来源网络、租户或项目标识、输入输出令牌数、调用额度变化、工具名称及执行结果摘要。记录“调用了什么工具、是否获准、是否成功”通常比保存完整工具参数更安全。认证令牌、密码、密钥和完整提示词不应写入普通审计日志。
提示词和响应怎样保护
默认只记录元数据，不记录原始提示词、模型回答或附件内容。确需排查质量问题时，应由明确的业务目的触发，采用单独的数据采集开关，并限定适用对象、采集期限和查看人员。保存前先过滤身份证件号、邮箱、手机号、访问令牌等字段；对仍需关联的标识，可使用带密钥的 HMAC 生成稳定替代值。普通哈希对低熵数据可能被猜测，不等于匿名化。
日志传输使用加密连接，存储密钥与日志数据分开管理。对审计记录启用追加写入、访问留痕和完整性校验；条件允许时将日志副本写入限制覆盖或删除的存储区。留存期限没有适用于所有服务的统一数字，应依据法律义务、合同、调查需求和数据敏感级别确定。工程上可把“在线检索若干周、之后归档”作为设计选项，例如评估 30 至 90 天的在线窗口，再按风险调整；这不是合规期限建议。
权限按职责拆分，而非人人可查
采用最小权限和职责分离：调用服务只获得调用所需模型与工具的权限；平台运维可以看服务健康、错误码和资源指标，不默认读取提示词；审计人员可查事件和策略变更，但不应因此获得修改日志的权限；安全管理员负责策略、密钥和紧急授权，并通过复核降低单人滥用风险。开发人员需要调试时，应使用脱敏样本或经过审批的临时权限。
| 角色 | 允许操作 | 默认限制 |
|---|---|---|
| 调用应用 | 调用指定模型、提交必要参数 | 不能查询其他应用日志或管理策略 |
| 运维人员 | 查看状态、错误码、调用链 | 不读取原始对话，不删除审计记录 |
| 审计人员 | 检索事件、导出经审批的证据 | 只读，导出行为本身也要记录 |
| 安全管理员 | 配置访问策略、处理紧急事件 | 高风险操作需审批并保留复核记录 |
权限可用 RBAC 角色控制基础范围，再用属性条件限制租户、数据等级、环境和时间。OAuth 2.0 令牌宜设置有限作用域与有效期；共享服务账号应按应用拆分，避免多人共用同一身份。定期核对账号归属，人员离岗、应用下线或权限到期时及时撤销授权。
从配置到复核的落地步骤
- 列出调用入口、模型、工具和可能接触的数据，标注敏感等级。
- 定义统一事件字段与脱敏规则，先在测试环境验证日志不会收集密钥和原始内容。
- 按调用、运维、审计、安全管理划分角色，配置最小权限，并为临时提权设置审批、到期时间和事后复核。
- 开启日志访问记录、完整性检查和备份；模拟一次越权查询与日志删除，确认能告警并留下证据。
- 定期检查高权限账号、异常导出、失败授权和策略变更，按实际风险调整留存与告警规则。
有效的大模型服务审计、访问控制与敏感数据保护，应让每次访问可归属、每项权限有边界、敏感内容少留存，并让日志本身也受到审计。
常见问题
是否应该保存完整对话？
通常不应默认保存。若确有排障或业务需要，应限定范围、用途、期限和访问人，并优先脱敏。
审计人员可以读取提示词吗？
不应因审计身份自动获得原文权限。需要查看时应单独审批、记录理由，并采用限时授权。
日志放在应用数据库里可以吗？
技术上可行，但应用管理员可能同时拥有修改业务数据和日志的能力。高风险场景宜分离写入与管理权限，并保留独立副本及完整性校验。
