不替换现有 OA，如何接入 AI 合同审查

多数接入卡住不是技术问题。按我们经手的项目，开放 API 的对接量多在一两周，真正拖时间的是这三件事没在项目启动前定下来，到联调阶段才发现两边理解不同，回头改流程比改代码贵得多。

一、审查在哪一步触发

最常见的两个位置是业务上传附件的那一刻，和提交审批的那一刻。前者覆盖面大，代价是会审掉大量最终作废的草稿，调用量和噪音一起上去；后者省调用，但风险要到流程末端才暴露，那时改动成本已经高了。比较务实的落点是提交审批时触发，再对金额或类型超过阈值的合同额外加一道上传即审。

还要分清外部来稿和自有模板生成的稿件是否走同一套规则。来稿的风险集中在付款、违约、管辖这些由对方拟定的条款上，自有模板更多是字段填写是否完整、有没有用错版本。一套规则同时管两类稿件，结果通常是对来稿不够严、对自有稿太吵。

同一份合同多轮修改时，逐版重审会把成本翻几倍，而多数轮次只动了金额或交付日期。只对有实质变更的版本重审更划算，靠版本对比先判断改动性质，再决定要不要重新过一遍审查。

二、结果回到哪里

写回 OA 的合同记录字段，还是作为附件挂在流程上，这个选择决定了半年后的可用性。写回字段意味着风险等级、命中条目这些信息可以统计、可以检索，也可以做成管理层看的报表；挂附件改动最小，但一年之后想回答「去年有多少份合同的付款条款被标过高风险」，只能人工翻附件。

风险清单要不要进 OA 的审批意见区，取决于审批人是谁。如果审批链上有非法务角色，把分级清单直接推到他面前反而会让他跳过判断、直接点同意。更稳的做法是法务确认后的结论进审批意见区，原始清单留在法务视图里。

抽取出的结构化字段是最容易被忽略的一项。当事人、金额、期限、付款节点这些如果不回流到既有台账，后续的到期提醒、付款计划和统计就都还得靠人工录一遍，接入 AI 省下的时间会在这里还回去。

三、由谁确认

接入 AI 之后，合同流程里多了一类此前不存在的决策：接受还是拒绝某一条机器给出的意见。这个动作如果没有明确的责任人、不留痕迹，事后追溯会比接入前更难，因为多了一层「系统提示过但没人处理」的模糊地带。这一条最容易在项目启动时被跳过，也是上线半年后最常出问题的地方。

具体要定的是：法务逐条确认，还是业务先过一遍再转法务；AI 判断与人工判断冲突时以谁为准；以及谁在什么时间接受或拒绝了哪一条，记在哪里。这三个问题的答案应该写进流程文档，而不是留给经办人各自发挥。

开放 API、iframe 嵌入和 Webhook 事件通知均为当前可用能力，三者不互斥。实际项目里最常见的是组合使用：API 发起审查，Webhook 通知完成，iframe 给经办人看细节。只用 API 而不给经办人一个可视的确认界面，最后往往变成法务在导出的文档里手工比对，接入的价值打了折扣。

7

可经 API 调用的 Zico AI 工作面：审查、速审、版本对比、翻译、信息抽取、摘要、会议纪要出处：Zico AI 页面能力清单，七项均标注为可用

2

已在客户生产环境运行的协同入口：飞书、企业内部 OA；其余按需对接出处：Zico 客户案例页

白标 iframe 要提前问清的几件事

身份怎么传是第一个。常见做法是用你这边的用户标识换取一次性会话，避免在两套系统里各维护一份账号；如果企业已经有统一身份，直接对接会更省事，但要确认权限粒度能不能对上，比如某个业务员只能看自己发起的合同，这个限制要在嵌入侧同样生效。

其次是 iframe 里的操作要不要回传。人在嵌入页面上确认了哪几条，如果不同步回原系统，留痕就断在了两个系统中间。样式方面，白标通常覆盖配色和标识，不等于可以任意改版，界面结构要提前看过再承诺给业务方。还要划清哪些功能在嵌入态下不开放，否则经办人会在两个入口之间来回跳，体验比不接入还差。

以「业务收到外部来稿、OA 里发起审批」为例，接入后的链路是这样的。

1. 1业务在原有 OA 里上传对方来稿，发起合同审批。
2. 2OA 在提交节点调用开放 API，传入文档和本企业的审查清单标识。
3. 3Zico AI 按甲乙方立场扫描主体、付款、违约、管辖、知识产权等条款，输出分级风险清单，每条锚回原文位置。
4. 4处理完成后经 Webhook 通知 OA，OA 领取结果。
5. 5风险清单写回 OA 的合同记录，或经白标 iframe 在原页面逐条展示。
6. 6法务逐条接受、拒绝或修改，确认动作记在 OA 的流程留痕里。
7. 7需要外发时导出意见稿，可去掉逐字改法再发给对方。
8. 8抽取出的当事人、金额、期限、付款节点经 API 回流既有台账。

以下几项要么在产品页标注为尚未上线，要么本身不属于接入 AI 能解决的范围。把它们写进验收标准，项目大概率会在验收环节卡住。

• 自动生成修订稿并回流下游：人确认改法后生成带批注或修订痕迹的新文件、交由下游系统领取，目前标注为即将上线，现阶段仍需人工把结论落到文档上。
• 私有化 LLM 部署：对 AI 推理也不出企业网络有要求时需要这一项，目前标注为上线中，具体状态以 Zico AI 页面为准，采购前应书面确认。
• 替原系统做审批：审批流、权限和台账仍在你的 OA 里，接入 AI 不改变这一层，指望它顺带解决审批慢的问题会落空。
• 笼统的准确率承诺：没有测试集和评估方法时不给整体准确率数字，验收应落在可核对的具体项上，这一点下一节展开。

还有一类边界容易被误解。合同审查可以挂谈判录音作对照，摘要在挂了录音时会把转写稿一并读入、标出与文本不一致的地方，但结论始终以合同文本为准。录音的作用是提醒双方口头谈过什么，不能用来推翻或补充签署文本里的约定。

接入类项目最容易出现的问题，是上线后指标看着都达成，业务却悄悄回到了原来的做法：风险清单没人点开，法务还是打开 Word 从头读一遍。这类失败在验收阶段是看不出来的，因为验收指标大多落在 AI 本身，而不是流程结果上。

样本量不必大，二三十份足够看出趋势，但必须是企业自己的真实合同脱敏后的版本，并且包含至少一份此前出过问题的稿件。那一份的作用是检验系统能不能发现你已经知道的风险，比任何整体准确率数字都更有说服力。用供应商准备的样例合同跑出来的结果不能作为验收依据，因为样例往往是按能力清单反向准备的。