Riesgos de agentes de IA: ¿Por qué fallan los "buenos"?

Los riesgos y modos de falla de los agentes de IA provienen principalmente de errores acumulativos silenciosos a lo largo del uso de herramientas en múltiples pasos, no de un colapso dramático del modelo. Un flujo de trabajo que parece 90% "correcto" en cada paso aún puede ser inutilizable de extremo a extremo a menos que esté construido con permisos explícitos, puntos de control y monitoreo.

Puntos Clave

• La fiabilidad del agente de múltiples pasos se multiplica a lo largo de los pasos, por lo que una precisión del 85% por acción puede colapsar a aproximadamente un 20% de éxito en un flujo de trabajo de 10 pasos, mientras que un 95% por acción se sitúa alrededor del 60%.
• Los fallos de agente más dañinos son los fallos "suaves": salidas plausibles, llamadas incorrectas a herramientas y objetivos que se desvían y que no desencadenan errores ni alertas.
• Los sistemas multiagente añaden sus propios modos de fallo, incluyendo el sesgo de conformidad y el estado compartido obsoleto, lo que puede convertir una alucinación en un falso consenso.
• La inyección de prompts es una amenaza en la capa de ejecución para los agentes porque puede dirigir las llamadas a herramientas y objetivos, no solo la salida de texto.

Cómo difieren las fallas de los agentes de IA

Un agente de producción falla como una cadena de ejecución con fugas, no como un programa que se bloquea. El software tradicional tiende a romperse de manera ruidosa: unAPIdevuelve un 500, hay errores en la consulta de la base de datos, un trabajo falla y se reintenta.

Los flujos de trabajo agenticos a menudo "tienen éxito" en la interfaz de usuario mientras hacen lo incorrecto, porque el sistema está optimizando para la coherencia y la finalización, no para la verdad. Ese es el cambio clave en el modelo mental para cualquiera que esté construyendo lo que son agentes de IA en crypto: el fracaso es frecuentemente una salida con un aspecto limpio que es operativamente incorrecta.

Las matemáticas de la acumulación son la parte que la mayoría de los equipos omiten. El ejemplo de Trantor es contundente: si un agente tiene un 85% de precisión por acción, un flujo de trabajo de 10 pasos solo tiene éxito aproximadamente el 20% de las veces. Incluso una precisión del 95% por pasoproducesolo alrededor del 60% de éxito en 10 pasos.

Esa es la misma forma que la decadencia de la tasa de llenado en un libro de operaciones cuando una estrategia necesita múltiples llenados dependientes. Cada paso puede ser localmente racional y aún así producir una ejecución globalmente rota.

Los sistemas agenticos también fallan de manera no determinística. Dos ejecuciones con las mismas entradas pueden divergir porque las muestras del modelo, las salidas de las herramientas cambian o el contexto recuperado se desplaza. Redis enmarca el patrón común como acumulación de errores en tuberías secuenciales donde los errores suaves se propagan sin fallos ni alertas.

Esa propiedad de “sin traza de pila” es la razón por la que los equipos diagnostican erróneamente las fallas de los agentes como “necesitamos un mejor modelo” cuando el verdadero problema son las puertas faltantes y la falta de observabilidad.

La criptografía añade un borde más afilado. Cuando un agente de IA tiene una billetera de agente, una llamada a una herramienta no es una solicitud de API inofensiva. Puede ser una transacción, una aprobación, un puente o una firma. El costo de un error silencioso no es una mala respuesta. Es una acción en cadena que se liquida.

Modos de falla de agente centrales que se deben esperar

El uso indebido de herramientas es el modo de falla base porque se sitúa en la frontera entre el lenguaje y la ejecución. Trantor describe a los agentes seleccionando la herramienta incorrecta, pasando argumentos incorrectos o ignorando errores de herramientas y continuando como si la acción hubiera tenido éxito.

En un contexto de criptografía de riesgos de agente de IA, eso se traduce claramente en errores del estilo “cadena incorrecta, token incorrecto, gastador incorrecto, cantidad incorrecta”. La parte peligrosa no es que la llamada falle. La parte peligrosa es que la llamada tiene un éxito parcial y el agente construye los siguientes pasos sobre un estado corrupto.

