当前，在各互联网大厂纷纷推出OpenClaw（一款开源人工智能体框架，俗称“龙虾”）产品、部分企业尝试将其接入生产环境的背景下，“养虾”所面临的法律风险也逐渐被推上前台：“龙虾”与普通大模型应用所面临的法律风险有什么不同？如果“龙虾”在运行过程中，误删数据、错误下单，责任算谁的？如果企业要“养虾”，如何进行合规管理？

3月19日，《每日经济新闻》记者（以下简称NBD）就上述问题，书面专访了北京德和衡（上海）律师事务所人工智能与自动驾驶部主任、高级合伙人白耀华律师。

白耀华律师 图片来源；受访者供图

应遵循“最小必要”原则，并对高危操作设置“人工确认”强制环节

NBD：OpenClaw作为“开源智能体框架”，它和普通大模型应用的法律风险有什么不同？

白耀华：OpenClaw作为“开源人工智能体框架”，其法律风险相较于普通大模型应用更为复杂和前置，核心差异在于其“开源”属性带来的责任主体模糊化，以及“智能体”属性使其从“信息生成者”转变为“行为执行者”，从而引入了操作失控与行为归责的新风险。

具体分析，普通大模型应用（如对话机器人）的法律风险主要集中在生成内容的知识产权侵权、虚假信息传播、个人信息处理合规等方面。而OpenClaw这类框架的风险是复合与升级的：

第一，“开源”带来的责任网络化风险。开源框架允许全球开发者贡献代码、开发插件，这导致安全管理、数据保护的责任主体从单一的运营方扩散到一个松散的生态。《中华人民共和国网络安全法》要求网络运营者制定并落实安全管理制度。在开源生态中，谁是“运营者”？框架的原始开发者、二次开发的企业、插件的提供者，都可能在不同环节承担相应责任，这使得责任界定异常困难。

第二，“智能体”带来的行为性风险。 普通大模型主要是“说”，而智能体框架驱动的应用是“做”——它能自动操作外部系统（如下单、删数据），这意味着风险从“言论与信息”领域，延伸到了“行为与操作”领域。一旦发生错误，可能直接造成财产损失、合同违约或系统破坏，其损害后果更直接、更实质。这要求开发者和使用者必须像管理一个“数字员工”一样，为其设定严格的权限边界和行为准则。

对于企业，我提出如下建议：企业在采用此类框架时，首要任务是厘清技术供应链上的各个法律主体，并通过合同明确各方的安全义务与责任边界；在内部治理上，须建立针对自动化执行工具的特殊管理制度，将其与普通的内容生成AI区别管理。

NBD：OpenClaw最大的特别之处，是它可能不仅能回答问题，还能自动操作网页、系统和工具。这样的能力在法律上意味着什么？

白耀华：自动操作能力在法律上意味着OpenClaw驱动的智能体从“辅助工具”升级为“行为代理”，其法律意义核心在于“行为授权范围”与“行为后果的可归责性”，可能直接触发合同履行、侵权责任及更严格的数据处理合规要求。

上述“行为代理”能力使其不再局限于提供建议，而是能代表用户或开发者直接与第三方系统交互，产生法律效力。比如：

第一，可能成为合同行为的执行方。智能体的自动下单、报价等操作，在法律上可能被视为用户或开发者发出的要约或承诺，一旦达成合意，即成立合同关系。若操作错误（如错误报价），可能引发合同纠纷。

第二，构成数据处理或访问行为。自动操作必然涉及对系统数据的读取、修改或删除，这直接落入《中华人民共和国数据安全法》和《中华人民共和国个人信息保护法》的规制范围。特别是，如果操作涉及自动化决策（例如根据用户数据自动给出不同报价），个人信息处理者必须按照《中华人民共和国个人信息保护法》第五十五条的规定，事前进行个人信息保护影响评估。

第三，侵权行为的潜在实施者。如果智能体越权访问他人系统、误删他人数据或发布诽谤言论，其行为可能构成对网络安全、财产权或名誉权的侵害，相关责任需要追溯至其控制者。

对于企业，我提出如下建议：企业必须为智能体划定清晰、具体的操作权限清单，遵循“最小必要”原则，禁止其访问与核心任务无关的系统或数据；对于涉及合同订立、支付、数据删除等高危操作，必须设置“人工确认”强制环节，不能完全交由智能体自动化处理。

NBD：如果OpenClaw驱动的智能体执行错误，比如误删数据、错误下单、错误报价、错误发言，责任应如何划分？

白耀华：责任划分无统一标准，需构建一个分层级的过错分析框架，核心在于举证证明损害后果与哪一方的过错行为（如设计缺陷、管理疏忽、指令错误）存在因果关系。通常涉及框架提供者、智能体定制开发者、插件提供者及最终用户等多方主体。

参考相关司法实践，责任划分可遵循以下思路：

第一，框架提供者/开源社区的责任基础。其通常仅对框架本身存在的、已知且未修复的底层安全漏洞负责。违反开源协议与因框架缺陷导致民事侵权是两个相对独立的问题，如果错误并非源于框架的根本性缺陷，其责任可能有限。

第二，智能体定制开发者/集成商的责任，这是最可能承担主要责任的环节。开发者负责具体的业务逻辑设计、权限配置和安全测试。如果因设计缺陷（如未对删除操作设置二次确认）、对框架的误用或测试不充分导致错误，其应承担相应责任。

第三，插件或外部工具提供者的责任，即对其提供的特定功能模块的安全性独立负责。如果错误由某个恶意或有漏洞的插件直接引发，该提供者应承担责任。

第四，最终企业用户的责任。用户负有最终的监督管理和合规使用义务，如果用户发出了模糊、错误的指令，或无视安全警告强行部署，或未对智能体进行必要的权限管控，则需要承担相应责任。

第五，损失范围的认定。如果智能体是企业核心业务（如自动交易）不可或缺的组件，其错误操作导致的损失可能需按整体业务影响来评估，而非仅计算直接损失。

对此，我提出以下建议：企业在委托开发或采购智能体服务时，必须在合同中明确约定责任条款，特别是针对因设计缺陷、算法错误导致的损失，约定清晰的赔偿机制；企业务必要建立并妥善保存全链条的操作日志和审计记录，这是事后进行过错认定和责任划分的关键证据。

