如果AI代为下单，责任该由谁承担
AI的下单错误不能仅凭一次确认点击就判定责任。本文将结合授权范围、交易对手、执行记录与补救机制展开探讨。
商业如果AI代为下单却送错了商品
假设你把采购日常用品的事交给了AI助手。屏幕上弹出了购物车和总金额，并询问是否完成订单。金额在预期范围之内，于是你点击了确认，可事后才发现商品中混入了含有过敏原成分的食品。配送地址选错、同一笔订单被重复扣款等意外也同样可能发生。
最后一步点击确实是由人完成的。但在此之前，用户的指令、AI的理解、商家的商品信息，以及下单与支付系统都在协同运转。究竟是哪个环节出了差错，决定了该找谁追究责任。
仅仅因为点击了确认，并不意味着用户必须承担全部责任。 反之，也不能单凭“是AI经手的”就断定用户完全免责。今天，我们就沿着意图、授权、执行、确认和补救这五个环节，来逐一审视事故发生时的成因与责任。
即使有确认环节，错误依然存在
哪怕只是负责回答的聊天机器人，也可能因错误信息造成损失。而智能体甚至拥有直接执行下单、发送、删除等操作的权限。这也是为什么我们在关注准确性的同时，还必须明确允许哪些行为以及如何进行撤回。
OpenAI 在 2025 年 1 月的 Operator 系统说明（System Card）中，公布了向未采取安全防护措施的模型指派 100 项日常任务的测试结果。其中引发不便的错误有 13 个，有 8 个可以在几分钟内轻松撤回。其余 5 个则包括发送给错误收件人的邮件以及订错的餐食等。
该公司解释称，主要通过确认环节将风险降低了约 90%。在另一项涵盖 607 项任务的评估中，在需要确认的情境下主动请求确认的比例——即确认召回率——平均为 92%。由于这是发布前的内部评估结果，因此不应将其直接理解为真实用户的事故发生率。Operator 系统说明
2025 年 7 月的 ChatGPT agent 系统说明中，确认召回率为 91.0%。文档解释称，由于评估过程中遗漏了许多实际确认行为的案例，该数值被低估了。对于金融交易等关键行为，则进行了单独评估。因此，我们不能仅凭两次公布的 92% 和 91% 就断定系统毫无改善，或者得出如今每十次支付就会有一次在未经确认的情况下直接执行的结论。ChatGPT agent 系统说明
我在这里尤为看重的，是在设计时必须将出错前的确认与出错后的恢复结合起来考量。
看到什么并予以批准，这一点至关重要
仅显示总额的界面，与同时显示商品名称、数量、配送地址乃至退换货条件的界面，用户所能核对的信息截然不同。日后在争议同意范围时，当时的界面展示与具体指令内容也会成为关键凭据。不过，界面上只显示了总额，并不意味着在法律上就会被自动认定为仅对总额作出了同意。
增加批准请求的做法同样存在局限。Anthropic 在 2026 年 4 月的一篇文章中，阐述了将工具的各项行为分别设定为始终允许、需要批准和拦截的方式。比如允许查询日历，但在发送邀请函时必须获得批准。与此同时，文章指出，如果要求确认数十次，用户可能就不会再仔细阅读请求了。在 Claude Code 中，他们还提出了先审核执行计划的方式。Anthropic 的设计说明
预先批准计划可以减轻每一步都要停下来的负担。但即便如此，也必须区分计划中包含的操作与新产生的操作。因为必须明确：允许整理文件是否等同于允许删除无关文件；批准单次支付是否包含了后续的自动扣款。
在 Anthropic 2026 年 2 月的一项使用研究中，Claude Code 的新用户中约有 20% 使用了会话全量自动批准，而在经验丰富的用户中这一比例超过了 40%。经验丰富的用户在执行过程中进行干预的频率也更高。这表明出现了一种并非预先批准每一步，而是在观察执行过程时随时介入的方式。这一结果并不直接意味着把关水平的下降。自主性衡量研究
我认为，相比批准的次数，用户实际能够掌控的范围更为关键。用户必须清楚自己托付了什么、可以在哪里叫停，以及哪些行为需要额外的许可。
也存在批准被篡改信息的风险
智能体读取的网页或文档中，可能潜藏着诱导其执行用户未授权行为的指令。这被称为提示注入（Prompt Injection）。比如，用户明明只是要求对比商品，页面内的隐藏指令却诱导它将信息发送至其他网站。
确认流程确实有助于减轻此类攻击造成的损害。然而，如果AI生成的摘要或批准界面本身就包含错误信息，用户就很可能会漏掉差错。OpenAI和Anthropic也并未单纯依赖单一的确认请求，而是结合了模型训练、监控机制和访问权限限制等多种手段进行综合说明。
在这种情况下，仅留下“已批准”的记录往往难以充分解释事故原因。系统读取了哪些资料、向用户展示了什么、批准的内容与实际执行的内容是否一致，这些环节都必须相互印证。批准记录本身并不能消除产品的缺陷，也无法抹杀经营者的违规责任。
可以分五步排查原因
| 步骤 | 核查内容 | 调阅资料 |
|---|---|---|
| 意图 | 用户请求了什么 | 原始指令与后续修改内容 |
| 权限 | 读取、写入、支付、删除中开放到了哪一步 | 权限设置与委托范围 |
| 执行 | 使用了哪些信息和工具进行处理 | 商品信息、工具调用、订单与支付记录 |
| 确认 | 向用户展示了什么 | 确认页面与确认时间戳 |
| 补救 | 是否支持取消、退款、恢复 | 商家联系方式与补救流程 |
这张表并不是划分法律责任比例的标准，而是用来把分散在不同公司的数据汇总起来、厘清原因的排查顺序。补救措施也未必全发生在产品之外：有时通过产品内的取消功能即可解决，有时则需要商家或支付服务商的协助。
如果企业内部账号与智能体共用，就需要更细致地保留日志记录。因为仅凭账号名称，往往很难分清究竟是员工本人操作，还是由智能体代为执行。细化到具体工具的权限配置，以及相应的审批和执行日志，有助于厘清这一界限。
OWASP 的智能体安全指南也建议：仅开放完成任务所需的最小工具权限，对敏感行为实施权限校验，并完整记录工具调用过程及其结果。OWASP 安全指南
显示下单界面的公司与销售者可能并非同一主体
OpenAI 的 Agentic Commerce Protocol 文档中提到，虽然由 ChatGPT 显示下单界面，但订单是否接受由销售者系统决定，货款也通过既有的支付服务商处理。OpenAI 解释称，在此架构下自己并非代表交易上销售者地位的名义销售商（merchant of record）。订单与支付架构
仅凭这一说明，并不能直接确定其在韩国法律上的地位或责任。必须结合该服务实际承担的角色以及适用的法律共同审视。面向销售者的商品信息提交条款中关于代理人责任的规定，针对的也是该提交行为本身。很难将其扩大解释为涵盖消费者 AI 助手造成的一切事故责任的条款。商品信息提交条款
韩国《电子商务法》第20条规定，通信销售中介方必须事先以让消费者易于知晓的方式告知自己并非交易当事人。中介方还必须核实作为经营者的销售者身份信息，并在消费者发出要约之前向其提供。仅仅在开发者文档中用英语说明销售者地位，并不能视为履行了对消费者的告知义务。第20条
第20条之2还规定了因遗漏告知或提供错误身份信息等产生的连带赔偿责任。这需要厘清损害与违规行为之间的关系，且对于身份信息相关的责任，在尽到相当注意义务的情况下存在例外免责情形。仅凭销售者名称未在单一界面上显示这一事实，并不能直接判定赔偿责任。
撤回要约（退货退款）原则上为自收到合同书面文件之日起 7 日内；若商品交付更晚，则以收到商品之日等为基准。若履行情况与标识、广告或合同内容不符，则适用自收到商品之日起 3 个月内、且自知悉或应当知悉该事实之日起 30 日内的独立标准。商品损坏或已提供的数字内容等存在限制与例外情形，因此必须核对具体的交易内容。法制处的撤回要约说明
该法如何适用于相关 AI 服务，取决于具体的交易架构。在实际纠纷中，不仅要审查确认界面，还必须汇总合同、商品信息和订单记录予以综合研判。
即使使用免费服务，也需要确认补救途径
免费的 AI 助手并不意味着其与个人信息保护或消费者权益保护相关的义务会自动免除。不过，无论免费还是付费，各款产品所能提供的记录、技术支持范围以及赔偿条款都各不相同。
发生事故时可以联系哪里、订单号能否导出、服务协议终止后是否仍能获取必要记录，这些都需要仔细考量。单纯依据价格高低，很难判断事后能否获得补救。
Oswarld视角
在准备这篇稿件时，比起数字，我花更长时间确认的是产品的上线与下线公告。
OpenAI目前的帮助文档说明，Operator网站已不再可用。文档还表示不再提供ChatGPT agent，并引导用户使用ChatGPT Work与云端浏览器。Atlas则标明2026年8月9日为终止服务日期，并提示用户另行保存所需的书签和浏览器资料。ChatGPT agent说明，Atlas下线说明
即使产品变更或终止，通过该产品执行的下单、发送、删除等操作结果也不会自动撤销。但与此相对，当时的操作确认界面或执行记录能否继续访问，则是另一回事。必须核实保存期限与迁移方法。
因此我认为，在引入行动型AI时，除了准确性之外，首先还必须追问：在不再使用该产品之后，是否仍能调查事故并采取必要措施？ 答案需要从合同条款、记录导出功能，以及销售方和服务对接方的支持流程中寻找。
员工使用公司内部账号操作智能体时也是同样的道理。必须清楚公司能查验的记录是仅仅只有员工账号名称，还是会连同确认与工具调用记录一并留存。这并不是主张无期限保存所有日志，而是强调在引入阶段就应当明确所需记录的范围、保存期限以及访问权限。
批准前需要确认的五件事
- 要执行的具体内容是否一目了然。 商品、数量、金额、配送地址等会改变结果的关键项，必须能够核对。
- 许可的范围是否明确。 请留意该授权是仅适用于本次任务，还是涵盖了重复执行或后续追加操作。
- 能否找到记录与取消途径。 请确认是否能够获取订单号、执行时间以及撤销操作的流程。
- 是否可以只赋予必要权限。 仅需查询的任务，完全没有必要开放支付或删除权限。
- 是否清楚交易对手与客服支持渠道。 请区分并理清 AI 提供商、卖家与支付服务商各自的角色及联系途径。
确认按钮只是减少事故的一种手段。单凭这一个按钮，既无法阻挡所有风险，也无法界定全部责任。用户实际可以审查的信息、控制执行的权限，以及在出错时赖以补救的记录与恢复程序，必须同时具备。
💬 如果您曾尝试把下单或发送任务交给 AI，在点击批准前，您还会多确认哪一项内容？也欢迎聊聊您在试图撤销操作时，却找不到所需记录的经历。
参考资料与延伸阅读
- OpenAI Operator 系统卡，2025 年 1 月 23 日。
- ChatGPT agent 系统卡，2025 年 7 月 17 日。
- Anthropic: Trustworthy agents in practice，2026 年 4 月 9 日。
- Anthropic: Measuring AI agent autonomy in practice，2026 年 2 月 18 日。
- OpenAI Agentic Commerce Protocol 的角色划分。
- OWASP AI Agent Security Cheat Sheet。
- 《电子商务法》：中介者的义务与责任以及撤回要约相关规定。
推荐往期阅读
