Los agentes de IA rara vez se bloquean. Fallan en silencio, y la investigación explica por qué

Los agentes basados en modelos de lenguaje de gran tamaño ahora responden a solicitudes de soporte, consultan bases de datos y planifican viajes. Cuando algo sale mal, suelen devolver una respuesta segura y un código de éxito. Un número creciente de investigaciones explica por qué estos fallos son difíciles de detectar y cómo los equipos de ingeniería están aprendiendo a medirlos.

Un fallo que parece un éxito

El software tradicional tiende a fallar de forma evidente. Una función genera una excepción, un servidor devuelve un código de error y un panel de monitorización se pone en rojo. Un agente de IA se comporta de otra manera. Funciona en bucle: un modelo de lenguaje lee una instrucción, decide llamar a una herramienta, como una API de búsqueda o una base de datos, lee el resultado y decide qué hacer a continuación. Cada paso puede fallar aunque todas las solicitudes de red de la cadena se completen correctamente.

Veamos un caso habitual. Una herramienta meteorológica falla y devuelve el texto «servicio no disponible» dentro de una respuesta que, por lo demás, parece normal. El modelo lee ese texto, se disculpa con cortesía o, peor aún, redacta un pronóstico verosímil a partir de los datos con los que se entrenó. El usuario recibe una respuesta fluida. Los registros del servidor muestran una solicitud correcta y una latencia normal. Ningún elemento de un sistema de monitorización convencional registra que algo haya salido mal.

Los proveedores de modelos describen esa misma brecha en su propia documentación. La guía de Google sobre la API de Gemini señala que el modelo «no ejecuta la función por sí mismo». Solo propone el nombre de una función y sus argumentos; la aplicación del desarrollador es la que realiza la llamada. Por tanto, la aplicación es la única parte del sistema que ve el resultado real. La guía de ingeniería de Anthropic para crear agentes plantea una idea relacionada: los agentes necesitan «la verdad sobre el terreno» del entorno en cada paso, por ejemplo, los resultados de las herramientas, para evaluar su propio progreso. Cuando una herramienta comunica un fallo como texto corriente, esa información no refleja la realidad y el agente no tiene forma de advertirlo.

No se trata de un problema nuevo, sino de una versión más aguda de uno antiguo. En 2015, ingenieros de Google liderados por D. Sculley describieron la «deuda técnica oculta» en los sistemas de aprendizaje automático. Sostenían que la mayor parte del riesgo en un sistema de aprendizaje automático en producción reside fuera del código del modelo, en las dependencias de datos, la configuración y el código de integración. Los agentes añaden una nueva capa a esa lista. Las instrucciones y las descripciones de las herramientas son elementos de configuración que pueden cambiar el comportamiento de un sistema sin modificar su código.

Pequeños cambios, grandes efectos

¿Hasta qué punto puede importar un pequeño cambio en una instrucción? En un artículo presentado en ICLR 2024, Melanie Sclar, de la University of Washington, y sus colegas modificaron únicamente el formato de las instrucciones con ejemplos de referencia: los separadores, los espacios y el uso de mayúsculas. El significado se mantuvo igual. Aun así, el rendimiento en la misma tarea varió hasta 76 puntos porcentuales de exactitud en LLaMA-2-13B. La sensibilidad no desapareció con modelos más grandes, más ejemplos ni el ajuste mediante instrucciones.

Los autores recomiendan informar de un intervalo de rendimiento para distintos formatos plausibles de instrucciones, en lugar de dar una sola cifra. Para los equipos de ingeniería, la lección práctica es más sencilla: modificar una instrucción equivale a cambiar el código. El cambio necesita un historial de versiones y debe someterse a pruebas antes de llegar a los usuarios.

Lo mismo se aplica a las descripciones de las herramientas, que el modelo lee como parte de sus instrucciones. La guía de Anthropic recomienda dedicar a las definiciones de las herramientas «la misma atención de ingeniería de instrucciones» que a la instrucción principal. Describe un agente de programación que cometía errores constantemente con las rutas relativas de los archivos. Cuando se modificó la herramienta para que exigiera rutas absolutas, el modelo empezó a utilizarla sin errores. El modelo no cambió; solo cambió la descripción que leía.

Un solo éxito no demuestra mucho

Otra línea de investigación estudia la consistencia. La prueba de referencia τ-bench, publicada por Shunyu Yao y sus colegas de Sierra y presentada en ICLR 2025, simula conversaciones de atención al cliente en las que un agente debe usar herramientas y seguir las reglas de una empresa. Los autores introdujeron una métrica llamada pass^k: la probabilidad de que un agente resuelva correctamente la misma tarea en los k intentos.

Los resultados fueron poco alentadores. Un agente GPT-4o resolvió alrededor del 61 % de las tareas minoristas en un solo intento. Cuando tenía que completar con éxito la misma tarea ocho veces seguidas, la tasa bajaba a alrededor del 25 %. Una demostración que funciona una vez dice poco sobre cómo se comporta un sistema en su milésima ejecución.

Dónde fallan los sistemas multiagente

Muchos equipos ahora encadenan varios agentes: uno planifica, otro ejecuta y un tercero revisa el trabajo. Un estudio de 2025 de UC Berkeley, «¿Por qué fallan los sistemas de modelos de lenguaje grandes multiagente?», analizó más de 1.600 trazas de ejecución anotadas en siete marcos de trabajo multiagente populares. Los autores, liderados por Mert Cemri, elaboraron una taxonomía llamada MAST con 14 modos de fallo agrupados en tres categorías: problemas de diseño del sistema, desajustes entre agentes y verificación de tareas.

