可审计、可回滚到底在审什么

「可审计、可回滚」几乎出现在每份 AI 治理要求里，但具体审什么、回到哪一步，往往说不清楚。落到执行层面，审计要回答的是三件事：当时依据什么、谁做的决定、影响范围多大；回滚要能回到一个明确的一致状态，而不是模糊的「上一版」。

审计要回答的三个问题

第一是依据。某次输出是基于哪些数据、哪些规则、哪个版本的模型产生的。这决定了结论是否可解释，也是判断责任的前提。缺少依据的记录，只能说明「系统输出了这个结果」，无法说明为什么。

第二是决定。如果过程中有人工介入，需要记录是谁、在什么时间、做了怎样的调整。如果没有人工介入，则需要记录系统按哪条规则自动放行。两种情况的记录要求不同，不能只记结果。

第三是影响。这次输出影响了什么：触发了哪些下游动作、覆盖了多少对象、是否对外发布。影响范围决定了复核的优先级，也是事后补救的依据。

三个问题对应三类记录。很多企业的留痕只覆盖了第一类，导致审计时无法还原完整过程。

回滚要回到一个明确的一致状态

「回滚到上一版」这个说法过于笼统。实际操作中至少要明确三点。

回到哪个版本。是模型版本、流程配置版本，还是两者一起回退。版本之间的兼容性需要提前确认，避免回退后配置与模型不匹配。

数据怎么处理。回退之后，期间产生的数据是保留、撤销还是标记。如果是自动执行的动作，撤销是否可行，不可撤销的部分如何补偿。这些问题必须在回滚预案里写明。

影响如何通知。已经受到影响的上下游系统与人员需要被告知，避免它们基于旧状态继续操作，造成二次问题。

没有这三点，回滚动作本身可能带来新的不一致。

让审计与回滚成为常规能力

这两项能力如果只在出问题时才被想起，很难在关键时刻发挥作用。可行的做法是把它们嵌入日常流程。

审计记录随运行自动产生，不需要人工整理。回滚演练定期执行，确认在真实环境下能在可接受的时间内完成。演练的重要性常被低估：没有演练过的回滚预案，实际执行时往往因为权限、依赖或数据问题而失败。