《欧盟人工智能法案》第 12 条：为什么每一次 AI 财务决策都必须自我记录

2027 年 3 月，一位监管人员打来电话，只问了一个问题:说明一下 AI 是如何得出你们去年 9 月计提的减值数字的。如果你的答案是一张聊天窗口的截图，你就有麻烦了。这不是声誉问题，而是法律问题。

这正是《欧盟人工智能法案》第 12 条为任何运行高风险 AI 系统的财务部门所创造的现实。条文简短而直白:高风险 AI 系统“应在技术上支持事件(日志)的自动记录”,且贯穿系统的整个生命周期。是自动的，不是手动的;是内置于系统之中，而不是靠某人记得保存的一堆导出 PDF 文件拼凑而成。十年来，财务领域的审计轨迹是一项可以做好也可以做差的最佳实践。而该法案将其归入了“义务”这一栏。

第 12 条究竟要求什么

条文措辞很重要，应当以审计师的眼光来读。系统必须能够自行记录。你不能靠让分析师做笔记来满足这一要求，因为笔记是有选择性的，而该法规恰恰是为防止这种选择性而制定的。日志记录必须贯穿系统的整个生命周期，从上线之日起到退役之日止，而不仅限于当前模型版本。

而且日志必须服务于法案所列明的特定目的。第 12 条将日志记录与三项工作绑定在一起:识别系统可能带来风险的情形、支持上市后监测，以及支持法律其他部分所规定的人类监督义务。简单来说，日志不是一个花架子功能。它存在的目的，是让人能够回溯、重建事件经过，并判断系统的行为是否得当。

接下来是财务团队常常忽略的部分。第 19 条设定了留存下限:日志必须保存与系统用途相适应的期限，且“至少六个月”,除非数据保护法或行业规则要求更长时间。六个月是最低要求，而非目标值。此外还有一条几乎是专门针对银行、保险公司和受监管实体而写的:已在欧盟金融服务法下承担内部治理要求的金融机构类提供者，必须将这些 AI 日志作为其在该法律下已维护的文档记录的一部分予以保存。该法案并没有为财务部门单独设置一套宽松制度，而是把 AI 日志记录直接并入你本已接受审计的文档管理体系之中。

为什么聊天记录不是审计轨迹

陷阱在这里。很多团队以为自己已经合规，因为他们的 AI 工具保留了对话历史。你可以往上翻，看到你问了什么、它答了什么。这难道不就是日志吗?

不是，而这正是本文的核心所在。聊天历史记录的是“话语”。第 12 条要求重建的是“决策”。二者截然不同。当 AI 告诉你的财务控制人员，调整后的 EBITDA 环比下降了 12% 时，真正具有法律意义的问题并不在聊天记录里:它调取了哪些原始数字?来自哪个系统、哪个版本、截至哪次结账日?是什么计算产生了这 12%?这个运算是它自己完成的，还是调用了一个确定性引擎?如果今天用同样的请求重新运行一次，你会得到相同的答案吗?

一份对话记录对以上问题一个都答不了。更糟的是，如果 AI 是在内部计算出该百分比的，那这份记录本身就具有误导性，因为它展示给你的数字很可能根本无法复现。我们此前曾撰文讨论过模型数字对了、运算却错了这一隐蔽的错误类别:比率颠倒、绝对值与百分比混淆、现金流符号错误。聊天日志会把错误答案原封不动地保留下来，却完全说明不了它为什么是错的。

第 12 条真正要求的是血统(lineage)。不是“AI 说了 X”,而是“AI 看到了这些输入，应用了这一操作，产生了这个输出，这就是从原始数据到最终数字的完整路径”。这是结构上完全不同的产物，而多数以 LLM 为核心的财务工具根本产生不了这样的东西。

架构决定了你能否合规

这正是监管从政策问题变成工程问题的地方。你无法记录一个系统从未知晓的东西。如果一个 LLM 读取一份 PDF,在其上下文窗口中暂存一些数字，然后一次性、不加区分地给出答案，那就没有干净的事件可供记录。推理过程与算术运算在概率模型内部纠缠在一起，你得到的是一句听起来合理的话，而不是一个可重建的决策。

出路是将各层分离。连接源系统:你的总账、你的 ERP、你的会计平台，并将它们对账合并为一个能够核对账目的模型。让 AI 从这个已对账的模型中检索数字，而不是每次都重新读取原始报表。将每一次计算都通过确定性引擎而非语言模型来完成，这样每次运行的运算结果都是一致的。这样一来，每一个步骤都成为一个离散的、可记录的事件:检索有来源和时间戳，计算有明确命名的输入和确定的公式，输出则可以沿着这两者一路追溯。

当架构以这种方式运作时，第 12 条的合规几乎是自动实现的，因为系统从一开始设计的目的就是记录决策。日志不是你记得去打开的一项功能，而是数字产生方式的一个自然副产品:相同的输入、相同的输出、完整的路径，这正是审计师所说的“可重放”。

这里值得作一点让步，因为怀疑论者理应得到回应。这一切都不会让 AI 本身变得更真实可靠。一个已对账、具备确定性运算并附有完整日志的层，仍然可能给出一个最终建立在错误源头假设之上的数字。真正改变的是当这种情况发生时，你所处的位置。届时你不必对监管人员耸耸肩，而是可以出示输入数据、版本、计算过程和该数字生成的确切时刻。你可以证明系统做了什么。该法规并不要求 AI 绝对正确，它要求 AI 可问责，而可问责是一种架构选择。

在最后期限到来之前意味着什么

时间表在变动，高风险义务的适用日期也有所调整，但方向没有变。无论最终的执行日期如何，第 12 条设定的门槛，自动记录、至少六个月的留存期、AI 记录并入你现有的金融服务文档体系，都不会放松。这是那种在审计到来之前很容易被忽视，而一旦你手上已经积累了一年未记录的 AI 决策后再想补救，代价会非常高昂的要求。

一个诚实的检验很简单。挑出上个季度 AI 呈现给你财务团队的任意一个数字。你今天能不能不靠模型事后猜测，就重建出它产生的确切过程:来源、版本、计算方式、时间戳?如果能，你已经基本满足了第 12 条的要求。如果不能，你面临的就不只是文档缺口，而是架构缺口，而文档缺口只是它的一个症状。

如果你想亲眼看看每个数字背后可重建的审计轨迹在实践中是什么样子,预约演示,并带上你最难回答的“证明这个数字”的问题。这正是你应该在监管人员发问之前先自己回答好的问题。