若使用OpenClaw出现数据泄露，不排除企业将承担连带责任

NBD：OpenClaw这类框架通常依赖插件、外部工具、浏览器自动化和代码执行环境，这会带来哪些网络安全法律风险？

白耀华：这种高度依赖外部组件的架构，会急剧扩大系统的“攻击面”，主要带来供应链安全风险、数据泄露风险、连带合规责任风险以及对第三方的侵权风险，极易违反网络安全等级保护制度。

具体分析四类主要风险：

第一，供应链攻击风险。恶意插件或受污染的外部工具可能成为“特洛伊木马”，导致数据被窃取、系统被控制。根据《中华人民共和国网络安全法》第二十四条，“网络产品、服务的提供者不得设置恶意程序”。使用者若因引入不安全组件导致自身或第三方受损，可能因未尽到审慎审查义务而承担责任。

第二，数据泄露与违规处理风险。插件和自动化工具可能在用户不知情下收集、传输敏感数据。若未单独明示并取得用户同意，将违反《中华人民共和国网络安全法》第四十三条、第四十四条关于个人信息收集使用的规定。

第三，连带合规责任风险。根据《中华人民共和国数据安全法》第二十七条，数据处理者应“建立健全全流程数据安全管理制度”。企业使用包含诸多外部组件的智能体，法律上可能视其为统一的“数据处理活动”。任何一个组件的安全漏洞导致数据泄露，企业作为整体活动的组织者都可能面临行政处罚。

第四，对第三方的侵权风险。智能体的自动化操作（如批量爬取数据）可能超出合理范围，构成对第三方网站或系统的未经授权访问，甚至可能被认定为网络攻击行为。

对于企业，我提出以下建议：建立严格的插件“白名单”管理制度，只允许使用经过彻底安全审计的官方或可信来源插件；对智能体运行环境进行网络隔离（沙盒化），限制其网络访问权限，防止一个插件的漏洞危及核心业务网络。

NBD：对于企业用户而言，若要使用OpenClaw，你有哪些合规方面的建议？

白耀华：企业应以“治理数字员工”的思维进行合规管理，构建覆盖准入评估、权限管控、过程审计、应急响应全生命周期的风控体系，并将核心义务通过合同固化。

在准入阶段，要进行深度尽职调查。仔细审查OpenClaw及其拟用插件的开源许可证，明确商用限制、代码开源义务等；与定制开发方签订权责清晰的合同，明确功能标准、安全要求、知识产权归属、责任限制与赔偿条款。

在部署阶段，要贯彻最小权限与隔离原则。既要权限最小化，为智能体分配完成特定任务所需的最少系统权限和数据访问权限，也要环境沙盒化，即在高风险操作场景中，使用隔离的测试环境运行，待充分验证后再考虑有限部署。

在运行阶段，要确保全程可审计与可干预。第一，要做好完备的日志记录，记录智能体的每一个决策依据、执行动作和结果，日志留存时间应符合《中华人民共和国网络安全法》不少于六个月的要求；第二，对关键操作要进行人工复核，即对涉及资金、合同、核心数据删除等操作，设置强制的人工审批或确认环节；第三，要定期进行安全评估，对智能体系统进行安全扫描和合规审计，特别是检查第三方组件的安全更新情况。

此外，还要有做好应急和兜底的准备。一方面是要制定应急预案，明确智能体发生异常行为（如疯狂下单、泄露数据）时的紧急处置流程；另一方面要考虑购买商业保险，可以考虑投保网络安全保险或产品责任险，以转移部分潜在的巨额赔偿风险。

我认为，OpenClaw所代表的技术方向充满潜力，但其法律风险也呈几何级数增长。企业拥抱创新时，必须同步构建与之匹配的、严谨的法律与合规框架，方能行稳致远。

当前，在各互联网大厂纷纷推出OpenClaw（一款开源人工智能体框架，俗称“龙虾”）产品、部分企业尝试将其接入生产环境的背景下，“养虾”所面临的法律风险也逐渐被推上前台：“龙虾”与普通大模型应用所面临的法律风险有什么不同？如果“龙虾”在运行过程中，误删数据、错误下单，责任算谁的？如果企业要“养虾”，如何进行合规管理？

3月19日，《每日经济新闻》记者（以下简称NBD）就上述问题，书面专访了北京德和衡（上海）律师事务所人工智能与自动驾驶部主任、高级合伙人白耀华律师。

白耀华律师 图片来源；受访者供图

应遵循“最小必要”原则，并对高危操作设置“人工确认”强制环节

NBD：OpenClaw作为“开源智能体框架”，它和普通大模型应用的法律风险有什么不同？

白耀华：OpenClaw作为“开源人工智能体框架”，其法律风险相较于普通大模型应用更为复杂和前置，核心差异在于其“开源”属性带来的责任主体模糊化，以及“智能体”属性使其从“信息生成者”转变为“行为执行者”，从而引入了操作失控与行为归责的新风险。

具体分析，普通大模型应用（如对话机器人）的法律风险主要集中在生成内容的知识产权侵权、虚假信息传播、个人信息处理合规等方面。而OpenClaw这类框架的风险是复合与升级的：

第一，“开源”带来的责任网络化风险。开源框架允许全球开发者贡献代码、开发插件，这导致安全管理、数据保护的责任主体从单一的运营方扩散到一个松散的生态。《中华人民共和国网络安全法》要求网络运营者制定并落实安全管理制度。在开源生态中，谁是“运营者”？框架的原始开发者、二次开发的企业、插件的提供者，都可能在不同环节承担相应责任，这使得责任界定异常困难。

第二，“智能体”带来的行为性风险。 普通大模型主要是“说”，而智能体框架驱动的应用是“做”——它能自动操作外部系统（如下单、删数据），这意味着风险从“言论与信息”领域，延伸到了“行为与操作”领域。一旦发生错误，可能直接造成财产损失、合同违约或系统破坏，其损害后果更直接、更实质。这要求开发者和使用者必须像管理一个“数字员工”一样，为其设定严格的权限边界和行为准则。

对于企业，我提出如下建议：企业在采用此类框架时，首要任务是厘清技术供应链上的各个法律主体，并通过合同明确各方的安全义务与责任边界；在内部治理上，须建立针对自动化执行工具的特殊管理制度，将其与普通的内容生成AI区别管理。

