一、Agent产品的风险升级，不在于“会回答”，而在于“会动手”

（一）从生成内容到执行动作，风险性质已经变了

普通生成式AI产品主要输出内容。

回答问题，生成文案，生成图片，整理资料，辅助分析。这类产品当然也有风险，例如输出错误、内容侵权、误导用户、泄露信息，但风险主要集中在“说了什么”“生成了什么”。

Agent产品不一样。

Agent不只是回答问题，还可能进一步执行动作。

它可以读取文件，调用API，发送邮件，提交表单，创建订单，修改配置，删除数据，触发交易，操作第三方平台，甚至在客户生产系统里完成一系列连续动作。

从“输出内容”到“执行动作”，法律风险会明显升级。

因为后果不再只是内容错误，而可能变成真实财产损失、数据损失、交易损失、业务中断、客户对外责任和监管事故。

例如，普通AI助手错误总结一份合同，客户还可以人工复核。

但Agent如果直接把错误结论写进审批系统、自动发送给交易对方、触发付款或提交监管表单，后果就不再停留在“答案不准确”层面。

再如，普通AI生成一封邮件草稿，用户可以选择不发。

但Agent如果自动发送邮件，可能形成对外承诺、泄露商业秘密，甚至引发合同履行争议。

所以，Agent产品的法务审查，不能继续沿用普通聊天机器人、普通SaaS、普通生成式AI的思路。

（二）Agent事故的核心原因，往往不是模型“失控”，而是权限失控

很多Agent事故，并不是因为模型突然变得不可理解，而是因为产品和客户一起给了它过大的权限。

它拿到了不该拿的权限。

调用了不该调用的接口。

执行了没有人工确认的高危动作。

访问了客户生产环境。

写入了真实业务系统。

事后又没有完整日志，无法还原操作链。

这种情况下，双方争议通常会集中在几个问题上：客户是不是授权了？Agent是不是超范围执行？AI企业有没有安全护栏？客户有没有配置最小权限？事故发生前有没有人工确认？发生后能不能回滚？日志能不能证明到底发生了什么？

如果这些问题在产品设计和客户合同中没有提前处理，事故发生后很难靠一句“用户自行负责”解决。

Agent治理的核心，不是只写免责声明，而是提前设计权限、审批、日志、回滚和责任机制。

权限没有设计，Agent越自动化，风险越大。

审批没有设计，Agent越高效，越可能绕过人工控制。

日志没有设计，事故越复杂，越无法分清责任。

回滚没有设计，错误一旦发生，损失会迅速扩大。

（三）Agent产品至少要管住八件事

AI企业做Agent产品，至少要把八件事管住。

第一，权限边界怎么分。只读、写入、修改、删除、发送、付款，必须分开授权。

第二，高危操作怎么列。删除、付款、发送、发布、修改权限、调用生产API等，不能让Agent自由判断。

第三，人工确认怎么设。确认不能流于形式，要让用户看清操作对象、操作内容、操作后果，并留下确认记录。

第四，日志证据怎么留。没有日志，就很难还原Agent到底做了什么。

第五，事故责任怎么分。客户错误配置、供应商产品缺陷、第三方插件故障，责任不同。

第六，客户合同怎么写。不能只写“客户授权Agent使用系统”，要把权限、确认、日志、回滚、事故处理写成条款。

第七，产品功能怎么限制。高危功能不能只靠协议免责，要在产品层面做默认禁用、二次确认、权限分级和异常中止。

第八，第三方模型、插件和平台责任怎么处理。Agent通常是一条技术链，不是一个单点系统。

这八件事处理不清，Agent产品越贴近客户真实业务，事故责任越难控制。

二、先把Agent分级，不能把所有Agent当成同一种产品

（一）不同Agent的风险等级完全不同

不是所有Agent都危险到同一程度。

低风险Agent，通常只做信息检索、资料总结、建议生成，不接入外部系统，不执行写入或删除动作。例如内部知识库问答、会议资料整理、制度检索助手。这类Agent的主要风险是回答错误、引用不准、泄露输入内容。

