AI 推理审计需要记录哪些工程证据

拿出 SOC 2 Type II 报告，不等于能回答客户对 AI 的追问：过去 90 天哪些模型处理过数据，某次决策能否还原，决策记录被改过又该怎么发现？作者指出，常规系统控制与 AI 决策留痕之间，还隔着一层工程建设。

这篇短文的价值，是把抽象的 AI 审计要求拆成几项具体工作：记录模型与提示词版本、保存当时生效的策略、让记录修改可被发现，并设置足够长的保留期。不过，作者给的是工程建议，没有提供落地实验或对照数据。

有了 SOC 2，为什么还会答不上客户的问题

SOC 2 Type II 能证明组织在访问控制、系统监控、变更管理等方面实施了相应控制。作者关心的却是另一组问题：

• 过去 90 天，究竟有哪些模型版本处理过客户的数据？
• 针对某个用户，AI 做了什么具体决策，能否重放产生该决策的输入？
• 谁能编辑这些记录，编辑发生后如何发现？

这三问分别指向处理历史、决策还原和记录完整性。系统运行是否受控，与某次 AI 决策是否有完整证据，是两个不同层次的问题。

作者给出的解释是：传统系统的逻辑通常由人编写，行为更接近确定性；推理系统的逻辑具有统计性，替换一个模型检查点（checkpoint）就可能改变行为，Agent 还会调用工具。只追踪应用代码的变化，未必能覆盖这些变化。

有一份合规报告，不等于已经保存了回答 AI 问题所需的证据。

一条推理记录，至少应该留下什么

作者提出四项做法，核心都是让历史决策能够被追溯。

第一，每条推理记录都绑定模型、模型版本和提示词模板 ID。只知道调用了哪个模型还不够，还要知道当时用的是哪个版本、哪套提示词模板，否则排查时容易拿今天的配置解释昨天的行为。

第二，记录采用仅追加（append-only）存储，并建立哈希链（hash chain），让修改可以被检测。仅追加限制历史记录的覆盖方式；哈希链则把前后记录关联起来，为发现篡改提供依据。

第三，记录决策发生时生效的策略版本。模型输出之外，还要知道当时适用哪套规则。事后只查当前策略，不能证明历史决策遵循了什么要求。

第四，保留期要足够长，至少能回答客户关于「上个季度」的追问。日志还在不在，是所有追溯工作的前提。

作者还提到 ISO 42001，以及 AICPA 正在起草的 AI 专项指导，主张团队不必等框架完善才补齐记录。但原文没有给出相关指导的具体名称、版本或进度，不能据此判断它们已经覆盖哪些要求。

我的判断

作者抓住了一个实际问题：审核通过，不能代替逐笔可查询的业务证据。对接入模型的产品来说，把模型、提示词和策略版本与单次推理关联起来，比故障发生后翻配置、猜版本更可靠。

但「SOC 2 回答不了任何 AI 问题」这个标题说得过满。原文没有逐项分析审计范围，也没有证明某家企业的现有控制和记录一定无法回答这些问题。更稳妥的理解是：不能仅凭 SOC 2 报告，就推定 AI 决策已经具备可追溯性。

四项建议也没有完整解决开头的三问。提示词模板 ID 不包含实际输入；记录了输入，也未必能让统计性模型再次生成完全相同的结果。作者没有展开输入快照、工具返回结果等信息如何保存。

同样，哈希链能否可靠地揭示修改，还取决于校验依据如何保护。谁能编辑记录、谁能重建整条链、如何触发检查，原文都没说清。相比普通可覆盖的日志，它提供了更明确的完整性思路，但不能直接等同于防篡改已经完成。

作者说这些工程「都不难」，属于经验判断，没有成本、性能或实施效果的数据支撑。

能拿来做什么

• 给 Node 推理入口补一份记录字段清单，逐项确认模型、模型版本、提示词模板 ID 和策略版本能否关联到每次请求。
• 用一笔历史 AI 请求做追溯演练，检查能否找到当时的实际输入和决策结果，并区分「恢复调用现场」与「重新生成相同输出」。
• 检查推理记录的写入权限、修改检测方式和保留期，再用「过去 90 天」与「上个季度」两个时间窗口验证是否查得到证据。