3. AI采购标的条款审查

AI采购合同中最容易埋雷的部分，不是价格，而是“标的”。传统软件采购可以写“采购XX系统一套，含XX模块”，但AI模型的“一套”到底是什么，往往在签约时说不清。模型能力描述模糊、性能指标无口径、版本迭代无约束、技术文档交付无清单、验收标准无量化，这五个问题会在履约阶段集中爆发。本节围绕这五个审查点，给出可落地的量化设计方法。

一、模型能力描述：从“能做什么”到“在什么条件下做到什么”

供应商常写“具备自然语言理解与生成能力”“支持多轮对话”“可进行知识问答”。这类描述无法验证，也无法追责。审查时应把能力描述拆成任务类型、输入形态、输出形态、约束条件四要素。

例如，把“支持合同问答”改写为：对PDF格式的中文采购合同，在单份不超过80页、扫描件清晰度不低于300dpi的条件下，针对合同主体、金额、付款节点、违约责任四类问题，输出带原文页码定位的答案，单次响应不超过15秒。这样写，能力边界清晰，后续验收才有抓手。

需要特别注意的是，能力描述中应明确不包含什么。比如“不承诺对非中文合同的处理效果”“不承诺对表格跨页合并的解析准确率”。负面清单与正面描述同等重要，它决定了供应商的责任边界，也决定了采购方在什么情况下不能主张违约。

二、性能指标：每个指标必须有口径、有基线、有测试集

性能指标是AI采购条款中最容易“看起来很美”的部分。准确率95%、召回率90%、响应时间小于2秒——这些数字如果没有口径，等于没写。审查时要求每个指标附带三个要素：定义口径、测试数据集、基线对比。

以“合同要素抽取准确率”为例，可量化的写法是：在双方确认的200份测试合同集上，对甲方、乙方、合同金额、签署日期四个字段，按“字段完全匹配”计算准确率，整体不低于92%，其中合同金额字段不低于95%。测试集由采购方提供，供应商不得用于训练。基线为供应商投标时提供的同口径测试结果。

响应时间也要区分场景：是首token时间还是完整响应时间？是平均还是P95？并发多少？建议写成：在4并发、输入长度不超过2000token的条件下，首token时间P95不超过1.5秒，完整响应P95不超过8秒。这些参数直接决定用户体验和系统容量规划。

三、版本迭代：锁定“当前版本”，约定“升级规则”

AI模型迭代速度快，供应商可能在履约期间静默升级模型，导致效果波动。合同应明确：交付版本号、升级通知义务、升级后的重新验收、回滚权利。

具体写法示例：乙方交付的模型版本为v3.2，模型权重哈希值为XXXX。履约期间如需升级至v3.3及以上，应提前15个工作日书面通知甲方，说明变更内容与影响范围。甲方有权要求对升级后版本按原验收标准重新测试；测试不通过的，甲方有权要求乙方回滚至v3.2或双方协商的其他稳定版本。未经通知的静默升级视为违约。

对于API调用的采购模式，还应约定“版本固定”条款：乙方应保证甲方调用的是指定版本，不得自动路由至其他版本。如果供应商无法提供版本固定能力，应在合同中降低对稳定性的预期，并约定效果波动的处理方式。

四、技术文档交付：清单化、格式明确、验收挂钩

技术文档不是“附赠品”，而是采购方后续运维、二次开发、合规审计的基础。审查时应把文档交付写成可勾选的清单，并与付款节点挂钩。

建议清单包括：模型架构说明（含参数量、训练数据来源概述）、API接口文档（含请求/响应示例、错误码、限流策略）、部署文档（含环境依赖、资源配置、启动步骤）、测试报告（含测试集说明、指标结果、失败案例分析）、运维手册（含监控指标、告警阈值、常见故障处理）、合规说明（含数据来源合法性、隐私处理措施、内容安全策略）。

每份文档应约定格式（如PDF+Markdown源文件）、语言（中文）、交付时间（如合同生效后10个工作日内）。文档不齐或质量不达标的，对应付款节点可暂缓支付。

五、验收标准：把“好用”翻译成可执行的测试用例

验收是前面所有条款的收口。建议采用“测试集+通过线+复测规则”三段式结构。测试集在合同附件中固定，通过线按指标逐项设定，复测规则明确不通过时的处理流程。

以下是一个可参考的验收参数表结构（示例参数，实际项目需根据业务调整）：

验收流程建议分两阶段：初验在交付后10个工作日内完成，重点验证功能与指标；终验在试运行30天后完成，重点验证稳定性与文档完整性。两阶段均通过后，才触发尾款支付。

最后强调一个审查习惯：把上述五个维度做成一张标的条款检查表，逐项打勾。任何一项写不出量化口径，就说明该条款在履约阶段必然产生争议。AI采购的标的审查，本质上是把“模型好不好”这个主观判断，转化为“在约定条件下是否达到约定指标”的客观验证。做到这一点，合同才真正具备可执行性。