中风险Agent，可以读取客户文件、查询内部系统、生成待确认邮件、表单、报告，但不能自动提交或发送。例如销售助手生成客户跟进邮件草稿，法务助手生成合同审查意见草稿，财务助手生成报表说明。这类Agent开始接触客户数据，但仍保留人工确认。

高风险Agent，可以调用API、修改客户系统数据、发邮件、下单、提交审批，或者接入CRM、ERP、代码仓库、云平台。这类Agent已经进入客户业务系统，错误操作可能直接影响业务流程。

极高风险Agent，可以删除数据、付款、修改权限、操作生产环境、对外发布内容、自动操作第三方平台账户。这类Agent一旦出错，可能造成不可逆损失。

如果企业把这些Agent都放在同一个产品协议里，用同一套免责声明、同一套责任上限、同一套客户授权条款，风险边界一定不够。

（二）上线前必须完成Agent风险分级

产品上线前，应至少区分六类Agent。

第一，只读型Agent。只读取、查询、总结，不写入、不提交、不删除。

第二，建议型Agent。提供建议、方案、分析，但不生成可执行指令。

第三，草稿型Agent。生成邮件、表单、报告、代码、审批材料，但必须由用户确认后才能发送或提交。

第四，半自动执行型Agent。可以执行部分动作，但高危动作必须人工确认。

第五，全自动执行型Agent。在限定权限和限定场景内，可以自动完成任务。

第六，生产环境操作型Agent。能够接入客户真实生产系统、生产数据库、业务账号、第三方平台或支付系统。

不同等级对应不同控制措施。

权限不同，确认机制不同，日志要求不同，责任上限不同，客户配合义务不同，事故处理要求也不同。

不能用聊天机器人协议覆盖生产环境Agent。

例如，一个只生成邮件草稿的Agent，可以在用户协议中强调辅助生成和人工审核。

但一个能自动发送客户邮件、修改CRM记录、创建订单的Agent，合同必须单独处理权限、确认、日志、回滚、客户内部审批和责任分担。

（三）销售和产品文案必须跟分级一致

Agent产品的销售文案和产品能力必须一致。

如果实际只是辅助建议，不要宣传成“全自动完成业务”。

如果产品默认需要人工确认，不要宣传成“无人值守”。

如果不能操作生产环境，不要暗示可以直接接管客户系统。

如果高危操作默认禁用，不要宣传成“全流程自动闭环”。

否则，后续事故发生时，客户可能依据销售材料主张供应商承诺了更高能力和更高安全保障。

例如，销售PPT写“自动完成客户全流程跟进”，实际产品只是生成跟进建议；客户据此开放邮件和CRM权限后发生误发，供应商再解释“我们只是辅助工具”，就会非常被动。

Agent产品的能力边界，应当同时体现在产品页面、销售材料、技术方案、客户合同、管理员配置页面和用户操作提示中。

三、权限管理必须坚持最小必要原则

（一）Agent事故的根源，很多时候是权限过大

Agent可能接触的权限非常多。

账号密码，API Token，数据库权限，云平台权限，邮件系统权限，代码仓库权限，CRM权限，ERP权限，支付系统权限，第三方平台账户权限。

权限越大，Agent能做的事情越多，事故后果也越重。

如果客户把管理员权限、生产权限、删除权限一次性开放给Agent，出事后责任分配会非常复杂。

客户可能说：供应商没有提醒权限风险。

供应商可能说：客户自己给了最高权限。

真正的问题是，合同和产品有没有要求最小必要权限，有没有禁止默认给高危权限，有没有把不同权限拆开授权。

Agent产品不能以“客户授权使用系统”作为一揽子授权。这个表述太粗，无法覆盖不同操作的风险差异。

（二）权限应拆成六类

Agent权限至少应拆成六类。

第一，能看。