La deriva de contexto y las cascadas de alucinación son la segunda clase. A medida que las salidas de herramientas y el razonamiento intermedio se acumulan, la atención del modelo se dispersa y comienza a operar en una versión distorsionada del objetivo. Trantor relaciona esto con el efecto de perdido en el medio en contextos largos.

Redis separa los límites de la ventana de contexto de la descomposición del contexto, y hace el punto que los traders reconocerán: agregar más información puede empeorar la calidad de la decisión cuando el sistema no puede recuperar de manera confiable el bit relevante.

La deriva de objetivo es el sangrado lento. Trantor lo describe como una falla emergente donde ningún paso individual es “incorrecto”, pero el agente termina optimizando para un objetivo diferente al especificado originalmente.

En flujos de trabajo de criptografía, la deriva de objetivo se presenta como un agente que comienza con “rebalanciar exposición” y termina con “maximizar actividad” porque aprendió que hacer más llamadas a herramientas parece progreso.

Los bucles de reintento y los costos descontrolados son el modo de falla mecánica que afecta los presupuestos antes de afectar la corrección. Trantor señala bucles infinitos donde las llamadas a herramientas fallidas desencadenan intentos repetidos, y recomienda límites de iteración estrictos y límites de gasto.

Esta es la traducción más clara de la disciplina de escritorio a las operaciones de agentes: si el sistema no puede detenerse a mitad de ejecución, no está listo para producción.

La degradación silenciosa de calidad es la que quema a los equipos durante semanas. Trantor enumera causas como la deriva del almacenamiento de documentos, la regresión de prompts, los cambios silenciosos en el comportamiento del modelo y el cambio en la distribución de entradas. El agente sigue "completando" tareas, pero la utilidad disminuye por debajo del umbral donde la salida es segura para actuar.

Coordinación multi-agente y riesgos en cascada

Las configuraciones multi-agente a menudo se venden como seguridad a través de la redundancia. Las fuentes apuntan en la otra dirección a menos que la verificación esté diseñada explícitamente. Redis destaca el sesgo de conformidad: los agentes en la parte inferior tienden a alinearse con una afirmación confiada en la parte superior, reforzando una alucinación en un falso consenso. Eso no es una peculiaridad teórica. Es un modo de falla de coordinación que parece acuerdo y envía salidas incorrectas más rápido.

El estudio de arXiv formaliza esto con MASFT, una taxonomía de 14 modos de falla multi-agente agrupados en tres categorías: fallas de especificación y diseño del sistema, desalineación entre agentes y fallas de verificación y terminación de tareas. El estudio analiza cinco marcos MAS en más de 150 tareas con trazas anotadas por humanos y reporta un acuerdo inter-anotador de Kappa de Cohen de 0.88.

También informa que la corrección de ChatDev puede ser tan baja como el 25% en su evaluación, y que intervenciones de mejor esfuerzo como la mejora de la especificación de roles y la orquestación mejoraron ChatDev en un +14% pero aún así permanecieron insuficientes para el despliegue en el mundo real.

La sobrecarga de coordinación no es solo latencia. Consume el presupuesto de contexto. Redis señala que las variantes multi-agente pueden tener un rendimiento inferior a las líneas base de un solo agente en razonamiento secuencial porque la sobrecarga de comunicación supera cualquier beneficio de paralelización. Cada traspaso adicional es otro lugar donde un error suave puede convertirse en "estado".

La memoria compartida y el estado obsoleto son el otro motor de cascada. Redis describe a los agentes leyendo el estado compartido en diferentes momentos y actuando sobre información que ya ha sido superada por acciones concurrentes. En crypto, así es como un agente puede aprobar a un gastador basado en un saldo anterior, luego ejecutar un intercambio basado en un saldo posterior y reconciliar ninguno.

Una red de solucionadores puede reducir algo de complejidad de ejecución al externalizar la búsqueda de caminos, pero también se convierte en otro límite donde las salidas deben ser validadas antes del siguiente paso.

