AI 决策追溯需要记录哪些日志

请求返回 200，错误率正常，日志也没丢，但几周后有人追问「AI 当时为什么给出这个结果」，团队仍可能答不上来。作者踩到的坑是：日志记录了服务运行，却没有记录系统决策。

这篇文章的价值，是把 AI 日志从运维问题拉回业务设计：一次决策要留下哪些证据，人工改判怎么串起来，保存多久由谁决定。作者开发的 LogPack 能辅助起草方案，但实际记录、存储和验证仍要团队完成。

服务没报错，不等于决策能追溯

作者原先的日志配置并不简陋：请求追踪、错误率、结构化日志、保留策略和仪表盘都有。问题出在记录对象选错了。

HTTP 访问日志能回答「请求是否到达、耗时多久」，却未必能回答「模型是否把某个申请人判为不符合条件」，更不会自动记录「操作员后来推翻了建议」。

这两类问题处在不同层次。前者关注服务如何处理请求，后者关注系统对业务对象做出了什么判断。

服务可观测，不等于决策可追溯。

作者把这一区别放进 EU AI Act 的高风险系统语境：Article 12 涉及提供者一侧的自动记录要求；Article 26 包含部署者保存系统所生成日志的义务，文章进一步聚焦 Article 26(6)。

这里是在转述作者对条款的定位。原文没有展开法律条文，也没有证明这些要求适用于所有 AI 应用。不能因为项目接入了模型，就直接把整套清单当成普遍适用的合规要求。

先设计决策事件，再决定日志怎么落地

作者认为，一条可用的决策事件至少应包含：

• 事件类型与时间戳。
• 输入的引用、系统输出，以及模型版本。
• 介入操作的人员身份。
• 与覆盖结果或停止操作关联的记录。

其中容易漏掉的，是人工介入。只记录模型最初输出，无法解释最终结果为什么发生变化；只记一条孤立的人工操作，也难以找回它改的是哪次决策。

输入引用同样重要。它提供了找到相关输入的线索，但原文没有交代引用如何解析、对应内容是否会变化，以及如何控制访问权限。这些仍是实施时需要补齐的设计。

作者手工拟方案时，遗漏了人工覆盖等事件，对保留策略也没有给出有效约定。结果，保存多久很容易落到配置日志接收端的人手里，由基础设施默认值替业务做决定。

为补这个缺口，作者开发了 LogPack：用户粘贴 AI 系统的运行描述，工具输出面向 Article 26(6) 的日志设计包，包括准备情况评估、需要捕获的事件清单，以及保留策略中的缺口。

它的输入质量决定草案质量。只写一句「我们用 AI 处理申请」，不足以生成严肃的事件方案；描述需要覆盖系统实际如何运行。

设计草案不能替你保存日志

LogPack 的边界很明确：它不连接基础设施，不采集或存储日志，也不观察系统运行。

日志记录器、存储、访问控制和删除任务，都要团队自行建设。工具也不会验证事件是否完整，更不能判断系统是否属于高风险类别，或团队是否承担部署者角色。作者提到，适用性还涉及 Annex III 中的用例分类。

保留策略尤其不能靠工具填一个数字了事。输入和输出记录得越完整，可能持有的个人数据就越多。作者提出，日志义务需要与数据保护要求一并考虑，但没有给出统一保存期限。

草案能暴露遗漏，不能证明系统已经按要求运行。

因此，LogPack 更接近一份可讨论的设计文档，不是法律意见、认证或实时审计工具。原文也明确否认「填完清单就能保证合规」的推断。

我的判断

作者最有用的提醒，是把日志字段当成业务设计，而不是框架顺手生成的副产品。只要系统结果可能被追问，就应先想清楚：将来需要还原什么，再决定今天记录什么。

但文章对 LogPack 的效果没有提供对照数据，也没有展示完整输出样例。它是否比手工评审遗漏更少、能否节省设计时间，原文没有证明。目前可以把它看作作者针对自身遗漏做出的辅助工具，不能据此认定它优于成熟团队已有的设计流程。

和现成的请求追踪相比，决策事件补充了业务结果与人工干预信息；和已有审计记录相比，它强调输入、输出、模型版本之间的关联。已有这些能力的团队，未必需要再引入一个生成草案的工具，可能只需检查字段和关联关系。

对普通 AI 编程助手、内容生成工具，也不要直接套用文章的法律适用判断。追溯设计有参考价值，具体义务仍取决于系统分类和团队角色。

能拿来做什么

• 在 Node 服务的 AI 调用流程中，检查现有日志能否关联输入引用、输出、模型版本和时间戳，避免排查时只能找到 HTTP 状态与耗时。
• 如果前端提供「接受建议」「人工修改」「停止处理」等操作，把这些动作与原始决策关联起来，让最终结果的变化有记录可查。
• 在接入日志存储前，明确谁能读取记录、保存多久、何时删除，不让日志平台的默认配置代替这些决定。
• 使用 LogPack 或类似草案工具时，提供真实运行流程，并逐项核对输出；涉及高风险系统时，单独确认适用范围，不能用清单代替判断。