AI 合同审查：先标风险，再让法务签字
AI 合同应用不只是总结合同，而是把合同类型、条款、义务、风险规则、审批和审计做成元数据，让 AI 标风险、法务确认责任。
先给结论：AI 合同应用的价值不止“总结合同”，而是把合同类型、条款、义务、风险规则、审批和审计做成元数据——AI 先看一遍、标出风险，但最后拍板的仍是法务。
“合同审查能不能先交给 AI 看一遍？”
这个问题背后，不是想让 AI 替代法务，而是想解决一个很现实的协作困境：业务等合同，法务排队看合同，审批人只看到一个附件和几个字段，真正的风险藏在几十页条款里。
传统合同管理系统通常擅长管台账：合同编号、甲乙方、金额、签署日期、到期时间、附件。可一旦进入“审查”，系统就经常退化成文件流转。风险由法务人工读，意见写在批注里，审批人再凭经验判断。
AI 原生的合同风险应用应该把合同从附件变成结构化业务对象。它能读合同，但更重要的是能把读取结果落到条款、义务、风险、审批和例外规则上。
你可以对平台说：
帮我搭建一个 AI 合同风险应用。它要管理销售合同、采购合同和保密协议；AI 自动抽取合同主体、金额、期限、付款、违约、数据安全、自动续约和责任限制条款；非标条款要生成风险意见，超过授权范围的合同进入法务和财务审批；AI 只能给建议，最终审查意见由法务确认。
平台生成的不是一个合同摘要工具，而是一套合同风险协作应用。
合同场景为什么不能只做“文档问答”
合同确实适合 AI 阅读，但如果只把合同丢给模型问“有什么风险”，很快会遇到三个问题。
第一，风险标准不统一。什么叫高风险？付款周期超过 90 天算不算？自动续约算不算？责任上限低于合同金额算不算？这些判断必须来自企业规则，而不是模型临场发挥。
第二，审查动作需要留痕。谁上传了合同，AI 抽取了什么，法务改了哪些意见，审批人为什么通过，这些都要能审计。
第三，合同和业务对象有关。一个条款是否异常，要看客户等级、合同类型、金额、行业、历史模板和授权政策。AI 不能只读文件，它还要读业务上下文。
所以 AI 合同应用必须元数据驱动。文档只是输入，最终要形成对象、字段、规则、流程和可追溯动作。
用自然语言生成合同审查模型
第一轮搭建时，平台应该生成这些核心对象：
| 对象 | 作用 |
|---|---|
contract | 合同主记录，包含类型、主体、金额、状态、负责人 |
contract_party | 合同方、签约主体、联系人、资质信息 |
contract_clause | AI 抽取出的条款分类、原文位置、摘要和标准匹配 |
contract_risk | 风险等级、原因、建议处理方式和责任人 |
obligation | 付款、交付、保密、续约、通知等履约义务 |
review_decision | 法务、财务、业务审批意见和确认记录 |
这些对象让合同审查从“读一个附件”变成“处理一组结构化风险”。
例如 AI 发现合同里有自动续约条款，系统不应该只在摘要里写一句。它应该创建一条 contract_clause，标记类型为“自动续约”，关联原文位置；再根据公司政策生成一条 contract_risk，提醒是否需要业务确认；如果续约通知期限小于 30 天，还应该创建后续提醒义务。
这就是 AI 原生应用和普通文档助手的差别：理解结果会进入业务系统。
搭建后继续用自然语言调整规则
合同规则经常随着管理要求变化。法务负责人可以直接说：
以后所有包含“无限责任”的合同都标为高风险，并且必须由法务总监审批。
平台应把这句话转成条款识别规则、风险等级规则和审批流程变更。
财务也可能说：
付款周期超过 60 天的销售合同，自动提示现金流风险；超过 90 天必须财务审批。
这会生成付款条款抽取规则、风险提示、审批条件和财务视图。
业务负责人可能补充：
战略客户可以接受 90 天账期，但必须在合同里标记例外原因。
这会引入例外规则：不是简单拦截，而是要求填写原因、指定审批人、记录授权依据。
自然语言搭建不是让业务人员写提示词，而是让规则变化能落到可运行的元数据里。
法务和业务如何在应用中对话
合同上传后，业务人员可以问：
这份合同有哪些需要我处理的风险？
AI 应该回答业务相关的问题，而不是把所有法律细节都堆出来：
- 付款周期为 90 天，超过默认政策，需要财务确认；
- 客户要求 99.9% 可用性承诺，需要产品和交付评估；
- 合同包含自动续约，需确认续约提醒责任人；
- 责任限制低于标准模板，建议法务复核。
法务可以继续问：
和我们标准销售合同相比，哪些条款偏离最大？
AI 应基于合同模板、条款库和历史审查意见生成差异清单，并把每个差异关联到原文位置和建议动作。
审批人则可以问：
为什么这份合同需要我审批？如果通过，有哪些后续义务？
这类问题最能体现应用价值。审批人不再只看一个附件，而是看到清楚的风险原因、例外依据和履约任务。
AI 可以先看，但不能最后拍板
合同是高风险场景，AI 的角色必须设计得清楚。
AI 适合做：
- 合同信息抽取；
- 条款分类和模板比对；
- 风险初判和原因解释；
- 审查意见草稿；
- 履约义务提取；
- 到期、续约、付款和通知提醒。
AI 不应该独立做：
- 最终法律意见；
- 高风险条款豁免；
- 合同签署承诺；
- 授权范围外的审批通过；
- 对外发送未经确认的法律文本。
所以应用中每个 AI 动作都要有状态：草稿、待确认、已确认、已驳回、已执行。每一步都应记录来源、模型输出、人工修改和最终责任人。
这不是束缚 AI，而是让 AI 可以进入真实合同流程。
第一版应该怎么搭
一个可落地的 AI 合同风险应用，可以从四个能力开始。
第一，合同台账和上传入口。先让合同类型、主体、金额、状态、负责人和附件进入统一对象。
第二，AI 抽取和风险初筛。抽取关键条款，生成风险卡片，但不自动给最终意见。
第三，法务确认和意见沉淀。法务修改 AI 风险意见，形成企业自己的条款经验库。
第四，审批和履约闭环。高风险合同进入审批，签署后生成付款、续约、交付、保密等履约任务。
这条路径不要求一开始就覆盖所有合同类型。先从销售合同或采购合同中的高频风险开始，规则会随着使用逐步长出来。
ObjectStack 的价值：把合同读懂后变成业务动作
AI 合同应用最怕停留在“读文档”层。读完以后，如果风险不能进入审批，义务不能进入任务，例外不能进入审计，知识不能沉淀成规则，价值就会很快耗尽。
ObjectStack 的元数据驱动方式，让自然语言搭建可以直接生成合同对象、条款对象、风险规则、审批流程和 Agent 工具。业务人员和法务人员继续用自然语言调整规则、追问风险、确认意见，应用则负责把这些对话落到受控记录里。
所以，合同确实可以先交给 AI 看一遍。但真正重要的是：AI 看完以后，风险要能被管理，意见要能被确认，义务要能被执行，责任要能被审计。