"Langosta" muestra sus garras, ¿cómo pueden las empresas criar langostas de forma segura? Entrevista exclusiva con Bai Yaohua del despacho de abogados Deheiheng: Es necesario establecer límites y normas para los "empleados digitales"

¡Invertir en acciones solo requiere consultar los informes de analistas de Jin Qilin, autoridad, profesionalismo, puntualidad, exhaustividad, ¡para ayudarle a descubrir oportunidades potenciales temáticas!

（Fuente: Daily Economic News）

Reportero de Daily Economic News: Song Sijian. Editor de Daily: Liao Dan.

Actualmente, en un contexto donde las grandes empresas de internet lanzan sus productos OpenClaw (un marco de trabajo de inteligencia artificial de código abierto, comúnmente conocido como “Langosta”) y algunas empresas intentan integrarlo en entornos de producción, los riesgos legales asociados a la “crianza de langostas” también están comenzando a salir a la luz: ¿en qué difiere el riesgo legal de OpenClaw respecto a las aplicaciones de modelos grandes tradicionales? Si durante su funcionamiento, “Langosta” elimina datos por error o realiza pedidos incorrectos, ¿quién asume la responsabilidad? Si una empresa quiere “criar langostas”, ¿cómo debe gestionar la conformidad legal?

El 19 de marzo, el periodista de Daily Economic News (en adelante NBD) realizó una entrevista escrita con el abogado Bai Yaohua, director del departamento de inteligencia artificial y conducción automática del bufete Beijing Deheheng (Shanghai) y socio senior, sobre estos temas.

Abogado Bai Yaohua. Fuente de la imagen: fotos proporcionadas por el entrevistado.

Se debe seguir el principio de “la mínima necesidad” y establecer un paso obligatorio de “confirmación manual” para operaciones de alto riesgo.

NBD: Como “marco de inteligencia artificial de código abierto”, ¿en qué difiere el riesgo legal de OpenClaw respecto a las aplicaciones de modelos grandes tradicionales?

Bai Yaohua: Como “marco de inteligencia artificial de código abierto”, los riesgos legales de OpenClaw son más complejos y preexistentes en comparación con las aplicaciones de modelos grandes convencionales. La principal diferencia radica en que su carácter “de código abierto” genera ambigüedad en los responsables, y su atributo de “agente inteligente” lo transforma de un “generador de información” a un “ejecutor de acciones”, introduciendo nuevos riesgos de pérdida de control y responsabilidad por sus acciones.

Analizando en detalle, los riesgos legales de aplicaciones tradicionales (como chatbots) se concentran principalmente en infracciones de derechos de propiedad intelectual por contenido generado, difusión de información falsa y cumplimiento en el manejo de datos personales. Sin embargo, los riesgos de marcos como OpenClaw son más complejos y se elevan en nivel:

Primero, el riesgo de responsabilidad en red derivado del carácter “de código abierto”. Al permitir que desarrolladores de todo el mundo contribuyan con código y plugins, la responsabilidad por gestión de seguridad y protección de datos se dispersa desde un único operador hacia un ecosistema disperso. La Ley de Ciberseguridad de la República Popular China exige que los operadores de redes establezcan e implementen sistemas de gestión de seguridad. En un ecosistema de código abierto, ¿quién es el “operador”? ¿El desarrollador original del marco, la empresa que realiza desarrollos secundarios o el proveedor de plugins? Todos pueden asumir responsabilidades en diferentes etapas, lo que hace difícil definir claramente quién es responsable.

Segundo, el riesgo de comportamiento asociado al atributo de “agente inteligente”. Mientras que los modelos grandes tradicionales principalmente “hablan”, las aplicaciones impulsadas por marcos de agentes inteligentes “hacen” —pueden operar automáticamente en sistemas externos (como realizar pedidos o eliminar datos). Esto extiende el riesgo del ámbito de “discurso e información” al de “acciones y operaciones”. Si ocurre un error, puede causar pérdidas patrimoniales, incumplimiento contractual o daños al sistema, con consecuencias más directas y sustanciales. Por ello, los desarrolladores y usuarios deben gestionar estos agentes como si fueran “empleados digitales”, estableciendo límites estrictos de permisos y normas de comportamiento.

Para las empresas, recomiendo: al adoptar estos marcos, primero deben clarificar quiénes son los responsables legales en la cadena tecnológica mediante contratos que definan obligaciones y límites de responsabilidad; además, en la gestión interna, deben establecer regulaciones específicas para herramientas de automatización, diferenciándolas de las IA de generación de contenido convencional.

NBD: La mayor particularidad de OpenClaw es que puede no solo responder preguntas, sino también operar automáticamente en páginas web, sistemas y herramientas. ¿Qué implica esto legalmente?

