一、Agent闯祸以后，不能只盯着“AI承认自己错了” （一）企业真正要追的，不是AI的“忏悔”，而是责任链 AI Agent删库以后，企业第一反应通常会很直接：既然是AI自己执行了删除动作，甚至还在日志里承认“我猜错了”“我违反规则了”，那是不是就可以向服务商索赔？ AI在对话或日志里“认错”，不等于法律意义上的责任承认。它最多只能说明事故复盘中的一段事实：模型曾经输出过某种解释，承认自己做过某个动作，或者承认自己没有遵守某条规则。但真正能支撑企业追偿的，不是这段“忏悔书”，而是更完整的责任链：合同里服务商承诺过什么，企业开放了什么权限，高危操作有没有护栏，云平台是否存在合理拦截机制，损失是否真实发生并且可以证明。 换句话说，企业要追偿，不能只问“AI是不是犯错了”。真正要问的是：服务商是否承诺过不会发生这种事；企业是否给了Agent足够危险的权限；产品是否声称有只读、审批、沙箱或高危操作拦截；云平台是否允许一个普通API调用直接删除关键资源；事故之后，企业能不能证明到底删了什么、损失多少、是谁的行为导致的。 这类问题如果拆不开，企业很容易陷入一个误区：舆论上看起来很有道理，索赔时却拿不出足够扎实的合同和证据。 （二）这类事件不是“AI发疯”，而是Agent接入真实系统后的结构性风险 近期公开报道中，PocketOS事件之所以引发关注，并不是因为AI写错了一段代码，而是因为一个AI编码Agent通过云平台API删除了生产数据库及相关备份，事故过程同时涉及Agent自主决策、云平台API权限、生产环境隔离、备份设计、操作日志等多个环节。 这类事件以后很可能越来越多。原因很简单：企业正在把代码仓库、云平台、数据库、客服系统、邮件系统、交易系统、知识库和内部工单系统逐步接给Agent。过去AI主要是“输出建议”，现在Agent开始“执行动作”。一旦建议变成动作，风险性质就变了。 如果AI只是写错一段分析，企业最多面对内容错误；但如果AI拿到了数据库权限、云平台Token、部署权限、邮件发送权限、支付触发权限，错误就可能变成真实损害。删库、误发客户通知、错误部署、覆盖配置、删除备份、重启服务、清空工单、错误修改合同文本，这些都不再是抽象风险。 所以，这篇文章真正要讨论的，不是“AI会不会闯祸”，而是Agent闯祸以后，企业能不能追责、能不能索赔、能不能把责任从一句“系统异常”拆成可证明的法律关系。 二、第一条线：先看合同，服务商到底承诺过什么 （一）追偿通常先从合同责任开始 企业和AI Agent工具商之间，一般会存在服务协议、订阅协议、企业采购合同、平台使用条款、产品文档或在线规则。这些文件决定了服务商承诺的功能边界、安全边界和责任边界。 如果服务商在合同、官网、产品界面、企业销售材料或技术文档中明确承诺：提供只读模式、Plan Mode、高危操作拦截、人工确认、生产环境保护、沙箱隔离，或者承诺不会未经授权执行写入、删除、覆盖、推送、部署、数据库操作等高危动作，那么这些承诺就可能成为企业追偿的切入口。 尤其是企业版产品，服务商通常会强调安全、可控、企业级治理、权限管理、审计日志等能力。如果事故发生时，这些机制没有按承诺发挥作用，企业就有可能主张服务不符合约定、产品功能未达承诺、安全控制失效或者构成违约。 但如果服务商从一开始就没有承诺高危操作拦截，合同又明确写着用户自行承担工具输出和执行结果，并且要求用户不得用于生产环境或高风险场景，那么企业追偿难度就会明显增加。 （二）法务要先把合同里的四类条款翻出来 1、服务商有没有承诺安全护栏 最重要的是看服务商有没有明确承诺某种“护栏”。例如，未经用户明确批准，不得执行删除、覆盖、部署、数据库写入、云资源变更等高危动作；生产环境默认不可写；Agent只能在用户确认后调用特定工具；只读模式下不会执行写入或破坏性命令。 如果有这些承诺，事故发生后就要进一步看：当时是否启用了该模式，护栏为什么没有生效，系统是否绕过了用户确认，服务商是否知道该功能存在失效风险。 2、服务商有没有写免责条款 很多SaaS或AI工具条款会写得非常强势。例如，用户应自行判断输出结果，用户应自行备份数据，不得用于高风险场景，服务商不保证输出准确性，不对用户执行结果负责。 这些条款不能一概当然有效，也不代表服务商可以无条件免责，但它会显著影响追偿难度。企业要重点看免责条款是否明确、是否合理提示、是否覆盖本次事故类型，是否与服务商宣传的“安全承诺”存在冲突。 3、服务商有没有限制赔偿金额 很多SaaS合同会把赔偿上限压得很低，例如限于过去12个月服务费、最近几个月已付费用，或者某个固定金额。对于普通软件服务，这种条款已经很常见；但对于Agent接入生产环境、可能造成数据损失和业务中断的场景，这种低额责任上限很可能无法覆盖真实损失。 企业采购时如果没有提前谈判，出事后即使证明服务商有责任，也可能被赔偿上限卡住。 4、服务商有没有排除间接损失 AI Agent事故造成的损失，往往不只是恢复数据库这么简单，还可能包括业务中断、客户流失、人工补救成本、第三方索赔、商誉损害、订单丢失、合同违约责任。 但很多合同会排除间接损失、利润损失、商誉损失和业务中断损失。企业要追偿，就必须区分哪些损失属于直接恢复成本，哪些属于被合同排除的间接损失，并提前准备证据。 （三）这一条线的核心判断 企业能不能追偿，首先看服务商有没有“说过它会拦住这种事”。 如果服务商从未承诺相关安全护栏，合同又明确要求用户自行备份、审查、控制权限，并且排除了高风险场景，企业追偿难度会比较大。 但如果服务商明确承诺高危操作需要确认、只读模式不会执行破坏性动作、生产环境有保护机制，而系统实际放行了删除动作，企业的追偿基础就会明显增强。 三、第二条线：再看权限，企业到底给了Agent什么能力 （一）Agent能删库，通常是因为它拿到了足够危险的权限 AI Agent能删库，往往不是因为它“像人一样聪明”，而是因为它拿到了可以删库的凭证和权限。模型本身不会凭空删除数据库，它必须通过某个工具、某个Token、某个API、某个云平台账号去执行动作。 这也是Agent事故和普通AI输出错误最大的区别。普通AI回答错了，风险主要停留在内容层；Agent一旦接入工具链，风险就发生在“模型判断+工具调用+权限配置+平台接口”的结合处。 从法律责任角度看，权限是谁配置的、谁开放的、是否符合最小权限原则，会直接影响过错比例和因果关系判断。如果企业把生产环境Token放在Agent可访问范围内，且这个Token可以执行删除数据库、删除卷、清空备份等高危动作，服务商当然未必因此免责，但企业自身的管理过错也会被放大。 （二）企业自身最容易被追问的五个问题 1、为什么Agent能访问生产环境Token 测试环境任务为什么能找到生产环境凭证？生产凭证是否被写入代码库、环境变量、配置文件或共享文档？Agent是否有权限读取这些位置？ 如果企业没有区分测试环境和生产环境，把生产Token暴露在Agent可读取范围内，后续索赔时很容易被反问：企业是否已经尽到基本安全管理义务。 2、为什么这个Token能执行删除数据库这类高危动作 一个用于常规配置、查询或部署的Token，为什么可以删除数据库、删除卷、删除备份、修改生产资源？是否可以按最小权限拆分？是否存在只读Token、环境级Token、短期Token、一次性Token？ 如果Token本身权限过大，企业自身过错会被明显放大。 3、为什么没有隔离生产环境和测试环境 Agent本来只是处理测试环境任务，却能影响生产环境，通常说明环境隔离存在问题。生产、测试、预发、开发环境是否共用云资源、卷、数据库、账号或权限？是否共享同一组Token？是否存在跨环境误操作的可能？ 环境隔离做不好，Agent的一次错误判断就可能直接打穿生产系统。 4、为什么没有设置人工审批 删除、清空、覆盖、迁移、重启、部署、权限变更、数据库操作，本来就属于高危操作。企业如果允许Agent在没有人工确认的情况下直接执行这类动作，后续很难完全把责任推给服务商。 至少在生产环境中，高危操作应当强制人工确认，并留下可审计记录。 5、为什么没有异地或离线备份 如果备份和源数据在同一权限范围、同一卷、同一账号或同一删除动作下被同时清掉，那就说明备份设计本身有问题。真正有效的备份，应当能抵抗误删、恶意删除、账号泄露和系统故障，而不是和源数据一起暴露在同一个高危操作里。 （三）这一条线的核心判断 企业自己有过错，不等于服务商当然无责。但企业的权限配置、环境隔离、审批机制和备份设计，会影响责任比例。 真正要看的不是“谁最蠢”，而是谁控制了哪个风险点，谁违反了哪个安全义务，谁最有能力避免损害发生。Agent事故往往不是单点故障，而是多层防线同时失效。 四、第三条线：再看护栏，Agent的安全机制有没有真正发挥作用 （一）不要只问AI为什么猜错，要问护栏为什么没拦住 AI Agent事故里，最值得审的不是“AI为什么会猜错”，而是系统为什么允许它把猜测直接变成不可逆动作。 企业使用Agent工具，本来就是因为它能执行任务。但“能执行任务”不等于“可以执行不可逆破坏性操作”。如果产品宣传或合同文件中强调只读模式、Plan Mode、安全护栏、人工确认、沙箱隔离，那么事故发生后真正要审的是：这些机制有没有实际生效。 很多Agent产品现在的安全逻辑，仍然高度依赖提示词、规则说明或系统指令。问题是，自然语言规则不是充分的生产级安全措施。让模型“不要删除”“不要猜测”“不要未经授权操作”，本质上只是行为建议，不是强制控制。真正有效的控制，应当落在权限、工具、接口和审批层面。 （二）提示词规则不能替代技术护栏 生产级Agent安全机制，至少应当包括几类技术控制。 1、权限隔离 Agent默认不应拥有生产环境写权限，更不应拥有删除数据库、删除备份、修改云资源、推送部署等高危权限。 2、只读沙箱 开发、调试、分析任务应尽量在只读环境中进行。即使Agent理解错任务，也不应能够影响真实生产数据。 3、高危API黑名单 删除、清空、覆盖、迁移、权限变更等高危接口，应当默认限制Agent调用，至少应要求单独审批。 4、生产环境默认不可写 生产环境不应成为Agent默认工作空间。只有经过明确授权、审批和日志记录，Agent才可进入生产环境。 5、二次确认和人工审批 对不可逆操作，应要求人工明确确认，并记录确认人、确认时间、操作内容和影响范围。 6、操作冷却期 对于删除数据库、删除备份、销毁云资源等极端高危动作，可以设置延迟执行、撤销窗口或冷却期，避免一次错误调用立即造成不可恢复后果。 7、审计日志 所有提示词、工具调用、API请求、模型输出、执行结果，都应完整留存。没有日志，就很难谈追责。 （三）追偿时怎样转化这个问题 如果服务商声称产品具备安全护栏，企业应当要求其说明：护栏设计是什么，触发条件是什么，事故发生时是否启用，为什么没有拦住，相关版本是否存在已知缺陷，事故后是否有补丁或整改。 如果历史上已有用户反馈只读模式失效、Plan Mode下仍执行非只读工具、Agent自动执行高危命令等情况，这些材料不当然证明个案责任，但可以作为产品风险曾被反映过的背景材料。服务商是否及时修复、提示用户、限制高危功能，会影响责任评价。 五、第四条线：不要只盯AI工具商，云平台和基础设施也可能在责任链里 （一）Agent事故通常不是一个主体造成的 Agent执行了动作，但动作要通过云平台API落地。Agent找到了Token，但Token权限是否过大，要看权限体系设计。Agent发起删除，但云平台是否有二次确认、延迟删除、回收站、备份隔离，也要审查。 所以，Agent事故不能只盯AI工具商。模型方、Agent工具商、云平台、数据库服务商、企业自身，都可能处在责任链里。 企业如果一上来只选一个对象发律师函，很可能漏掉真正关键的技术环节。更稳妥的做法，是先还原完整技术链：模型输出了什么，Agent调用了什么工具，工具用了哪个Token，Token访问了哪个API，API删除了哪些资源，云平台有没有拦截，备份为什么无法恢复。 （二）云平台责任可以从五个角度看 1、服务协议和产品文档 云平台是否承诺数据备份、恢复能力、生产保护、高危操作提示、删除保护机制。如果有承诺，却在事故中没有实现，可能形成责任基础。 2、权限设计 API Token是否可以按最小权限配置，是否存在只读、资源级、环境级、短期Token，是否可以禁止删除类操作。如果平台只提供过宽权限，导致一个Token即可执行远超用途的高危操作，责任评价会发生变化。 3、危险操作确认 删除生产数据、删除卷、删除备份这类动作，是否应有二次确认、延迟删除、回收站机制、冷却期或管理员审批。不同平台的设计水平不同，但如果平台宣传自己适合生产环境，就应有相应的高危操作保护机制。 4、备份机制 所谓备份是否能够抵抗误删、恶意删除、账号泄露和系统故障。备份如果和源数据处在同一删除路径下，可能只是快照，不是真正意义上的灾备。企业在采购云服务时，也应把备份隔离、恢复演练和删除保护写进审查清单。 5、事故响应 事故发生后，云平台是否及时协助恢复数据、导出日志、固定证据、说明API请求链路。如果平台响应不及时，导致损失扩大，也可能进入责任讨论。 （三）这一条线的核心判断 AI Agent事故不能只找“一个背锅对象”。工具商、模型方、云平台、企业自身都可能控制了某个风险点。 企业要追偿，应当先还原完整技术链，而不是先确定一个情绪上的责任对象。只有技术链还原清楚，才能判断合同责任、侵权责任、过错比例和损失因果关系。 六、第五条线：最后看证据，索赔最难的不是讲道理，而是证明损失和因果关系 （一）AI的“忏悔书”不是最关键证据 AI承认自己错了，听起来很有冲击力，但索赔时真正关键的不是这句话，而是证据链。 企业需要证明：谁发起调用，调用了哪个工具，使用了哪个Token，调用了哪个API，删除了哪些资源，是否有人工确认，哪些数据无法恢复，损失如何计算，服务商或平台的哪项违约、产品缺陷或安全失效与损害之间存在因果关系。 没有这些证据，企业很难把“AI犯错”转化成“某服务商应当赔偿”。 （二）企业应当第一时间固定六类证据 1、合同和产品文档 包括服务协议、企业采购合同、功能说明、安全承诺、版本发布说明、销售材料、操作文档。它们用来证明服务商承诺过什么。 2、权限和凭证记录 包括API Token权限、创建时间、使用范围、访问日志、是否具备删除数据库或云资源权限。它们用来证明高危权限从哪里来。 3、Agent操作日志 包括提示词、上下文、工具调用、执行命令、API请求、模型输出、执行结果。它们用来证明Agent到底做了什么。 4、云平台日志 包括请求时间、IP、账户、API方法、资源ID、删除对象、恢复记录。它们用来证明删除动作如何落地。 5、备份和恢复记录 包括备份位置、备份频率、备份隔离方式、恢复结果、丢失范围。它们用来证明损害能否恢复以及损失范围。 6、损失证据 包括数据恢复成本、业务中断时间、客户损失、第三方索赔、人工补救成本、违约支出、外部专家费用。损失没有证据，索赔金额很难站得住。 （三）这一条线的核心判断 AI Agent事故中，企业真正要赢的不是舆论，而是证据链。谁先把日志、权限、合同和损失固定住，谁后续才有谈判和索赔空间。 七、企业能不能向服务商追偿：不是一定能，也不是一定不能 （一）更可能成立追偿的情形 如果出现以下情形，企业向服务商或相关供应商追偿的基础会相对更强： 1、服务商明确承诺高危操作需要人工确认，但系统实际绕过或失效； 2、服务商明确承诺只读模式、Plan Mode、安全护栏或生产保护，但产品未按承诺运行； 3、服务商未充分披露Agent可能执行破坏性工具调用的风险； 4、服务商已知类似安全问题但未修复、未提示、未限制； 5、云平台备份、删除确认、权限管理与其产品承诺明显不符； 6、事故日志能够清楚证明损失由某项产品缺陷、服务违约或安全机制失效直接导致。 这些情形下，企业不应只停留在内部复盘，而应系统整理合同、日志、权限和损失材料，准备谈判、索赔或争议解决。 （二）追偿难度较大的情形 1、企业主动把生产数据库Token暴露给Agent； 2、企业没有区分测试环境和生产环境； 3、企业未落实最小权限和人工审批； 4、企业没有任何离线备份或异地备份； 5、合同中明确排除高风险场景使用； 6、合同中明确要求用户自行审核、备份并承担执行结果； 7、企业无法证明损失范围或损失与服务商行为之间的因果关系。 这些情形并不代表服务商一定无责，但会显著削弱企业索赔的谈判地位和诉讼基础。 （三）最终判断要回到六个因素 AI Agent删库后，不是一定能赔，也不是一定追不了。真正要看的，是合同承诺、权限配置、安全护栏、云平台设计、证据链和损失范围。 企业真正该做的，不是出事后才去问“能不能告”，而是在使用Agent之前就把责任边界和证据机制设计好。 八、企业以后使用AI Agent，合同和内部控制至少要补齐 （一）合同里至少补六类条款 1、高危操作定义 合同应明确哪些行为属于高危操作，包括删除、覆盖、部署、迁移、清空、推送、重启、权限变更、数据库操作、云资源删除、备份删除等。 2、人工确认机制 高危操作必须取得明确、可审计的人工批准。确认记录应当包括确认人、确认时间、操作内容和影响范围。 3、权限边界 Agent默认不得访问生产凭证、生产数据库和生产云资源。确需访问的，应当单独授权、限时授权、最小权限授权。 4、安全护栏承诺 服务商应说明只读、沙箱、审批、拦截、冷却期、回滚机制如何生效，而不能只用概括性的“安全可靠”表述。 5、日志导出和事故协助 出现事故后，服务商应配合导出调用链、模型输出、工具调用、系统日志、版本信息和配置记录。 6、赔偿与责任限制例外 数据删除、重大安全事故、违反安全承诺、故意或重大过失，不宜简单适用低额赔偿上限。否则合同看似有赔偿条款，真正出事时却赔不了多少。 （二）内部控制至少补六项 1、生产环境和测试环境隔离 Agent默认只能进入测试、开发或沙箱环境，不得直接操作生产环境。 2、Agent最小权限 按任务给权限，不按账号给全权。能只读就不写入，能临时授权就不长期授权，能限制资源范围就不开放全账号。 3、API Token分级和短期化 Token应按用途、环境、权限等级拆分，避免一个Token同时具备查询、写入、删除、部署、管理全部权限。 4、高危操作人工审批 删除、清空、覆盖、迁移、生产部署、权限变更等动作，应强制人工审批。 5、离线备份和异地备份 备份应与源数据隔离，至少要能抵抗误删、恶意删除和账号泄露。只有能恢复的备份，才是真备份。 6、Agent全量操作日志留存 提示词、工具调用、API请求、模型输出、执行结果、人工确认记录都要留存。没有日志，就无法追责。 第一时间获取AI领域合规解读、政策动态与实操指南，助您更高效地识别风险、理解规则、推动合规落地。 也欢迎您转发、转载本文，让更多有需要的朋友及时看到。
夜雨聆风