读取文件、读取记录、查询系统、查看知识库、检索数据库。这类权限看似低风险，但也可能涉及商业秘密、个人信息和客户敏感数据。

第二，能写。

创建草稿、填写表单、生成工单、写入待确认内容。这类权限通常还未对外生效，但已经进入客户系统。

第三，能改。

修改配置、修改客户资料、修改订单信息、修改任务状态、修改代码或文档。这类权限可能影响客户业务流程。

第四，能删。

删除文件、删除数据库记录、删除备份、删除账号、删除日志。这类权限风险极高，原则上不应默认开放。

第五，能发。

发送邮件、发布内容、提交表单、发送通知、推送消息、提交审批。这类权限可能形成对外表达或法律后果。

第六，能付。

支付、下单、触发扣款、执行交易、确认订单、提交采购。这类权限直接涉及财产损失和交易责任。

每一类权限都应单独授权，不能把“授权Agent使用系统”写成一揽子授权。

尤其是“能删、能发、能付、能改生产环境”，应当单独确认。

（三）合同中要写明客户的权限配置义务

客户合同中应明确，客户应按照最小必要原则配置权限。

客户不得向Agent提供超出约定用途的权限。

客户不得向Agent开放生产环境高危权限，除非双方另有书面确认。

客户应定期检查、撤销、更新授权。

客户应及时撤销离职员工、变更岗位人员、外包人员的相关权限。

客户应对其自行配置、扩大、共享、泄露权限导致的后果负责。

AI企业应提供权限配置建议、风险提示和产品限制，但客户最终系统权限控制仍应由客户确认和管理。

这类条款不是形式主义。

如果客户将删除权限、付款权限、管理员权限直接交给Agent，又不设置内部审批和备份，事故发生后要求AI企业全部赔偿，就需要回到合同中看客户是否违反了权限配置义务。

四、高危操作必须列清单，不能让Agent自由判断

（一）不可逆高危操作不能交给Agent自行判断

Agent最不能靠自己判断的，是不可逆高危操作。

高危操作包括删除数据、覆盖文件、修改数据库、付款或下单、发送对外邮件、发布公开内容、提交监管、税务、工商、海关等文件、修改用户权限、停用系统、调用生产环境API、推送代码、关闭备份或日志。

这些动作一旦执行，可能难以撤回，可能直接造成损失。

不能把这些事项交给Agent自行判断是否执行。

例如，Agent判断某个文件“可能无用”后自动删除，可能删除客户重要资料。

Agent判断某个邮件“可以发送”后自动外发，可能泄露商业秘密。

Agent判断某个接口“可调用”后写入生产系统，可能造成业务数据错乱。

Agent判断某个订单“符合条件”后自动下单，可能触发财产损失。

高危操作清单，是Agent产品风险治理的基础。

（二）高危操作清单应写进产品规则和客户合同

产品规则中应明确，哪些操作禁止Agent自动执行，哪些操作必须人工确认，哪些操作必须管理员确认，哪些操作需要双人审批。

客户合同中也应明确高危操作定义、高危操作审批流程、客户确认后果、未经确认执行的责任、超范围配置的责任。

不能只在产品说明里轻描淡写。

高危操作应当作为责任分配的核心条款。

例如，可以约定：删除、付款、对外发布、发送邮件、修改权限、调用生产环境API、提交监管文件等操作，均属于高危操作。未经客户授权人员明确确认，Agent不得自动执行。客户自行关闭确认机制、扩大权限或绕过风控导致损失的，由客户承担相应责任。

同时也要写清，如果Agent未经确认执行了高危操作，或者执行内容超出客户确认范围，AI企业不能当然免责。

（三）高危操作要有分级确认机制

高危操作确认不能只有一个“用户同意后执行”的笼统表述。

更合理的是分级。

普通操作，可以自动执行并留日志。例如读取公开信息、整理内部资料、生成待确认草稿。

中风险操作，执行前提示用户确认。例如创建工单、更新非核心字段、生成待提交表单。

