跳到主要内容

AI 赔偿缺口:当模型出错且没有人的合同能为你提供保障时

· 阅读需 12 分钟
Tian Pan
Software Engineer

一位客户的总法律顾问给你发来一封只有一行的邮件:“如果下周模型在我们的合规工作流中捏造了事实,谁的保险来赔付?”你把邮件转发给工程副总裁,他转发给法务,法务又转回给你。等这条转发链结束时,三个人都分别假设其他人已经仔细阅读过模型提供商的条款。但实际上没人读过。合同之间并没有真正的衔接——而你,作为中间层,是第一个发现这一点的人。

这就是 AI 赔偿缺口。它的存在是因为每个企业级 AI 产品都处于一个由三环组成的责任链中——终端客户、你的产品、模型提供商——每一环都默默假设下层在承担责任。模型提供商的条款将赔偿限额设定在过去 12 个月的费用总额左右,并明确排除对输出准确性的责任。你的 MSA(主服务协议)通过客户律师未仔细阅读的下游转嫁条款继承了这些排除项。而你的客户与他们的下游用户(当输出出错时真正的链尾受害者)签署的合同却将你的产品列为责任方,且没有明确的上游追索权。

第一次索赔发生时,大家才会发现这个缺口。在此之前,责任链上的每一个人都在抱着侥幸心理得过且过。

责任链并未闭合

并排阅读这三份合同,结构性问题就显而易见了。

模型提供商的商业条款排除了对模型输出的准确性、完整性或可靠性的责任。赔偿限额被封顶在过去 12 个月支付的费用内。即便存在赔偿条款,其范围也非常狭窄:大多数主流供应商——OpenAI、Anthropic、Microsoft、Google、IBM——都提供“版权盾”(Copyright Shield)或类似保障,涵盖因输出引发的第三方知识产权侵权索赔,但前提是必须遵守有关护栏、内容过滤和仅使用正式发布功能等条件。这种保障是真实存在的,但非常局限:它处理的是知识产权类索赔,而非事实准确性类、监管认证类或有害内容类索赔。

你与客户签署的 MSA 通常会做两件事之一。要么它将供应商的排除项向下转嫁——这意味着你的产品在合同上成为了你并未参与制定的限制条款的传声筒;要么它不转嫁,在这种情况下,你就在没有任何上游追索权的情况下,默默地为这个缺口承保。这两种选择在不同层面上都很糟糕。转嫁方案看起来更安全,直到你的客户与下游用户签署了任何一层都无法履行的义务。非转嫁方案看起来对客户更友好,直到出现一个金额符合你的责任上限、但赔偿范围超出你承受能力的索赔。

客户与终端用户的合同通常是缺口首先浮现的地方。终端用户签署的协议针对的是某项服务——比如财务规划、合规产品或分诊系统——并假设该服务对其告知的内容负责。他们看不到模型提供商。他们看不到你的产品。他们看到的是屏幕上的品牌,他们起诉的也是该品牌。至于该品牌能否向上游追回损失,取决于一种在当今大多数 B2B AI 部署中实际上并不存在的合同结构。

版权盾并非幻觉之盾

这一领域最严重的混淆是将两个无关的风险类别混为一谈。“赔偿”并不是单一的概念。它是一系列针对特定索赔类别的豁免条款,而那些提供听起来很宏大的承诺的供应商,通常只涵盖其中一种。

知识产权侵权豁免——有时被称为“版权盾”(Copyright Shield)、“客户版权承诺”或类似名称——涵盖的是第三方声称你客户使用的模型输出侵犯了其专利、商标、版权或商业秘密的情况。这很有意义。它解决了训练数据暴露带来的真实下游知识产权风险。这也是模型供应商最愿意承保的索赔类别,因为法律环境趋于统一,且每个客户的风险敞口是有限的。

但这种豁免并不延伸到事实准确性。它不涵盖以下情况:模型自信地声称某种药物相互作用是安全的(实际上并非如此),或者合规证明是有效的(实际上已过期),或者财务数字是最新(实际上是 2023 年的快照)。它不涵盖模型代表你的产品做出的监管认证。它不涵盖由代理系统(Agentic System)做出且客户无法撤销的决策所导致的后果。这些正是导致加拿大航空(Air Canada)先例的索赔类别——加拿大一个法庭判定该航空公司对其聊天机器人虚构的哀悼票价政策承担 812 美元的赔偿责任,金额虽小,但原则重大:公司不能对其 AI 告知客户的内容免除责任。主流供应商推出的“我们将为你辩护”声明并不涉及这一领域。

由此产生了两点结论。首先,如果采购团队看到“供应商提供赔偿”就停止阅读,那他们实际上是在做一项自己并不知情的承保决策。其次,如果产品团队在供应商仅提供知识产权赔偿的情况下,交付了高风险的输出类别——如医疗指导、法律解释、财务建议、合规证明——那么他们正默默地将剩余风险转移到产品团队自己的资产负债表上。

赔偿矩阵的真实样貌

一项必须落地的规范——且大多数 AI 产品团队目前只是零散地在做,而非将其视为一个连贯的产出物——就是赔偿矩阵(Indemnification Matrix)。它将每一类索赔与技术栈的每一层进行映射,使除外条款(carve-outs)清晰可见,而不是让它们作为假设埋藏在三个没人会放在一起阅读的合同中。

一个可行的矩阵包含行和列。行是索赔类别:输出结果的知识产权侵权、事实准确性、有害内容、合规性、数据安全、隐私、可用性、性能。列是技术栈的各层:模型提供商、你的产品、客户、终端用户。每个单元格回答两个问题。第一:哪一层的合同明确针对这一类索赔?第二:赔偿限额是多少,有哪些排除条款?那些空白的单元格就是缺口。

