AI企业法律风险地图(三十八):Agent误操作、自动删库、越权调用,责任怎么认定?一、Agent事故的核心，不是“答错了”，而是“做错了”
（一）Agent事故和普通AI输出错误不是一类风险
普通AI输出错误，通常表现为回答错误、生成虚假内容、判断不准、推荐错误、总结遗漏、生成内容侵权。信息错误当然也可能造成损失，例如客户采纳错误合同审查意见、发布错误广告文案、依据错误风控判断作出业务决定。但在多数场景下，AI仍然停留在“输出建议”“生成内容”“辅助判断”的层面。Agent可能删除数据库，修改代码仓库，自动发送错误邮件，自动批准订单，自动取消交易，自动付款，自动封禁账号，自动修改服务器配置，自动调用外部API，自动下载或上传敏感文件，自动访问无权限数据，自动执行错误脚本。行为错误的损害更直接，也更难用一句“仅供参考”免责。因为当Agent已经接入数据库、邮件系统、支付系统、代码仓库、云服务器、CRM、ERP、OA、工单系统、生产系统时，它不再只是一个聊天机器人，而是一个可以调动企业数字资源的自动化执行主体。（二）Agent责任判断要回到四个核心问题
Agent事故发生后，不能只问“AI为什么会这么做”。更关键的是四个问题。Agent能删库、能付款、能发邮件、能操作代码仓库，不是天然发生的。通常是客户或供应商配置了账号、密钥、API、角色和权限。如果Agent没有生产部署权限，它不能把错误代码推到生产环境。所以，权限是谁给的、怎么给的、有没有审批、有没有限额、有没有期限，是责任认定的第一入口。Agent能做什么、不能做什么，是否可自动执行，是否必须人工确认，是否禁止高风险动作，需要在产品设计、合同约定和客户配置中明确。如果合同约定只用于内部辅助，客户却把它接入生产系统自动执行，客户风险会明显增加。如果供应商产品默认支持高风险自动执行，但没有说明边界，也没有提供安全机制，供应商风险也会增加。删除数据、修改生产环境、对外发送、资金支付、正式审批、账号封禁等动作，是否需要人工二次确认，决定事故责任大小。如果系统未经确认自动执行高风险动作，供应商和部署方都要解释为什么允许自动执行。如果客户明确关闭确认机制，或者明知高风险仍授权全自动执行，客户责任会增加。如果没有日志，没有调用链，没有提示词记录，没有模型版本记录，没有工具调用记录，没有权限验证记录，责任认定会非常困难。必须还原：谁下的指令，Agent如何理解，调用了什么工具，使用了什么权限，是否经过确认，实际执行了什么，能否回滚。（三）Agent治理的本质是权限治理、流程治理和证据治理
企业上线Agent，不能只让业务部门测试“能不能提高效率”，也不能只让技术团队评估“模型能力够不够”。法务、合规、信息安全、IT、业务负责人和采购都要参与。权限治理：Agent能访问什么、能修改什么、能删除什么、能对外发送什么、能不能操作生产环境。流程治理：哪些动作必须人工确认，哪些动作只能生成草稿，哪些动作可以低风险自动执行，哪些动作必须禁止。证据治理：输入、输出、提示词、模型版本、工具调用、权限验证、人工确认和执行结果能不能完整留痕。这三个问题没有解决，Agent越智能，事故越难控。二、先判断Agent到底被授权做什么
（一）Agent不是一个统一概念
市场上很多产品都叫Agent，但风险等级完全不同。有些Agent只是任务规划助手，只能帮用户拆解任务、生成步骤、提出建议。有些Agent只是调用搜索、知识库和文档工具，帮助用户检索信息、总结材料、生成报告。有些Agent可以调用企业内部系统，例如CRM、工单系统、OA、知识库、文件系统。有些Agent可以自动操作数据库、邮件、代码仓库、云平台。有些Agent可以自动执行完整业务流程，例如自动处理客户投诉、自动更新订单状态、自动审批报销、自动生成并发送通知、自动修改服务器配置。这些产品都可能被称为Agent，但法律风险完全不同。一个只读型文档问答Agent，主要风险是回答错误和信息泄露。一个可以执行SQL的数据库Agent，风险就包括误删、误改、越权查询和数据破坏。一个可以操作付款接口的财务Agent，风险直接进入资金安全。一个可以部署代码的研发Agent，风险进入生产系统稳定性。因此，Agent合同和审查不能只看产品名称，要看它被授权做什么。（二）Agent至少可以分为四级
1、一级：只读型Agent
只读型Agent只能读取信息、检索资料、生成建议，不能修改系统。例如内部知识库助手、文档问答助手、合同摘要助手、制度查询助手。这类Agent的主要风险是输出错误、引用错误、越权读取和数据泄露。责任重点是知识库权限、检索范围、输出提示、人工复核和日志。2、二级：半自动型Agent
半自动型Agent可以生成操作建议、草拟邮件、生成SQL、生成审批意见，但必须人工确认后执行。例如客服回复草稿、合同审查意见、代码建议、报表生成建议、审批意见草案。如果系统只是生成草稿，客户人员复核后发送，客户责任会增加。如果系统表面要求确认，但确认界面没有展示关键风险，或者实际执行内容与确认内容不一致，供应商仍可能承担责任。3、三级：受限执行型Agent
受限执行型Agent可以在特定范围内自动执行低风险动作。例如创建待办、生成工单、分类邮件、更新非关键标签、自动归档文件、同步普通状态字段。低风险动作要有范围限制、频率限制、对象限制、权限限制和回滚机制。如果所谓低风险动作实际可以影响客户权益、数据完整性或业务流程，就不能简单按低风险处理。4、四级：高风险执行型Agent
高风险执行型Agent可以操作生产系统、数据库、资金、审批、客户账户、代码仓库、云服务器或外部平台。例如自动运维Agent、财务付款Agent、销售自动跟进Agent、代码部署Agent、数据库管理Agent、自动化风控Agent。默认关闭高危权限、人工强确认、操作限额、日志防篡改、备份和回滚、应急停止按钮，都是基本要求。（三）风险等级越高，责任要求越重
只读型Agent出错，主要是输出责任和数据访问责任。受限执行型Agent出错，要看权限和执行范围是否合理。高风险执行型Agent出错，要看是否有强制人工确认、审批流、日志、回滚和应急机制。同样是“Agent误操作”，责任判断不能一概而论。如果Agent只是生成删除建议，客户管理员确认后手动删除，重点看客户确认和操作。如果Agent直接自动删除数据库，重点看系统设计、权限配置、确认机制和日志。如果Agent本来只被允许创建工单，却越权调用删除接口，重点看权限隔离和系统缺陷。（四）合同和产品说明必须写清Agent等级
真正能决定责任的是：Agent能访问什么系统、使用什么账号、调用什么工具、执行什么动作、是否人工确认、日志如何保留、异常如何回滚。三、Agent事故常见类型
（一）自动删库和数据破坏
这类事故最严重，因为它直接影响数据安全和业务连续性。清空生产数据库，可能造成系统瘫痪、客户投诉、交易中断、监管风险。误删备份或清理日志，还会让后续恢复和责任认定更加困难。这类事故审查重点是：Agent是否拥有删除权限，是否能操作生产环境，是否有备份，是否有二次确认，是否有危险命令拦截，是否有回滚机制。（二）越权访问和越权调用
这类事故容易引发数据安全、商业秘密、个人信息和客户合同违约风险。例如一个多租户Agent在回答A客户问题时调用了B客户知识库，可能构成严重保密事件。再如Agent为了完成任务，把客户文件传给外部插件或第三方API，可能涉及数据出境、个人信息共享、客户合同违约。越权事故通常不是模型“答错”，而是权限隔离、访问控制和工具调用边界出了问题。（三）错误对外发送
AI客服错误承诺退款，消费者可能据此主张企业履行。Agent向客户发送错误报价，可能引发合同成立、缔约过失或商业信誉损害争议。Agent群发敏感文件，可能造成商业秘密泄露和个人信息泄露。错误对外发送的责任审查重点是：Agent是否被授权外发，外发前是否人工确认，收件人和内容是否展示清楚，客户是否能撤回或更正，供应商是否提供必要拦截机制。（四）错误交易和付款
财务、采购、电商、供应链、金融业务中的Agent尤其要谨慎。如果Agent可以操作资金、订单、退款、发票、采购审批，就必须设置金额限制、审批层级、收款方校验、异常拦截和人工确认。（五）代码和运维事故
这类事故需要重点看开发、测试、生产环境隔离和人工审批机制。研发类Agent不能直接越过代码审查、测试、CI/CD审批、生产发布流程。如果Agent生成代码只是建议，开发人员审核后提交，责任边界与自动部署不同。如果Agent直接提交并发布到生产环境，供应商和客户都要说明为什么允许自动部署。（六）业务流程误判
这类事故不一定造成系统损坏，但可能影响人的权益、客户关系和业务公正性。业务流程类Agent不能只关注效率，还要关注可解释、申诉、人工复核和纠错机制。四、供应商什么时候要承担责任
（一）产品默认权限过大
如果供应商提供的Agent默认拥有高权限，默认可删除、修改、发送、付款、审批，默认可访问生产系统，默认无二次确认，默认无操作限制，默认无日志追踪，供应商产品设计风险较高。Agent产品不应以“客户可以自己配置”为由，默认开放高危权限。只读优先，草稿优先，人工确认优先，低权限优先，沙箱优先。高危功能应默认关闭，由客户单独申请、单独授权、单独确认。如果供应商为了突出自动化能力，把删除、付款、审批、外发、部署等高风险能力默认打开，后续事故中很难完全免责。（二）没有合理安全机制
供应商应根据Agent能力提供必要安全机制，例如：如果这些机制缺失，供应商可能承担产品设计和服务违约责任。尤其是供应商面向企业客户提供可执行Agent时，不能只交付“能调用工具”的能力，还要交付“可控调用工具”的能力。Agent能不能控制风险，是产品能力的一部分，不是客户额外承担的全部责任。（三）未充分提示Agent风险
供应商如果没有说明Agent可能调用工具，Agent可能执行错误操作，客户应限制权限，高风险动作应人工确认，不得将测试版本接入生产环境，不得将普通Agent用于资金、医疗、安全、关键业务自动执行，客户可能主张供应商未尽提示义务。对于高风险功能，应在合同、产品文档、后台配置页面、权限申请页面、高风险操作确认页面反复提示。例如客户给Agent开放数据库写权限时，系统应提示“该权限可能导致数据被修改或删除，建议仅在测试环境使用，并配置备份和二次确认”。（四）销售或产品宣传过度承诺
如果供应商宣传Agent可以全自动接管运维，可以替代人工审批，可以自动管理数据库，可以自动做销售和付款，无需人工干预，越用越聪明不会出错，后续事故发生时，供应商难以完全免责。Agent销售宣传必须与合同、产品说明和风险提示一致。不能销售阶段说“自动化闭环”，合同阶段写“仅供辅助参考”。不能演示时展示自动删改数据库，实际出事时说客户不应开放权限。不能宣传“无人化运维”，却没有提供生产变更审批、回滚和日志机制。（五）系统缺陷直接导致事故
如果事故来自供应商系统缺陷，供应商承担责任的可能性较高。如果客户已经按照说明配置权限和确认机制，但系统仍然绕过限制执行高风险操作，供应商责任明显。如果日志缺失是因为供应商日志模块故障，供应商也很难要求客户证明完整操作过程。五、客户什么时候要承担责任
（一）客户授予了过高权限
如果客户给Agent配置管理员账号，开放生产数据库写入权限，提供真实支付权限，开放全量客户数据，配置可删除备份的权限，提供跨系统通用密钥，让Agent使用个人高权限账号，未按供应商要求设置角色权限，事故源于客户授权过大，客户自身责任明显增加。客户不能把所有系统都接给Agent，再要求供应商承担全部后果。企业内部应当禁止使用个人管理员账号接入Agent。应使用专用服务账号，并按最小权限原则配置访问范围。对生产系统、资金系统、客户数据系统、代码仓库、云平台，应当单独审批。（二）客户关闭或绕过安全机制
客户如果关闭二次确认，关闭审批流程，关闭异常拦截，关闭日志，跳过测试环境，允许Agent直接操作生产环境，扩大自动执行范围，跳过供应商建议的安全配置，这些行为通常会减轻供应商责任。例如供应商默认要求付款前人工确认，客户为了效率关闭确认，导致Agent错误付款。例如供应商建议先在沙箱环境测试，客户直接接入生产数据库。例如供应商提供白名单机制，客户直接允许Agent调用所有API。（三）客户超范围使用Agent
客户超范围使用Agent，导致损失，不应全部由供应商承担。合同约定低风险流程，客户用于付款、风控、医疗、安全生产。Agent适用范围越高风险，对客户内部控制要求越高。客户如果把低风险产品用于高风险业务，必须自己承担相应风险。（四）客户未履行内部管理义务
Agent进入企业系统后，客户不能把内部控制责任全部转移给供应商。如果客户没有备份，Agent误删后无法恢复，损失扩大部分可能与客户管理缺失有关。如果客户没有员工培训，业务人员用模糊指令要求Agent“清理无用数据”，导致误删，客户也要承担管理责任。如果客户没有异常监控，Agent持续错误执行多个小时，客户没有及时停止，损失也可能扩大。（五）客户业务人员错误指令
用户给Agent错误目标，上传错误文件，要求删除“无用数据”但范围不清，要求“清理数据库”但未限定表，要求“通知所有客户”但未审核内容，要求“自动处理所有待办”但未确认规则，都可能导致事故。客户应对自己人员的指令、审批和使用行为承担管理责任。例如不能使用“清理一下”“处理掉”“全部执行”“自动搞定”这类模糊指令。对于删除、付款、审批、外发、生产变更，应使用结构化表单或限定参数，而不是完全开放自然语言命令。六、上游模型和工具提供方什么时候负责
（一）Agent通常不是单一系统
不能只说“Agent出错”，要看错误发生在哪一层。是模型理解错了任务，还是工具调用框架把参数传错了？（二）基础模型错误不一定直接导致上游责任
如果基础模型只是生成建议，应用供应商决定如何把建议转成工具调用，客户决定是否允许自动执行，那么上游模型方未必直接对最终损失负责。例如基础模型生成了“建议删除重复数据”的文本，应用供应商把它解析成删除命令，客户系统又允许自动执行。最终删库事故不一定由基础模型方直接承担。上游模型方责任通常取决于其合同承诺、API服务条款、模型输出责任限制、版本变更通知和是否存在明显服务缺陷。（三）工具或插件缺陷可能触发责任
如果事故由具体工具缺陷造成，工具提供方可能在其合同责任范围内承担责任。工具提供方如果承诺权限校验、安全拦截、回滚或日志功能，却没有实现，可能承担相应责任。但客户通常仍会先向直接合同相对方主张，再由应用供应商向上游或工具方追偿。（四）应用供应商要管理上游依赖
七、人工确认能不能免责
（一）人工确认是Agent责任分配的核心
Agent最重要的风控机制之一，就是高风险动作前人工确认。没有人工确认，事故责任通常更容易指向系统设计和权限配置。尤其是高风险执行型Agent，如果没有强制确认机制，供应商和客户都要解释为什么允许自动执行。（二）人工确认必须是真确认
展示对象、金额、收件人、数据表、文件路径、代码分支。如果用户根本不知道Agent将删除哪些数据、发送给谁、付款多少，所谓确认意义有限。例如确认页面只显示“是否继续任务”，但不显示即将删除哪些表、影响多少行数据，这不是真正有效确认。（三）人工确认不能无限转移责任
如果系统信息展示错误，风险提示不充分，确认界面误导，Agent实际执行内容与确认内容不一致，高风险操作被拆成多个低风险步骤绕过确认，客户人员没有专业能力理解确认内容，供应商仍可能承担相应责任。例如用户确认的是“删除测试数据”，Agent实际删除了生产数据。用户确认的是“发送给内部测试群”，系统实际发给全部客户。用户确认的是“部署到测试环境”，实际部署到生产环境。这种情况下，即使有确认记录，也不能当然免除供应商责任。（四）合同中应区分人工确认前和人工确认后
八、权限控制是Agent合同的核心条款
（一）Agent权限不能笼统授权
如果合同只写“接入客户系统”，后续很难判断Agent是否有权调用某个接口、读取某类数据或执行某项动作。（二）最小权限原则应写进合同
默认不得执行资金、审批、处罚、账号封禁等高风险动作。供应商也可以防止客户随意开放高危权限后把损失全部推给自己。（三）权限应分层管理
删除、付款、审批、生产部署等高风险权限，应由业务、IT、安全、法务或合规共同确认。（四）权限变更要留痕
如果Agent事故发生后，客户无法说明为什么给Agent开放某项权限，责任会更难控制。如果供应商无法证明权限是客户主动配置或确认的，也很难把责任全部归于客户。九、日志和可追溯性决定能不能认定责任
（一）没有日志，责任很难说清
（二）Agent日志至少应记录十类信息
对于高风险Agent，还应记录环境信息，例如测试环境还是生产环境、操作对象、影响范围、操作前后状态、调用账号、IP、时间戳。这些日志不仅用于责任认定，也用于安全审计和事故恢复。（三）日志不能被Agent自己随意删除
Agent如果有权限删除自己的操作日志，风险极高。尤其是自动删库、越权调用、错误付款、生产部署事故，日志必须独立于Agent执行权限。否则Agent误操作后把日志也删了，事故调查会陷入困境。（四）日志也涉及数据合规
但在争议、审计、安全事件期间可以依法依约延长保留。因此，Agent合同不能只写“完整记录日志”，还要写明日志用途、保留期限、访问人员、调取条件、争议保全和删除机制。十、Agent事故后的应急处理
（一）第一步：立即停止自动执行
客户和供应商应立即暂停Agent任务，冻结高风险权限，关闭外部接口，暂停自动付款、发送、删除、部署等功能，切换人工流程。例如Agent正在持续发送错误邮件，应立即关闭外发权限。Agent正在执行批量删除，应立即冻结数据库写入权限。（二）第二步：保护现场和证据
不要在未备份证据前就覆盖系统、删除日志、重置配置。（三）第三步：评估损害范围
（四）第四步：执行恢复和减损
如果任何一方拖延，导致损失扩大，都可能影响责任分配。（五）第五步：责任复盘
Agent事故通常不是单点问题，而是产品设计、权限管理、人工确认、日志、培训和合同边界共同失效。十一、合同中如何设计Agent事故责任条款
（一）Agent能力说明
如果Agent可以调用邮件、数据库、支付、代码仓库、云平台，必须逐项列明。（二）权限和账号条款
（三）高风险动作条款
合同可以约定：未经客户书面确认，不得开启高风险自动执行；客户开启后，应承担相应配置和审核责任；供应商仍应保证系统按确认内容执行并保留日志。（四）人工确认条款
要写清确认内容包括操作对象、范围、金额、收件人、文件路径、数据表、生产环境标识和风险提示。（五）日志和审计条款
对于高风险Agent，日志是基础设施，不是可选功能。（六）责任限制条款
如果供应商系统缺陷导致事故，或者供应商明知高风险仍未提供基本安全机制，完全免责很难成立。十二、客户上线Agent前至少问十二个问题
（一）第一问：Agent到底能做什么
它是只读，还是生成建议，还是创建草稿，还是提交审批，还是自动执行，还是操作生产系统。（二）第二问：Agent会访问哪些系统
数据库、邮件、CRM、ERP、OA、代码仓库、云平台、支付系统，任何一个系统都可能改变风险等级。（三）第三问：Agent有什么权限
读取、写入、删除、导出、发送、审批、付款、部署，必须逐项列明。（四）第四问：哪些操作需要人工确认
删除、付款、对外发送、审批、封禁、生产环境变更，原则上都应人工确认。（五）第五问：Agent是否能访问敏感数据
个人信息、客户数据、商业秘密、财务数据、人事数据、源代码，都应纳入敏感数据清单。（六）第六问：是否有测试环境
Agent应先沙箱测试，再灰度上线，最后生产开放。测试环境要尽量模拟真实流程，但不能让测试Agent随意接触真实敏感数据。（七）第七问：是否有操作限额
单次删除上限、单次付款上限、单次发送上限、批量操作限制、频率限制，都应提前设置。（八）第八问：日志是否完整
指令、提示词、模型版本、工具调用、权限验证、人工确认、执行结果，都必须记录。（九）第九问：是否能回滚
数据能不能恢复，代码能不能回滚，配置能不能回滚，任务能不能撤销，邮件能不能撤回，订单能不能取消。（十）第十问：上游工具是否可靠
模型、插件、API、云、数据库工具、邮件工具、支付工具，都可能成为事故源头。客户不能只看Agent前端效果，也要看工具链安全。（十一）第十一问：事故发生后谁处理
供应商联系人、客户系统负责人、法务、信息安全、业务部门、数据保护负责人，都要提前明确。（十二）第十二问：损失怎么分担
供应商系统缺陷、客户配置错误、客户超范围使用、上游工具异常、人工确认失误、日志缺失，都应在合同中有对应责任分配。十三、常见争议场景
（一）Agent删除客户数据库
如果客户授予生产数据库删除权限，并关闭确认，客户责任较重。如果供应商默认开放删除权限，且没有危险命令拦截和回滚机制，供应商责任也会增加。（二）Agent自动发送错误报价
如果合同约定报价必须人工确认，Agent绕过确认自动发送，供应商风险较高。如果客户主动开启自动报价并取消审核，客户责任增加。（三）Agent越权访问其他客户知识库
（四）Agent自动部署错误代码
供应商认为客户允许Agent进入生产CI/CD流程。如果客户允许Agent直接部署生产环境且没有审批，客户责任较重。如果供应商宣传可自动部署并承诺安全，且系统缺少必要检查，供应商责任增加。（五）Agent错误调用付款接口
十四、给AI供应商的可执行建议
（一）不要默认开放高危权限
供应商不要默认开放删除、付款、审批、部署、对外发送、生产环境修改、敏感数据导出、跨系统调用等高危权限。（二）把Agent产品设计成可控系统
Agent产品应当是可控系统，而不是只追求自动化。这些不是附加功能，而是企业级Agent的基本能力。（三）销售不要宣传全自动替代人
Agent可以提升效率，但高风险业务不能简单宣传为无人化。对资金、生产、医疗、法律、金融、人事、数据删除等场景，要强调人工确认和风险边界。不能一边宣传全自动，一边在合同里写全部由客户自行负责。（四）合同要把客户配置责任写清楚
供应商要把自己负责的系统安全机制和客户负责的配置管理边界写清楚。十五、给客户的可执行建议
（一）不要让Agent一开始就进生产环境
（二）不要给Agent管理员权限
应按任务给权限，按系统给权限，按时间给权限，按金额给权限，按数据范围给权限，并定期回收权限。（三）关键操作必须人工确认
（四）上线前做事故演练
十六、Agent责任的本质是权限责任
Agent最大的法律风险不是它会不会思考，而是它能不能执行。所以，Agent不是普通聊天机器人升级版，而是企业数字权限体系中的新主体。Agent能造成多大损失，取决于企业给了它多大权限。很多Agent事故不是AI突然失控，而是权限、确认、日志、边界和管理没有设计好。Agent误操作、自动删库、越权调用后，责任怎么认定，不能只问“AI为什么这么做”，而要问六件事：这六件事说不清，Agent越智能，企业责任越难控。诚邀您关注我的公众号✨
第一时间获取AI领域合规解读、政策动态与实操指南，助您更高效地识别风险、理解规则、推动合规落地。
也欢迎您转发、转载本文，让更多有需要的朋友及时看到。
您的关注与支持，是我持续创作的重要动力。
夜雨聆风