Bai Yaohua: La capacidad de operación automática significa que el agente impulsado por OpenClaw pasa de ser una “herramienta auxiliar” a un “agente de comportamiento”, y su relevancia legal radica en el “alcance de autorización de acciones” y en la “responsabilidad por las consecuencias”. Esto puede activar directamente obligaciones contractuales, responsabilidad por daños y requisitos más estrictos en el cumplimiento de protección de datos.

Este “agente de comportamiento” ya no solo ofrece recomendaciones, sino que puede interactuar directamente con sistemas de terceros en nombre del usuario o desarrollador, generando efectos jurídicos. Por ejemplo:

Primero, puede actuar como ejecutor en contratos. Operaciones automáticas como realizar pedidos o cotizaciones por parte del agente pueden considerarse ofertas o promesas emitidas por el usuario o desarrollador. Una vez que se alcanza un acuerdo, se forma un vínculo contractual. Si hay errores (como cotizaciones incorrectas), pueden derivar en disputas contractuales.

Segundo, puede constituir un acto de procesamiento o acceso a datos. La operación automática implica leer, modificar o eliminar datos en sistemas, lo cual está regulado por la Ley de Seguridad de Datos y la Ley de Protección de Información Personal de China. En particular, si la operación involucra decisiones automatizadas (como ofrecer diferentes precios según datos del usuario), el responsable del tratamiento de datos debe realizar una evaluación de impacto en la protección de datos personales antes de proceder, según el artículo 55 de la Ley de Protección de Información Personal.

Tercero, puede ser el potencial infractor en casos de violación. Si el agente accede sin autorización a sistemas de terceros, elimina datos de forma indebida o difama, sus acciones pueden constituir una infracción a la seguridad de la red, a la propiedad o a la reputación, y la responsabilidad debe atribuirse a quien lo controle.

Para las empresas, recomiendo: definir claramente y de forma concreta los permisos operativos del agente, siguiendo el principio de “la mínima necesidad”, prohibiendo el acceso a sistemas o datos no relacionados con tareas esenciales; además, para operaciones de alto riesgo como contratos, pagos o eliminación de datos, establecer pasos de “confirmación manual” obligatoria, sin permitir que el agente actúe automáticamente en estos casos.

NBD: Si el agente impulsado por OpenClaw comete errores, como eliminar datos por error, realizar pedidos incorrectos, cotizaciones erróneas o emitir declaraciones equivocadas, ¿cómo se debe dividir la responsabilidad?

Bai Yaohua: No existe un estándar único; se debe construir un marco de análisis de culpa en niveles, cuyo núcleo es demostrar mediante pruebas la relación causal entre el daño y la conducta negligente de alguna parte (como defectos de diseño, negligencia en gestión o instrucciones erróneas). Normalmente, involucra a múltiples responsables: el proveedor del marco, los desarrolladores a medida, los proveedores de plugins y el usuario final.

Siguiendo la práctica judicial, la responsabilidad puede distribuirse así:

Primero, la responsabilidad del proveedor del marco o comunidad de código abierto. Generalmente, solo responde por vulnerabilidades de seguridad conocidas y no corregidas en el marco. La violación del acuerdo de código abierto o la responsabilidad civil derivada de defectos en el marco son cuestiones distintas. Si el error no se debe a un defecto fundamental del marco, su responsabilidad puede ser limitada.

Segundo, la responsabilidad del desarrollador o integrador del agente. Son los más propensos a asumir responsabilidad principal. Son responsables del diseño lógico, configuración de permisos y pruebas de seguridad. Si por defectos de diseño (como no incluir doble confirmación en eliminaciones), mal uso del marco o pruebas insuficientes se produce un error, deben responder en consecuencia.

Tercero, la responsabilidad del proveedor de plugins o herramientas externas. Son responsables de la seguridad de sus módulos específicos. Si un plugin malicioso o vulnerable causa un error, el proveedor debe responder.

Cuarto, la responsabilidad del usuario final. Tiene la obligación de supervisar y usar de forma conforme. Si emite instrucciones ambiguas, ignora advertencias de seguridad o no controla los permisos del agente, debe asumir la responsabilidad correspondiente.

Quinto, la extensión del daño. Si el agente es un componente esencial del negocio (como en operaciones automáticas de trading) y un error causa pérdidas, estas deben evaluarse considerando el impacto global en el negocio, no solo los daños directos.

Mi consejo: en contratos de desarrollo o adquisición de agentes, las empresas deben definir claramente las responsabilidades, incluyendo mecanismos de indemnización por defectos de diseño o errores algorítmicos; además, deben mantener registros completos de todas las operaciones y auditorías, que serán clave para determinar responsabilidades posteriormente.

En caso de filtración de datos por uso de OpenClaw, no se descarta que la empresa asuma responsabilidad solidaria.