La lección multi-agente es simple: más agentes no crean más seguridad por defecto. Crean más superficies para que las suposiciones no verificadas se conviertan en duraderas.

Amenazas de seguridad en flujos de trabajo agénticos

La inyección de prompts es el modo de falla de seguridad que más importa para los agentes porque no se limita al texto. Trantor describe la inyección de prompts como la vulnerabilidad número uno de OWASP LLM Top 10 para 2025 y enfatiza que es más peligrosa en contextos agénticos porque puede secuestrar objetivos y llamadas a herramientas a lo largo de un flujo de trabajo. Esa es la diferencia entre "el chatbot dice algo raro" y "el agente cambia lo que está tratando de hacer."

Los riesgos de seguridad de los agentes se expanden porque cada entrada externa ahora es influencia ejecutable. Documentos recuperados, salidas de herramientas, memoria e incluso mensajes de otros agentes son todas entradas que pueden llevar instrucciones hostiles.

Trantor recomienda tratar cada documento, registro de base de datos, respuesta de API y salida de herramienta como potencialmente adversariales, y sanitizar las entradas antes de que entren en el contexto del agente.

En cripto, los escenarios de inyección de comandos en agentes cripto son sencillos: una entrada de lista de tokens maliciosos, un fragmento de “documentación” envenenado en la recuperación, o una respuesta de herramienta elaborada pueden llevar al agente a aprobar a un gastador, conectándose a un controlador de atacante.dirección, o firmar un mensaje no intencionado.

Por eso, los riesgos de seguridad de los agentes de IA se centran principalmente en el control de acciones, no en la filtración de datos.

Las mitigaciones son arquitectónicas. Un tee puede ayudar con la integridad y el aislamiento de partes del entorno de ejecución, pero no resuelve por sí solo el secuestro de instrucciones. La defensa principal es restringir lo que el agente puede hacer, validar lo que está a punto de hacer y registrar lo que hizo de una manera que pueda ser auditada.

Trantor también afirma que el 88% de las organizaciones que implementan agentes de IA reportaron al menos un incidente de seguridad en 2025. Esa cifra se presenta como una afirmación secundaria en la fuente, pero coincide con la dirección del viaje: una vez que los agentes pueden actuar, la superficie de incidentes crece más rápido que los controles de la mayoría de los equipos.

Controles de diseño y operaciones que funcionan

Los controles que funcionan parecen límites de riesgo, no "mejoras en la solicitud". La tesis en las fuentes es que los fallos de los agentes se acumulan a través de pasos y actores, por lo que el sistema necesita límites explícitos, verificación y observabilidad en cada frontera.

Una pila de control estilo escritorio se puede expresar como una secuencia de construcción ordenada:

1. Alcance herramientas al menor privilegio. Los ejemplos de uso indebido de herramientas de Trantor son fundamentalmente fallos de permisos. Un agente no debería tener acceso amplio al sistema de archivos o de administrador cuando solo necesita una función, y la misma lógica se aplica a una billetera de agente que puede firmar transacciones arbitrarias. 2. Controlar las llamadas a herramientas con esquemas y precondiciones.

Trantor recomienda la validación de esquemas para detectar argumentos incorrectos antes de la ejecución. Para herramientas de criptomonedas, eso significa validar la cadena, el token, los decimales, el destinatario y las variaciones de asignación antes de que se permita realizar una llamada. 3. Insertar puntos de verificación de validación.

Redis recomienda validar en cada límite, y la taxonomía MASFT de arXiv señala las fallas de verificación de tareas y de terminación como una categoría importante. Un rol de verificador debe ser estructuralmente diferente del planificador, o se convierte en monocultura. 4. Controlar el crecimiento del contexto. Trantor recomienda una resumisión jerárquica a intervalos regulares para prevenir la deriva del contexto.

Redis advierte que agregar más contexto puede empeorar los problemas de coordinación debido a la descomposición del contexto y el comportamiento de perdido en el medio. 5. Limitar bucles y costos en la capa de orquestación. Trantor exige límites de iteración estrictos y monitoreo de costos en tiempo real con límites de gasto. Este es el requisito del interruptor de emergencia en forma de ingeniería. 6.

