夜雨聆风三句话先说结论：
框架：五层架构已迭代到 v3，能把法规、数据、检查、整改和人工复核串成一条工作链； 价值：方向可能成立，但目前只验证了程序能跑通，真实业务效果还有待进一步验证； 启示：判断要不要往下投，看命中率和专家采纳率，不看演示效果或功能数量。
过去一段时间，我围绕一个问题做了三轮探索：
怎样设计一套能够进入企业真实业务的 AI 内控框架？
它得能连接业务数据、执行检查程序、保留证据、推动整改。不只是查法规、写制度、生成底稿，专业判断和最终责任仍留给人。
围绕这个目标，我参照框架搭了一套五层架构，并用采购付款做系统验证。架构从 v1 迭代到 v3，从技术部件的组合，变成覆盖知识、数据、检查、缺陷整改和人工复核的内控工作原型。
目前，采购试点已跑通从数据检查、线索输出到缺陷整改的程序链路，主要模块都有代码、配置和自动化测试，潜在说明部分内控方法可以被结构化、程序化，具备了进入企业流程的基础。
但最关键的一关还没过：三个检查模型尚未经过真实业务数据验证，命中率、误报率、复核成本和使用者采纳情况仍是未知数。
因此，这不是产品发布，也不是能力展示，更像一份阶段复盘：框架怎样形成，三次迭代改变了什么，试点验证了什么，下一步要用哪些证据判断它能否产生企业价值。
为什么会有这次尝试
近几年，不少业务扩张很快的公司，制度、系统和内控团队很难同步增长：新业务要补控制，旧制度要查执行，系统里又积累了大量交易数据；内控内审团队要覆盖的组织、流程与风险越来越多，人员数量和专业能力却不可能无限增加。
这种压力很容易让人对 AI 产生期待：
能不能自动检查业务数据？ 能不能快速对照法规和公司制度？ 能不能自动生成底稿、缺陷建议和整改报告？ 能不能把优秀内控人员的经验复制给更多人？
这些期待并不夸张。真正的难点在于，怎样把分散的 AI 能力放进完整、可控、可持续的内控工作链条，而不只是完成某一个任务。
之前，我关注到 Anthropic 发布的 Claude for Financial Services。它在 2025 年 7 月首版方案里，重点提到受治理的数据连接、来源链接和人工核验；2026 年 5 月的方案进一步归纳为 Skills、Connectors 和 Subagents：专业知识要沉淀，数据访问要受控，复杂任务要拆分，结果仍由人审阅批准。
这给了我一个启发：AI 要进入内控这类高要求工作，如何搭建框架。专业方法放在哪里？数据怎样进入？任务如何拆分？过程怎样留痕？结论由谁确认？这些问题不解决，模型回答得再流畅，也很难进入真实工作。
基于这个判断，我搭了一套面向企业内控的五层架构，并选择采购付款作为验证场景。
五层架构：把 AI 能力放进内控工作链条
内控不是一个单点任务。
法规和公司制度回答“应该怎样”，业务数据反映“实际发生了什么”，检查程序负责取证和分析，缺陷管理还要处理分级、整改、验收与报告。任何一项专业结论，都需要说明依据、数据、程序和责任人。
这套框架要回答五个问题，并对应拆成五层来分别承担：
| 第1层 · 法规与专业知识资产 | |
| 第2层 · 预防侧与检查侧技能 | |
| 第3层 · 知识与数据连接 | |
| 第4层 · 子任务处理 | |
| 第5层 · 编排与人工复核 |
这五层不是为了让系统更复杂，而是为了让不同性质的能力分开管理。
法规更新不必重写全部程序；阈值变化只需调整规则配置；接入新业务系统只改数据连接；模型更换时，证据结构、复核流程和责任边界仍能保留。
从企业应用角度看，这种分层决定了项目能否持续运行：企业要的不是某一次生成效果好，而是专业知识能更新、检查程序能复用、数据访问受控、结果可追溯。
框架的三次变迁：从技术分工到内控闭环
五层结构不是一开始就成形的。
每次迭代都来自一个新暴露的问题：第一版解决能力怎样分工，第二版补内控方法论，第三版把检查结果接入缺陷整改和治理流程。
v1：先把不同能力拆开
第一版参考 Anthropic 的基础框架：法规和专业资料放在知识底座，方法做成技能，数据通过连接器进入，复杂任务拆给子任务模块，最后由编排层和人工复核收口。
这一版定了一个原则：专业能力尽量沉淀在规则、配置和模板里，不全押在某个模型上——透明规则能解决的先交给规则，需要理解语义、归纳证据、起草文字的部分，再考虑用企业可信任的模型。
v2：技术架构不能代替内控方法论
第二版时，我发现五层技术分工虽然完整，却还没真正回答“怎样做好内控”。
比如，一开始把“合规对照”当成一件事，检查制度条款是否齐全。后来才发现这不够：制度写得够不够，是设计有效性；实际有没有照做，是运行有效性，两者证据完全不同。前者看制度文本，后者看穿行测试和实际操作记录。不拆开，系统很容易把“制度写得好”误判成“控制执行得好”。
因此，v2 引入了基于 COSO 五要素的内控方法，增加战略与风险关联、设计与运行两层对照，以及流程文件的证据要求。
v3：从发现问题走向管理问题
第三版继续补全工作链条。促使这一步的，是一个尴尬的现实：检查模型能找出问题，制度对照能判断性质，但一条缺陷登记之后该归谁、何时验收、要不要上报，系统里全是空白，问题发现了，却没有出口。
此外，治理结构、组织架构和职务授权被纳入预防侧；缺陷管理从发现问题延伸到分级、整改、验收和报告；底层资料从法规库扩展到法规、底稿、手册模板、问卷和监管案例。
三次迭代之后，它才从一个 AI 功能集合，逐渐变成一套内控工作系统的原型。
两条不能绕开的边界
框架不断扩展，但有两条边界始终没变。
第一条：数据必须留在受控环境
采购数据包含供应商、价格、合同、付款和人员信息。开发阶段可以用公开资料、样例或脱敏数据，正式运行必须回到企业受控环境；公开法规可从外部知识库查询，公司制度和交易数据不能随意上传。目前程序完全在本地运行，没有调用外部模型 API。
后续需要公司制定可信任的大模型作为基地能力。
第二条：专业结论必须由人负责
系统可以计算价格波动、整理制度缺口、生成结构完整的底稿，但不能因供应商价格异常就认定舞弊，更不能自行宣布控制有效，或把缺陷定为重大。
因此，每条检查线索必须附上命中规则、数据证据、判断阈值和复核建议；制度、底稿、缺陷级别和整改验收等结果保留“待核”状态。
以 B9 采购价偏离模型为例，一条线索大致包含：
命中规则：单笔采购单价高于该物料近 12 个月均价 30%； 数据证据：物料编码、供应商名称、本次单价、历史均价、采购日期； 判断阈值：30%，内控人员可按物料类别调整； 复核建议：核查是否存在紧急采购、规格变更或议价记录。
以上均为示意信息，不是真实业务数据。
系统输出到这里就停，“是不是异常”“要不要立项核查”仍由人判断。
这会降低自动化程度，却能避免更危险的情况：系统看起来替人完成了判断，实际上没人说得清结论怎么来的。人工复核不是 AI 失败后的补救，而是系统设计的一部分。
为什么用采购付款做验证
采购付款有一条相对完整的业务链：请购、供应商准入、询比价、下单、验收、付款。这里既有制度和授权，也有交易数据、审计证据和整改要求，五层架构都能找到落点。财政部《企业内部控制应用指引第 7 号——采购业务》对职责分离、供应商管理、采购定价、验收、付款和采购后评估也有明确要求。
第一轮试点只选了三个依赖采购交易明细的模型：
这三个模型远不能覆盖采购风险的全貌，目的只是先确认最短链路能不能成立。这里的逻辑可以参考前面文章《自建审计（内控）系统的实践与反思》。
五层架构在试点中分别做了什么
1. 知识底座
项目把采购相关法规、底稿、问卷和监管案例整理成 40 余个控制点、10余项供应商穿透异常信号和一套控制测试配置，不再散落在不同文档里，可被合规对照、制度生成和控制测试重复调用。
这初步证明了专业知识可以被结构化。但由谁维护、法规变化后如何更新，还没有形成正式机制。
2. 预防侧和检查侧技能
检查侧已实现 B7、B9 和 C13；预防侧可以生成审批权限表、循环文件和采购内控手册骨架。规则、字段和输出格式都有测试，不再完全依赖个人临场发挥。
不过，三个模型只覆盖少量采购风险，预防侧生成的也主要是结构，具体岗位、审批金额、制度名称和业务例外仍需人工补充。
3. 知识与数据连接
采购明细已能完成字段映射、清洗和校验，线索、缺陷、整改状态也有统一的数据结构。样例数据能跑完整条链路，真实业务数据尚未接入。
4. 子任务处理
合规对照已拆成制度设计和实际执行两个层次；风险评分、控制测试和供应商穿透核查也各自定义了输入与输出。目前这些模块主要按规则和模板工作，后续可在少量语义任务中评测企业可信任的模型，用于制度语义比对、证据归纳和初稿生成。
5. 编排与人工复核
检查结果可以进入合规对照，形成缺陷建议，流向整改台账和分层报告。整改责任、措施、期限、验收和结项都有固定字段，状态也能保存。人工复核不再只是一句免责声明，而是进入了工作流和数据结构。
从试点产出到企业价值
截至 2026 年 6 月 25 日，项目已经形成：
B7、B9、C13 三个采购数据检查模型和 Excel 线索报告； 40 余个采购控制点、两层合规对照和缺陷台账； 审批权限表、循环文件和采购内控手册骨架； 穿行测试及控制测试底稿； 供应商四步穿透核查和10余项异常信号； 整改状态、结项及分层报告； 治理、组织、授权和制度建设的整体层面控制初稿。
工程上有近 20 个业务源码文件，约 1,400 行；十余个测试文件，约 770 行；70 余项自动化测试全部通过；另有约 16 个 YAML 配置和知识文件，共约 3,000 行，累计近 30 次代码提交。
这些数字不能证明系统已经有效，却至少说明它不再只是一份概念方案：数据处理、规则计算、文档生成和整改状态都有代码，主要模块也有测试。
如果后续通过真实数据和真实用户验证，这套框架在企业中的价值主要落在三个方面：
- 提高覆盖和效率： 自动完成字段清洗、规则检查、异常筛选和底稿初稿，让内控人员把时间集中在例外分析和专业判断上；
- 提高工作质量的一致性： 把控制点、证据要求、检查程序和复核建议固化下来，减少项目和人员之间的执行差异；
- 沉淀组织能力： 把个人经验转化为可维护、复用、追溯的知识与规则资产，让内控能力不再过度依赖少数人。
拿 B9 的例子来说：过去核一类采购价格异常，内控人员要先导数据、按物料筛一遍、再翻历史价格对比，光这一步就要花不少时间。现在系统先把命中规则、数据证据和阈值整理好，人直接从这条线索往下问“是不是异常”“要不要立项”，省下的是机械整理的时间，专业判断这一步并没有被替代。
这些价值目前还不能按节省工时或减少损失量化。试点完成的是价值路径验证：系统知道从哪里取依据、怎样处理数据、如何输出证据、结果该流向哪里。
在此基础上，这次探索还带来了四项阶段价值。
第一，把模糊设想变成了可以验证的对象
过去可能笼统讨论“AI 能不能做内控”，现在这个问题被拆成更具体的判断：数据能不能进入？规则能不能复用？证据是否完整？专家是否采纳？系统能否减少复核时间？
问题变得可测量，项目才有可能继续改进。
第二，把个人经验变成了一部分组织资产
控制点、检查规则、证据要求、异常信号和复核建议开始进入配置与模板，不再只存在于某位专家的经验里。这些资产还不完整，但已经具备重复使用、共同评审和持续更新的基础。
第三，提前暴露了真正的瓶颈
试点最初看起来是个 AI 项目，做到后面才发现，最难的事未必是选模型。数据质量、制度版本、规则阈值、例外处理、人员责任和结果采纳，任何一项没解决，都可能让模型能力失去意义。
“AI 出 80% 初稿”这类说法也需要降温。程序能搭好结构，模型可以起草部分文字，但岗位、金额、公司制度、实际证据和专业结论仍要人来补。AI 更现实的价值，可能是减少整理和起草的时间，而不是独立完成大部分专业判断。
第四，为是否继续投资提供了证据
探索项目不一定要立刻产生规模化收益，它也能帮管理层更早判断：哪些设想值得继续，哪些功能该停，下一笔资源该投向数据、模型，还是流程治理。
一次诚实暴露不足的试点，比一场看似无所不能的演示更有价值。
当前成熟度：2.9/5
以下评分不是专业认证，只是我根据现有证据作出的阶段判断。各维度算术平均，没有加权；建设和评分都由我完成，分数应谨慎看待。
综合成熟度约为 2.9/5。这个分数不算高，主要失分在接入真实的场景。
项目最厚的部分仍是知识、配置和模板，真正处理交易数据的核心只有三个模型；现有代码也没接入大模型运行时，多数模块采用“读取配置、执行规则、生成文档”的方式，更准确地说，它是一套完成了局部程序化验证的 AI 内控架构原型，已经证明部分专业工作可以结构化和程序化，但还没证明这些能力在真实业务中足够准确、好用、可信。
下一步：先让真实数据说话
下一阶段暂停增加新业务循环，也暂停增加更多采购子任务。
先找一份脱敏的真实采购明细，对 B7、B9、C13 做历史业务测试，请内控人员逐条复核，记录六项结果：
如果系统输出与历史结果基本一致，再进入小范围私有 Beta：
找两三名内控或内审人员，在一次真实项目中使用； 接入稳定的数据导出或只读接口； 挑选少量语义任务，评测企业可信任的大模型； 记录人工采纳、修改和驳回情况。
试点过关后，再选一个差异较大的业务循环，比如资金或销售可能比继续扩充采购更合适，因为会带来新的数据结构和职责问题，能真正检验架构的通用性。
判断是否继续投入，主要看三件事：
看数据。 真实采购数据能否稳定产生可解释、有复核价值的线索？
看使用。 工具有没有减少筛选数据、整理底稿和起草文件的时间？内控人员是否愿意继续用？
看治理。 数据是否留在受控环境，模型和规则变更是否经过审批，输出能否追溯，人的责任是否清楚？
每过一关，再投入下一阶段资源。
对内控行业使用 AI 的几点启示
1. 从单点工具转向工作系统
查法规、写制度、生成底稿都可以是 AI 的切入口，但单点效率不等于整体价值。
真正进入企业后，评价标准会变成：专业依据能否更新，数据能否受控接入，检查程序能否重复执行，结果能否进入整改与报告流程。AI 内控的建设对象不应只是一个功能，而应是一条完整的工作链。
2. 先选择容易验证的业务场景
第一次试点不必覆盖全部风险，更适合选数据结构相对稳定、专业标准较清楚、结果能由专家复核的场景。
采购付款适合作起点，是因为业务链、交易明细和控制要求都相对明确。范围越清楚，越容易判断问题来自数据、规则、模型还是流程。
3. 先建设证据链，再提高智能程度
内控这类高责任场景中，可追溯往往比生成速度更重要。
先把法规、制度、数据、规则、证据和结论分开管理，等证据链稳定后再让模型承担语义理解、归纳和起草任务，风险会小得多。
4. 规则和模型不是替代关系
价格偏离、集中度、字段校验等问题，可以靠透明规则稳定处理；制度语义比对、例外原因归纳和报告初稿，更适合由模型辅助。
把所有事情交给模型，不代表系统更先进，有时只是更难解释。
5. 人工复核必须成为系统功能
谁来复核、复核什么、能否修改、如何驳回、怎样留痕，都应进入工作流。“最终由人负责”如果只出现在报告末尾的一句提示里，很难成为真正的责任机制。
这也呼应了 IIA（国际内部审计师协会）《人工智能审计框架》的“三线模型”：治理层定方向和边界，管理层负责把 AI 用起来、用得负责任，内部审计作为第三线提供独立评估。
6. 用业务证据决定是否继续投入
一个好的试点，也可能得出“当前数据不支持”“使用成本过高”或“某些任务不适合交给模型”的结论。这不等于失败，反而帮企业在大规模投入前看清边界。
AI 内控真正需要的，不是更激进的承诺，而是更低成本、更高质量的验证。命中率、线索采纳率、复核时间和证据完整率，比功能数量更能说明项目是否值得继续。
写在最后
这次采购试点还没有证明五层架构已经成功，但它把一些原本模糊的问题，落到了文档、规则、数据结构和代码中：
先问业务问题和责任边界，再看模型能做什么； 把法规、制度、数据、证据和结论分开管理； 透明规则能解决的，不交给模型猜； 把人工复核写进流程和字段； 让真实数据和真实使用者决定项目是否继续。
对很多正在尝试 AI 的内控、审计和合规团队来说，最焦虑的可能不是“要不要做”，而是“怎样开始才不会走偏”。
我的体会是：不必一开始覆盖所有业务循环，也不必急着做出完整平台。先选一个边界清楚的业务问题，跑通最短证据链，再用真实数据判断它有没有价值。
当然内控工作远不只是搭建系统， 人跟人、人跟组织之间必须建立信任，才能做好内控。
参考资料
Anthropic：《Claude for Financial Services》，2025 年 7 月 15 日。 Anthropic：《Agents for financial services》，2026 年 5 月 5 日。 财政部：《企业内部控制应用指引》，其中第 7 号为采购业务。 COSO：《Achieving Effective Internal Control Over Generative AI》。 The Institute of Internal Auditors：《Artificial Intelligence Auditing Framework》。
如果你也在尝试把 AI 引入内控、审计或合规工作，可以想一想：你们现在最缺的是模型能力，还是一条能够被专业人员信任的证据链？
