先定事件清单
除登录与操作外，AI 应用要额外记录检索命中的文档标识、模型输入摘要与输出内容、人工接管动作。为什么：只记登录无法回答模型为什么这样答，争议时也还原不出依据；上线后补埋点会缺掉整段历史，证据链出现断口。
字段字典统一
主体用统一账号标识而不是姓名，时间统一时区，每条日志带链路标识，把一次请求的多段记录串起来。怎么做：开发埋点前先定十几项必备字段，避免各模块命名不一致，等到拼接排查时才发现对不上，只能返工重来。
日志自身要保护
日志里常含合同正文与客户信息，需要脱敏、单独存储并限制查询权限。为什么：审计库如果谁都能查，它本身就成了新的泄露源；查询日志的行为也要留痕，否则内部人员查看过什么，同样无法追溯。
可检索可还原
留存期限按法规与内部制度设定，《网络安全法》对网络日志留存有明确要求；存储要能防删改，并支持按主体、对象与时间段检索。怎么验证：做一次还原演练，比检查日志条数更能说明审计是否真的可用。
事件清单谁来签字
日志记什么，不能只由开发按方便程度决定。做法：由业务负责人列出争议高发场景，安全负责人补合规必需项，法务确认留存与调取要求，三方在一张事件清单上签字；开发按清单埋点，运维按清单核验覆盖率。清单缺签字的，验收时按未完成处理，不以后补埋点替代。
适用与不适用
适合谁
- 需要向审计证明可追溯的 AI 应用
- 发生过多角色数据争议的业务系统与部门
- 由外部实施方交付并运维的项目与部门
不适合谁
- 只处理公开资料、不含业务数据的演示程序
典型场景
某物流企业的运单异常处理助手接入统一日志。团队先列七类事件与十六个字段，把应用与网关日志汇入同一存储，用链路标识串起检索与生成；日志中的收件人电话做掩码，查询需审批。安全部门每月抽一次真实工单做还原演练。
可执行步骤
- 列出必须留痕的事件：登录、提问、检索命中、生成、导出与授权变更。
- 定字段字典：主体、时间、对象、动作、结果、数据范围与链路标识。
- 把应用与网关日志集中采集，统一时区，同时保留原始时间戳与来源。
- 对日志中的敏感字段做掩码，查询日志需审批，并在日志本身留下访问记录。
- 按法规与内部制度设定留存期限，启用防删改存储并定期演练还原。
常见坑
- 只记登录不记提问与检索，模型给出错误结论时无法还原依据，只能凭印象解释，责任也说不清。
- 日志里直接存客户电话与合同正文，审计库变成新的泄露源，一次权限误配就把风险放大到全员。
- 各系统时间不同步，又没有链路标识，同一次请求的多段日志拼不起来，排查成本明显上升。
自检与验收清单
- 事件清单是否覆盖提问、检索、生成与导出，并有记录
- 字段字典是否包含链路标识、数据范围与结果
- 日志中的客户信息与合同字段是否已掩码，可现场抽查
- 留存期限、防删改措施是否已配置并生效，可逐项核对
常见问题
日志要保存多久？
按客户方合规要求与行业惯例确定，涉及个人信息处理的还要满足最小必要与相应保存期限。关键在于完整、不可篡改、可检索，而不只是保存时间长；长而不可查的日志，在事件调查中帮不上忙。
日志会不会拖慢系统？
异步写入并设缓冲与降级，通常对主流程影响有限。要注意埋点失败不能阻断业务：写日志失败时降级为本地缓存并告警，而不是让请求报错，这一点要在设计阶段写明，并通过压测验证。
只查日志算审计吗？
不够。日志回答发生了什么，审计还要有制度、审批与复核记录相互印证。建议把日志与授权变更单、抽测记录放进同一证据体系，形成可交叉验证的链条，单独一份日志很难支撑审计结论。