Riesgo estructural en sistemas LLM con autonomía y herramientas

Riesgo estructural en sistemas LLM con autonomía y herramientas

La conversación pública sobre IA todavía gira alrededor del “modelo”: si alucina, si razona, si está sesgado. Pero la frontera real del riesgo ya se movió. El problema no es solo lo que el modelo dice, sino lo que un agente hace cuando se le conecta a herramientas, memoria persistente y canales reales de comunicación.

El preprint Agents of Chaos (arXiv:2602.20021) publicado por investigadores de diversas universidades, entre ellas Stanford, Harvard y el MIT, documentó un punto crucial: cuando un modelo de lenguaje (LLM, por sus siglas inglés) deja de ser un asistente conversacional y se convierte en un agente autónomo con acceso a correo electrónico, Discord, sistema de archivos y ejecución de comandos, el conjunto adquiere vulnerabilidades que no se explican por “errores de texto”, sino por la arquitectura que integra lenguaje + autonomía + herramientas + persistencia.

Lo “obvio” que no alcanza con saber

Los científicos no solo descubrieron que tipo de riesgos presentan los agentes de IA, también mostraron cómo aparecen bajo condiciones sorprendentemente comunes: solicitudes indirectas, confusión de autoridad, memoria persistente, multiusuario y inconsistencias entre “lo que el agente reporta” y “lo que el sistema realmente hizo”.

Los autores despliegaron agentes basados en OpenClaw en un entorno de laboratorio “vivo”, con agentes corriendo 24/7, memoria persistente, cuentas de email y comunicación por Discord; y documentan once estudios de caso con fallas relevantes para seguridad, privacidad y gobernanza.

Los comportamientos observados incluyeron, entre otros:

  • Cumplimiento con instrucciones de no-propietarios (non-owners), incluso cuando no hubo una justificación clara para beneficiar al owner.

  • Divulgación de información sensible por vías indirectas: no porque el agente “quiera filtrar”, sino porque al reenviar correos “para dar contexto” terminó exponiendo datos.

  • Acciones desproporcionadas: agentes que “protegen” un secreto ejecutando cambios destructivos a nivel de sistema (por ejemplo, dañando su propia configuración de correo), creyeron haber resuelto un problema de confidencialidad.

  • Bucle de recursos y persistencia accidental: tareas que se conviertieron en procesos sin condición de término (loops, cron jobs, monitoreos infinitos), con consumo sostenido de tokens y recursos.

  • Desacople entre reporte y estado: el agente afirmó haber completado una tarea, pero el estado del sistema contradijo esa afirmación, lo que conviertió la “coherencia narrativa” en una fuente de riesgo operativo.

El punto de fondo es que estos fallos emergieron en la interfaz: autoridad, identidad, permisos, herramientas y memoria. Es decir, en la capa agentica.

L2: agentes que actúan, pero no se saben límites

En el paper  los investigadores utilizaron una escala de autonomía para ubicar a estos agentes cerca de un nivel L2: donde ejecutaron subtareas de forma autónoma (enviar emails, correr comandos, manejar archivos), pero carecieron de la capacidad consistente de detectar cuándo debían detenerse, pedir verificación o transferir control.

Ese “punto ciego” fue central, porque en sistemas con herramientas, el error deja de ser una frase equivocada y se convierte en una modificación persistente.

Responsabilidad: ¿quién responde por el daño?

Al documentar fallas en escenarios multiusuario y multicanal, el paper aterriza una pregunta que hoy está abierta en despliegues reales: cuando un agente filtra datos o ejecuta acciones destructivas, ¿quién es responsable?: El proveedor (por el modelo y sus restricciones/valores), el owner (por permisos y configuración), o el tercero que interactúa (por ingeniería social o abuso de la superficie de ataque).

Los autores plantean que esto requiere atención urgente de investigación técnica, derecho y política pública.

Cuatro rutas para salir del “agente monolítico con acceso total”