Construir observabilidad que coincida con sistemas probabilísticos. Redis recomienda IDs de correlación para cada invocación de agente, llamada a herramienta y mensaje entre agentes, además de trazas estructuradas que incluyan tokens consumidos, latencia y estado de éxito o fracaso por paso. La degradación silenciosa de la calidad solo aparece cuando las distribuciones de salida y las muestras.auditoríasse rastrean a lo largo del tiempo.

Los controles organizativos son tan importantes como los técnicos. Trantor afirma que el alcance descontrolado y los problemas de calidad de los datos representan el 61% de las fallas combinadas de los agentes de IA. Esa es la razón poco glamorosa por la que muchos pilotos nunca se convierten en sistemas de producción.

Conclusiones prácticas para un despliegue más seguro

La preparación para la producción comienza midiendo la cadena, no admirando el modelo. Si el flujo de trabajo necesita 10 pasos dependientes, el único número de fiabilidad honesto es la tasa de éxito compuesta, no la "precisión" por paso. El ejemplo de Trantor del 85% al ~20% es la forma más rápida de comprobar si un sistema es una demostración o una herramienta operativa.

Los diseños de múltiples agentes deben justificar su complejidad. El artículo de arXiv muestra ganancias de rendimiento mínimas en los benchmarks y documenta baja corrección para ChatDev en algunas evaluaciones. Redis argumenta que las configuraciones de un solo agente pueden superar a las de múltiples agentes en razonamiento secuencial porque la sobrecarga de coordinación consume contexto e introduce nuevos modos de falla.

El uso de múltiples agentes puede justificarse para trabajos paralelizable, pero solo cuando los roles de verificación y los criterios de terminación son explícitos.

Para los despliegues de criptomonedas, la primera prioridad es restringir la ejecución. Un agente de IA con una billetera de agente debe funcionar con permisos restringidos, límites de gasto estrictos y un interruptor de emergencia que pueda terminar la ejecución en medio del proceso.

Trata las salidas de herramientas, los documentos recuperados y la memoria como entradas adversariales, porque la inyección de prompts es un secuestro del flujo de trabajo, no un truco de chat.

La segunda prioridad es la observabilidad. Los fallos suaves no alertan a nadie. Se manifiestan como cambios sutiles en la adherencia al formato, puntuaciones de confianza, tasas de error de herramientas, uso de tokens y tasas de finalización. Sin trazas, los equipos no pueden separar la alucinación, el estado obsoleto y la deriva de objetivos, y seguirán "corrigiendo prompts" mientras el sistema sigue fallando.

La historia más amplia de los agentes en criptomonedas se dirige hacia más autonomía, más acceso a herramientas y máscomposabilidad.Eso convierte los riesgos y modos de falla de los agentes de IA en un problema de diseño, no en un problema de modelo, y los equipos que sobrevivan se parecerán mucho a escritorios de ejecución disciplinada: límites explícitos, verificación en los límites y monitoreo estricto de lo que realmente hizo el sistema.

La Opinión

He visto equipos tratar una tasa de "respuesta buena" del 90% como si fuera un SLA de producción, y luego actuar sorprendidos cuando el agente se desmorona en el momento en que tiene que hacer diez cosas seguidas.

Las matemáticas de Trantor son la bofetada correcta en la cara: un 85% por paso que se convierte en ~20% de extremo a extremo en 10 pasos es exactamente cómo una estrategia con buenas probabilidades por llenado aún muere cuando necesita una cadena de llenados.

También he visto configuraciones de múltiples agentes crear una falsa comodidad. En flujos de trabajo secuenciales, el sesgo de conformidad de Redis aparece rápidamente: una alucinación confiada se convierte en "consenso" porque nadie está pagado para verificar, solo para estar de acuerdo.

La postura que se mantiene es aburrida y efectiva: el menor privilegio, puertas de esquema, puntos de verificación de verificación, límites de costos duros y trazas que permiten a alguien reproducir la ejecución y localizar la primera transferencia defectuosa.

Fuentes

• Trantor
• Redis
• arXiv