高风险操作，必须管理员确认。例如发送对外邮件、修改客户资料、调用关键API、提交业务审批。

极高风险操作，应禁止自动执行或要求双重人工审批。例如删除数据、付款、修改权限、操作生产环境、对外发布正式内容。

生产环境操作，原则上应默认禁用，必须单独书面授权。

这种分级，比一句“用户同意后执行”更有操作性，也更利于事故后责任判断。

五、人工确认不能流于形式

（一）表面确认不能真正降低风险

很多Agent产品表面有确认，实际确认不足。

常见问题包括：确认按钮隐藏很深，用户没有看到具体操作内容，只显示“是否继续”而不显示风险后果，多个操作打包一次确认，用户确认的是草稿但Agent执行的是不同动作，系统没有记录确认过程。

这种确认很难真正降低风险。

事故发生后，客户可能主张：自己没有明确授权具体高危操作，只是点击了一个模糊按钮，并不知道Agent会删除、发送、付款、提交或修改哪些内容。

如果AI企业想依靠“客户已确认”分配责任，就必须确保确认机制本身清楚、具体、可证明。

（二）有效人工确认至少要包含四个要素

有效人工确认至少要包含四个要素。

第一，操作对象。

要改哪个文件、哪张表、哪个账户、哪个订单、哪个数据库、哪个客户记录、哪个第三方平台账号。

第二，操作内容。

要删除、修改、发送、提交、付款、发布、调用接口，还是调整权限。

第三，操作后果。

是否不可撤回，是否影响生产环境，是否影响第三方权益，是否产生对外法律后果，是否可能造成数据丢失。

第四，确认记录。

谁确认，何时确认，确认了什么，从哪个账号、哪个IP、哪个页面确认。

少了这些要素，人工确认的证据价值会下降。

尤其是高危操作，确认页面应当尽量展示操作前后的差异、影响范围、不可逆提示和可回滚情况。

（三）合同中应明确客户确认的法律效果

合同中可以约定，客户授权人员确认高危操作后，视为客户同意Agent执行该具体操作。

客户应确保确认人员具有相应权限。

客户不得事后以内部审批不足对抗AI企业，但AI企业明知确认人员无权的除外。

AI企业应确保实际执行内容与确认内容一致。

如果Agent执行超出确认范围的动作，AI企业不能当然免责。

例如，客户确认发送一封邮件给A客户，Agent却发送给A、B、C三个客户；客户确认修改测试环境配置，Agent却修改了生产环境配置；客户确认删除临时文件，Agent却删除了核心数据库记录。这些都不能简单归入“客户已确认”。

人工确认的价值，在于具体确认具体操作，而不是让客户一次性背书所有后果。

六、日志是Agent事故责任分配的核心证据

（一）没有日志，就很难还原Agent到底做了什么

Agent事故后，双方最常争议的是：用户输入了什么指令，Agent理解成了什么任务，调用了哪个工具，使用了哪个权限，有没有人工确认，操作对象是谁，操作前系统有没有提示，操作后是否可回滚。

这些都需要日志证明。

没有日志，AI企业很难证明自己没有违约，客户也很难证明损失由Agent造成。

例如，客户说Agent误删了文件。AI企业需要知道用户是否下达删除指令，Agent是否请求确认，客户是否点击确认，删除对象是什么，是否有回收站，是否有人后续手动删除。

再如，客户说Agent误发邮件。需要看邮件内容是谁生成的，是否进入草稿箱，谁确认发送，是否经过二次编辑，是否由Agent自动发送，还是客户自己点击发送。

日志不是技术附属品，而是Agent事故责任分配的核心证据。

（二）Agent日志至少要记录八类信息

Agent日志至少应记录八类信息。

第一，用户指令。用户原始输入、任务要求、上传文件、上下文信息。

第二，Agent任务拆解过程。Agent如何理解任务，拆分了哪些步骤，准备调用哪些工具。

第三，模型版本。使用的模型、版本、配置、提示词策略。

