真正关键的 LLM 合同条款：企业级 AI 采购者的谈判清单

大多数企业级 LLM 合同的谈判逻辑都是倒置的。法务部门会花三周时间研究“责任限制”条款——这一条款几乎永远不会被触发——而决定你的产品明年能否存活的条款，却在格式条款中被草草通过：供应商有权弃用你所依赖的模型，而通知义务仅定义为“尽商业上的合理努力通知你”。

问问那些在模型退役日期截止前仍有生产流量的人吧。迁移不是一次法律事件，而是一场工程“消防演习”——重新运行评估套件，重新调整那些表现已经悄然发生变化的提示词 (Prompts)，还要向客户解释为什么助手的语气一夜之间变了。任何赔偿条款都无法涵盖这种损失。但是，如果在前期谈妥“弃用通知”条款，就能将这场消防演习转化为一个有计划的项目。

这是一份针对 AI 买家、真正能转移风险的条款清单，大致按它们对你造成负面影响的频率排序。同样重要的是，它还评估了哪些杠杆是供应商真正会愿意让步的，而哪些条款只会让你白白浪费谈判筹码。

从实际的故障模式开始，而非模板

标准的 SaaS 协议包含几十个条款；但在任何交易中，只有少数几个条款带有真正的风险。对于 LLM 采购，风险集中在标准 SaaS 策略无法触及的地方，因为故障模式是全新的：

• 你购买的产品会在你不知情的情况下发生变化。 模型会被弃用、静默更新或被量化。没有任何其他软件类别会每隔 12–18 个月就停用其核心产品。
• 你的数据变成了别人的资产。 输入和输出流经供应商的基础设施，而默认条款通常允许他们保留比你预期更多的数据。
• 输出结果会产生第三方责任。 生成的文本可能会侵犯版权、构成诽谤或言之凿凿地误导事实——而“谁来赔偿”的问题在法律上确实尚未定论。
• 算力容量无法保证。 速率限制 (Rate limits) 通常出现在文档页面而非合同承诺中，而文档页面可以在不通知的情况下随时更改。

每一项都对应一个特定的条款。按它们实际伤害你的可能性排序如下。

模型弃用与版本稳定性：最先伤到你的条款

这是整份协议中发生概率最高的风险，而大多数初次购买者根本不会就此进行谈判。

市场基准具有参考意义。Amazon Bedrock 承诺模型从发布到生命周期结束至少有 12 个月的时间。Azure OpenAI 通常提供一年的正式版 (GA) 支持以及一段时期的延长访问窗口。第一方 API 提供商的表现则参差不齐：Anthropic 发布了关于长期保留模型权重的承诺，但公开承诺并不等同于合同约定的通知期，而且其他供应商在退役模型时，留给客户的缓冲期远比企业客户预想的要短。

你应该具体要求什么：

• 在合同中明确最短弃用通知期——对于企业协议，12 个月是可以实现的；6 个月是底线。具体的数字并不如“写进协议”本身重要，而不是写在供应商可以随意编辑的文档页面上。
• 锁定特定的模型版本，而非别名 (Aliases)。 如果你的订单上写着购买的是“最新模型”的访问权限，那么你就等同于同意了一系列不受限的静默行为变更。请明确快照标识符 (Snapshot identifiers) 并要求在重新指定你所依赖的别名之前进行通知。
• 明确定义的迁移支持义务。 在过渡期内延长旧模型的访问权限，理想情况下还应包含针对强制迁移导致的重新评估工作而设立的积分抵扣机制。

供应商几乎永远不会同意的一件事是：承诺无限期地提供某个模型。服务器容量是昂贵的，弃用是供应商收回容量的方式。不要追求长生不老，而要追求可预测的通知和铺平的迁移路径。这是他们愿意让步的杠杆。

数据保留与训练权利：书面明确默认设置

这一部分隐藏了两个独立的问题，而买家经常将它们混为一谈：供应商保留你的数据多久，以及他们在持有数据期间可以拿它做什么。

关于保留期，主要 API 提供商的常见默认设置是 30 天，用于滥用监控，之后删除。零数据保留 (ZDR) 方案——即 Prompts 和输出在交易完成后绝不持久化存储——在大多数主要供应商中都存在，但通常受限于用例审查和企业级协议。如果你身处医疗、金融行业，或处理任何监管机构认为敏感的数据，ZDR 值得明确申请；供应商批准的情况比买家预想的要多，但绝不会是默认项。

关于训练权利，企业级和 API 层的格局已基本趋同：主要供应商现在默认不使用企业客户的数据进行训练。但“基本趋同”这个词在其中起到了关键作用。审计过不同供应商 LLM 条款的律师报告称，细节上存在显著差异：承诺是否涵盖微调以及预训练？是否延伸到子处理器 (Sub-processors)？“服务改进”的例外条款是否悄悄重新引入了标题条款所排除的内容？

你需要的合同语言应该是肯定且狭义的：供应商仅可为了提供本协议项下的服务而使用客户数据，句号。这种表述无需你逐一列举即可关闭例外窗口。同时配合以下条款：