NBD: Los marcos como OpenClaw dependen mucho de plugins, herramientas externas, automatización en navegadores y entornos de ejecución de código. ¿Qué riesgos legales en ciberseguridad conlleva esto?

Bai Yaohua: Este tipo de arquitectura, altamente dependiente de componentes externos, amplía significativamente la superficie de ataque, generando riesgos en la cadena de suministro, filtración de datos, responsabilidad conjunta por cumplimiento y posibles infracciones a terceros, violando fácilmente las normas de protección de niveles de seguridad cibernética.

Analicemos los principales riesgos:

Primero, el riesgo de ataques en la cadena de suministro. Plugins maliciosos o herramientas contaminadas pueden convertirse en caballos de Troya, permitiendo el robo de datos o el control del sistema. Según el artículo 24 de la Ley de Ciberseguridad, “los proveedores de productos y servicios de red no deben incluir programas maliciosos”. Si el uso de componentes inseguros causa daños a la propia empresa o a terceros, esta puede ser responsable por no haber realizado una revisión prudente.

Segundo, riesgos de filtración de datos y manejo no conforme. Plugins y herramientas automatizadas pueden recopilar y transmitir datos sensibles sin que el usuario lo sepa. Si no se informa claramente y no se obtiene el consentimiento, se viola la Ley de Ciberseguridad en los artículos 43 y 44 sobre recolección y uso de información personal.

Tercero, responsabilidad conjunta por cumplimiento. Según el artículo 27 de la Ley de Seguridad de Datos, los responsables del tratamiento de datos deben establecer sistemas de gestión de seguridad en toda la cadena. Si una empresa usa agentes con múltiples componentes externos, legalmente puede considerarse que realiza una “actividad de tratamiento de datos” unificada. Si alguna vulnerabilidad provoca una filtración, la organización en su conjunto puede ser sancionada.

Cuarto, riesgos de infracción a terceros. La automatización del agente (como scraping masivo) puede exceder los límites razonables y constituir acceso no autorizado a sitios o sistemas de terceros, incluso ser considerado un ataque cibernético.

Mi recomendación: establecer un sistema estricto de “lista blanca” para plugins, permitiendo solo aquellos auditados y confiables; además, aislar el entorno del agente en una sandbox, limitando su acceso a la red para evitar que una vulnerabilidad afecte la red principal.

Para las empresas, sugiero: gestionar estrictamente los plugins mediante una “lista blanca”, solo permitiendo los provenientes de fuentes oficiales o confiables; además, aislar el entorno del agente en una red separada, limitando su acceso a recursos críticos.

NBD: Para los usuarios empresariales que quieran usar OpenClaw, ¿qué recomendaciones de cumplimiento legal tienen?

Bai Yaohua: Las empresas deben gestionar la conformidad como si administraran “empleados digitales”, construyendo un sistema de gestión de riesgos que abarque desde evaluación de acceso, control de permisos, auditorías de procesos y respuesta a emergencias, y formalizando obligaciones clave en contratos.

En la fase de acceso, realizar una diligencia profunda. Revisar cuidadosamente las licencias de código abierto de OpenClaw y sus plugins, verificando restricciones comerciales y obligaciones de código abierto; firmar contratos claros con los desarrolladores a medida, especificando estándares funcionales, requisitos de seguridad, propiedad intelectual, límites de responsabilidad y mecanismos de compensación.

En la fase de despliegue, aplicar los principios de menor privilegio y aislamiento. Asignar solo los permisos necesarios para cumplir tareas específicas, y en escenarios de alto riesgo, usar entornos de prueba aislados, verificando exhaustivamente antes de desplegar en producción.

Durante la operación, garantizar registros completos y la posibilidad de intervención. Primero, mantener logs detallados de decisiones, acciones y resultados del agente, con un período de conservación que cumpla con al menos seis meses según la Ley de Ciberseguridad. Segundo, establecer revisiones manuales para operaciones críticas, como transacciones financieras, contratos o eliminación de datos sensibles, con aprobaciones o confirmaciones obligatorias. Tercero, realizar evaluaciones periódicas de seguridad, incluyendo escaneos y auditorías de cumplimiento, especialmente en componentes de terceros.

Además, preparar planes de contingencia y respaldo. Por un lado, definir procedimientos de respuesta rápida ante comportamientos anómalos del agente (como órdenes masivas o filtraciones). Por otro, considerar la contratación de seguros cibernéticos o de responsabilidad de productos para mitigar riesgos de indemnizaciones elevadas.

Creo que la tecnología que representa OpenClaw tiene un gran potencial, pero también implica riesgos legales en escalas exponenciales. Las empresas que innovan deben construir simultáneamente un marco legal y de cumplimiento riguroso para poder avanzar con seguridad.