跳到主要内容

4 篇博文 含有标签「liability」

查看所有标签

没人会为你的智能体承保

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的智能体开始工作了。它处理工单、发放退款、更新记录、完成闭环——无需人工干预,且根据你的指标,其质量超过了执行同样任务的人类中位数。你已经准备好让智能体完全脱离人工干预。然而部署陷入了停滞,不是卡在工程环节,而是在一次会议中,法务或财务部门的人提出了一个你无法回答的问题:一旦出错,损失由谁承担?

这是智能体自主化过程中能力曲线无法触及的部分。你可以将准确率从 95% 提升到 99%,但上述问题依然存在。因为阻碍部署的从来不是“模型是否足够好”,而是由概率系统采取不可逆行动所带来的风险必须由人承担,而现在没人愿意承担。你的职业责任险(E&O 保险)是为人类失误编写的,且越来越多地将自动化失误排除在外。你的模型供应商合同声明对一切后果免责。而且,目前还没有哪家保险公司能为这类系统制作精算表——因为每当你修改一次提示词(Prompt),系统的失败率就会悄然发生偏移。

赔偿缺口:当你的智能体执行了不可逆操作,谁的预算来买单?

· 阅读需 10 分钟
Tian Pan
Software Engineer

你的智能体刚刚向错误的账户发放了 40,000 美元的退款,重新路由了一份触发加急运费的货运订单,或者推送了一个导致客户生产环境宕机六小时的配置更改。操作已经完成。它是不可逆的,或者代价大到接近不可逆。现在唯一重要的问题是那个在你上线产品前没人问过的问题:谁的预算来买单?

大多数团队都是通过惨痛的教训才发现答案的。在三天后的会议室里,供应商的客户经理在免提电话里向他们回读赔偿限额条款。限额是年度订阅费。而损失是这个金额的 40 倍。对话很快就结束了。

谁该为模型的错误买单:在智能体产品中设计责任机制

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

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

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

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

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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