


一家银行用AI将36万小时的合同审查压缩到秒级,不是因为它有更好的模型,而是因为它先回答了三个问题:业务知识在哪、决策权归谁、责任怎么追溯。
相同的起点,不同的终点
JP摩根大通是全球投入AI预算最大的金融机构——每年170亿美元技术预算,2000多名数据科学家。它最著名的AI项目COiN(Contract Intelligence,合同智能平台)解决了一个看似简单的问题:每年需要审查12000份商业贷款协议,每份协议需要律师和贷款专员从150多个维度提取关键条款——利率条款、偿付安排、违约触发条件、担保结构。这项工作每年消耗约36万小时的人力。
COiN系统上线后,36万小时被压缩到秒级。但更值得关注的是一个容易被忽略的细节:COiN不是替代了律师的判断,而是重新定义了律师做什么判断。高置信度的条款提取被自动通过,低置信度的输出被标记并路由给专业审查人员。系统每被纠正一次,模型就学习一次。七年下来,它的准确率超过了人工审查。
中国银行业的AI项目数量在过去两年增长了近五倍。2024年国资委启动央企「AI+」专项行动,明确「应用领航、数据赋能、智算筑基」三个方向,央企已在超过500个场景布局AI。但多数项目的轨迹与COiN不同——它们停在了试点。
差距不在模型。差距在方法。
COiN团队在启动系统开发之前,做了一件大多数AI项目不会做的事:他们用了数个月时间,先和商业贷款部门最资深的律师一起,把「什么是一个合格的合同审查」这件事完整地拆解了一遍。不是写功能需求,是拆解判断逻辑——哪些条款存在解读歧义、哪些判断只能由人做出、哪些可以交给机器、出错后的纠正成本有多大。大多数中国企业的AI项目跳过了这一步。
IRO方法论:识别、重设计、运营
基于对企业AI转型项目的持续研究和实践,我们将一套可操作的工作框架归纳为三个阶次——不是三个方向,而是同一工程的三个阶段,每阶段有具体操作步骤、有命名、有产出物。
I(Identify,识别):判断逻辑拆解法

传统IT需求分析问的是「系统要做什么」。判断逻辑拆解法问的是「人做这个判断时,脑子里经过了哪些计算」。
两者的本质区别是:需求分析产出一份功能清单,判断逻辑拆解法产出一套判断规则集——包含变量、权重、阈值和例外情形。
操作步骤不复杂,但每一步都需要业务和技术协同完成:
场景采样。选取最资深的审批人员实际经手的典型业务案例,不是让他们写「审批标准」——那产出的是制度文件,不是判断逻辑。而是让他们回溯真实案例:「这笔贷款你批了,当时看了哪些点?」「那一笔被你挡回去了,触发你否决的到底是哪个信号?」
标准提取。从案例回溯中提取出实际使用(而非书面规定)的判断标准。这个过程中最常出现的发现是:同一个判断节点上,两个十五年的老风控可能给出不同的标准。这不是他们不专业,而是组织的判断逻辑从未被正式对齐过。
冲突发现与共识收敛。将提取出的标准交叉验证,发现分歧点,推动业务团队对分歧点达成统一标准。这一步的产出不是完美的规则系统,而是组织内部首次对「我们到底怎么做判断」的正式共识。
这种拆解不是访谈纪要,而是一套可复用的模板。以一笔贷款审批为例,工作坊按固定箭头流推进:

注:案例编号 → 当时的审批结论 → 当时实际看了哪些信息→ 其中哪些信息真正影响结论 → 哪些属于个人经验(无法言明) → 哪些可以数据化 → 哪些永远无法被表达
当「无法表达」的那一栏被填出来,组织就第一次看见了自己的判断盲区。这一步做完,AI 才有可翻译的输入——否则它拿到的只是字段,不是逻辑。
JP摩根的COiN团队在启动开发前,用了数月时间完成的就是这个阶段。它产出的不是一份技术需求文档,而是一套被法律和业务团队共同确认过的合同审查判断规则集。
R(Redesign,重设计):审批链三分类法

