多模态 AI 进入企业业务后，最难的不是识别，而是确认

内容概要 

AI 能读表格、识别模板并生成一份格式完整的合同草稿，但这还不是合同流程的完成。企业真正需要解决的是：生成结果依据什么、哪些字段仍有冲突、谁有权确认，以及确认后系统可以推进到哪一步。

核心观点：多模态 AI 进入企业业务后，识别只是起点。把候选信息变成可以执行、可以追责的业务事实，才是自动化真正困难的部分。

当 AI 把一份合同完整生成出来，标题、条款、格式甚至措辞都没有问题时，很多人会认为工作已经结束。但真正的风险，可能才刚刚开始。

上一周，我们讨论了 AI 开始参与经营后，企业真正需要补上的，是数据、规则、权限和责任。

这些词听起来很大，落进具体流程里，往往集中在一个很小的动作上：确认。

图 1　数据、规则、权限与责任，最终在业务流程中汇聚为一次可追溯的确认。

图片：NOVA 团队制作

在 NOVA 已经开发的一项合同生成场景中，业务人员提供一份交易信息表和一份合同模板。AI 读取表格中的交易信息，再识别模板中的条款结构和待填位置，生成一份新的合同草稿。

草稿版式整齐、字段齐全、条款也像模像样，人很容易把文件生成误认为业务完成。对需要处理合同、订单与交付的大宗行业从业者来说，一个单位、交付日或结算条件的误差，还会继续进入到履约与结算环节。

所以对于可以执行、可以追责的业务来说，草稿生成之后，系统必须停下来，等待有权限的人审核。审核人确认的也不只是有没有错别字，而是这份草稿是否忠实地承接了原始交易信息，能否进入下一步合同流程。

图 2　纸质合同与数字工具并存的审阅场景。

图片：Karola G / Pexels　

一份草稿里，可能藏着三种不同的错误

很多人把多模态 AI 理解成更聪明的 OCR：先把表格和模板读出来，再自动填空。按照这个理解，只要识别准确率足够高，流程就能自动运行。

但一份合同草稿进入审核时，需要防范的并不只有识别错误。下面三类问题是对这类流程的通用风险拆解：

第一种错误确实来自识别。AI 可能读错一个数字、漏掉一个日期，或者把扫描件中的相似字符混淆。这类错误通常最显眼，也最容易通过原文对照发现。

第二种错误发生在匹配。表格里的数字可能全部识别正确，却被填进了错误的位置；“含税单价”被放进“不含税单价”，“交付日”被理解成“签署日”，数量的单位从吨换成千克时没有同步处理。每个局部都像是对的，组合起来却不是原来的交易。

第三种错误更隐蔽：信息和位置都没有错，但系统无权替企业作出这个决定。模板存在两个版本，AI 选择了其中一个；交易表没有填写违约处理方式，系统沿用了模板默认条款；业务人员在备注中写了一个例外条件，但这个人是否有权改变标准合同口径并不明确。

到了这一层，继续提升识别能力已经解决不了问题。争议的对象已经从 AI 看见了什么，变成企业是否接受它所理解的业务关系。

这就是识别结果、业务事实与业务确认之间的差别。

识别结果只是从材料中得到的候选信息。只有当它对应到正确的交易、使用了适用的规则、经过有权限的人核验，才可能成为企业接受的业务事实。确认之后，系统才能把状态从草稿待审推进到可进入签署流程。

图 3　Google Cloud Document AI 的文档处理能力示意。图中展示信息准备、分类、抽取、训练与存储，并不代表业务确认已经完成。

来源：Google Cloud Document AI 文档（CC BY 4.0）　

真正要确认的是下一步能不能发生

如果把合同审核理解成逐字重读，AI 只是把录入工作换成了校对工作。原来由业务人员填写整份合同，现在变成业务人员从头检查 AI 填写的整份合同，效率提升很快会被审核成本抵消。

更合理的确认界面，应当把人的注意力集中到真正影响业务的差异上。

审核人看到合同中的数量时，应当能回到交易表中的原始单元格；看到交付条款时，应当知道它来自交易信息、模板固定条款，还是系统根据规则补出的内容。交易表与模板发生冲突时，界面要直接标出差异，而不是把两份文件和一份草稿同时扔给审核人，让他自己寻找。

系统还要说明确认的后果。点击通过以后，是仅仅保存一个内部版本，还是把合同发送给对方？是进入法务复核，还是进入签署？如果这一步会产生对外承诺，确认人的身份与权限就不能只靠一个登录账号来推定。

因此，一次有效的确认至少要留下四组信息。原始材料是什么，AI 如何处理，人工改了什么，最终把业务推进到了哪个状态。以后出现争议，企业才能还原当时的依据；同类错误再次发生，技术人员也能判断应该修正规则、调整模板，还是改变权限。

