← Physical AI 系列
ESSAY 13 / 16 · 治理与社会契约

机器人犯错之后,账单寄给谁?

从模型到运营者:规模部署需要怎样的责任链?

作者原创首次公开发表: · AINEMA最近更新:

设想这样一次事故:机器人在仓库搬运时,撞坏了一台昂贵仪器。硬件供应商说机械结构正常,模型公司说环境超出测试范围,集成商说客户更改过设置。客户只想恢复生产,却先收到三份互相指向别人的说明。

这不是一个已经发生的案例,而是一种值得在采购前排练的情境。机器越能自主行动,交付链条就越不能依赖“出问题再商量”。

Physical AI 的商业成熟度,既体现在成功时完成多少工作,也体现在失败时能否迅速止损、查明原因,并承担承诺过的责任。

FIG. 13 / 论证结构
01任务授权
02系统与现场
03事故证据
04责任与补救
能力链条需要对应的责任链条。

安全、调查与赔偿,是三个问题

安全设计试图降低事故发生的概率;事故调查试图还原事情为什么发生;赔偿安排决定损失怎样得到处理。三个环节相关,却不能相互代替。

一个系统通过了某项测试,不代表它不会在新环境中失效。一次损失得到赔付,也不意味着系统已经修复。供应商给出一份技术解释,更不等于受影响的人已经获得合理救济。

Google DeepMind 的机器人安全说明把语义、物理和运行层面的防护组合起来。这种分层思路有助于理解风险:理解指令、约束动作和管理现场,都可能需要独立防线。它是技术框架,不能替代具体产品的认证,也不能直接决定一场事故中的法律责任。官方安全说明

因此,采购者需要分别追问:哪些风险已经验证,发生异常时谁接管,损失出现后由谁先回应。把这三个问题压缩成一个“成功率”,会隐藏最重要的差别。

自主性增加之后,责任链要更清楚

一项机器人服务可能涉及硬件、基础模型、任务应用、现场集成、运营维护和客户使用。每一方掌握的控制权、信息与干预机会都不同。

我主张先画控制链,再谈责任链。谁批准了任务?谁修改了速度或动作范围?谁知道现场条件发生变化?谁能够停止系统?这些问题能够帮助确定需要保存哪些证据,也帮助各方把合同写得更具体。

这不意味着控制某个按钮的人必然承担全部责任。法定责任仍取决于司法辖区、事实与适用规则;合同也不能当然排除第三人的权利。这里讨论的是部署之前应当完成的组织设计。

对客户而言,可以约定一个明确的事故响应窗口:由服务商先协调恢复、保存证据和联络相关方,再根据调查进行内部追偿。这个窗口不必承担所有最终损失,却应避免客户在多家公司之间重复解释同一件事。

真正可交付的自主系统,需要一个找得到、叫得应、能采取行动的运营主体。

这个主体还需要拥有实际资源:能够暂停任务、调度替代服务和通知受影响的人。只有一个客服邮箱,却没有处理权限,仍然不构成完整的响应能力。

日志需要帮助还原事实,也需要克制

如果事故发生后只剩下一段模型生成的解释,我们未必知道真实过程。更有用的证据可能包括任务版本、授权记录、关键传感器状态、人工接管、软件更新和紧急停止事件。

但“为了安全记录一切”也不是充分理由。在家庭和照护环境中,无限保留视频与声音,会把事故调查系统变成日常监视系统。

我的建议是按用途设计留存:平时保留必要的事件摘要;异常发生时,在预先说明的权限范围内保存相关片段;对查看、导出和删除设置记录与期限,同时为适用法律要求的留存和事故调查保全预留例外。具体做法需要结合司法辖区、现场风险和隐私要求验证,不能用一个模板覆盖仓库与卧室。

还应允许证据呈现不确定性。某个传感器没有记录到,不等于事情没有发生;模型对原因的自述,也不是独立调查结论。可追溯的目标,是让人更有条件判断,而不是让系统自动给自己免责。

保险能转移部分损失,不能修复坏系统

保险值得纳入商业设计,因为单个客户未必有能力承受低频但严重的损失。不过,是否能够承保、承保哪些场景、哪些事项除外,都需要具体评估。不能在产品介绍中先假定“保险会兜底”。

更完整的成本表应考虑免赔部分、停机、替代服务、调查与维护,以及可能无法获得赔付的损失。否则,设备报价看起来便宜,风险却只是被留给客户。

同样,工作验收记录可以帮助识别履约边界,却不是自动判责工具。Proken 如果记录了一次搬运通过验收,它可以证明特定条件下某项工作被接受,不能据此证明整个作业过程不存在隐性损害,也不能把一个工作单位变成法律结论。

这也是为什么计量体系必须容纳失败、返工与争议。只记录成功动作的账本,适合展示进展,却不足以支撑长期服务。

小企业需要可承担的规则

最有力的反对意见是:层层审计、日志和保险可能使部署成本过高,最终只有大企业能使用机器人。这个担忧成立,尤其当合规流程与实际风险脱节时。

解决方向应当是比例适当。低风险、可逆的小任务,可以采用简洁的标准条款与事件记录;涉及身体伤害、关键设施或敏感空间的任务,需要更严格的验证与响应。风险分类也应随真实运行经验调整。

企业现在就能做一件务实的事:在采购演示中加入一次“失败演练”。人为设置一个安全的异常,让供应商展示系统怎样停止、通知谁、保存什么、如何恢复,再把承诺写进服务安排。

这可能比再看一次流畅演示更能揭示交付能力。失败不可完全消除,责任的真空却可以提前减少。

前面讨论照护时,我们问机器能否让人生活得更好。走到制度层面,同一个问题变成了:当机器没有做到承诺的事情,人是否仍然得到及时、公平的对待?

采购机器人时,你会先问它能完成多少工作,还是先要求看一次失败后的完整处理流程?

本文为作者的研究与观点。事实、模型推演与未来假设分别表述;文内链接可用于追溯来源。