并购交割后，法务收到四百份供应商合同，最难的往往不是把文件找出来，而是回答几个会马上影响业务的问题：哪些合同将在三个月内自动续期？今天有效的责任上限究竟写在哪一份文件里？哪份补充协议已经改掉了原来的终止安排？主协议、订单、续约函和修订协议散在不同系统里，拼回一条能经得起追问的现行条款链，才是合同盘点最费时间的部分。
GC AI 在 8 月 5 日发布的 Contract Intelligence，瞄准的正是这一步。按其官方介绍，产品可以连接 Google Drive、SharePoint、OneDrive、Dropbox、Ironclad 或直接上传的文件；用户用自然语言定义字段，系统将结果整理成可筛选表格，并链接回合同原文。它也宣称可以识别主协议与修订、续约、工作说明书之间的关系。Artificial Lawyer 记录了这次上线。不过，目前关于准确率、漏检率及扫描件质量影响的公开材料仍主要来自厂商，法务团队不宜把演示效果直接当作验收结论。
先把一个问题问到可以落地
与其一开始把全部合同导入新系统，不如先挑一个答案会带来明确动作的问题。比如，核对未来九十天内自动续期的供应商合同。范围可以只限于一个业务单元和一种合同类型；法务先人工确认签署状态、续期日、通知窗口、责任上限，并标出哪些补充协议改变了这些字段。这样得到的不是抽象的“测试集”，而是一份团队本来就会依赖的业务底稿。
随后再把同一批材料交给工具。表格好不好看并不重要，值得记录的是三类错误：字段提取错了、合同根本没被列出来、主协议和后续修订被串错了。只有部分签字页的扫描件、名称相近但交易主体不同的协议，以及写着“与主协议冲突时以本协议为准”的补充协议，都应放进首轮测试。一个结果如果不能指到具体页码或原文段落，就不该进入续约提醒或管理层报告。
能点回原文，也不等于问题已经答对
合同 AI 的引用功能很有用：它把律师从反复翻页中解放出来。但引用只证明系统给出了一个出处，并不自动证明它找到了正确版本，理解了定义条款，也没有漏掉后来的变更。以“协议期限”为例，生效日、验收日和自动续期机制可能共同决定答案；单独摘出终止条款，仍未必能判断今天是否还有解约空间。
因此，一份可供业务使用的合同台账，至少要留下系统提取值、原文位置、依据的文件版本和复核时间。付款承诺、赔偿、责任限制、数据跨境、审计权及控制权变更等字段，尤其不适合在第一次机器提取后就自动改写台账或触发对外通知。这里的重点不是给每个字段增加一道形式上的审批，而是让后来接手的人看得懂：这个结论从哪里来，后来有没有被新的文件改变。
连接器会放大原有的权限问题
产品公告提到基于角色的访问、租户隔离和“不用于训练”的安排；GC AI 的安全文档也说明其主要模型提供商采用零数据保留或不训练约束。这些说明值得写入采购问卷，却不能替代企业自己的验证。真正要在试点里查清楚的是：连接器能否继承源系统权限，离职账号如何撤销，导出的表格由谁保管，删除合同后索引、缓存和下游副本何时清除。
有些问题只有在负向测试时才会出现。原本分属不同事项、彼此隔离的文件夹，一旦进入统一检索层，能否被同一角色用自然语言绕着查出来？无权用户是否能据此推断合同是否存在、相对方是谁或某项条款大致内容？先用脱敏或低敏合同把这些问题跑一遍，比上线后再补权限说明实在得多。
合同 AI 最适合先承担存量盘点、续约窗口核对和尽调字段初筛。试点结束后应留下的，不是一张漂亮的功能清单，而是三十到五十份经过人工核对的合同、固定的问题和字段定义，以及每次模型或连接器更新后留下的差异记录。等到系统能稳定说明答案来自哪份文件、哪一段、之后有没有被改过，法务才有理由让它进入日常工作流。