会计中的 AI:在黑箱之下依然保留 GoBD 可追溯性

慕尼黑一位税务顾问(Steuerberater)向我们讲述了一次至今仍让他不安的客户审查。账本看起来很干净，数字都对得上。然后他问一位初级员工，某一批收据是怎么被归类的，得到的回答是:“我们把它们粘贴进 ChatGPT,它给出了科目建议。”没有人记录过提示词(prompt),没有人能重现那些建议。账目录入完成了，但产生它的推理过程，在聊天窗口关闭的那一刻就已经蒸发了。

这就是 AI 在 GoBD 层面的问题，一幕就说明白了。不是 AI 判断错了，而是没人能证明它是对的。

GoBD 到底要求什么，说人话

GoBD 是德国税务机关关于以电子形式妥善保存账簿和记录的原则性规定。它并不新，在关键问题上也并不含糊。有三项要求，和大多数生成式 AI 的运作方式直接冲突。

Nachvollziehbarkeit(可追溯性):一个具备专业知识的第三方，必须能够在合理时间内、不需要你的帮助，追溯清楚一笔业务是如何变成一条账目记录的。这条记录要能追溯回源文件，而源文件也要能顺着往前对应到这条记录。正向核对和反向核对都必须成立。

Nachpruefbarkeit(可核验性):记录必须是可以被检验的。审计人员应当能够拿一个数字去核对背后的证据，以及产生它的规则。

Unveraenderbarkeit(不可篡改性):一条记录一旦记入，你不能悄悄覆盖它。任何修改都必须被记录下来，使原始状态和修正后的状态同时保留可查。

还有第四点常被人忽略:Verfahrensdokumentation(流程文档)。你需要把数据进入账本、并在过程中被处理转换的方式记录下来。如果有工具接触了这些数据，这个工具就是你必须描述的流程的一部分。

把这四点放在一起看，答案自然浮现。一个提供“建议”科目归类的自由文本聊天助手，能留下可重现的痕迹吗?不能。它能生成一个可以写下来、第三方可以重新执行一遍的流程吗?除非你自己搭建了这套支撑结构，否则也不能。

为什么一个标准的大语言模型会同时违反这四点

大语言模型做的是，在给定上下文的情况下生成最可能的下一个词元(token)。它不会去调取一个固定数字，也不会以你能检查的方式来做运算。同一个问题问两次，可能得到两个不同的答案，而且都是用同样从容的口吻说出来的。这对起草一封邮件来说没什么问题，但当输出成为一份涉税记录的一部分时，就成了问题。

你可以自己做个测试。把一段损益表摘录粘贴进一个通用助手，问它毛利率。你通常会得到一个数字。在一个新会话里再问一次，你可能会得到一个略有不同的数字，或者不同的四舍五入方式，又或者一个数字第一次悄悄假定了一种增值税(VAT)处理方式，第二次又换了另一种。模型并不是在调取你的毛利率，它是在模式匹配出某个看起来像毛利率的东西。

现在把 GoBD 叠加上去看:

• 可追溯性失败，因为答案无法对应到某一条具体的源数据行。
• 可核验性失败，因为重新运行同样的提示词，未必能重现同一个数字。
• 不可篡改性失败，因为没有记录显示模型当时看到了什么、说了什么。
• Verfahrensdokumentation 无法写出来，因为这个过程本身还不够确定，无法被描述清楚。

这并不意味着 AI 在德国的会计工作中无法使用。它意味着 AI 不能成为记录系统本身，也不能成为做运算的那个环节。

真正的风险:Schatten-KI(影子 AI)

这个问题里危险的那部分，不是一个经过批准使用的工具，而是 Schatten-KI,也就是影子 AI。员工悄悄把账本摘录、发票和客户数据粘贴进另一个标签页里打开着的、随便某个消费级聊天机器人。这感觉起来无伤大雅，毕竟只是“找个帮手问一下”。但每一次粘贴，都是你会计流程中一个未被记录的步骤，其中一些粘贴，同时也是一起等着被发现的数据保护事件。