这条链路可以压缩成一句话：

原始证据进入系统，AI 形成候选结果；规则暴露冲突，责任人作出确认；确认记录再推动下一步。

它比 AI 自动生成合同多了几个环节，却更接近企业真正可以使用的自动化。

人在回路中，不等于把工作退回给人

人工确认经常被描述成 AI 能力不足时的临时补丁。这个理解会让企业走向两个极端。要么不信任系统，所有内容都重新检查；要么为了追求自动化率，尽量减少人工介入。

真正需要优化的，是人为什么被叫进来。

格式固定、来源明确、规则没有冲突的字段，可以由系统自动提取和填充。关键字段缺失、材料之间不一致、模板版本不明确，或者下一步涉及对外承诺时，流程才转给拥有相应权限的人。人的精力由此留给例外和责任判断，无需机械地重复 AI 已经完成的工作。

这也改变了企业评估多模态 AI 的方式。识别准确率只能告诉我们模型读对了多少内容；企业还需要观察，系统是否把真正的冲突交给了正确的人，审核者能否快速回到原始依据，确认后的结果是否频繁被后续环节推翻。

如果一份合同生成得很快，却需要审核人逐字排查，或者签署前反复返工，这条流程仍然没有跑通。反过来，哪怕系统暂时不能自动处理所有情况，只要它能把无争议字段可靠填好，把少数关键差异集中呈现，并留下完整的修改与确认记录，就已经开始改变业务如何流转。

多模态 AI 的边界，应当划在确认之前

多模态 AI 把表格、文档、图片、语音变成统一可处理的信息，确实扩大了企业自动化的入口。但信息格式统一，不代表证据效力相同；内容能够识别，也不代表系统获得了决定权。

在合同场景中，AI 可以读取材料、匹配字段、检查缺项、提示冲突并形成草稿。它不能因为草稿外观完整，就替企业确认交易条件，更不能在权限不明时直接推进签署或对外发送。

所以，多模态 AI 进入企业业务后，最难的不是让模型继续多认出几个字段，而是设计一条可信的确认链路。每个结论都能回到原始依据，每个例外都能找到责任人，每次通过都明确改变了什么状态。

当这条链路成立，人工确认不再是自动化之外的一道刹车，而会成为自动化的一部分。企业得到的也不只是一份生成得更快的合同，而是一套知道何时可以继续、何时必须停下来的工作系统。

结语：识别给出答案，确认决定业务是否继续

回到开头那份看起来已经完成的合同草稿。AI 可以把表格里的交易信息搬进合同，也可以把缺项和冲突提示出来，但企业真正接手的不是一份文本，而是一连串后果：这份合同是否可以发给对方，是否可以进入签署，是否会成为后续履约和结算的依据。

识别解决的是“材料里有什么”，匹配解决的是“这些信息应当进入哪里”，确认解决的则是“企业是否接受这个结果，以及谁愿意对此负责”。三者不是同一道准确率问题。前两步做得再快，如果最后一步没有依据、权限和记录，自动化只是把不确定性更快地送进了业务。

因此，判断一条多模态 AI 流程是否真正跑通，不能只看生成时间和识别率。还要看审核人能否回到原始证据，差异是否被集中呈现，例外是否交给了有权处理的人，以及一次确认究竟推动了什么状态。确认不是 AI 工作的尾声，而是 AI 结果成为企业业务事实的分界线。

下周预告：一个看起来正确的答案，为什么还不能直接行动？

本篇讨论了 AI 生成的结果为什么必须经过确认。下周，我们会把这个问题放进更广泛的企业经营现场：当系统、报表或业务人员给出一个看起来明确的答案，企业还需要确认哪些没有被答案包含的条件？

这个问题既可能发生在 AI 面对证据不足时——它是否知道什么时候应当停下来；也可能发生在一笔订单或一项现货业务上——毛利为正，是否意味着现金更充足、整笔业务真正划算。无论最终从哪个场景切入，我们都会继续拆开“表面成立”背后的边界、资金占用与经营后果，讨论企业怎样避免把一个局部正确的结果，误当成可以直接执行的完整答案。

如果你正在把表格、合同、单据或现场图片接入业务流程，可以向 NOVA 提交一个脱敏的确认场景。我们会围绕三个问题拆解它：哪些内容可以自动通过，哪些情况必须停下，以及谁应当对确认负责。

说明：本文所述合同生成场景为 NOVA 已开发的业务场景，不代表系统已经替代人工审核、自动签署合同或产生经客户验收的经营结果。文章仅讨论企业 AI 工作流设计，不构成合同、交易或法律建议。