第四，工具调用记录。调用了哪个工具、插件、接口、系统模块。

第五，API请求和响应。请求时间、请求对象、返回结果、异常信息。

第六，权限使用记录。使用了哪个账号、哪个Token、哪个权限范围。

第七，人工确认记录。谁确认、何时确认、确认内容、确认页面、确认结果。

第八，执行结果和异常信息。执行成功、失败、中止、回滚、报错、重试。

如果涉及客户生产系统，还应记录操作前后状态、资源ID、数据快照或备份信息。

对于删除、修改、发布、付款等高危操作，日志要求应更高。

（三）日志留存要平衡证据和合规

Agent日志不能完全不留，否则无法举证。

也不能无限留存所有敏感数据，否则可能违反数据最小化、个人信息保护和客户保密要求。

合同中应约定日志范围、保存期限、访问权限、脱敏要求、导出机制、争议时调取流程、服务终止后的日志处理。

企业客户尤其会关心，日志是否包含商业秘密、个人信息和生产系统数据。

所以，日志机制要分层。

普通操作可以记录摘要和操作结果。

高危操作应记录完整操作链。

涉及敏感信息的内容应尽量脱敏。

争议发生时，双方按照约定流程调取原始日志或必要证据。

服务终止后，日志应按合同约定删除、返还、匿名化或保留必要期限。

七、事故处理要有回滚、止损和通知机制

（一）事故发生后，第一目标是先止损

Agent事故发生后，第一目标不是争谁对谁错，而是先止损。

常见事故包括误删文件、误发邮件、误改配置、误提交表单、误调用API、误下单、误发布内容、误导出数据。

如果没有应急机制，损失会迅速扩大。

误发邮件后，如果不及时撤回或通知接收方保密，泄密范围会扩大。

误发布内容后，如果不及时下架，传播范围会扩大。

误调用API后，如果不及时冻结权限，错误操作可能继续发生。

误删数据后，如果不及时恢复，备份可能被覆盖。

合同和产品都应提前设计暂停、冻结、撤销、回滚、通知、取证、恢复机制。

（二）Agent产品应尽量提供回滚能力

对于可逆操作，应提供撤销机制。

对于修改类操作，应保留操作前版本。

对于删除类操作，应提供回收站或备份恢复。

对于发送和发布类操作，应提供撤回或下架流程。

对于权限变更，应支持一键恢复或管理员回退。

对于API调用，应记录请求并支持中止、补偿或撤销。

对于不可逆操作，原则上不得自动执行，或者必须强确认。

没有回滚能力的操作，应在执行前给出更高等级风险提示。

例如，系统应明确提示“该操作不可撤销”“该操作将影响生产环境”“该操作将向第三方发送信息”“该操作可能触发付款或交易”。

如果产品没有任何回滚能力，又允许Agent自动执行高危操作，事故后AI企业很难解释自己已采取合理安全措施。

（三）事故通知机制要写清

事故通知机制至少要写清十个问题。

谁发现谁通知。

通知时限。

通知内容。

双方应急联系人。

是否暂停Agent权限。

是否保全日志。

是否冻结相关账号或Token。

是否通知第三方平台、监管部门或受影响用户。

是否由客户对外沟通。

是否由AI企业提供技术说明。

没有通知机制，事故后双方容易互相等待、互相推责。

例如，AI企业发现Agent异常调用客户API，但合同没有通知流程，技术团队只在内部排查，没有及时通知客户暂停权限，导致损失扩大。此时，AI企业就可能因未及时通知和止损承担不利后果。

八、客户不能把所有Agent事故都推给AI企业

（一）客户在Agent使用中也有管理义务

客户使用Agent，不是把内部管理责任全部转给AI企业。

客户至少应负责提供合法账号和权限，按最小必要原则配置权限，管理授权人员，审查Agent执行结果，设置高危操作审批，不向Agent提供无关Token或生产权限，及时撤销离职人员权限，建立内部使用规范。