NBD：OpenClaw最大的特别之处，是它可能不仅能回答问题，还能自动操作网页、系统和工具。这样的能力在法律上意味着什么？

白耀华：自动操作能力在法律上意味着OpenClaw驱动的智能体从“辅助工具”升级为“行为代理”，其法律意义核心在于“行为授权范围”与“行为后果的可归责性”，可能直接触发合同履行、侵权责任及更严格的数据处理合规要求。

上述“行为代理”能力使其不再局限于提供建议，而是能代表用户或开发者直接与第三方系统交互，产生法律效力。比如：

第一，可能成为合同行为的执行方。智能体的自动下单、报价等操作，在法律上可能被视为用户或开发者发出的要约或承诺，一旦达成合意，即成立合同关系。若操作错误（如错误报价），可能引发合同纠纷。

第二，构成数据处理或访问行为。自动操作必然涉及对系统数据的读取、修改或删除，这直接落入《中华人民共和国数据安全法》和《中华人民共和国个人信息保护法》的规制范围。特别是，如果操作涉及自动化决策（例如根据用户数据自动给出不同报价），个人信息处理者必须按照《中华人民共和国个人信息保护法》第五十五条的规定，事前进行个人信息保护影响评估。

第三，侵权行为的潜在实施者。如果智能体越权访问他人系统、误删他人数据或发布诽谤言论，其行为可能构成对网络安全、财产权或名誉权的侵害，相关责任需要追溯至其控制者。

对于企业，我提出如下建议：企业必须为智能体划定清晰、具体的操作权限清单，遵循“最小必要”原则，禁止其访问与核心任务无关的系统或数据；对于涉及合同订立、支付、数据删除等高危操作，必须设置“人工确认”强制环节，不能完全交由智能体自动化处理。

NBD：如果OpenClaw驱动的智能体执行错误，比如误删数据、错误下单、错误报价、错误发言，责任应如何划分？

白耀华：责任划分无统一标准，需构建一个分层级的过错分析框架，核心在于举证证明损害后果与哪一方的过错行为（如设计缺陷、管理疏忽、指令错误）存在因果关系。通常涉及框架提供者、智能体定制开发者、插件提供者及最终用户等多方主体。

参考相关司法实践，责任划分可遵循以下思路：

第一，框架提供者/开源社区的责任基础。其通常仅对框架本身存在的、已知且未修复的底层安全漏洞负责。违反开源协议与因框架缺陷导致民事侵权是两个相对独立的问题，如果错误并非源于框架的根本性缺陷，其责任可能有限。

第二，智能体定制开发者/集成商的责任，这是最可能承担主要责任的环节。开发者负责具体的业务逻辑设计、权限配置和安全测试。如果因设计缺陷（如未对删除操作设置二次确认）、对框架的误用或测试不充分导致错误，其应承担相应责任。

第三，插件或外部工具提供者的责任，即对其提供的特定功能模块的安全性独立负责。如果错误由某个恶意或有漏洞的插件直接引发，该提供者应承担责任。

第四，最终企业用户的责任。用户负有最终的监督管理和合规使用义务，如果用户发出了模糊、错误的指令，或无视安全警告强行部署，或未对智能体进行必要的权限管控，则需要承担相应责任。

第五，损失范围的认定。如果智能体是企业核心业务（如自动交易）不可或缺的组件，其错误操作导致的损失可能需按整体业务影响来评估，而非仅计算直接损失。

对此，我提出以下建议：企业在委托开发或采购智能体服务时，必须在合同中明确约定责任条款，特别是针对因设计缺陷、算法错误导致的损失，约定清晰的赔偿机制；企业务必要建立并妥善保存全链条的操作日志和审计记录，这是事后进行过错认定和责任划分的关键证据。

若使用OpenClaw出现数据泄露，不排除企业将承担连带责任

NBD：OpenClaw这类框架通常依赖插件、外部工具、浏览器自动化和代码执行环境，这会带来哪些网络安全法律风险？

白耀华：这种高度依赖外部组件的架构，会急剧扩大系统的“攻击面”，主要带来供应链安全风险、数据泄露风险、连带合规责任风险以及对第三方的侵权风险，极易违反网络安全等级保护制度。

具体分析四类主要风险：

第一，供应链攻击风险。恶意插件或受污染的外部工具可能成为“特洛伊木马”，导致数据被窃取、系统被控制。根据《中华人民共和国网络安全法》第二十四条，“网络产品、服务的提供者不得设置恶意程序”。使用者若因引入不安全组件导致自身或第三方受损，可能因未尽到审慎审查义务而承担责任。

第二，数据泄露与违规处理风险。插件和自动化工具可能在用户不知情下收集、传输敏感数据。若未单独明示并取得用户同意，将违反《中华人民共和国网络安全法》第四十三条、第四十四条关于个人信息收集使用的规定。

第三，连带合规责任风险。根据《中华人民共和国数据安全法》第二十七条，数据处理者应“建立健全全流程数据安全管理制度”。企业使用包含诸多外部组件的智能体，法律上可能视其为统一的“数据处理活动”。任何一个组件的安全漏洞导致数据泄露，企业作为整体活动的组织者都可能面临行政处罚。

第四，对第三方的侵权风险。智能体的自动化操作（如批量爬取数据）可能超出合理范围，构成对第三方网站或系统的未经授权访问，甚至可能被认定为网络攻击行为。

对于企业，我提出以下建议：建立严格的插件“白名单”管理制度，只允许使用经过彻底安全审计的官方或可信来源插件；对智能体运行环境进行网络隔离（沙盒化），限制其网络访问权限，防止一个插件的漏洞危及核心业务网络。

NBD：对于企业用户而言，若要使用OpenClaw，你有哪些合规方面的建议？

白耀华：企业应以“治理数字员工”的思维进行合规管理，构建覆盖准入评估、权限管控、过程审计、应急响应全生命周期的风控体系，并将核心义务通过合同固化。

在准入阶段，要进行深度尽职调查。仔细审查OpenClaw及其拟用插件的开源许可证，明确商用限制、代码开源义务等；与定制开发方签订权责清晰的合同，明确功能标准、安全要求、知识产权归属、责任限制与赔偿条款。