• 明确的删除义务及时间表，涵盖备份和日志，以及合同终止时的数据返还。
• 当前的子处理器列表及通知权（理想情况下还有异议权），当列表发生变化时。你的数据承诺强度取决于最弱的子处理器。
• 审计或认证权——至少要有 SOC 2 报告，如果你的合规体系有要求，还应包含在合理通知后的审计权。

在企业级层面，供应商很容易在保留窗口和训练语言上做出让步——这是公认的领域，他们有预先批准的后备方案。但在标准认证之外的审计权上，他们动作缓慢。请据此调整你的谈判策略。

赔偿保障：在评估承诺之前先阅读排除条款

在 Microsoft 推出 Copilot 版权承诺以及 OpenAI 发布版权护盾（Copyright Shield）后，版权赔偿保障成为了核心卖点，Google 和 Adobe 也随后推出了类似的计划。Google 的版本因其双重保障而备受瞩目：它既涵盖了源自训练数据的索赔，也涵盖了源自生成内容的索赔。从表面上看，这似乎是供应商在替你承担行业中最大的法律模糊性风险。

在实践中，其价值完全取决于排除条款，而这些排除条款的影响非常重大：

• 保障视你的配置而定。 如果你关闭了安全系统、内容过滤器或要求的缓解措施，大多数计划都会使保障失效。如果你的工程师因为某个审核层干扰了正常的合法请求而将其关闭，你可能已经无意中使赔偿条款失效了。
• 知情即排除。 如果你明知或理应知道输出内容构成了侵权 —— 或者你通过提示词诱导了侵权内容的生成 —— 你将不在保障范围内。
• 层级至关重要。 这些承诺通常涵盖企业版和 API 客户，而不包括免费版或个人版。如果你工作流的一部分通过个人版产品运行，那部分流量很可能不在保障范围内。
• 上限决定条款价值。 赔偿上限仅限于已付费用的条款，与无上限的辩护义务是完全不同的。上限在哪里设定 —— 是包含在一般责任上限内，还是设在独立的高额上限（super-cap）内，抑或是无上限 —— 是这些交易中少数几个真正可协商的资金条款。

战略解读：版权赔偿是真实的但范围有限，它们覆盖的是供应商的风险面（训练数据来源、模型行为），而不是你的风险面（你的应用程序在下游如何使用输出内容）。基本上不可协商的是对输出内容“准确性”的赔偿保障 —— 没有供应商会为概率系统的事实准确性背书，要求这一点意味着你并不了解自己购买的是什么。

速率限制、容量和价格保护：隐藏在文档中的商业条款

这是一个令人不安的模式：你的架构所依赖的数字 —— 每分钟 token 数（TPM）、每分钟请求数（RPM）、并发量 —— 通常存在于通过引用并入合同的文档中，而供应商可以单方面修改这些文档。你的合同保证了你对服务的使用权，但往往对服务的“容量”闭口不谈。

对于生产环境的工作负载，请将容量写入合同：

• 将承诺吞吐量作为合同条款，无论是预置吞吐量单位（PTU）、保留容量，还是在期限内不得降低的指定速率限制底线。一些供应商现在提供可迸发（burstable）结构 —— 即保留的基准容量加上对突发池的优先访问权 —— 这能很好地应对发布高峰和季节性流量。
• 限制变更的通知要求。 如果供应商只需更新一下文档就能削减你的速率限制，那么你的容量规划就是建立在沙滩上的。
• 有约束力的可用性 SLA —— 但要现实地看待其涵盖范围。99.9% 的可用性 SLA 衡量的是端点是否响应，而不是模型表现如何。服务抵扣额（Service credits）对于真正的停机来说只是补偿性的表象；SLA 的实际价值在于作为监控承诺和升级触发机制。

在定价方面，同等能力的每 token 费率呈下降趋势，这改变了谈判态势：长期的价格锁定反而可能对你不利。你真正需要的是非对称保护 —— 在合同期限内（以及续约时，这通常是 SaaS 供应商收回折扣的地方）设置涨幅上限，同时保留向下重新谈判或参照市场价格调整的自由。供应商授予续约涨幅上限的意愿远高于“最惠客户”条款，因为后者会带来审计负担，其法律团队通常会抵制。

核心条款：退出权是你真正的筹码

当供应商相信你可以离开时，上述每个条款都变得更容易谈判；而当他们知道你无法离开时，谈判就会变得异常艰难。这使得可移植性不仅是一个架构问题，更是一个合同问题。

具体而言：与重大变更相关的终止权（未经合同通知的弃用、速率限制降低、你反对的次级处理商变更）、在适用情况下导出微调后的产物和评估数据，以及按当时费率计算的过渡协助期。这些都不是过分的要求。它们共同将“我们在续约前被锁定了”转变为“我们有选择权”，而这是唯一能推动其他条款落地的谈判立场。

最后，给工程负责人的真诚提醒：合同是保障，而非架构的替代品。弃用通知条款为你赢得了迁移时间；而抽象层和维护良好的评估套件才是让你真正利用这段时间的关键。谈判成功的团队，其技术姿态能让离开的威胁变得可信 —— 法律筹码和工程筹码相辅相成，缺一不可。