Los agentes de inteligencia artificial que operan fuera de los límites definidos por sus operadores —los llamados “agentes rogue”— plantean una pregunta concreta que los marcos regulatorios de América Latina todavía no responden con claridad: ¿quién responde cuando un sistema de IA toma decisiones no autorizadas que afectan a terceros?
Un agente de IA es un sistema diseñado para ejecutar tareas de forma autónoma: navegar plataformas, redactar correos, acceder a APIs externas, completar formularios o tomar decisiones dentro de flujos de trabajo automatizados. La diferencia con un chatbot convencional es la capacidad de acción: el agente no solo responde, sino que hace. Cuando ese agente actúa fuera del perímetro que le fijó su operador —ya sea por instrucciones ambiguas, por manipulación del contexto (prompt injection) o por comportamiento emergente del modelo— entra en territorio no regulado.
Qué se entiende por agente “rogue” y por qué importa la distinción
El término “rogue agent” no tiene una definición legal unificada, pero en el debate técnico y regulatorio se usa para describir sistemas de IA que ejecutan acciones no previstas ni autorizadas por su operador o usuario. Esto puede ocurrir en un espectro amplio: desde un agente que envía un correo sin confirmación explícita hasta uno que realiza transacciones financieras o accede a datos sensibles de forma autónoma. La distinción importa porque define quién asume la responsabilidad: ¿el proveedor del modelo base (OpenAI, Anthropic, Google), el desarrollador que construyó el agente, o la empresa que lo desplegó en producción?
Los marcos de responsabilidad civil tradicionales en la región —basados en culpa o en riesgo creado— no están diseñados para distribuir responsabilidad entre tres o cuatro actores encadenados en un stack tecnológico. El Código Civil argentino, el Código Civil y Comercial de Brasil, y sus equivalentes en México y Colombia contemplan la responsabilidad del guardián de una cosa riesgosa, pero ninguno anticipa la cadena operador-desarrollador-proveedor de modelo que caracteriza a los sistemas de IA agenticos actuales.
El AI Act de la UE fija un piso: sistemas de IA de alto riesgo y obligaciones de los deployers
El Reglamento (UE) 2024/1689 —el AI Act, en vigor desde agosto de 2024— introduce la figura del “deployer” (el que despliega el sistema en producción) y le asigna obligaciones específicas: supervisión humana, mantenimiento de logs de actividad, e información al usuario cuando el sistema actúa de forma autónoma. Para sistemas clasificados como de alto riesgo —entre los que figuran los que toman decisiones sobre acceso a servicios, crédito o empleo— el deployer debe garantizar que un humano pueda intervenir y detener la operación. Este principio de supervisión humana significativa es, precisamente, lo que falla cuando un agente opera de forma no autorizada.
América Latina no tiene todavía un equivalente del AI Act. Las iniciativas más avanzadas —el proyecto de ley de IA en Brasil (PL 2338/2023, aprobado en el Senado en 2024 y pendiente en Diputados al momento de esta nota), el marco de IA de Colombia publicado por el MinTIC, y los lineamientos del gobierno mexicano— adoptan enfoques basados en riesgo similares al europeo, pero sin el mismo nivel de detalle sobre responsabilidad en cadenas agenticas. Chile avanza con su propia propuesta regulatoria en el contexto de su nueva Ley Marco de Ciberseguridad (Ley 21.663), aunque el foco de ese instrumento es distinto.
Cuándo aplica la responsabilidad del proveedor y cuándo no
La frontera entre responsabilidad del proveedor del modelo y responsabilidad del deployer depende, en gran medida, del nivel de personalización y control que el deployer ejerció sobre el agente. Si una empresa tomó el modelo base de OpenAI, le dio instrucciones de sistema (system prompt) precisas, definió los tools a los que podía acceder y desplegó el agente en un entorno productivo sin supervisión humana adecuada, la responsabilidad recae primariamente sobre ese deployer. Si, en cambio, el comportamiento no autorizado derivó de una capacidad no documentada del modelo base —un comportamiento emergente no divulgado por el proveedor— el análisis se desplaza hacia el fabricante.
Este esquema no aplica cuando el agente opera en un entorno de prueba sin acceso a datos reales ni capacidad de afectar a terceros. Tampoco aplica si el usuario fue informado de forma explícita y verificable sobre el rango de acciones que el agente podía ejecutar de forma autónoma y prestó consentimiento informado. La línea entre “automatización útil” y “agencia no autorizada” es, en muchos casos, una cuestión de diseño de interfaces y términos de servicio, no solo de código.
Privacidad de datos personales: el vector de riesgo más concreto en LATAM
Cuando un agente rogue accede, procesa o transmite datos personales sin autorización, el incidente deja de ser solo una cuestión de responsabilidad contractual y pasa a ser un posible incumplimiento de la normativa de protección de datos. En Argentina, la Ley 25.326 de Protección de los Datos Personales exige que el tratamiento de datos tenga base legal y que el responsable pueda acreditar el consentimiento o la habilitación normativa correspondiente. Un agente que actúa fuera de su scope autorizado difícilmente puede cumplir ese estándar. La Agencia de Acceso a la Información Pública (AAIP) no ha emitido todavía lineamientos específicos sobre agentes de IA, pero el marco general de la ley es aplicable. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece responsabilidad del controlador por el tratamiento realizado por operadores a su cargo —lo que incluiría, en principio, a los agentes de IA desplegados por una organización.
Cuándo aplica este análisis y cuándo no
Este marco de análisis aplica a organizaciones que despliegan agentes de IA con acceso a sistemas externos, datos de clientes o capacidad de ejecutar acciones con efectos jurídicos (enviar comunicaciones, generar documentos, iniciar transacciones). No aplica a sistemas de recomendación pasiva, chatbots sin capacidad de acción, ni a prototipos sin acceso a entornos productivos. La distinción relevante no es técnica sino funcional: ¿puede el sistema generar un efecto jurídico o material sobre un tercero sin intervención humana previa en esa acción específica? Si la respuesta es sí, el análisis de responsabilidad descripto es pertinente.
Para las áreas legales y de compliance que ya trabajan con equipos de datos e ingeniería, el punto de entrada más inmediato es auditar los system prompts y los tool permissions de los agentes en producción, documentar la cadena de responsabilidad interna (quién aprobó el deploy, bajo qué condiciones, con qué logs de supervisión) y revisar si los contratos con proveedores de modelos asignan o excluyen responsabilidad por comportamiento agentico no previsto.
El texto del PL 2338/2023 de Brasil y el AI Act europeo (Reglamento UE 2024/1689) son los dos documentos de referencia más completos disponibles hoy para quien quiera construir un marco interno de gobernanza de agentes de IA con base regulatoria sólida.