在部署阶段，要贯彻最小权限与隔离原则。既要权限最小化，为智能体分配完成特定任务所需的最少系统权限和数据访问权限，也要环境沙盒化，即在高风险操作场景中，使用隔离的测试环境运行，待充分验证后再考虑有限部署。

在运行阶段，要确保全程可审计与可干预。第一，要做好完备的日志记录，记录智能体的每一个决策依据、执行动作和结果，日志留存时间应符合《中华人民共和国网络安全法》不少于六个月的要求；第二，对关键操作要进行人工复核，即对涉及资金、合同、核心数据删除等操作，设置强制的人工审批或确认环节；第三，要定期进行安全评估，对智能体系统进行安全扫描和合规审计，特别是检查第三方组件的安全更新情况。

此外，还要有做好应急和兜底的准备。一方面是要制定应急预案，明确智能体发生异常行为（如疯狂下单、泄露数据）时的紧急处置流程；另一方面要考虑购买商业保险，可以考虑投保网络安全保险或产品责任险，以转移部分潜在的巨额赔偿风险。

我认为，OpenClaw所代表的技术方向充满潜力，但其法律风险也呈几何级数增长。企业拥抱创新时，必须同步构建与之匹配的、严谨的法律与合规框架，方能行稳致远。

当前，在各互联网大厂纷纷推出OpenClaw（一款开源人工智能体框架，俗称“龙虾”）产品、部分企业尝试将其接入生产环境的背景下，“养虾”所面临的法律风险也逐渐被推上前台：“龙虾”与普通大模型应用所面临的法律风险有什么不同？如果“龙虾”在运行过程中，误删数据、错误下单，责任算谁的？如果企业要“养虾”，如何进行合规管理？

3月19日，《每日经济新闻》记者（以下简称NBD）就上述问题，书面专访了北京德和衡（上海）律师事务所人工智能与自动驾驶部主任、高级合伙人白耀华律师。

白耀华律师 图片来源；受访者供图

应遵循“最小必要”原则，并对高危操作设置“人工确认”强制环节

NBD：OpenClaw作为“开源智能体框架”，它和普通大模型应用的法律风险有什么不同？

白耀华：OpenClaw作为“开源人工智能体框架”，其法律风险相较于普通大模型应用更为复杂和前置，核心差异在于其“开源”属性带来的责任主体模糊化，以及“智能体”属性使其从“信息生成者”转变为“行为执行者”，从而引入了操作失控与行为归责的新风险。

具体分析，普通大模型应用（如对话机器人）的法律风险主要集中在生成内容的知识产权侵权、虚假信息传播、个人信息处理合规等方面。而OpenClaw这类框架的风险是复合与升级的：

第一，“开源”带来的责任网络化风险。开源框架允许全球开发者贡献代码、开发插件，这导致安全管理、数据保护的责任主体从单一的运营方扩散到一个松散的生态。《中华人民共和国网络安全法》要求网络运营者制定并落实安全管理制度。在开源生态中，谁是“运营者”？框架的原始开发者、二次开发的企业、插件的提供者，都可能在不同环节承担相应责任，这使得责任界定异常困难。

第二，“智能体”带来的行为性风险。 普通大模型主要是“说”，而智能体框架驱动的应用是“做”——它能自动操作外部系统（如下单、删数据），这意味着风险从“言论与信息”领域，延伸到了“行为与操作”领域。一旦发生错误，可能直接造成财产损失、合同违约或系统破坏，其损害后果更直接、更实质。这要求开发者和使用者必须像管理一个“数字员工”一样，为其设定严格的权限边界和行为准则。

对于企业，我提出如下建议：企业在采用此类框架时，首要任务是厘清技术供应链上的各个法律主体，并通过合同明确各方的安全义务与责任边界；在内部治理上，须建立针对自动化执行工具的特殊管理制度，将其与普通的内容生成AI区别管理。

NBD：OpenClaw最大的特别之处，是它可能不仅能回答问题，还能自动操作网页、系统和工具。这样的能力在法律上意味着什么？

白耀华：自动操作能力在法律上意味着OpenClaw驱动的智能体从“辅助工具”升级为“行为代理”，其法律意义核心在于“行为授权范围”与“行为后果的可归责性”，可能直接触发合同履行、侵权责任及更严格的数据处理合规要求。

上述“行为代理”能力使其不再局限于提供建议，而是能代表用户或开发者直接与第三方系统交互，产生法律效力。比如：

第一，可能成为合同行为的执行方。智能体的自动下单、报价等操作，在法律上可能被视为用户或开发者发出的要约或承诺，一旦达成合意，即成立合同关系。若操作错误（如错误报价），可能引发合同纠纷。

第二，构成数据处理或访问行为。自动操作必然涉及对系统数据的读取、修改或删除，这直接落入《中华人民共和国数据安全法》和《中华人民共和国个人信息保护法》的规制范围。特别是，如果操作涉及自动化决策（例如根据用户数据自动给出不同报价），个人信息处理者必须按照《中华人民共和国个人信息保护法》第五十五条的规定，事前进行个人信息保护影响评估。

第三，侵权行为的潜在实施者。如果智能体越权访问他人系统、误删他人数据或发布诽谤言论，其行为可能构成对网络安全、财产权或名誉权的侵害，相关责任需要追溯至其控制者。

对于企业，我提出如下建议：企业必须为智能体划定清晰、具体的操作权限清单，遵循“最小必要”原则，禁止其访问与核心任务无关的系统或数据；对于涉及合同订立、支付、数据删除等高危操作，必须设置“人工确认”强制环节，不能完全交由智能体自动化处理。

NBD：如果OpenClaw驱动的智能体执行错误，比如误删数据、错误下单、错误报价、错误发言，责任应如何划分？

白耀华：责任划分无统一标准，需构建一个分层级的过错分析框架，核心在于举证证明损害后果与哪一方的过错行为（如设计缺陷、管理疏忽、指令错误）存在因果关系。通常涉及框架提供者、智能体定制开发者、插件提供者及最终用户等多方主体。

参考相关司法实践，责任划分可遵循以下思路：

第一，框架提供者/开源社区的责任基础。其通常仅对框架本身存在的、已知且未修复的底层安全漏洞负责。违反开源协议与因框架缺陷导致民事侵权是两个相对独立的问题，如果错误并非源于框架的根本性缺陷，其责任可能有限。