判断逻辑被结构化之后,下一个问题是:它应该以什么效力嵌入审批链?
传统的做法是在旧流程上插一个「AI建议」环节。但审批链是一条责任链——每个节点的人不是在对信息做判断,是在对自己的签字做判断。「AI建议」如果不附带「制度性的使用规则」,它就不是辅助工具,而是增加了一个需要被解读和防御的新变量。
三分类法的核心是将审批链上的每个节点按判断的可解释性边界而非任务复杂度来分类:
全自动节点。AI独立执行的判断必须是可被完整追溯的高确定性判断——工商数据比对、合同条款的标准化抽取、历史数据的结构化汇总。这类节点的共同特征是「AI的结论可以被原始数据直接验证」,判断过程不涉及模糊推理。组织对这类节点承担系统级风险责任,人的角色从执行者转变为抽检者。责任映射:数据责任(AI)→ 规则责任(AI)→ 审批责任(人抽检)→ 结果责任(组织承担系统级风险)。
增强节点。AI辅助但人最终签发的判断,应用于「信息整合工作量极大但最终判断需要综合多个定性维度」的场景——尽调报告框架生成、关联交易线索提示、信用评分初筛。AI提供结构化信息并标注置信度,人复核并承担签发责任。关键设计是:复核标准必须预先定义——复核人是在核验「AI数据来源的完整性」,还是在独立重做一遍判断,两种「复核」对应的责任性质完全不同。责任映射:数据责任(AI+人复核)→ 规则责任(人确认)→ 审批责任(人签发)→ 结果责任(签发人)。
保留节点。 涉及不可量化的定性判断和重大不确定性——实控人道德风险评估、复杂违约重组方案、最终审批决策——完全保留人类闭环判断。AI的角色退回到零:只提供结构化信息,不做任何判断建议。责任映射:四层责任全部归于人,AI 仅承担数据责任的辅助呈现。
O(Operate,运营):强制留痕触发机制

判断规则建立了,决策权分配了,最后一步是让整个系统可追溯。
金融AI系统的合规性不能被定义为「系统上线时通过了合规审查」。合规性必须被设计为一个持续的过程——每一个判断节点、每一次人机交互、每一个「AI标记高风险但人工选择通过」的例外操作,都必须是可被独立审计和复盘的。
更关键的是,这套日志不应只记录「AI 给了什么建议、人做了什么决定」,而应像 DeepSeek 的思考过程一样,完整呈现 AI 的推理路径——它匹配了哪些判断规则、经过了哪些中间推理步骤、在哪个节点做出了关键判断,让每一次辅助决策都可被「倒带复盘」。
强制留痕触发机制的设计逻辑是:用后置的风险成本倒逼前置的实质审查。
当AI标记高风险(例如关联交易线索、资金循环迹象)但审批链上的人工判断选择「通过」时,系统不禁止这一操作,但强制要求输入结构化的判别依据——上传核实后的贸易背景合同、说明商业合理性、记录具体核查过程——并将整个人工干预操作与当时的AI预警锁定为溯源快照。
从系统优化角度,机制还应支持从「人审」到「机学」的闭环:当审核人员用大白话写下「这家企业上下游太集中,实控人还有两家空壳公司」时,系统应能将这种自然语言表述逐步文本化、结构化,经人工确认后转化为可重复适用的判断规则,成为规则引擎持续进化的养料。
这意味着,如果项目后期爆雷,审计追溯不只追溯到「谁签的字」,而是追溯到「签字时是否看到了预警、是否给出了合理的解释依据」。这套机制不增加审批负担——它只是让审批者对自己的判断留下可被事后验证的证据。
很多 AI 项目最后没人敢用,根因不是模型不准,而是责任没有被数字化——AI 标了「高风险」,人签了字,出事后谁负责却无人能说清。
所以真正的 AI 治理,不是模型治理,而是责任治理。
这套方法论的适用边界
国资委「AI+」专项行动提出的「数据赋能」和「应用领航」两大方向,与国家金融监督管理总局金发〔2026〕8号「谁使用谁负责」的监管原则同向——本质上都在推动国企完成从「有AI工具」到「有AI治理」的转型。
这个过程需要的不是更多模型采购,而是一套能被嵌入采购流程、写入验收标准、服务于组织治理的工作方法。
IRO三阶方法论的设计起点是国企和金融机构的真实场景——审批链长、问责压力大、采购流程天生倾向于「看得见的交付物」。
它不是取代现有IT项目管理的框架,而是在技术项目启动之前,先完成那部分「任何技术团队都无权代表组织做出的治理决策」。
摩根大通COiN项目 的成功常被归因于一个领先的大模型。但事实是,它领先的不是模型,而是组织在模型之前先完成了一次自我理解——把「什么是合格的合同审查」拆解成可被机器执行的判断规则,并把每一层责任写进系统。AI 不会自动理解一家企业,它只会忠实放大企业原本的判断逻辑。如果组织自己都说不清为什么这样审批、这样决策、这样担责,模型学到的也只是混乱。
AI 转型真正的第一步,从来不是部署模型,而是让企业第一次看清自己的判断逻辑。
关于余策数智
余策数智专注于国有企业与金融机构的数智化转型问题研究,为用户提供包含组织治理、金融风控与企业合规的综合性转型咨询服务,提供关于数智转型、数字风控、智能监管、全栈合规的咨询服务、政策解读、行业研究,组织方法论等。


夜雨聆风