缺口才是关键。目前大多数 AI 产品的矩阵,如果如实绘制,在“事实准确性”和“合规性”这两行通常是空的,只有模型提供商层的“知识产权侵权”格子里有内容。那个有内容的单元格承担了整个风险类别(知识产权)的权重,而其他行的权重为零。那些空白行被无声地吸收进工程团队“我们会让它不发生”的信念中。这种信念并没有合同支持。

两项调整可以使矩阵变得实用。首先,区分已保风险(insured risk)与自担风险(absorbed risk):任何赔偿限额远低于实际索赔规模的行都是自担风险,无论合同名义上怎么写。面对 5000 万美元的下游索赔,100 万美元的责任上限在功能上等同于自担风险。其次,将空白单元格引向明确的决策,而非默认状态:要么调高与模型提供商的条款,购买明确的 AI 保险批单(endorsement),缩减产品输出面以覆盖合同涵盖的索赔类别,或者将剩余风险明确计入客户合同。其中任何一项都是决策,而现状并非如此。

输出类别风险分类法

在这个领域,最被低估的工具是分类法(taxonomy),它根据输出类别的责任级别对 AI 功能进行分级,并将合同策略与该级别挂钩。

高责任输出类别是指下游使用会产生可衡量损害的类别:涉及具体金额的财务建议、影响治疗决策的医疗指导、外行会据此行动的法律解释、监管机构可能依赖的合规证明、决定攻击面的安全建议。这些类别的输出在模型错误与可量化的下游损失之间有着直接联系。针对这些输出的合同策略需要具有攻击性:划定赔偿范围、在条款中写入客户侧的审核义务、根据具体用例校准输出免责声明,并持有明确的保险头寸,而非仅靠运气。

中等责任类别更多是操作性而非建议性的:将工作路由给人工审核员的分类、人类在行动前核实的摘要、人工在发送前编辑的草案、用户自行阅读的检索文档。错误链中有人参与,这虽然不能消除责任,但限制了实际的索赔规模。合同策略可以相对宽松:标准上限、输出仅供参考的免责声明、较轻的审核义务。

低责任类别包括格式化、翻译、用户会重写的草稿生成,以及其他下游用途本质上是生成性而非权威性的输出。错误链条短且可逆。合同策略可以采用 SaaS 默认模板。

目前大多数 AI 产品在所有三类输出中都采用统一的合同策略。这种策略继承自法务团队在 2023 年手头的 SaaS 模板,当时并未预料到生成式输出。正确的模式是分层的合同界面——为不同的输出类别制定不同的条款——并将其写入面向客户的条款结构中,使合同能够反映产品的实际风险形态。

保险层的关闭速度快于合同层

仅看合同的视角忽略了第三个维度,而这个维度的变化速度超过了大多数产品团队的认知。

从 2025 年到 2026 年,保险承保商一直在悄无声息地(在某些情况下是明确地)向商业综合责任险(CGL)、专业责任险(E&O)、董监高责任险(D&O)和受托人责任险中添加 AI 输出排除条款。2026 年 1 月生效的 ISO 批单在 A 类和 B 类保障中引入了针对生成式 AI 损害的广泛排除。至少有一家主要承保商为 D&O 和 E&O 引入了“绝对”AI 排除条款,消除了任何因 AI 使用、部署或开发而产生的索赔保障,并明确列出了聊天机器人通信、未能检测 AI 生成材料以及 AI 治理不足等除外责任。网络安全保险(Cyber policies)目前尚且稳固,一些承保商提供明确的 AI 批单,重新覆盖特定风险,如数据投毒、使用权侵权和监管违规。

综合效应是挤压正在收紧。产品团队本以为在组合中的保障——认为 E&O 保单会兜底长尾 AI 索赔——正被明确剥离,与此同时,合同层又未能填补这一缺口。如果一个团队不与风险管理小组进行保险审查,那么它就是在通过默认而非分析来做出承保决策,而这个默认值正日益变为“不予承保”。

正确的节奏是每季度与公司的经纪人进行一次审查,列出生产环境中的 AI 功能、它们覆盖的输出类别、它们暴露的索赔类别,以及保单中触达或未触达这些风险的语言。大多数 AI 产品团队从未进行过这种对话。那些进行过对话的团队平均会发现,在最近一次续保周期中,他们原本以为的两三个保障项要么被排除,要么被设置了分项限额(sub-limited)。

将合约态势视为一项产品特性

架构方面的启示虽然陌生,但逻辑直接:AI 功能的合约态势是产品表面的一项特性,而非法律团队的事后补充。

这句话很难内化,因为它与过去十年产品组织的运作方式背道而驰。SaaS 的打法将合同视为一种后台职能:法律团队审查 MSA,产品上线,合同要么没问题,要么在客户采购团队反对时悄悄重新谈判。AI 产品没有这种待遇。合同承担了产品自身无法完成的风险分配工作,因为其故障模式 —— 即“自信地输出错误内容” —— 是技术本身固有的,并非工程手段可以完全消除的。

内化了这一点的团队会在第一起索赔发生前就构建好责任堆栈。他们在客户的法务总监发来邮件之前就起草好了赔偿矩阵。他们在法律部门开口前就对输出类别的风险分类进行了分层。他们在续约周期到来前就与风险小组一起进行保险审查。他们像谈判延迟 SLA 一样严肃地谈判模型提供商条款,因为在大规模应用时,两个提供商之间的赔偿差异是一个真实存在的数字,应该出现在“自研还是外购”的评估表里。

没有做到这一点的团队只能带着侥幸心理对客户的邮件耸耸肩。这种做法在 SaaS 时代行得通。但在 AI 时代行不通,而第一起索赔发生之时,就是所有人意识到这一点之日。

References:Let's stay in touch and Follow me for more thoughts and updates