第二，智能体定制开发者/集成商的责任，这是最可能承担主要责任的环节。开发者负责具体的业务逻辑设计、权限配置和安全测试。如果因设计缺陷（如未对删除操作设置二次确认）、对框架的误用或测试不充分导致错误，其应承担相应责任。

第三，插件或外部工具提供者的责任，即对其提供的特定功能模块的安全性独立负责。如果错误由某个恶意或有漏洞的插件直接引发，该提供者应承担责任。

第四，最终企业用户的责任。用户负有最终的监督管理和合规使用义务，如果用户发出了模糊、错误的指令，或无视安全警告强行部署，或未对智能体进行必要的权限管控，则需要承担相应责任。

第五，损失范围的认定。如果智能体是企业核心业务（如自动交易）不可或缺的组件，其错误操作导致的损失可能需按整体业务影响来评估，而非仅计算直接损失。

对此，我提出以下建议：企业在委托开发或采购智能体服务时，必须在合同中明确约定责任条款，特别是针对因设计缺陷、算法错误导致的损失，约定清晰的赔偿机制；企业务必要建立并妥善保存全链条的操作日志和审计记录，这是事后进行过错认定和责任划分的关键证据。

若使用OpenClaw出现数据泄露，不排除企业将承担连带责任

NBD：OpenClaw这类框架通常依赖插件、外部工具、浏览器自动化和代码执行环境，这会带来哪些网络安全法律风险？

白耀华：这种高度依赖外部组件的架构，会急剧扩大系统的“攻击面”，主要带来供应链安全风险、数据泄露风险、连带合规责任风险以及对第三方的侵权风险，极易违反网络安全等级保护制度。

具体分析四类主要风险：

第一，供应链攻击风险。恶意插件或受污染的外部工具可能成为“特洛伊木马”，导致数据被窃取、系统被控制。根据《中华人民共和国网络安全法》第二十四条，“网络产品、服务的提供者不得设置恶意程序”。使用者若因引入不安全组件导致自身或第三方受损，可能因未尽到审慎审查义务而承担责任。

第二，数据泄露与违规处理风险。插件和自动化工具可能在用户不知情下收集、传输敏感数据。若未单独明示并取得用户同意，将违反《中华人民共和国网络安全法》第四十三条、第四十四条关于个人信息收集使用的规定。

第三，连带合规责任风险。根据《中华人民共和国数据安全法》第二十七条，数据处理者应“建立健全全流程数据安全管理制度”。企业使用包含诸多外部组件的智能体，法律上可能视其为统一的“数据处理活动”。任何一个组件的安全漏洞导致数据泄露，企业作为整体活动的组织者都可能面临行政处罚。

第四，对第三方的侵权风险。智能体的自动化操作（如批量爬取数据）可能超出合理范围，构成对第三方网站或系统的未经授权访问，甚至可能被认定为网络攻击行为。

对于企业，我提出以下建议：建立严格的插件“白名单”管理制度，只允许使用经过彻底安全审计的官方或可信来源插件；对智能体运行环境进行网络隔离（沙盒化），限制其网络访问权限，防止一个插件的漏洞危及核心业务网络。

NBD：对于企业用户而言，若要使用OpenClaw，你有哪些合规方面的建议？

白耀华：企业应以“治理数字员工”的思维进行合规管理，构建覆盖准入评估、权限管控、过程审计、应急响应全生命周期的风控体系，并将核心义务通过合同固化。

在准入阶段，要进行深度尽职调查。仔细审查OpenClaw及其拟用插件的开源许可证，明确商用限制、代码开源义务等；与定制开发方签订权责清晰的合同，明确功能标准、安全要求、知识产权归属、责任限制与赔偿条款。

在部署阶段，要贯彻最小权限与隔离原则。既要权限最小化，为智能体分配完成特定任务所需的最少系统权限和数据访问权限，也要环境沙盒化，即在高风险操作场景中，使用隔离的测试环境运行，待充分验证后再考虑有限部署。

在运行阶段，要确保全程可审计与可干预。第一，要做好完备的日志记录，记录智能体的每一个决策依据、执行动作和结果，日志留存时间应符合《中华人民共和国网络安全法》不少于六个月的要求；第二，对关键操作要进行人工复核，即对涉及资金、合同、核心数据删除等操作，设置强制的人工审批或确认环节；第三，要定期进行安全评估，对智能体系统进行安全扫描和合规审计，特别是检查第三方组件的安全更新情况。

此外，还要有做好应急和兜底的准备。一方面是要制定应急预案，明确智能体发生异常行为（如疯狂下单、泄露数据）时的紧急处置流程；另一方面要考虑购买商业保险，可以考虑投保网络安全保险或产品责任险，以转移部分潜在的巨额赔偿风险。

我认为，OpenClaw所代表的技术方向充满潜力，但其法律风险也呈几何级数增长。企业拥抱创新时，必须同步构建与之匹配的、严谨的法律与合规框架，方能行稳致远。

当前，在各互联网大厂纷纷推出OpenClaw（一款开源人工智能体框架，俗称“龙虾”）产品、部分企业尝试将其接入生产环境的背景下，“养虾”所面临的法律风险也逐渐被推上前台：“龙虾”与普通大模型应用所面临的法律风险有什么不同？如果“龙虾”在运行过程中，误删数据、错误下单，责任算谁的？如果企业要“养虾”，如何进行合规管理？

3月19日，《每日经济新闻》记者（以下简称NBD）就上述问题，书面专访了北京德和衡（上海）律师事务所人工智能与自动驾驶部主任、高级合伙人白耀华律师。

白耀华律师 图片来源；受访者供图

应遵循“最小必要”原则，并对高危操作设置“人工确认”强制环节

NBD：OpenClaw作为“开源智能体框架”，它和普通大模型应用的法律风险有什么不同？

白耀华：OpenClaw作为“开源人工智能体框架”，其法律风险相较于普通大模型应用更为复杂和前置，核心差异在于其“开源”属性带来的责任主体模糊化，以及“智能体”属性使其从“信息生成者”转变为“行为执行者”，从而引入了操作失控与行为归责的新风险。

