3. 人工智能供应商合同架构审查

人工智能供应商的合同很少是一份文件。典型结构是：一份主协议（Master Agreement）搭骨架，若干附件与政策文件挂在其下，其中SLA管服务可用性与支持响应，数据处理协议（DPA）管个人信息与训练数据的合规处理，知识产权条款管模型、数据、输出成果的归属与许可，责任限制条款管赔偿上限与除外情形。审查的关键不是逐份读完，而是判断这五者是否互相咬合——一份文件给出的权利，是否被另一份文件悄悄收回；一份文件设定的义务，是否在另一份文件里被免责条款架空。

一、先建立“效力层级”与“引用关系”地图

审查第一步是确认冲突时以谁为准。多数主协议会写“本协议正文与附件冲突时以正文为准”，但DPA往往又写“就个人数据处理事项，DPA优先于主协议”。这两句话叠加后，实际效力顺序会变成：DPA（仅限数据保护事项）＞主协议正文＞SLA＞其他附件。如果供应商把责任限制条款放在主协议正文，而把数据泄露通知义务放在DPA，那么“DPA优先”就可能让数据泄露责任绕开主协议的责任上限——这既可能是保护，也可能是陷阱，取决于责任限制条款是否明确覆盖DPA。

因此建议在审查表中单列一栏“引用与冲突”，逐条记录：该条款被谁引用、引用时是否改变了原条款的适用范围、冲突规则是否形成闭环。常见失衡信号是：主协议说“供应商对数据准确性不承担责任”，而SLA却承诺“输出准确率≥95%”，两者直接矛盾，此时必须要求明确以哪一条为准，否则争议时供应商会择低适用。

二、SLA与责任限制的“数字咬合”

SLA通常用服务抵扣（Service Credit）作为唯一救济。审查时要算一笔账：假设合同年费120万元，SLA约定可用性低于99.9%时按月度服务费10%抵扣，单月最高抵扣30%。那么即使供应商整月不可用，客户最多拿回3.6万元，而业务中断损失可能是数百万元。此时若责任限制条款又写“供应商总责任不超过过去12个月已付费用”，SLA的抵扣就成了赔偿的唯一出口，实际风险敞口几乎全部留在客户侧。

合理的做法是要求关键指标与责任上限挂钩：对可用性、数据泄露、知识产权侵权三类高风险事项设置独立于一般上限的赔偿额度，或明确将其列为责任限制的除外情形。审查时可直接在合同中标注：SLA第4.2条的抵扣是否“排他性救济”，若是，则必须同步检查责任限制条款是否对重大违约留出例外。

三、DPA与知识产权条款的交叉地带

AI场景下最容易被忽略的是“训练数据”与“输出成果”的权属。DPA通常只规定供应商作为处理者的义务，但若主协议允许供应商“使用客户数据改进模型”，这就同时触发了知识产权条款和DPA的边界问题：改进后的模型权重归谁？客户数据是否进入供应商的通用模型？如果DPA写“数据仅用于提供服务”，而主协议又写“供应商可为改进服务使用客户数据”，两者直接冲突，且DPA优先时，主协议的改进授权可能无效——供应商却可能已经实际使用了数据。

建议在审查中要求供应商明确三项：训练是否使用客户数据、使用后模型是否专属、输出成果的商用许可是否覆盖客户业务场景。若供应商拒绝将“不使用客户数据训练”写入DPA，则应把该风险计入责任限制的除外情形，或要求提高赔偿上限。

四、可执行的审查清单

以下清单可直接用于逐份合同比对，建议每项标注“已闭环 / 存在冲突 / 缺失”：

完成上述比对后，输出一份“权责失衡清单”，按风险等级排序：高等级为“义务被免责架空、赔偿被上限封顶、数据使用授权冲突”，中等级为“SLA指标模糊、通知时限过长”，低等级为“文本表述不一致但不影响实质权利”。这份清单就是后续谈判和补充协议的直接输入。