外包AI合同验收，别只写准确率，写这4类指标
中小企业外包 AI 项目，合同里只有模型准确率，通过验收也无法追责。本文给出四类能写进合同的验收指标：业务结果、覆盖范围、延迟与可用性、错误处理与重训责任，并说明每项怎么约定、怎么赔付。
合同里只写“模型准确率不低于约定值”，几乎等于没写验收标准。这个判断不好听，但事实很直接：根据 RAND 对 2,400 多个企业 AI 项目的分析，80.3% 的项目没有交付预期业务价值。技术指标通过和业务失败经常同时发生。
我的判断是：模型准确率只应该作为供应商内部测试和上线前评估的指标，不应成为合同主验收标准。外包 AI 项目的合同应当围绕四类指标写：业务结果、覆盖范围、延迟与可用性、错误处理与重训责任。下面拆开说。
模型准确率是模型判断对的比例。它不告诉你错误发生在哪、代价多大。假设一家工厂外包外观质检 AI，合同写“测试集平均准确率不低于供应商承诺值”。上线后，强反光环境下误报大量良品，产线为了不停线绕过系统，真正的缺陷漏到客户手里。供应商表示准确率达标。这个假设不是否定准确率，而是说明聚合数字会掩盖错误分布和业务代价。另一个问题是数据质量。Gartner 的研究把 85% 的 AI 项目失败追溯到数据质量差；而数据质量问题往往在测试集上看不到，上线后才暴露。合同如果不写业务结果和重训责任，买方最后只能拿到一个好看的模型评分。
第一类：业务结果，不要只写模型分数
业务结果指标应来自业务系统，而不是测试集。测试集是供应商准备好的题目，业务系统是每天生产里真实发生的题目。
以中小制造企业为例，如果外包的是视觉质检，合同应写：在一个约定的验收观察期内，某产品线的漏检率不超过 X%、每班次人工复核量不超过 Y 件、误报导致的停线时间不超过 Z 分钟。X、Y、Z 应在项目启动前从现有业务数据里测出基线，而不是拍脑袋。
如果外包的是外贸 AI 客服，指标可以是：询盘信息提取错误率、需要人工接管的订单比例、同一问题重复询问次数。关键是把指标定义、测量口径、数据来源、验收周期写进合同。
业务结果指标的另一个作用是防止“试点成功、推广失败”。这一问题在 AI试点总成功，一推广就失败：缺的不是模型 一文中有讨论。合同里如果不写业务结果，验收就容易变成双方在会议室里看测试集的表演。
第二类：覆盖范围，把边界写死
AI 合同最容易扯皮的地方，不是模型不行，而是“我没说过这个场景要做”。假设模型在 A 产线表现好，到了 B 产线光照不同就失效；在中英询盘上效果好，到了意大利文询盘就乱翻。合同只写准确率，等于默认所有范围都覆盖了，实际上没有。
覆盖范围至少应包含：产品型号或 SKU、缺陷类型或问题类型、语言、渠道、数据输入条件、设备或机台、操作人员的行为边界。
超出范围怎么办，也要写。假设上线后新增一类缺陷，供应商是否有义务扩展？如果合同不写，供应商大概率会报一个新项目的价格。买方应在合同里区分“范围内优化”和“范围外新增”，分别约定响应时间和费用。
大厂商的交付标准已经把场景适配作为核心能力。2025 年 9 月，阿里云通过中国信通院大模型交付实施最高等级（5 级）认证，评估项包括需求分析、模型调优、场景适配、运维保障等 34 项能力。无论供应商大小，买方都可以用这个逻辑问一句：能不能说清楚场景边界，本身就是交付能力的一部分。
第三类：延迟与可用性，别被 99.9% 骗了
很多合同会写“系统可用性不低于 99.9%”。这个数字看起来高，实际用处有限。以 Azure OpenAI 的公开 SLA 为例，它承诺 99.9% 月度可用性，但只衡量“服务有没有返回响应”，不衡量响应快不快；停机前 43.2 分钟不赔，超过也只赔当月服务费的 10%，只有停机超过 7 小时 12 分钟才赔 25%。换句话说，真正让业务受损的慢响应、限流、排队，可能一分不赔。
中小企业用 AI，很多时候是通过一家外包商调用云厂商模型。上游 SLA 不覆盖的延迟风险，必须由集成商或外包方在合同里承担，或者在价格里做出取舍。建议在合同中单独定义“有效可用性”：响应时间 p95 不超过 X 秒（p95 是一种避免被极端值拉偏的延迟指标），连续超过阈值达到约定时长视为性能不达标；支持的最大并发量、排队策略、高峰期降级方案也要写。赔付最好写现金或扣款，而不是只能抵扣未来账单的服务信用。
延迟不是技术细节，是钱。假设一个质检 AI 从秒级响应变成等很久才出结果，产线可能等不及它，整套系统就可能被绕过。
第四类：错误处理与重训责任，不写就是新项目
模型上线后一定会遇到新数据、新错误。中小企业很少在合同里写“上线后错了怎么办”。可能出现的情况是：项目验收那天开始，任何调整都被供应商当成新的需求变更。
建议合同至少写明四点。第一，错误分级：P0 安全事故、法律违规、客户大量流失；P1 主要功能错误；P2 轻微错误。分别约定响应和修复时间。第二，漂移监测：模型面对的数据和训练时越来越不一样，效果会下降，要约定谁负责监测业务指标变化，多久出一次报告。第三，重训触发条件：错误率超过阈值、新增语种或缺陷类型时，供应商应在约定工作日内给出方案，费用是否包含在首年服务费里要明确。第四，数据所有权：训练数据、标注数据、提示词、评估集归谁，合同结束后能否带走。
如果项目涉及企业知识库，责任归属和更新机制更要在合同里写清楚。企业知识库没人用，先检查三个机制 一文指出，知识库不是建完就活着，它需要写入激励、责任归属和过期机制。AI 外包合同如果不约定这些，等于花钱买一个注定过期的静态系统。
什么情况下这个判断不成立
如果企业买的是标准化 SaaS 产品，而不是做定制外包，谈判空间小得多。这种情况下，四类指标不可能全部写进去，但可以用来评估供应商：覆盖范围有没有说清楚？延迟 SLA 赔不赔慢响应？模型质量回退有没有升级路径？至少可以选择交付实施标准更成熟的供应商。
如果项目本身是金额很小的试验性试点，业务结果指标可能过于苛刻。试点阶段的重点是验证可行性，合同中更应写清试点范围、失败降级条件和不能直接推广的约束。
尚未完全解决的问题是：很多中小企业没有足够历史数据，签订合同时连业务基线都测不出来。是先花一笔钱做数据基线，还是先签一个“上线后商定周期内补测基线”的条款？我倾向后者，但这给供应商留下了扯皮空间，可能需要在付款节点上做约束。
这篇文章不提供合同模板。四类指标背后的逻辑只有一句：验收应证明业务问题被解决，而不是证明模型好看。
参考来源
- AI外包合同
- 验收指标
- 中小企业AI
- SLA
- 数据漂移