具体分析，普通大模型应用（如对话机器人）的法律风险主要集中在生成内容的知识产权侵权、虚假信息传播、个人信息处理合规等方面。而OpenClaw这类框架的风险是复合与升级的：

第一，“开源”带来的责任网络化风险。开源框架允许全球开发者贡献代码、开发插件，这导致安全管理、数据保护的责任主体从单一的运营方扩散到一个松散的生态。《中华人民共和国网络安全法》要求网络运营者制定并落实安全管理制度。在开源生态中，谁是“运营者”？框架的原始开发者、二次开发的企业、插件的提供者，都可能在不同环节承担相应责任，这使得责任界定异常困难。

第二，“智能体”带来的行为性风险。 普通大模型主要是“说”，而智能体框架驱动的应用是“做”——它能自动操作外部系统（如下单、删数据），这意味着风险从“言论与信息”领域，延伸到了“行为与操作”领域。一旦发生错误，可能直接造成财产损失、合同违约或系统破坏，其损害后果更直接、更实质。这要求开发者和使用者必须像管理一个“数字员工”一样，为其设定严格的权限边界和行为准则。

对于企业，我提出如下建议：企业在采用此类框架时，首要任务是厘清技术供应链上的各个法律主体，并通过合同明确各方的安全义务与责任边界；在内部治理上，须建立针对自动化执行工具的特殊管理制度，将其与普通的内容生成AI区别管理。

NBD：OpenClaw最大的特别之处，是它可能不仅能回答问题，还能自动操作网页、系统和工具。这样的能力在法律上意味着什么？

白耀华：自动操作能力在法律上意味着OpenClaw驱动的智能体从“辅助工具”升级为“行为代理”，其法律意义核心在于“行为授权范围”与“行为后果的可归责性”，可能直接触发合同履行、侵权责任及更严格的数据处理合规要求。

上述“行为代理”能力使其不再局限于提供建议，而是能代表用户或开发者直接与第三方系统交互，产生法律效力。比如：

第一，可能成为合同行为的执行方。智能体的自动下单、报价等操作，在法律上可能被视为用户或开发者发出的要约或承诺，一旦达成合意，即成立合同关系。若操作错误（如错误报价），可能引发合同纠纷。

第二，构成数据处理或访问行为。自动操作必然涉及对系统数据的读取、修改或删除，这直接落入《中华人民共和国数据安全法》和《中华人民共和国个人信息保护法》的规制范围。特别是，如果操作涉及自动化决策（例如根据用户数据自动给出不同报价），个人信息处理者必须按照《中华人民共和国个人信息保护法》第五十五条的规定，事前进行个人信息保护影响评估。

第三，侵权行为的潜在实施者。如果智能体越权访问他人系统、误删他人数据或发布诽谤言论，其行为可能构成对网络安全、财产权或名誉权的侵害，相关责任需要追溯至其控制者。

对于企业，我提出如下建议：企业必须为智能体划定清晰、具体的操作权限清单，遵循“最小必要”原则，禁止其访问与核心任务无关的系统或数据；对于涉及合同订立、支付、数据删除等高危操作，必须设置“人工确认”强制环节，不能完全交由智能体自动化处理。

NBD：如果OpenClaw驱动的智能体执行错误，比如误删数据、错误下单、错误报价、错误发言，责任应如何划分？

白耀华：责任划分无统一标准，需构建一个分层级的过错分析框架，核心在于举证证明损害后果与哪一方的过错行为（如设计缺陷、管理疏忽、指令错误）存在因果关系。通常涉及框架提供者、智能体定制开发者、插件提供者及最终用户等多方主体。

参考相关司法实践，责任划分可遵循以下思路：

第一，框架提供者/开源社区的责任基础。其通常仅对框架本身存在的、已知且未修复的底层安全漏洞负责。违反开源协议与因框架缺陷导致民事侵权是两个相对独立的问题，如果错误并非源于框架的根本性缺陷，其责任可能有限。

第二，智能体定制开发者/集成商的责任，这是最可能承担主要责任的环节。开发者负责具体的业务逻辑设计、权限配置和安全测试。如果因设计缺陷（如未对删除操作设置二次确认）、对框架的误用或测试不充分导致错误，其应承担相应责任。

第三，插件或外部工具提供者的责任，即对其提供的特定功能模块的安全性独立负责。如果错误由某个恶意或有漏洞的插件直接引发，该提供者应承担责任。

第四，最终企业用户的责任。用户负有最终的监督管理和合规使用义务，如果用户发出了模糊、错误的指令，或无视安全警告强行部署，或未对智能体进行必要的权限管控，则需要承担相应责任。

第五，损失范围的认定。如果智能体是企业核心业务（如自动交易）不可或缺的组件，其错误操作导致的损失可能需按整体业务影响来评估，而非仅计算直接损失。

对此，我提出以下建议：企业在委托开发或采购智能体服务时，必须在合同中明确约定责任条款，特别是针对因设计缺陷、算法错误导致的损失，约定清晰的赔偿机制；企业务必要建立并妥善保存全链条的操作日志和审计记录，这是事后进行过错认定和责任划分的关键证据。

若使用OpenClaw出现数据泄露，不排除企业将承担连带责任

NBD：OpenClaw这类框架通常依赖插件、外部工具、浏览器自动化和代码执行环境，这会带来哪些网络安全法律风险？

白耀华：这种高度依赖外部组件的架构，会急剧扩大系统的“攻击面”，主要带来供应链安全风险、数据泄露风险、连带合规责任风险以及对第三方的侵权风险，极易违反网络安全等级保护制度。

具体分析四类主要风险：

第一，供应链攻击风险。恶意插件或受污染的外部工具可能成为“特洛伊木马”，导致数据被窃取、系统被控制。根据《中华人民共和国网络安全法》第二十四条，“网络产品、服务的提供者不得设置恶意程序”。使用者若因引入不安全组件导致自身或第三方受损，可能因未尽到审慎审查义务而承担责任。

第二，数据泄露与违规处理风险。插件和自动化工具可能在用户不知情下收集、传输敏感数据。若未单独明示并取得用户同意，将违反《中华人民共和国网络安全法》第四十三条、第四十四条关于个人信息收集使用的规定。

