Why Internally-Built AI Fails Fund Accounting Audits¶

📊 Level ⭐ | 7.6KB

摘要¶

2026 年 2 月 COSO 发布生成式 AI 内控指引（Achieving Effective Internal Control Over Generative AI），与 PCAOB AS 2201 共同把基金会计中 AI 的审计门槛抬到两个必须回答的问题：能否证明 AI「看到了什么」，以及能否证明「它和上季度跑的是同一个系统」。文章的核心论点是：大多数内部构建的 AI（通用聊天工具包裹在基金结账流程上）从构造上就无法回答这两个问题，而审计就绪的 AI 在基金会计中是架构决策而非功能特性——构建时用 AI 生成并验证逻辑、运行时用确定性代码执行，配合防篡改审计轨迹与平台级 maker/checker。

核心要点¶

两个审计问题：①"Can you prove what the AI saw?"——对应 PCAOB AS 2201 的证据要求；②"Can you prove it's the same system that ran last quarter?"——对应 COSO 2026 的可复现性要求。
内部 AI 无法回答：会话历史可编辑、模型静默漂移、输出非确定性、缺乏版本控制的变更治理——四者共同使内部构建的 AI 在构造上无法通过上述两问。
六类反复出现的失败模式：无不可变审计轨迹、模型静默漂移、非确定性输出、无变更治理、"交给 IT 不转移风险"、每次变更重新打开所有历史问题。
交给 IT ≠ 转移合规责任：Finance 仍对输出负责，而 IT 在维护一个自己不执行的流程里的 AI 逻辑。
架构答案是"构建时 AI、运行时代码"：AI 一次性生成并验证规则引擎（瀑布、GP/LP 分配、catch-up 条款），运行时由确定性代码执行，无实时 LLM 调用触达基金计算。
防篡改审计轨迹 + 版本化可回滚 + 平台级 maker/checker：每条交易生成只读的输入/逻辑版本/审核人记录；邮件与 Slack 审批不通过 SOX 等效控制的测试。

深度分析¶

审计标准从"功能正确"转向"证据与复现"¶

在私人基金会计中，每一次 close 都是一次控制测试。当 AI 进入该流程后，问题不再是"算得对不对"，而是"算得可证明、可复现、并在与审计师对范围内其他系统相同的标准下被治理"。COSO 2026 与 PCAOB AS 2201 并不是提出全新的控制概念——它们只是把既有的变更管理与可复现性测试，正式延伸到了 AI 之上；真正新的认识是，大多数内部构建的 AI 因其构造本身就无法通过这套标准。审计的证明对象从"功能是否正确实现"转向"这个 AI 看过哪些数据、用什么逻辑处理、版本是否与上次一致"，这是一套全新的证明体系。

失败模式的内在不变量：可编辑性与漂移¶

六类失败模式背后共享同一个结构性根源：把"概率性、可编辑、无版本"的 LLM 会话直接当作会计控制链的一环。会话历史可编辑意味着审计证据可被事后修改；模型静默漂移意味着上次通过审计的版本与当前版本可能已不同；非确定性输出意味着相同输入无法复现相同结果；无变更治理意味着任何代码修改都可能重新打开所有历史审计问题；而"交给 IT"的误区则在于——合规断言并不随构建责任移交，Finance 仍对输出负责。对 AI/ML 研究者而言，这指向一个清晰的工程含义：在受控环境中，"可复现性"必须被当作一等公民，而非事后补救。

构建时 AI / 运行时代码：把 LLM 从控制环中移出¶

文章提出的可审计范式是一种明确的职责切分：AI 只在构建阶段被用于生成已验证的逻辑（waterfall 规则引擎、fund-of-one 分配逻辑、GP 经济切分），一旦逻辑通过验证，运行时的引擎就是确定性代码——相同输入、相同输出，每个周期一致，没有任何实时 LLM 调用触及基金计算。这与当前许多企业"用 LLM 直接处理基金计算"的做法截然相反。其洞察在于：基金会计的数学本质是确定性的（catch-up 条款、优先回报、管理费瀑布、GP/LP 分配都是规则绑定计算，而非概率猜测），因此正确的架构是"用确定性执行来兑现这个本质"，而不是"在每个 close 上管理幻觉风险"。当运行时是确定性代码而非实时模型调用，幻觉不再是风险面，控制测试退化为架构天然满足的可复现性。

从功能特性到平台治理：agentic 时代的控制边界¶

可审计架构的五层控制——防篡改审计轨迹（PCAOB AS 2201）、确定性（COSO 2026）、版本化与回滚（变更管理）、平台级 maker/checker（SOX 等效）、受治理的 agent 平台——本质上是在把 AI 从"提示词工作流"提升为"受审计的系统组件"。文章特别指出，随着 AI agent 承担更多基金管理工作流，agent 所运行的平台本身才是控制：agent 处理交易，平台负责记录、治理与证明。缺少这层治理，agent 就是 prompt-and-pray；有了它，agent 就是可审计组件。对研究者而言，这是"系统 > 模型"的又一个实证——护栏与可证明性来自运行环境而非模型能力。

实践启示¶

基金/财务团队：把"审计就绪性"当作架构要求而非功能清单来评估 AI 供应商或内部构建方案——要求防篡改的输入/输出记录、可证明的模型版本、确定性执行证明；对"上次审计与本次审计之间模型版本是否变化"应得到明确的书面回答。
IT 团队：把 AI 的角色从"运行时的智能计算"重新定义为"构建时的逻辑生成"——用 AI 辅助编写基金会计规则引擎，再以确定性代码执行；避免在任何触及基金计算的环节保留实时 LLM 调用。
审计人员：把关注重心放在版本控制、变更管理与防篡改审计日志上——这些是判断 AI 是否"审计就绪"的核心证据，而非输出准确性本身；平台级 maker/checker（而非邮件/Slack 审批）是 SOX 等效控制的基本要求。
AI 产品设计者：面向金融行业的产品必须从一开始内置审计轨迹（输入记录、逻辑版本、执行时间戳），而非事后补充；这是产品能否进入金融控制环境的准入门槛。
构建 vs 购买决策：把"我们让 IT 内部造一个"当作真正的架构决策来审视——可审计架构是多年基金会计工程对移动中的审计标准的执行结果，而非一个季度内用通用模型加电子表格就能堆出来的东西。