针对德国财务团队的调查一再呈现出同样的图景:相当一部分员工已经在工作中使用 AI 工具，其中相当一部分是在 IT 部门或管理层不知情的情况下使用的。你无法靠写一份政策文件来让自己置身事外。人们会去用能替自己省下二十分钟的工具。真正的工作是给他们一条经过批准、恰好也是符合 GoBD 要求的路径。

这种风险敞口是具体的。如果一位税务稽查员(Betriebspruefer)认定账目不具备 nachvollziehbar 的特性，最坏的结果不是一封措辞严厉的信，而是 Verwerfung,也就是记录被驳回，税基可能被改为估算。而估算结果，很少对你有利。

在 AI 参与流程时，如何保住审计轨迹

解决之道不是禁止 AI,也不是更多地信任它，而是改变你让 AI 负责的范围。三条原则，按顺序排列。

1. 数字活在经过对账的模型里，而不是活在聊天窗口里

在任何 AI 接触某个数字之前，底层数据必须先被整合进一个能对回总账的、经过对账的财务模型里。会计数据、银行数据、明细账、上传的对账单，先被汇总、匹配、并核对回源头。这才是唯一可信的数据源，它独立于任何人提出的任何问题而存在。AI 并不“知道”你的营收，它是从一个早已与你的账本一致的模型里查出来的。

这正是我们在 Rexfin 所构建的核心:一个所有回答都能追溯回去的、经过对账的模型。如果你想了解为什么对账必须先于 AI 完成，可以参阅关于符合 GoBD 与 AI 法案要求的财务模型的主题文章,里面给出了完整论证。

2. 运算发生在确定性的引擎里，而不是模型里

大语言模型擅长的是用德语理解一个问题，以及用通俗的语言解释一个答案。它不擅长做运算，更不擅长做可审计的运算。因此计算必须发生在某个确定性的环节。问一次毛利率，相同的输入应当每次都按同一个有据可查的公式产生同一个输出。AI 负责路由问题，引擎负责求和。正是这种分工，让结果可重现，而这恰恰是 Nachpruefbarkeit 所要求的。关于这一点更深入的论证，可以参阅姊妹文章《为什么数据质量胜过模型》。

3. 每一个数字都携带出处，并被记录在案

当 AI 报告一个数字时，你应当能点击它，看到:哪些源文件为它提供了输入、哪个计算过程产生了它，以及产生的时间。而这次交互本身，也应当被写入一个不可篡改的日志。这一步同时覆盖了可追溯性和不可篡改性。一个能说清自己来源、并保存在防篡改记录中的数字，是一个你能在稽查(Pruefung)中站得住脚地捍卫的数字。

把这三点放在一起,Verfahrensdokumentation 几乎自己就写出来了，因为现在有了一个稳定、可描述的流程:数据进入，对账，确定性计算，附带引用作答，记录在案。你可以把这份描述交给第三方，他们能够照着走一遍。

一句诚实的提醒

这套做法有必须坦白说明的局限。它不会把 AI 变成记账员，人依然拥有账目录入和判断决策的所有权。它也不能免除你在把记录交给模型处理时所承担的数据保护义务。而且没有任何架构能免除你实际维护 Verfahrensdokumentation 的责任，工具让这件事变得可行，但依然需要你保持它的更新。

它真正为你带来的，是 GoBD 真正追求的那个东西。不是一台更聪明的机器，而是一台经得起辩护的机器。

对任何你想让它接触账本的 AI,测试方法很简单，你甚至可以在演示中当场验证:挑一个它产生的数字，让它把依据摆出来。如果它能说出源文件、重现计算过程，并证明记录未被篡改，它就配得上出现在一个德国财务职能部门里。如果它只能听起来自信满满，那它就不配。

如果你想看看用你自己的账本会是什么效果,预约一次演示,带上一个你平时需要在审计人员面前捍卫的数字来。