第三，连带合规责任风险。根据《中华人民共和国数据安全法》第二十七条，数据处理者应“建立健全全流程数据安全管理制度”。企业使用包含诸多外部组件的智能体，法律上可能视其为统一的“数据处理活动”。任何一个组件的安全漏洞导致数据泄露，企业作为整体活动的组织者都可能面临行政处罚。

第四，对第三方的侵权风险。智能体的自动化操作（如批量爬取数据）可能超出合理范围，构成对第三方网站或系统的未经授权访问，甚至可能被认定为网络攻击行为。

对于企业，我提出以下建议：建立严格的插件“白名单”管理制度，只允许使用经过彻底安全审计的官方或可信来源插件；对智能体运行环境进行网络隔离（沙盒化），限制其网络访问权限，防止一个插件的漏洞危及核心业务网络。

NBD：对于企业用户而言，若要使用OpenClaw，你有哪些合规方面的建议？

白耀华：企业应以“治理数字员工”的思维进行合规管理，构建覆盖准入评估、权限管控、过程审计、应急响应全生命周期的风控体系，并将核心义务通过合同固化。

在准入阶段，要进行深度尽职调查。仔细审查OpenClaw及其拟用插件的开源许可证，明确商用限制、代码开源义务等；与定制开发方签订权责清晰的合同，明确功能标准、安全要求、知识产权归属、责任限制与赔偿条款。

在部署阶段，要贯彻最小权限与隔离原则。既要权限最小化，为智能体分配完成特定任务所需的最少系统权限和数据访问权限，也要环境沙盒化，即在高风险操作场景中，使用隔离的测试环境运行，待充分验证后再考虑有限部署。

在运行阶段，要确保全程可审计与可干预。第一，要做好完备的日志记录，记录智能体的每一个决策依据、执行动作和结果，日志留存时间应符合《中华人民共和国网络安全法》不少于六个月的要求；第二，对关键操作要进行人工复核，即对涉及资金、合同、核心数据删除等操作，设置强制的人工审批或确认环节；第三，要定期进行安全评估，对智能体系统进行安全扫描和合规审计，特别是检查第三方组件的安全更新情况。

此外，还要有做好应急和兜底的准备。一方面是要制定应急预案，明确智能体发生异常行为（如疯狂下单、泄露数据）时的紧急处置流程；另一方面要考虑购买商业保险，可以考虑投保网络安全保险或产品责任险，以转移部分潜在的巨额赔偿风险。

我认为，OpenClaw所代表的技术方向充满潜力，但其法律风险也呈几何级数增长。企业拥抱创新时，必须同步构建与之匹配的、严谨的法律与合规框架，方能行稳致远。

当前，在各互联网大厂纷纷推出OpenClaw（一款开源人工智能体框架，俗称“龙虾”）产品、部分企业尝试将其接入生产环境的背景下，“养虾”所面临的法律风险也逐渐被推上前台：“龙虾”与普通大模型应用所面临的法律风险有什么不同？如果“龙虾”在运行过程中，误删数据、错误下单，责任算谁的？如果企业要“养虾”，如何进行合规管理？

3月19日，《每日经济新闻》记者（以下简称NBD）就上述问题，书面专访了北京德和衡（上海）律师事务所人工智能与自动驾驶部主任、高级合伙人白耀华律师。

白耀华律师 图片来源；受访者供图

应遵循“最小必要”原则，并对高危操作设置“人工确认”强制环节

NBD：OpenClaw作为“开源智能体框架”，它和普通大模型应用的法律风险有什么不同？

白耀华：OpenClaw作为“开源人工智能体框架”，其法律风险相较于普通大模型应用更为复杂和前置，核心差异在于其“开源”属性带来的责任主体模糊化，以及“智能体”属性使其从“信息生成者”转变为“行为执行者”，从而引入了操作失控与行为归责的新风险。

具体分析，普通大模型应用（如对话机器人）的法律风险主要集中在生成内容的知识产权侵权、虚假信息传播、个人信息处理合规等方面。而OpenClaw这类框架的风险是复合与升级的：

第一，“开源”带来的责任网络化风险。开源框架允许全球开发者贡献代码、开发插件，这导致安全管理、数据保护的责任主体从单一的运营方扩散到一个松散的生态。《中华人民共和国网络安全法》要求网络运营者制定并落实安全管理制度。在开源生态中，谁是“运营者”？框架的原始开发者、二次开发的企业、插件的提供者，都可能在不同环节承担相应责任，这使得责任界定异常困难。

第二，“智能体”带来的行为性风险。 普通大模型主要是“说”，而智能体框架驱动的应用是“做”——它能自动操作外部系统（如下单、删数据），这意味着风险从“言论与信息”领域，延伸到了“行为与操作”领域。一旦发生错误，可能直接造成财产损失、合同违约或系统破坏，其损害后果更直接、更实质。这要求开发者和使用者必须像管理一个“数字员工”一样，为其设定严格的权限边界和行为准则。

对于企业，我提出如下建议：企业在采用此类框架时，首要任务是厘清技术供应链上的各个法律主体，并通过合同明确各方的安全义务与责任边界；在内部治理上，须建立针对自动化执行工具的特殊管理制度，将其与普通的内容生成AI区别管理。

NBD：OpenClaw最大的特别之处，是它可能不仅能回答问题，还能自动操作网页、系统和工具。这样的能力在法律上意味着什么？

白耀华：自动操作能力在法律上意味着OpenClaw驱动的智能体从“辅助工具”升级为“行为代理”，其法律意义核心在于“行为授权范围”与“行为后果的可归责性”，可能直接触发合同履行、侵权责任及更严格的数据处理合规要求。

上述“行为代理”能力使其不再局限于提供建议，而是能代表用户或开发者直接与第三方系统交互，产生法律效力。比如：

第一，可能成为合同行为的执行方。智能体的自动下单、报价等操作，在法律上可能被视为用户或开发者发出的要约或承诺，一旦达成合意，即成立合同关系。若操作错误（如错误报价），可能引发合同纠纷。

第二，构成数据处理或访问行为。自动操作必然涉及对系统数据的读取、修改或删除，这直接落入《中华人民共和国数据安全法》和《中华人民共和国个人信息保护法》的规制范围。特别是，如果操作涉及自动化决策（例如根据用户数据自动给出不同报价），个人信息处理者必须按照《中华人民共和国个人信息保护法》第五十五条的规定，事前进行个人信息保护影响评估。