如果客户自己把最高权限交给Agent，又不设置审批和备份，事故后要求AI企业全部赔偿并不合理。

例如，客户直接把管理员账号、支付权限、生产数据库写入权限交给Agent，但没有设置金额上限、操作确认、备份机制。后续发生误操作时，客户自身权限配置和管理过错会成为责任分配的重要因素。

（二）客户原因导致事故的常见情形

客户原因导致Agent事故的情形很多。

客户提供错误指令。

客户上传错误数据。

客户配置过高权限。

客户关闭安全提示。

客户确认了高危操作。

客户未做备份。

客户超出约定场景使用。

客户擅自接入第三方系统。

客户内部人员滥用Agent。

客户未及时响应事故通知。

客户未撤销离职人员权限。

客户将测试环境配置用于生产环境。

客户绕过产品限制自行调用底层API。

这些都应在合同中写入责任排除或责任分担。

如果事故主要由客户上述行为导致，不应全部由AI企业承担。

（三）客户内部管理不能由AI企业兜底

AI企业可以提供产品和安全建议，但不能替客户管理所有内部审批。

不能替客户保证每个员工都正确使用。

不能替客户承担所有业务决策后果。

不能替客户判断每一项发送、付款、发布、删除行为是否符合客户内部制度。

合同中应明确，客户对其业务流程、权限配置、人员管理、内部审批、数据备份和最终决策负责。

AI企业提供的是系统和服务，不是客户内部管理部门。

九、AI企业也不能只靠“用户授权”免责

（一）用户授权不是万能免责牌

客户有管理义务，不等于AI企业可以只靠“用户授权”免责。

即使客户授权Agent使用系统，AI企业仍应确保产品符合合同约定功能和安全承诺。

如果AI企业明知存在重大漏洞却未修复，不能免责。

如果安全护栏形同虚设，不能免责。

如果宣传承诺“高危操作必须确认”但实际没有确认，不能免责。

如果Agent执行了超出授权范围的动作，不能免责。

如果日志缺失导致无法还原事故，AI企业也会很被动。

用户授权的法律效果，取决于授权是否明确、产品是否按授权执行、AI企业是否履行了合理安全义务。

（二）AI企业至少要承担三类义务

AI企业至少要承担三类义务。

第一，产品安全义务。

合理设计权限、审批、风控、日志、回滚和异常中止机制。尤其是对高危操作，不能只靠提示词和免责声明。

第二，合同履行义务。

按照合同约定提供功能、限制、服务和安全措施。合同写了必须人工确认，就必须真实执行；合同写了日志留存，就必须能导出；合同写了高危操作默认禁用，就不能默认开启。

第三，事故协助义务。

发生事故后，协助排查、恢复、导出日志、冻结权限、联系第三方、减少损失。

如果AI企业没有做到这些，不能简单说“客户自己授权的”。

（三）销售过度承诺会放大AI企业责任

Agent产品尤其要避免销售过度承诺。

不要宣传Agent绝不会误操作。

不要宣传Agent可完全替代人工。

不要宣传所有操作都有安全护栏，除非产品确实做到了。

不要宣传接入生产环境没有风险。

不要宣传客户无需配置权限。

不要宣传无人值守全自动处理所有业务。

如果销售材料和实际产品能力不一致，事故后客户很可能主张虚假或误导性承诺。

销售材料、产品文档、官网宣传、合同条款、管理员后台提示，应保持一致。

十、第三方模型、插件和平台责任也要纳入合同

（一）Agent通常不是单一系统，而是一条技术链

Agent产品通常不是单一系统，而是一条技术链。

它可能包括基础模型、Agent框架、插件系统、第三方API、客户系统、云平台、浏览器或自动化工具、数据存储服务。

事故可能发生在任何环节。

基础模型理解任务错误。

插件权限声明不清。

第三方API返回异常。

云平台故障。

客户系统接口变化。

浏览器自动化工具点击错误。

