坑一：只记登录
最常见的做法是接入单点登录后就算完成，提问、检索、生成一概不记。为什么致命：争议往往发生在回答内容上，没有输入与输出的日志，既无法复核模型依据，也判断不出是谁触发了这次查询，只能靠当事人回忆。
坑二：明文入库
日志直接把合同正文、手机号、地址写进去，看似完整，实际把审计库变成了高危数据仓库。怎么做：入库前按字段脱敏，正文只留摘要与文档标识，确需原文的场景单独授权并按审批调取，查询行为同样留痕。
坑三与坑四：断裂与可删
各服务时间不同步又缺链路标识，一次请求的日志分散在网关、应用与模型调用三处，拼不出完整链路；日志目录又对应用账号可写，出事后第一反应是清空文件，证据随之消失，事后无法补救，怎么补都来不及。
坑五：只存不查
日志存了几年，从没做过检索与还原演练，真要调取才发现字段缺失、索引没建、权限不对。怎么改：每季度抽一次真实业务问题做还原，把耗时与缺口记录下来，倒逼字段、索引与审批流程补齐。
别把日志当免责
有的团队以为日志齐全就能在争议中免责，这是误解。日志证明系统当时记录了什么，不证明行为合法，也不替代法律意见与责任认定；能不能作为证据、证明力多大，由客户方法务与外部机构判断。做法：把日志定位为事实还原工具，争议时提供完整链路与原始记录，结论交由客户方与专业机构作出。
适用与不适用
适合谁
- 发生日志争议或审计问询的系统与部门
- 准备接入审计平台的 AI 应用与部门
- 承担安全整改任务的运维团队与部门
不适合谁
- 完全离线、不处理业务数据的演示程序
典型场景
某制造企业的设备维修助手在上线半年后被质疑给出了错误的安全规程。排查时发现只记了登录日志，检索与生成内容均未留存，无法确认当时检索到哪一版规程；团队随后补齐输入输出摘要与链路标识，并做了两次还原演练。
可执行步骤
- 盘点现有日志：登录、提问、检索、生成、导出各自有没有留痕与字段。
- 为缺失环节补埋点，先定字段再开发，避免各模块命名各自为政，完成后归档。
- 入库前按字段脱敏，正文只留摘要与文档标识，原文另行授权调取。
- 检查日志目录权限，改用只写或哈希链存储，禁止应用账号删除与覆盖。
- 每季度做一次还原演练，按演练结果补齐字段、索引与访问审批，并留存记录。
常见坑
- 只接登录日志就算完成审计，回答内容无从复核，争议发生时只能凭印象解释，责任边界模糊。
- 日志明文保存合同与客户信息，一次权限误配就让审计库成为泄露源，影响面比原系统更大。
- 日志目录对应用账号可写，出事第一反应是清空文件，证据灭失后再想还原时间线已不可能。
自检与验收清单
- 提问、检索、生成与导出四类动作是否都有留痕
- 日志入库前是否按字段脱敏，并留存摘要标识
- 多段日志能否通过链路标识完整拼接还原，可现场抽查
- 日志存储是否禁止应用账号删除、覆盖或改名
常见问题
日志记多了会不会有风险？
会。日志本身也是数据资产，记全与记少都要有边界：只记审计必需字段，敏感内容脱敏或摘要化，访问权限按角色收敛。记全但不设访问控制，风险比不记更高，这一点在设计时要一并考虑。
五个坑里哪个最严重？
无法还原最严重。其他问题都能通过补埋点、改权限逐步修复，唯独历史日志缺失无法追补；一旦争议发生在补记之前，就没有证据可用。所以事件清单要在功能开发同期确定，不能等上线后再补。
小系统也要做这么全吗？
可以按风险裁剪。不含敏感数据、只有内部少数人使用的工具，保留登录与关键操作即可；涉及客户数据或对外服务的系统，提问与检索必须留痕，否则无法回应监管与客户的追溯要求。