Su principal conclusión es que muchos fallos se deben al diseño del sistema, no solo a las limitaciones del modelo subyacente. Los agentes ignoran el papel que tienen asignado, pierden el hilo de la conversación o dan una tarea por terminada sin comprobar el resultado. Estos fallos no dejan ningún error registrado. Solo se pueden detectar si alguien puede leer lo que hizo realmente cada agente. La cobertura de Unite.AI sobre la paradoja multiagente plantea una idea relacionada desde el punto de vista de la arquitectura: añadir agentes puede amplificar un error inicial en vez de cancelarlo.

Hacer visible lo invisible

La respuesta desde la ingeniería toma ideas de los sistemas distribuidos, donde desde hace tiempo se sigue el recorrido de las solicitudes a través de numerosos servicios mediante una técnica llamada rastreo. Aplicado a los agentes, cada solicitud del usuario se convierte en un rastro, y cada llamada al modelo o a una herramienta, en un «tramo» dentro de él. Un tramo registra la entrada, la salida, los tokens utilizados y cuánto tiempo llevó. OpenTelemetry, el organismo de estándares del sector para este ámbito, está elaborando convenciones compartidas para los tramos de IA generativa. A fecha de 2026, esas convenciones todavía figuran como en desarrollo, por lo que los nombres de los atributos aún pueden cambiar.

Varios proyectos de código abierto, como Langfuse, Arize Phoenix y AcruxCore, ya aplican esta idea. Su código fuente es público, así que los equipos pueden examinar cómo se almacena un rastro y ejecutar el software en sus propios servidores. Registran las llamadas a modelos y herramientas como tramos de un único rastro y permiten que los equipos les asignen puntuaciones de calidad. La elección de la herramienta importa menos que un detalle: el tramo de una herramienta debe registrar lo que esta devolvió realmente, no solo si la solicitud de red se realizó correctamente. Sin eso, el fallo de la herramienta meteorológica descrito anteriormente sigue siendo invisible.

Las encuestas del sector indican que el rastreo ya es habitual, pero las pruebas van a la zaga. El informe sobre el estado de la ingeniería de agentes de LangChain encuestó a 1.340 profesionales a finales de 2025. La calidad fue el obstáculo más citado para poner agentes en producción: la mencionó el 32 % de los encuestados. El 89 % de las organizaciones afirmó contar con algún tipo de observabilidad para sus agentes, y el 62 % disponía de un rastreo detallado de los pasos individuales y las llamadas a herramientas. Solo el 52,4 % realizó evaluaciones fuera de línea con conjuntos de prueba, y el 37,3 % evaluó el tráfico en vivo. La mayoría de los equipos puede ver qué hicieron sus agentes. Menos equipos comprueban si lo hicieron correctamente.

Evaluar respuestas a gran escala

Los rastros muestran qué ocurrió. No indican si la respuesta fue buena. Leer a mano todas las conversaciones no es viable a gran escala, por lo que cada vez más equipos utilizan un segundo modelo como evaluador, un enfoque conocido como «LLM como juez». Un artículo de NeurIPS 2023 de Lianmin Zheng y sus colegas concluyó que los modelos avanzados, como GPT-4, coincidían con las preferencias humanas en más del 80 % de los casos, aproximadamente al mismo nivel que las personas coinciden entre sí.

El mismo artículo documentó las debilidades del método. Los modelos evaluadores prefieren la respuesta que se muestra primero y las respuestas más largas, y pueden favorecer los textos escritos por ellos mismos. Por tanto, las puntuaciones de los modelos evaluadores son estimaciones. Son útiles cuando se necesita evaluar grandes volúmenes, pero deben contrastarse con un pequeño conjunto de ejemplos etiquetados por personas, cuyo orden de respuesta se haya aleatorizado.

De la práctica a la política

Este trabajo de medición también se está convirtiendo en una expectativa de gobernanza. El Instituto Nacional de Estándares y Tecnología de Estados Unidos publicó su Marco de gestión de riesgos de IA en enero de 2023. Una de sus cuatro funciones centrales, «Medir», pide a las organizaciones cuantificar, hacer seguimiento y documentar los riesgos de la IA a lo largo del tiempo. En el caso de un agente, los rastros y las puntuaciones de evaluación son las pruebas que exige esa función.

Qué pueden hacer los equipos ahora

Esto se hace eco del argumento planteado en esta plataforma: la fiabilidad es la verdadera prueba de la IA agéntica. La investigación anterior añade los detalles de medición que sustentan ese argumento: la fiabilidad no es una propiedad que se observa una sola vez, sino un rango que hay que medir continuamente.

La investigación apunta a un breve conjunto de prácticas, muchas de las cuales también recomiendan los principales proveedores de modelos. La guía práctica de OpenAI para crear agentes aconseja a los equipos «configurar evaluaciones para establecer una línea de base de rendimiento» antes de optimizar, y ceder el control a una persona cuando un agente supera un número determinado de intentos fallidos o se enfrenta a una acción de alto riesgo. Anthropic recomienda «realizar pruebas exhaustivas en entornos aislados» antes de que los agentes actúen por su cuenta.

En la práctica, esto se traduce en unos cuantos pasos concretos. Mantén las instrucciones y las descripciones de las herramientas bajo control de versiones, como el código. Prueba cada cambio en las instrucciones con un conjunto de datos fijo y espera un rango de resultados, no una sola cifra. Ejecuta cada caso de prueba varias veces, porque una sola ejecución oculta la inconsistencia. Registra los resultados de las herramientas en los rastros, para que una herramienta defectuosa no pueda ocultarse tras un código de éxito. Considera las puntuaciones de los evaluadores automatizados como estimaciones y contrástalas con personas.

Ninguna de estas prácticas exige un avance decisivo en las capacidades de los modelos. Exigen tratar a un agente de IA como lo que es: un sistema probabilístico que debe medirse, porque rara vez anunciará sus propios fallos.