什么是合同智能？
合同智能是把权威合同文件转化为可关联、可查询、可追溯并持续维护的业务记录。它连接协议身份、有效版本、主体、条款、义务、事件、责任人和来源，使用户能够回答合同问题并把已验证承诺交给运营流程。
它不是一次性把合同转成表格，也不是生成一段摘要。真正的合同智能必须知道某个答案来自哪份文件、哪个版本和哪段文字，是否被后续修订改变，验证到什么程度，以及现实发生变化时谁负责更新。
成熟度不取决于提取字段数量，而取决于用户能否基于记录安全完成工作：找到有效协议、准备通知、确认付款条件、分配履约责任、调查例外或回答审计问题。
合同智能提供记录基础，不替代审查、审批和分析
| 能力 | 主要单位 | 回答的问题 | 核心产出 |
|---|---|---|---|
| 合同智能 | 协议及其关系 | 当前有效约定、义务和证据是什么 | 持续维护的权威派生记录 |
| 自动化合同审查 | 收到的文件 | 文本中有哪些候选偏离或问题 | 待人工确认的来源化发现 |
| 合同审批 | 一个待决定事项 | 谁有权接受哪项选择或剩余风险 | 决定、理由、条件和版本绑定 |
| 合同分析 | 定义清楚的合同集合 | 组合中有哪些趋势、分群和异常 | 指标、比较和行动队列 |
这些能力可以共享数据，但责任不同。智能记录不能改写签署文本；分析汇总不能成为单份合同的法律结论；机器提取也不能绕过审批或授权。
先选择一项可交付的合同服务，再设计数据模型
“让所有合同可搜索”太宽，难以定义完成标准。应选择一项有用户、有频率、有行动和有后果的服务，例如提供付款条件答案、准备到期通知、分配安全证明义务、确认价格调整机制或生成争议事实包。
服务定义句式：当［触发事件］发生时，［用户］需要在［时间］内获得［答案或工作包］，依据［合同与外部证据］采取［动作］；若［关键证据缺失、冲突或低置信］，由［角色］核对并记录结果。
服务定义会反向决定需要哪些字段、关系、验证强度、权限和更新频率。没有真实使用者的“全字段提取”通常造成大量无人维护的数据。
先回答组织究竟有哪些有效协议
盘点所有可能来源：签署平台、共享盘、采购与销售系统、邮件归档、文档库、财务系统和业务团队保存的记录。对每份材料记录来源、获取时间、文件类型、签署状态、所属实体、交易对方和可访问范围。
区分已签协议、草稿、红线、工作副本、模板、订单、通知和证明材料。重复文件不能简单按文件名删除；内容相同但权限、签名或来源不同的副本，可能仍需要保留记录关系。任何无法确认的文件进入待核对队列。
用稳定协议身份把文件、事项与业务对象连接起来
| 身份层 | 需要标识 | 用途 |
|---|---|---|
| 协议 | 一个法律关系或承诺集合 | 跨版本保持稳定主键 |
| 文档 | 主协议、附件、订单、修订和通知 | 保留文件级来源与权限 |
| 版本 | 草稿、签署版、替代版和修订状态 | 避免旧文本覆盖当前约定 |
| 主体 | 内部实体、交易对方、关联方和联系人 | 连接权利、义务和权限 |
| 业务对象 | 客户、供应商、项目、产品、资产或账户 | 让合同进入实际运营语境 |
不要只用合同编号或文件路径作为唯一身份，因为编号可能缺失、重复或在系统迁移后改变。稳定标识应由受控规则生成，并保留原始编号作为可查询属性。
建立主协议、修订、订单与附件之间的生效关系
合同智能必须区分“文件存在”与“条款在目标时间有效”。为文档建立补充、替代、修订、引用、优先和终止关系，并记录生效日期、适用范围和需要人工裁决的冲突。
修订可能只改变特定条款或特定订单，不能把整份主协议全部替换。查询一个付款条件时，系统需要沿关系图找到目标业务、目标期间和适用文档，再返回来源与不确定性。无法确定优先级时，应明确显示冲突，而不是选择最新日期的文件。
数据模型应连接事实、关系、状态与证据
| 对象 | 关键字段 | 需要的关系 |
|---|---|---|
| 协议 | 类型、实体、状态、期间、管辖和负责人 | 文档、主体、业务对象 |
| 条款 | 类型、原文、位置、有效期、验证状态 | 定义、例外、修订和政策 |
| 义务 | 行动、责任方、受益方、触发、截止和证明 | 条款、事件、任务和履约证据 |
| 事件 | 类型、时间、来源、状态和影响 | 义务、通知、决定和后续动作 |
| 决定 | 选择、理由、授权、条件和时间 | 版本、偏离、批准和责任人 |
| 来源 | 文件、版本、位置、获取方式和访问权限 | 所有派生记录 |
“有保密条款”这样的布尔字段通常不足以支持行动。实际服务还可能需要保密对象、允许披露、例外、期限、通知、返还销毁和适用主体等关系化信息。
把条款解释成义务时，必须保留触发条件和证据
条款是文字，义务是需要某方在特定条件下采取或避免某种行为，事件则改变义务状态。记录责任方、受益方、触发事件、到期规则、前置条件、重复频率、容许期、完成证明、升级方式和相关条款。
不要只提取日期：“每年 3 月 31 日”只有在知道谁负责、要提交什么、从何时开始、遇到非工作日怎样处理、需要什么证明以及修订是否改变它时，才能成为可执行义务。
根据使用后果为字段设置不同验证等级
机器可以准备候选字段，但验证标准应由使用场景决定。全文搜索或发现型浏览可以显示带置信标记的候选结果；生成付款、发送终止通知、履行监管承诺或作出重大披露前，需要更强的来源核对。
| 等级 | 允许用途 | 最低要求 |
|---|---|---|
| 候选 | 搜索、探索和排队 | 保留来源与机器状态，不自动触发动作 |
| 已抽查 | 低影响运营参考 | 代表样本通过，异常仍转人工 |
| 已确认 | 明确范围内的业务流程 | 人员核对有效版本和原文 |
| 高影响确认 | 付款、通知、终止或其他重大动作 | 领域审核、完整证据和适当批准 |
验证状态属于具体字段和具体版本，不应因为一份合同中某个日期已确认，就把所有提取内容整体标为可信。
新签、修订、通知和现实事件都要更新记录
把签署完成、修订生效、订单创建、通知发送、付款、交付、验收、事件报告、责任人变化和合同关闭作为受控更新入口。每次变化都保存来源、处理人、时间和受影响记录，并根据关系重算状态。
修订进入后，应识别哪些条款、义务、提醒、查询答案和下游任务可能失效；责任人离职或组织调整时，应重新分配未完成义务。更新失败不能静默保留旧答案，应显示过期或待核对状态。
每个合同问题都需要一个答案契约
答案契约说明用户问题、查询范围、截至时间、返回字段、允许的验证状态、来源展示、缺失处理、响应时间和升级路径。例如“我们能否涨价”不应只返回是或否，而要返回适用协议、机制、计算基准、通知要求、时间窗口、例外、修订和待确认条件。
定位权威合同、版本、附件和相关事项。
基于已验证记录回答范围明确的问题。
在触发事件和行动窗口前通知负责人。
组合来源、状态、任务和所需批准。
提醒必须落到负责人、行动和关闭证据
一个义务提醒要包含事项、协议、来源条款、触发、截止、负责人、所需动作、前置条件、验证状态和升级路径。负责人可以确认、委派、争议、请求补证据或完成，并提供相应记录。
关闭不等于点击完成。不同义务需要不同证明，例如发送记录、对方确认、付款凭证、交付验收、证书、审批或会议记录。若业务事实与合同记录冲突，应保留争议并交给适当人员处理，而不是覆盖来源。
按文档、字段和用途控制访问
合同可能包含个人信息、价格、薪酬、调查、争议、知识产权和安全细节。访问应基于角色、事项、实体和必要用途，并对高敏感字段应用更细粒度限制。搜索索引、向量表示、缓存、导出和日志也属于数据路径。
记录查看、修改、验证、导出和权限变更，设置适当保留与删除规则。对外部模型或服务，核对文件、提示和输出是否用于训练、保存多久、存储在哪里、哪些分包方可访问，以及退出时怎样导出和删除。
从一个问题和一组协议开始分阶段建设
- 选择服务。确定用户、问题、动作、后果和成功标准。
- 核对合同集合。找到权威文件，建立身份和文档关系。
- 设计最小模型。只定义服务所需的字段、关系和状态。
- 建立参考集。由合格人员确认代表性答案和边界案例。
- 运行候选提取。保留来源、置信、缺失和冲突。
- 按风险验证。高影响字段逐项确认，低影响字段抽查。
- 接入工作流。把已验证记录转成查询、提醒或工作包。
- 监测并扩展。修复缺陷后再增加合同族、语言或服务。
扩展单位应该是“一个已验证服务”，不是“再提取一百个字段”。这样能把维护成本与实际价值对应起来。
用代表性合同和真实问题评估合同智能
测试集应覆盖签署原件、多个修订、订单和附件、扫描文件、表格、多语言、不同实体、缺失材料、异常日期和敏感合同。由领域人员建立独立参考答案，不能只使用供应商熟悉的演示模板。
| 评估面 | 关键问题 |
|---|---|
| 身份与层级 | 能否找到权威协议并正确应用修订 |
| 提取与关系 | 字段、主体、条件和交叉引用是否正确 |
| 答案质量 | 是否包含范围、来源、验证状态和未知 |
| 行动安全 | 高影响动作是否要求适当复核和批准 |
| 持续维护 | 新文件、事件和人员变化能否正确传播 |
| 运营负担 | 纠错、验证、权限和集成需要多少工作 |
案例：跨区域经销协议的价格调整与报告义务
以下组织、地区和结果均为虚构，用于说明方法。一家设备企业希望为经销团队提供两项服务：确认各地区协议的年度价格调整机制，以及在季度报告到期前把要求交给正确负责人。
团队先为每个经销关系建立稳定协议标识，连接主协议、地区附表、价格附件和修订。价格调整记录不只保存比例，还连接适用产品、指数或成本基准、计算日期、通知提前期、上限、例外和来源。报告义务记录责任方、模板、覆盖期间、提交方式、截止规则和完成证明。
| 发现 | 系统处理 | 业务动作 |
|---|---|---|
| 一份修订只改变特定产品线 | 保留主协议规则，并限定修订适用范围 | 产品团队只更新受影响价格表 |
| 某地区报告截止引用当地工作日 | 标记需要地区日历与人工确认 | 运营负责人确认本期实际日期 |
| 旧负责人已经离职 | 义务保持未分配，不自动关闭 | 业务主管重新指定负责人 |
| 系统未找到价格通知方式 | 显示证据缺口而不是“无需通知” | 领域人员检查附件与历史通知 |
最终交付不是一张静态字段表，而是能回答具体问题、生成带来源工作包，并随修订和履约事件持续更新的合同服务。
AI 适合建立第一轮候选记录，不适合填补未知事实
AI 可以识别文档类型、定位条款、抽取候选字段、连接定义、发现冲突和生成查询初稿。所有候选都要保留来源与机器状态；缺失材料、版本优先级、商业背景和专业解释不能由模型凭语气补齐。
使用已获授权的材料，让工具协助定位候选风险与原文；再由专业人员确认有效版本、字段关系和适用范围。只有通过相应用途质量门槛的记录，才进入提醒、分析或审批。
合同智能的十二个常见失败模式
没有用户、问题和维护责任。
重复、版本和系统迁移造成混淆。
忽略修订范围和优先关系。
用户无法回到权威文本。
条款无法连接主体、条件和义务。
不同字段的证据状态被抹平。
缺证据变成确定答案。
信息出现却没有行动闭环。
点击状态无法证实履约。
旧条款继续驱动查询与任务。
敏感数据通过查询或导出泄露。
人员、文件与现实变化造成记录漂移。
合同智能常见问题
合同智能是把权威合同文件转化为可关联、可查询、可追溯并持续维护的业务记录。它连接协议身份、有效版本、主体、条款、义务、事件、责任人和来源，使用户能够回答合同问题并把已验证承诺交给运营流程。
合同智能建立并维护单份及关联协议的结构化事实与关系，是可靠数据基础；合同分析在这些记录之上汇总合同集合、定义指标、比较分群并识别趋势。没有经过治理的智能记录，分析结果容易出现分母、版本和来源错误。
最低应保存稳定协议标识、法律实体、交易对方、合同类型、状态、有效期间、主从文档关系、修订影响、关键条款、义务、事件、负责人、来源位置、验证状态、权限和变更历史。字段范围应由具体业务服务决定，而不是一次提取所有可能信息。
不应一概直接使用。探索性搜索可展示明确标识的候选字段；付款、通知、终止、数据处理或其他高影响动作应核对有效版本和来源原文。验证强度应根据字段错误后果、文档质量和使用场景分级。
把新签、修订、通知、履约证据、责任人变化和合同关闭作为受控事件接入；为每项记录保存来源、版本和更新时间，设置重新验证触发器，并通过异常队列、抽样、用户纠错和定期对账修复漂移。