治理财务领域的 AI：LLM 时代的模型风险、控制与验证

2026 年 4 月，美联储、货币监理署（OCC）和联邦存款保险公司（FDIC）废止了 SR 11-7，代之以一套基于风险的跨机构模型风险管理框架。随后他们做了一件应该让每一位财务负责人为之警醒的事：新规定明确将生成式和自主式 AI 排除 在适用范围之外，称其“新颖且发展迅速”，并承诺日后会另行发布征求意见稿。于是，十年来财务领域最强大、最不可预测的技术，恰恰在其治理规则出现空白的这段窗口期，进入了你的技术栈。

这个空白不能成为观望的借口。审查人员不需要一份专门的 AI 指引才能询问你如何管控一个触及总账的工具。他们照样会问。而“LLM 是这么说的”绝不是你在质询下想给出的答案。

本专题内容旨在用你真正能够站得住脚的控制措施来弥合这一空白。不是政策表演，也不是一份没人读的四十页 AI 章程。贯穿以下每一页的论点很简单：LLM 是一个有用的界面，却是一个糟糕的记录系统。治理财务领域 AI 的方法，是不再要求它去做那些无法被验证的事情，而是围绕它擅长的事情部署确定性机制和严格的审计轨迹。

为什么语言模型无法通过模型风险测试

模型风险管理一直建立在几个假设之上：模型是一种将输入转化为输出的量化方法。你可以对其进行规范说明，用基准对其验证，测试其边界，并复现其结果。SR 11-7 的核心要求是“有效质疑”：由合格且独立的人员不断施压，直到理解模型的失效点为止。

大语言模型同时违反了这些假设中的大多数。

它是非确定性的。同一个问题问两次，你可能得到两个不同的数字、两种不同的舍入方式、对“上一季度”两种不同的解读。它没有自己的审计轨迹：产生答案的权重是一个 1750 亿参数的黑箱，而不是一份可核算的计算过程。它容易被诱导：措辞巧妙的提示词，甚至隐藏在它所读文档中的文本，都可能左右其输出。而它陈述一个捏造的数字时，语气会和陈述一个真实数字时一样从容自信。验证人员称最后这一点为“幻觉”；审查人员则称之为“未经解释的重大错报”。

这并不意味着 LLM 毫无用处。它意味着 LLM 不适合大多数供应商悄悄赋予它的那个角色：计算数字的那个环节。2026 年框架的核心纪律（按固有风险和用途分级、从开发到退役的全生命周期溯源、按比例设置控制措施），如果你将 AI 工具承担的两项工作区分开来，其实能与这套纪律清晰对应。一项是解读工作（理解问题、找到相关数字、解释答案），另一项是计算工作（得出数字）。前者可以交给 LLM，后者绝不可以。

这种分工是 Rexfin 架构设计背后的核心理念，也是平台架构的主线。

控制模型：验证输出，而非验证“神谕”

你无法像验证信用评分卡那样验证一个生成式模型。你不会从中得到一个稳定、可复现的函数，所以不要再试图为模型本身做认证，而应该开始为它周围的边界做认证。三项控制措施承担了大部分工作。

确定性计算。 AI 呈现的每一个数字，都应来自每次运行方式相同的计算引擎，而不是语言模型自己的算术能力。LLM 决定要计算什么以及要提取哪些数字，而一个独立的确定性引擎才真正执行计算。运行一千次，得到一千次相同的答案。这正是模型风险管理（MRM）本应测试的属性，也是一个原始 LLM 永远无法提供的属性。更多机制细节参见运作原理。

输出验证与来源追溯。 任何数字在到达人类面前之前，都应能追溯到具体来源：某个总账科目、某条对账后的记录，或某份已提交的报表。如果一个数字无法追溯到其来源，就不能被交付。这把幻觉从一个隐性风险变成了一个可被捕捉的错误。一个答案要么能追溯到源头，要么就会被拦截。

完整的审计轨迹。 谁在什么时候问了什么，哪个版本的数据回答了问题，运行了哪次计算，得到了什么结果：每一次交互都被记录下来。当审查人员或审计师问“给我看看这个数字是怎么产生的”时，你给出的是一份记录，而不是耸耸肩。

一个对账模型，否则你治理的什么都不是

围绕 AI 的控制措施是必要的，但并不充分。如果 AI 读取的是两套 ERP 系统的三份导出文件，再加上某人邮件发来的一张 Excel 表，你所构建的就不是一个可治理的系统，而是一种更快产出前后矛盾数字的方式。垃圾进，自信的垃圾出。

这就是为什么基础比模型本身更重要。Rexfin 连接你的会计和财务数据源（QuickBooks、Xero、NetSuite、Sage、SAP、Oracle、数据仓库，或上传的报表），构建出一个与总账相符的对账后财务模型。一个单一的真实来源。AI 只从这里检索，也只能从这里检索。它没有第二个版本的营收可以误入。

对于一位财务管控人而言，这就是一个可审计的 AI 工具与一个等待被发现问题的责任隐患之间的区别。其背后的对账纪律在下方的结账自动化专题中有详细介绍，连接层则在集成中说明。

审查人员实际会问什么

提前设想这场对话会很有帮助。决定你的 AI 工具能否通过治理评审的问题是可预见的：

• 你能复现这个数字吗？（确定性引擎：可以。）
• 底层数字来自哪里？（来源追溯：一个具名的总账科目。）
• 是什么阻止模型凭空捏造一个数字？（输出验证：无法追溯的答案会被拦截。）
• 如果有人输入恶意提示词会怎样？（提示词注入无法改变一个对账后的数字，因为 LLM 并不负责计算这个数字。）
• 给我看一年的“谁问了什么”。（审计轨迹：在这里。）

如果你对以上任何一个问题的回答是“我们相信模型”，那么你就有一个 2026 年框架无法为你遮挡的问题。安全页面对威胁模型有更深入的介绍，包括提示词注入和数据隔离。

从这里开始

本专题下的各篇文章逐项论证这套控制体系。你可以按任意顺序阅读，但大多数团队会从验证问题开始：

• 为什么 LLM 无法通过模型验证，应该验证什么才对：为边界做认证而非为黑箱做认证的技术论证。
• 确定性计算：让 AI 数字可复现的控制措施：解读与计算的分离如何满足模型风险管理的要求。
• 构建一份审查人员会接受的审计轨迹：需要记录什么，以及来源追溯如何将幻觉变成可捕捉的错误。
• 财务 AI 中的提示词注入与数据隔离：攻击面是什么，以及为什么对账后的模型能限制爆炸半径。

出于诚实，说句该说的话：这一切都不能让 LLM 单独使用时变得安全可信，Rexfin 也不假装如此。模型仍可能误读问题，或总结得不够好。改变的是后果。当 AI 无法计算数字，无法触及未经对账的数字，也无法产出无法追溯到源头的答案时，它的错误就会变得可见、可控，而不是悄无声息、后果重大。这正是治理的全部意义所在：不是让工具变得完美，而是让它的失败变得可被捕捉。

监管空白终将被填补。届时表现出色的团队，是那些已经提前构建了站得住脚的控制措施的团队，而不是等着一纸指引来告诉他们“好”的标准是什么。如果你想看看确定性计算、来源追溯和审计轨迹如何在你自己的数据上运作，预约演示，带上你最棘手的问题。