第三，侵权行为的潜在实施者。如果智能体越权访问他人系统、误删他人数据或发布诽谤言论，其行为可能构成对网络安全、财产权或名誉权的侵害，相关责任需要追溯至其控制者。

对于企业，我提出如下建议：企业必须为智能体划定清晰、具体的操作权限清单，遵循“最小必要”原则，禁止其访问与核心任务无关的系统或数据；对于涉及合同订立、支付、数据删除等高危操作，必须设置“人工确认”强制环节，不能完全交由智能体自动化处理。

NBD：如果OpenClaw驱动的智能体执行错误，比如误删数据、错误下单、错误报价、错误发言，责任应如何划分？

白耀华：责任划分无统一标准，需构建一个分层级的过错分析框架，核心在于举证证明损害后果与哪一方的过错行为（如设计缺陷、管理疏忽、指令错误）存在因果关系。通常涉及框架提供者、智能体定制开发者、插件提供者及最终用户等多方主体。

参考相关司法实践，责任划分可遵循以下思路：

第一，框架提供者/开源社区的责任基础。其通常仅对框架本身存在的、已知且未修复的底层安全漏洞负责。违反开源协议与因框架缺陷导致民事侵权是两个相对独立的问题，如果错误并非源于框架的根本性缺陷，其责任可能有限。

第二，智能体定制开发者/集成商的责任，这是最可能承担主要责任的环节。开发者负责具体的业务逻辑设计、权限配置和安全测试。如果因设计缺陷（如未对删除操作设置二次确认）、对框架的误用或测试不充分导致错误，其应承担相应责任。

第三，插件或外部工具提供者的责任，即对其提供的特定功能模块的安全性独立负责。如果错误由某个恶意或有漏洞的插件直接引发，该提供者应承担责任。

第四，最终企业用户的责任。用户负有最终的监督管理和合规使用义务，如果用户发出了模糊、错误的指令，或无视安全警告强行部署，或未对智能体进行必要的权限管控，则需要承担相应责任。

第五，损失范围的认定。如果智能体是企业核心业务（如自动交易）不可或缺的组件，其错误操作导致的损失可能需按整体业务影响来评估，而非仅计算直接损失。

对此，我提出以下建议：企业在委托开发或采购智能体服务时，必须在合同中明确约定责任条款，特别是针对因设计缺陷、算法错误导致的损失，约定清晰的赔偿机制；企业务必要建立并妥善保存全链条的操作日志和审计记录，这是事后进行过错认定和责任划分的关键证据。

若使用OpenClaw出现数据泄露，不排除企业将承担连带责任

NBD：OpenClaw这类框架通常依赖插件、外部工具、浏览器自动化和代码执行环境，这会带来哪些网络安全法律风险？

白耀华：这种高度依赖外部组件的架构，会急剧扩大系统的“攻击面”，主要带来供应链安全风险、数据泄露风险、连带合规责任风险以及对第三方的侵权风险，极易违反网络安全等级保护制度。

具体分析四类主要风险：

第一，供应链攻击风险。恶意插件或受污染的外部工具可能成为“特洛伊木马”，导致数据被窃取、系统被控制。根据《中华人民共和国网络安全法》第二十四条，“网络产品、服务的提供者不得设置恶意程序”。使用者若因引入不安全组件导致自身或第三方受损，可能因未尽到审慎审查义务而承担责任。

第二，数据泄露与违规处理风险。插件和自动化工具可能在用户不知情下收集、传输敏感数据。若未单独明示并取得用户同意，将违反《中华人民共和国网络安全法》第四十三条、第四十四条关于个人信息收集使用的规定。

第三，连带合规责任风险。根据《中华人民共和国数据安全法》第二十七条，数据处理者应“建立健全全流程数据安全管理制度”。企业使用包含诸多外部组件的智能体，法律上可能视其为统一的“数据处理活动”。任何一个组件的安全漏洞导致数据泄露，企业作为整体活动的组织者都可能面临行政处罚。

第四，对第三方的侵权风险。智能体的自动化操作（如批量爬取数据）可能超出合理范围，构成对第三方网站或系统的未经授权访问，甚至可能被认定为网络攻击行为。

对于企业，我提出以下建议：建立严格的插件“白名单”管理制度，只允许使用经过彻底安全审计的官方或可信来源插件；对智能体运行环境进行网络隔离（沙盒化），限制其网络访问权限，防止一个插件的漏洞危及核心业务网络。

NBD：对于企业用户而言，若要使用OpenClaw，你有哪些合规方面的建议？

白耀华：企业应以“治理数字员工”的思维进行合规管理，构建覆盖准入评估、权限管控、过程审计、应急响应全生命周期的风控体系，并将核心义务通过合同固化。

在准入阶段，要进行深度尽职调查。仔细审查OpenClaw及其拟用插件的开源许可证，明确商用限制、代码开源义务等；与定制开发方签订权责清晰的合同，明确功能标准、安全要求、知识产权归属、责任限制与赔偿条款。

在部署阶段，要贯彻最小权限与隔离原则。既要权限最小化，为智能体分配完成特定任务所需的最少系统权限和数据访问权限，也要环境沙盒化，即在高风险操作场景中，使用隔离的测试环境运行，待充分验证后再考虑有限部署。

在运行阶段，要确保全程可审计与可干预。第一，要做好完备的日志记录，记录智能体的每一个决策依据、执行动作和结果，日志留存时间应符合《中华人民共和国网络安全法》不少于六个月的要求；第二，对关键操作要进行人工复核，即对涉及资金、合同、核心数据删除等操作，设置强制的人工审批或确认环节；第三，要定期进行安全评估，对智能体系统进行安全扫描和合规审计，特别是检查第三方组件的安全更新情况。

此外，还要有做好应急和兜底的准备。一方面是要制定应急预案，明确智能体发生异常行为（如疯狂下单、泄露数据）时的紧急处置流程；另一方面要考虑购买商业保险，可以考虑投保网络安全保险或产品责任险，以转移部分潜在的巨额赔偿风险。

我认为，OpenClaw所代表的技术方向充满潜力，但其法律风险也呈几何级数增长。企业拥抱创新时，必须同步构建与之匹配的、严谨的法律与合规框架，方能行稳致远。