AI 调用日志的两难：既要能对账审计，又不能成为新的泄露点
团队把大模型调用收进统一入口后，日志系统很快会面对一个看似简单、实则两头为难的问题：排障和对账需要尽可能多的细节，而完整的提示词与回复里又常常带着客户资料、内部文档和代码。如果一律全量记录、长期保存，日志库本身就会变成最大的敏感数据聚集点；如果什么都不留，出了问题又无从查起。本文把这个问题拆成三件事来回答：哪些字段必须留、哪些内容应该默认关闭或脱敏、不同层的保留期怎么定。依据包括 OpenTelemetry 的 GenAI 语义约定、OpenAI 的数据保留说明与 GDPR 第 5 条的原则（核验日期 2026-10-01）；具体保留天数请由合规与财务部门确认，文中的时长仅为设计思路。
从三份公开资料里得到的设计原则
行业约定：元数据默认记录，内容默认关闭
OpenTelemetry 的 GenAI 语义约定把模型名、操作类型、输入输出 Token 数、结束原因这类字段当作常规属性，而把输入消息、输出消息这类内容字段定为选择性开启。该约定说明，输入消息很可能包含用户个人信息等敏感内容，实现方可以提供过滤或截断的选项；记录内容时有三种常见方式：默认不记录、写在 span 属性里（便捷但有大小限制，且所有能看链路追踪的人都能看到）、存到外部存储并在 span 里只留引用，后一种更适合敏感数据与大流量场景。该规范目前仍处在演进中，字段名可能调整，落地前要对照最新版本。
上游厂商：你的日志之外，还有对方的保留
OpenAI 的数据保留说明里写明，默认情况下所有 API 调用都会生成滥用监测日志，最多保留 30 天，法律要求更长时除外；符合条件的客户经批准可以启用零数据保留，定制选项在组织或项目的数据控制设置里配置；不同端点的保留方式也不同，比如某些端点保留 30 天，有些会话类数据则保留到被删除为止。这意味着设计自己的保留期时，要把上游的保留情况一起列进数据流清单，不要默认“我们删了就等于没有”。
法规原则：最小化与存储限制
GDPR 第 5 条提出两条与日志直接相关的原则：数据应当“适当、相关，并限于处理目的所必需”，以及能识别个人身份的数据保存时间不应超过实现目的所需。翻译成日志设计就是：每一个字段都要能说出“为了什么用途留”，并给它一个明确的过期规则。这是原则性要求，具体适用与天数请以所在地区的法规与公司制度为准。
四层字段：元数据、内容、聚合指标、禁止落盘
第一层：元数据，审计与对账的基础
这一层不含正文，风险相对低，可以长期保留：请求 ID、时间戳、调用方（用户、应用、项目）、模型名与版本、路由与回退的每一跳、输入输出 Token 数、首字延迟与总耗时、结束原因、错误分类、单次费用、提示词与 Schema 的版本号。有了这些，就能回答“谁在什么时候用了哪个模型、花了多少、是否发生过切换”。其中“用户”建议记录内部 ID，而不是姓名、邮箱等直接标识。
第二层：内容，默认关闭或脱敏后短期保留
提示词与回复正文对排障很有帮助，但风险最高。建议默认关闭，需要时按应用、按时段开启；开启后先脱敏再写入，并把正文存到独立、权限更严的存储，日志里只留引用。保留期要明显短于元数据，可以参考上游对滥用监测日志的 30 天量级作为上限思路，再按用途缩短。
第三层：聚合指标，长期保留且不含个人标识
按天、按项目、按模型汇总的用量、费用、错误率与延迟分位数，用于趋势、预算与容量规划，可以长期保留，不需要关联到个人。预算与分摊的使用方式，可以对照团队 AI 预算治理：用量看板、告警阈值与部门分摊。
第四层：禁止落盘的内容
API 密钥、访问令牌、完整的授权头、用户密码、支付信息，不论是在请求头、错误信息还是工具参数里出现，都应该在写入前被剔除或替换，并把“日志里出现密钥样式字符串”作为告警项。这一层没有保留期一说，目标就是不写。
| 层级 | 典型字段 | 默认状态 | 保留思路 |
|---|---|---|---|
| 元数据 | 请求 ID、模型、Token、延迟、费用、回退路径 | 默认记录 | 按审计与财务要求较长保留，由合规确认天数 |
| 内容 | 提示词、回复正文、工具参数 | 默认关闭或脱敏 | 短期保留，独立存储，到期自动删除 |
| 聚合指标 | 日用量、错误率、P95 延迟 | 默认记录 | 长期保留，不含个人标识 |
| 凭证与密钥 | API Key、令牌、授权头 | 禁止落盘 | 不保留，写入前剔除 |
审计真正需要的三类证据
谁调用了、调用了什么模型、结果如何
审计通常不需要读正文，而是需要确认三件事：调用方的身份与授权范围、实际使用的模型与路由路径、结果状态与结束原因。路由与回退路径尤其重要，因为一次请求实际走了哪个模型，直接关系到费用、数据去向和结果质量，这部分的记录方式可以对照多模型路由自动切换的原理。
费用异常的回溯依据
用量突然超支时，运营最常问的是“是哪个应用、哪一天、哪类请求导致的”。元数据层里的应用、模型、Token 与费用已经足够回答，不需要翻看提示词正文。成本异常的排查思路可以对照Token 用量突然超支怎么办。
访问日志的人，也要被记录
审计系统自己也需要被审计：谁在什么时候查看了哪些内容、是否导出过数据。内容层的访问要单独授权、单独记录，避免所有有看板权限的人都能看到原文。
落地清单：上线前要确认的六件事
- 列出每一个记录字段的用途，没有明确用途的字段不记录。
- 内容层默认关闭，开启需要审批与期限。
- 写入前统一剔除密钥样式字符串，并把命中情况作为告警。
- 用户标识用内部 ID，不直接记录姓名、邮箱、手机号。
- 每一层都配自动过期任务，并定期抽查是否真的删除。
- 把上游厂商的保留情况列进数据流清单，并由合规确认天数。
总结：留得起账，也删得干净
AI 调用日志的设计核心是分层：元数据负责对账与审计，内容负责短期排障，聚合指标负责趋势与预算，凭证则不落盘。如果你的团队正在评估统一的模型入口，可以先用 Tonbo AI 的内置 AI Chat 面板和多模型路由，对照自己的字段清单，确认用量、模型和回退路径是否都能在元数据层查到，再决定内容层要不要开、开多久。接入方式见OpenAI 兼容 Token API 接入指南。