数据存储服务中断。

如果合同只在客户和AI企业之间粗暴分配责任，不考虑第三方依赖，后续争议会很难处理。

（二）AI企业应披露关键第三方依赖

AI企业应向客户披露关键第三方依赖。

例如基础模型供应商、云平台供应商、插件或工具供应商、浏览器自动化组件、外部API服务、向量数据库和存储服务。

如果关键第三方服务中断、限流、变更、下线、调价或出现漏洞，应按合同约定处理。

客户合同中应写明，第三方服务中断是否当然属于供应商违约，供应商是否承担替代和协助义务，损失责任是否受限制。

如果AI企业对客户承诺Agent服务连续可用，但实际上严重依赖单一第三方模型或插件，就应在SLA和责任限制中写清边界。

（三）插件生态要特别审

Agent接入插件后，风险会明显扩大。

插件可能读取、写入、删除、发送、付款。

AI企业应设置插件审核、插件权限声明、插件白名单、客户安装确认、异常停用机制。

插件权限应向客户展示清楚。

客户安装插件前，应看到插件能访问什么数据、能执行什么操作、是否可能写入生产系统、是否会向第三方传输数据。

客户自行安装第三方插件导致事故，不应当然由AI企业承担全部责任。

但如果AI企业官方应用市场上架插件、推荐插件、默认启用插件，或者未审查高危插件权限，AI企业仍可能被追问管理责任。

十一、Agent客户合同中至少要写清十类条款

（一）Agent功能边界

第一类，是Agent功能边界。

要写清Agent能做什么，不能做什么，哪些只是建议，哪些可以执行，哪些需要人工确认。

不能只写“提供智能体服务”。

（二）权限配置

第二类，是权限配置。

要写清最小必要权限、客户授权方式、生产环境权限、Token和API密钥管理、权限撤销机制。

客户自行扩大权限的后果，也要写清。

（三）高危操作清单

第三类，是高危操作清单。

至少包括删除、付款、发送、发布、修改权限、修改数据库、提交表单、调用生产API。

高危操作应当对应确认和审批机制。

（四）人工确认机制

第四类，是人工确认机制。

要写清确认对象、确认内容、确认人员、确认记录、确认后的法律效果。

确认不应只是一个模糊按钮。

（五）日志和审计

第五类，是日志和审计。

要写清日志范围、保存期限、导出方式、访问权限、争议时调取机制。

没有日志，就没有责任链。

（六）回滚和恢复

第六类，是回滚和恢复。

要写清撤销机制、备份机制、版本恢复、删除恢复、不可逆操作限制。

没有回滚能力的操作，应提高确认等级。

（七）客户配合和管理义务

第七类，是客户配合和管理义务。

包括权限管理、人员管理、审批流程、数据备份、结果复核、超范围使用责任。

客户管理义务必须有具体后果。

（八）事故处理

第八类，是事故处理。

包括通知时限、止损措施、暂停权限、日志保全、恢复协助、对外沟通。

事故处理条款越清楚，损失越容易控制。

（九）第三方服务

第九类，是第三方服务。

包括模型供应商、云平台、插件、API、第三方中断和故障责任。

Agent不是单点系统，第三方责任必须写进合同。

（十）赔偿责任

第十类，是赔偿责任。

要写清责任原因、过错程度、损失证明、责任上限、间接损失排除、客户原因排除、重大过错例外。

Agent产品不能轻易接受无上限责任。

十二、Agent产品内部上线前，建议做一次“五类压测”

（一）权限压测

第一类，是权限压测。

只读权限是否真的只读。

测试环境权限是否能误触生产环境。

低权限用户是否能触发高危操作。

Token是否可被Agent误用。

离职人员权限是否能被继续调用。

权限压测的目标，是防止“看起来低权限，实际能做高危动作”。

（二）高危操作压测

第二类，是高危操作压测。

删除、覆盖、付款、发送、发布、修改权限、调用生产接口，都要测试系统是否强制拦截或确认。

