你的智能体刚刚向错误的账户发放了 40,000 美元的退款，重新路由了一份触发加急运费的货运订单，或者推送了一个导致客户生产环境宕机六小时的配置更改。操作已经完成。它是不可逆的，或者代价大到接近不可逆。现在唯一重要的问题是那个在你上线产品前没人问过的问题：谁的预算来买单？
大多数团队都是通过惨痛的教训才发现答案的。在三天后的会议室里，供应商的客户经理在免提电话里向他们回读赔偿限额条款。限额是年度订阅费。而损失是这个金额的 40 倍。对话很快就结束了。
这就是赔偿缺口，它不是一个你可以留到发布后交给采购部门处理的法律脚注。它是一个设计约束，从一开始就应该决定你赋予一个智能体多少自主权。令人不安的事实是，执行某项操作的技术能力与承担该操作责任的财务权限是由完全不同的系统管理的——你的代码库和你的合同——而这两个系统几乎从未在智能体被允许做什么的问题上达成一致。
订阅费与实际风险敞口之间的错配
2026 年的标准 AI 供应商合同读起来仍然像 2019 年的 SaaS 合同。责任限额被设定为过去 12 个月内支付的费用。间接损失——收入损失、加急货运、监管罚款、客户停机时间——被直接免除。当软件只是一个仪表盘时，这是一种合理的分配。一个有漏洞的仪表盘向你展示了一个错误的数据；你注意到了，你没有根据它采取行动，爆炸半径被工具与后果之间的人类判断所限制。
而自主智能体移除了那个“人”。智能体部署的核心意义在于，系统在无需等待人点击批准的情况下进行规划和行动。因此，爆炸半径不再受判断力的限制，而是受你在工具调用中配置的权限限制。一个被误解的指令可以以机器的速度和规模移动库存、执行交易或提交支出。
审视供应链中智能体部署的法律分析师对这一结构性问题直言不讳：如果供应商合同将赔偿责任限制在订阅费，而智能体却能自主触发数倍于该费用的损失，这便不再是风险分配，而是风险转移。对于超过限额的每一美元损失，你都是最终的承担者，而那个限额不过是舍入误差。
团队常犯的错误是，将其视为供应商需要声明免责的问题，因此不是他们自己需要解决的问题。这完全搞反了。正因为供应商已经声明免责，这完全成了你的问题，并且当事故报告写成时，损失会落在任何一个恰好负责该预算的内部部门头上。
因果关系是一场委员会讨论，而委员会不付钱
即使你想把责任推回给某人——供应商、模型提供商、数据供应商——你也会遇到缺口的另一半：智能体的失败很少有单一、清晰的原因。
当智能体做出了代价高昂的错误行为时，事后复盘通常会发现一条链条。模型的推理看似合理但存在缺陷。它所依据的数据是过时或格式错误的。系统提示词留下了歧义。集成环节没有强制执行每个人都以为在别处执行了的支出限制。人类监督在纸面上存在，但已退化为走形式。抽掉其中任何一根线，失败都不会发生。这意味着涉及的每一方——模型供应商、你的平台团队、数据提供商、集成商——都可以指着另一根线说“不是我们”。
这就是为什么在实践中“谁该负责”的问题解决得如此缓慢。自主系统的责任由合同和既定的法律原则决定，而不是由模型的日志决定，而在智能体 AI 出现之前起草的合同中，根本没有能够清晰映射到多方因果链的语言。结果是，责任默认由部署机构承担，因为你是触及了链条中每一个环节的那一方。你选择了供应商，你提供或批准了数据，你配置了权限，你决定了需要多少人工审核。法院和交易对手很容易就能把损失判定给做出所有这些选择的实体。
你无法通过工程手段让因果关系变得简单。但你可以通过工程手段让它变得“清晰可见”——而清晰度决定了你是否能从任何人那里追回任何损失。这就带到了工程师实际可以控制的部分。
保险兜底正在悄然消失 多年来，人们一直有一个默契的假设：如果合同没有涵盖 AI 损失，保险会涵盖。那是“隐性 AI”时代——保单从未提及 AI，默认被认为涵盖了 AI。那个时代在特定的时间点结束了。
2026 年 1 月，保险服务办公室（Insurance Services Office）针对商业综合责任险推出了标准化的生成式 AI 除外责任背书，主要保险公司纷纷在综合责任险、董事及管理人员责任险（D&O）以及职业责任险（E&O）中增加了明确的 AI 除外条款。这些除外条款并不总是你能一眼读出并定价的单一清晰条款。它们出现在修订后的基础表格中，体现在对什么算作受保“专业服务”的缩小定义中，以及散落在保单结构各处的承保削减中。
其实际效果就是保险界所称的“碎片化”或“缺口风险”：你的网络安全险、技术职业责任险、董事及管理人员责任险和雇佣实践险各自独立地缩小了对 AI 的覆盖范围，而 AI 驱动的损失则掉进了它们之间的缝隙，没有任何一份保单对此做出响应。更糟糕的是，许多旧的综合责任险将 AI 错误视为“技术故障”——明确不予承保——而不是“专业错误”。这种区别听起来很学术，直到它决定了一项索赔是否能获得赔付。
因此，你暗中依赖的兜底正在撤走，而风险敞口却在同时增加。如果你的风险模型中有一项未注明的条目写着“保险会解决它”，那么该条目现在就是虚构的，除非有人专门购买了智能体职业责任险，并确认它对自主操作损失负责。大多数公司都没有这样做。默认的情况是：没有承保，合同有限额，损失由你的运营预算承担。
为终将发生的损失进行工程设计 好消息是，决定由谁买单的几乎每一个杠杆都是工程团队可以构建的，而不仅仅是律师可以谈判的。将以下内容视为部署检查清单，而非合规表演。
在代码中，将权限（Authority）与许可（Permissions）相匹配。 Agent 的财务权限应在动作发生处强制执行，而不是在政策文档中描述。设置明确的阈值——金额、数量、爆炸半径——超过这些阈值，Agent 必须上报给人类而不是自行采取行动。如果你的合同规定供应商仅对最高 X 的损失负责，那么在技术上， A g e n t 应该无法在没有人工干预的情况下执行风险超过 X 的损失负责，那么在技术上，Agent 应该无法在没有人工干预的情况下执行风险超过 X 的损失负责，那么在技术上， A g e n t 应该无法在没有人工干预的情况下执行风险超过
让每一个决策都可追溯。 如果你无法展示 Agent 做了什么以及为什么要这样做，你就无法从供应商、保险公司或交易对手那里追回损失。当损失发生时，易于访问且防篡改的决策日志——包括输入、推理轨迹、工具调用、数据版本——是最有价值的工程制品。通过这些日志，你可以证明故障源于模型的缺陷而非你的配置错误，这是“供应商赔偿我们”与“我们自己买单”之间的区别。
在事故发生前而非发生期间分配所有权。 现在就写下来，哪个内部预算将吸收 Agent 的损失，以及由谁负责授权 Agent 给定水平的自主权。一份简单的责任图谱——谁负责数据质量，谁负责权限配置，谁负责上报阈值，谁签署提高自主权上限的决定——可以将一场为期三天的推诿扯皮变成一份一页纸的参考文档。负责自主权决策的团队应当是其预算面临风险的团队。如果这两者错位，你就会得到极度自主的 Agent，因为授权的人感受不到成本。
像你真的会用到合同一样去谈判。 争取能够反映 Agent 决策规模的责任限制（Liability caps），而不是仅反映订阅价格。争取专门针对自主行为造成的损害进行后果性损害赔偿（Consequential-damages）的豁免。争取第三方索赔的赔偿保障，并要求供应商购买包含 Agent 职业责任险（E&O）的保险。你不会赢得所有这些条款——目前的市场数据表明，只有约三分之一的 AI 供应商提供有意义的第三方赔偿保障——但你失败的诉求会明确告诉你未投保的风险敞口所在，从而让你相应地限制自主权。
核心要点：自主权是一个支出决策 我们的直觉是将 Agent 的自主权视为能力问题——模型有多聪明，工具调用有多可靠，评估套件（Eval suite）有多好。这些都很重要，但它们不是核心约束条件。真正的约束条件是，你授予的每一分自主权，都是你同意承担的一分财务风险敞口，通常这些并未被记录在案，而且几乎从未被定价。
做得正确的团队并不是那些拥有最复杂 Agent 的团队。而是那些在发布前就决定了单次错误行为可能造成的最大损失，根据合同和保险确认了该金额，然后设置 Agent 权限，使技术上的“爆炸半径”永远不会超过财务覆盖范围的团队。这并不是事后补救的法律演习。这与你已经应用在速率限制（Rate limits）、重试（Retries）和熔断器（Circuit breakers）上的容量与限制思维如出一辙——只不过应用对象从请求量变成了金额。
在 Agent 行动之前决定谁来买单。如果你无法回答某个特定动作的买单问题，就不应允许 Agent 自主执行该动作。你的代码允许 Agent 做的与你的合同和保险所覆盖的范围之间的差距，并非假设。它是一个数字，而且可能很大，目前这个数字正被默默地分配给你。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
