2 篇博文 含有标签「liability」

一个智能体订错了机票。它给错误的客户发送了道歉邮件。它编写了一个数据库迁移脚本，删掉了一个仍有三个服务在读取的列。在每种情况下，模型都生成了一个看起来合理的动作，执行了它，然后继续运行。而在每种情况下，都有人承担了真实的代价——改签费、受损的关系，或是凌晨 2 点的故障排查。

令人不安的地方在于：大多数 AI 产品对于“谁来承担代价”这个问题没有答案。在设计评审中，这个问题从未被提及。它在以后才会显现，以支持工单的形式，一个接一个地出现在支持队列中——因为客户听起来很生气，而客服代表没有可以遵循的政策，只能即兴提供 40 美元的额度。将此乘以每月几千张工单，单位经济效益就会悄然腐烂——不是因为一次戏剧性的失败，而是因为一个无人关注的缓慢漏洞。

“模型犯了错”不只是一个支持升级。它是一个计费事件。而在智能体时代生存下来的产品，将是那些在收到第一张愤怒的工单之前就为这类事件做好了设计的产品，而不是那些靠感觉即兴退款，直到毛利变为负值的产品。

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

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

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