El diseño “LLM + wrapper + todas las herramientas + persistencia” no es el único camino. A continuación, cuatro vías alternativas que podrían reducir riesgo sin renunciar por completo a la potencia operativa:

Micro-agentes con capacidades acotadas

Una primera alternativa consiste en abandonar el modelo de agente generalista con acceso amplio a herramientas y sustituirlo por una arquitectura fragmentada basada en micro-agentes especializados. En este enfoque, cada agente opera bajo el principio de menor privilegio: dispone únicamente de los permisos estrictamente necesarios para ejecutar su función específica, utiliza un conjunto reducido de herramientas y mantiene superficies de interacción cuidadosamente delimitadas.

Esta segmentación reduce las rutas de escalamiento y limita el impacto potencial de fallas o abusos. Al impedir que un solo agente concentre múltiples capacidades críticas, se minimiza la probabilidad de que errores locales se conviertan en consecuencias sistémicas. Desde la perspectiva de la seguridad, la distribución controlada de capacidades suele ser más robusta que la centralización de acceso bajo una única instancia con facultades amplias.

Supervisión estructural con intervención humana (Human-in-the-loop)

Una segunda vía implica reforzar la supervisión humana no como validación superficial al final del proceso, sino como componente estructural del sistema. El análisis presentado en Agents of Chaos sugiere que muchos de los daños documentados no emergen de decisiones abiertamente maliciosas, sino de secuencias acumulativas de acciones que, consideradas aisladamente, parecen razonables, pero en conjunto cruzan umbrales críticos.

Un enfoque más robusto introduce puntos de control explícitos antes de la ejecución de acciones irreversibles —como la eliminación de información, la modificación de credenciales o la creación de procesos persistentes—, ante solicitudes provenientes de terceros sin autoridad verificable, en situaciones donde se detecte ambigüedad de legitimidad, y cuando el agente no pueda confirmar de manera fiable el estado real del sistema. Este diseño puede ralentizar la operación, pero incrementa significativamente la gobernabilidad y la trazabilidad de las decisiones.

Agentes con conciencia del estado del sistema (state-aware agents)

Uno de los hallazgos más delicados del estudio es el desacople entre la representación lingüística del éxito y la realidad operativa del sistema. El agente puede afirmar que una acción ha sido completada —por ejemplo, la eliminación de información sensible— sin que el estado subyacente haya cambiado efectivamente. Este desfase constituye un riesgo estructural.

Los llamados agentes state-aware buscan reducir esta brecha mediante mecanismos explícitos de verificación. Antes y después de ejecutar una acción, el sistema consulta el estado real de los recursos involucrados, valida efectos observables, registra auditorías detalladas y, en caso de incertidumbre o inconsistencia, adopta un modo de fallo seguro en lugar de asumir cumplimiento exitoso. Este enfoque desplaza el énfasis desde la coherencia narrativa hacia la comprobación empírica del resultado, introduciendo una capa adicional de consistencia entre representación y ejecución.

Orquestación multi-modelo y separación funcional de roles

Una cuarta alternativa cuestiona la premisa de que un único modelo deba planificar, ejecutar y justificar sus propias acciones. En su lugar, propone una arquitectura de orquestación en la que distintas instancias cumplen funciones diferenciadas. Un modelo puede encargarse de la planificación estratégica; otro, de la validación y evaluación de riesgos; un tercero, de la ejecución con permisos acotados; y una capa adicional puede desempeñar funciones de auditoría y monitoreo de consistencia, ciclos anómalos o patrones de abuso.

Esta separación funcional introduce redundancia deliberada y reduce la probabilidad de que un único error se propague sin control. Además, facilita la trazabilidad, ya que permite identificar con mayor precisión en qué etapa del proceso se produjo una desviación. En sistemas complejos, la distribución de responsabilidades suele incrementar la resiliencia frente a fallos emergentes.

Esto reduce bucles, alinea controles y permite trazabilidad: cuando algo falla, se puede rastrear en qué capa falló.