不能只在文档里写高危操作需要确认，产品里必须真的拦住。

（三）提示词绕过压测

第三类，是提示词绕过压测。

用户是否可绕过禁止规则。

Agent是否会忽视系统提示。

是否会将建议误执行为动作。

是否会把测试指令作用于真实环境。

是否会被诱导调用未授权插件。

Agent产品不能只防正常使用，还要防绕过和误用。

（四）日志压测

第四类，是日志压测。

能否记录完整操作链。

能否导出。

能否还原人工确认。

能否区分客户指令和Agent自主步骤。

能否记录插件和API调用。

能否记录执行前后状态。

日志压测的目标，是确保事故发生后可以还原事实。

（五）事故恢复压测

第五类，是事故恢复压测。

误删能否恢复。

误发能否撤回。

误改能否回滚。

误调用能否停止。

权限能否一键冻结。

客户和供应商能否快速协同。

事故恢复不是事故发生后才设计的，而应在上线前完成验证。

十三、Agent产品不是不能接入客户系统，但必须先把权限和责任讲清楚

（一）不同权限和不同动作，不能混在一起处理

Agent产品不是不能接入客户系统。

但必须先把权限和责任讲清楚。

只读和可写不同。

草稿和发送不同。

测试环境和生产环境不同。

建议和执行不同。

普通操作和高危操作不同。

人工确认前和人工确认后不同。

这些不区分，Agent事故责任就无法分清。

如果合同只写“客户授权Agent接入系统”，既没有权限边界，也没有高危操作清单，更没有确认和日志机制，出事后很难判断到底是谁的问题。

（二）AI企业不能只把安全写在用户协议里

Agent产品安全不能只写在用户协议里，要做进产品里。

最小权限，高危操作拦截，人工确认，日志留存，回滚恢复，插件审核，事故通知，这些是Agent产品的基本安全底座。

没有产品层控制，合同免责会很薄弱。

如果产品允许Agent直接删除生产数据，合同里再写“用户自行承担风险”，争议中未必能真正保护AI企业。

如果产品宣传有安全护栏，却没有真实执行，高危操作仍然可以绕过，合同条款反而会变成客户追责依据。

（三）客户不能把Agent当成全能实习生随便给权限

客户也不能把Agent当成一个全能实习生，随便给权限、随便接系统、随便放生产环境。

客户要配置权限，要管理人员，要审批高危操作，要备份关键数据，要复核执行结果，要遵守约定用途。

否则，事故发生后，客户自身过错会成为责任分配的重要因素。

尤其是在客户自行扩大权限、关闭安全提示、确认高危操作、未做备份、超范围使用、擅自接入第三方系统的情况下，客户很难要求AI企业承担全部责任。

十四、Agent越接近真实业务系统，越要把权限、审批、日志、回滚和责任写清楚

Agent产品最大的错觉，是把“能执行”当成“能放心执行”。

能发邮件，不等于可以自动对外发。

能删文件，不等于可以拿到删除权限。

能调用API，不等于可以直接接生产环境。

能完成任务，不等于可以跳过人工审批。

能提高效率，不等于可以取消内部控制。

Agent越接近真实业务系统，越要把权限、审批、日志、回滚和责任写清楚。

对AI企业来说，Agent产品的竞争力不只是自动化能力，还包括可控能力、审计能力、止损能力和责任分配能力。

对客户来说，引入Agent不是把业务责任交给AI，而是要重新设计内部权限、审批、复核和事故处理机制。

一个成熟的Agent项目，不应只问“能不能自动完成任务”，还要问：能不能限制权限，能不能识别高危操作，能不能人工确认，能不能留痕，能不能回滚，能不能在事故发生时迅速止损。

Agent真正进入企业业务系统后，技术边界就是法律边界，权限设计就是责任设计。

如果权限给得太大，审批设得太弱，日志留得太少，回滚能力不足，合同责任又写得太粗，Agent越能干，企业风险越大。