🤖 AI

When Errors Become Narratives: A Longitudinal Taxonomy of Silent Failures in a Production LLM Agent Runtime

Este artículo presenta un estudio longitudinal de un entorno de ejecución de un agente LLM en producción que identifica fallos silenciosos "verosímiles" —donde el sistema genera narrativas convincentes pero incorrectas en lugar de señales de error— y propone una taxonomía de cinco clases y un marco de defensa para lograr que tales fallos del agente sean ruidosos, atribuibles y aburridos.

Autores originales: Wei Wu

Publicado 2026-06-15

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Wei Wu

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes un robot asistente personal muy inteligente e incansable. Trabaja las 24 horas del día, los 7 días de la semana, revisa tu calendario, lee noticias, resume tus correos electrónicos y te envía informes diarios. Confías plenamente en él.

Pero aquí está la parte aterradora: a veces, el robot comete un error, pero en lugar de decir: "Oye, metí la pata", lo corrige silenciosamente creando una mentira que suena perfecta y enviándotela. No se bloquea ni activa una alarma. Simplemente te dice algo que no es cierto con total confianza y, debido a que suena tan fluido y lógico, le crees.

Este documento es un informe detallado de un investigador que observó cómo su propio asistente de IA funcionaba en el mundo real durante ocho semanas. Descubrieron que el mayor peligro no es cuando el robot se rompe de forma ruidosa; es cuando se rompe silenciosamente y te miente.

Aquí está el desglose de sus hallazgos, utilizando analogías sencillas:

1. El problema principal: "Fallo plausible" (Fail-Plausible)

En los sistemas informáticos antiguos, un "fallo silencioso" significaba que una máquina dejaba de funcionar, pero las luces seguían en verde. El sistema estaba roto, pero nadie lo sabía.

En este nuevo mundo de la IA, el problema es peor. El documento lo llama "Fallo plausible".

La analogía: Imagina a un chef que quema un filete. En lugar de tirarlo o decírtelo, el chef toma el filete quemado, lo cubre con una salsa elegante y te lo sirve diciendo: "Este es un nuevo plato de 'delicia carbonizada'".
La realidad: La IA detecta un error (como una conexión a internet rota o un código informático extraño), pero en lugar de detenerse, utiliza sus habilidades lingüísticas para convertir ese error en una historia fluza y creíble. Podría decirte que hay una "crisis en una importante empresa tecnológica" cuando, en realidad, solo vio un código de error que parecía una crisis.

2. Las cinco formas en que el robot se pierde silenciosamente

El investigador categorizó 22 incidentes diferentes en cinco tipos de "fallos silenciosos":

A. El problema de la "Casa Diferente" (Caprichos del entorno): El robot fue entrenado en una casa perfecta y soleada (la computadora del desarrollador), pero vive en una casa vieja y con corrientes de aire (el servidor real). Intenta abrir una puerta que existe en la casa soleada, pero que está tapiada en la real. El robot cree que está trabajando, pero en realidad está atrapado.
B. El problema del "Mapa Equivocado" (Suposiciones de diseño): El robot asume que un archivo siempre está en la cocina. Pero en el mundo real, el archivo está en el garaje. El robot busca en la cocina, no encuentra nada y simplemente adivina qué hay en el garaje sin comprobarlo. Funciona bien en las pruebas (donde el archivo estaba en la cocina), pero falla en la realidad.
C. El problema del "Error Susurrado" (Absorción de errores): El robot comete un error, pero la parte del sistema que reporta los errores se amortigua. Es como una alarma de humo que ve el humo, pero solo susurra un "beep" tan suavemente que nadie lo oce. El error ocurre, pero la advertencia ha sido despojada de toda información útil.
D. El problema del "Narrador Mentiroso" (Fallo plausible): Este es el más peligroso. La IA recibe datos malos (como un mensaje de error corrupto) y convierte esa basura en una historia perfecta y segura. No solo está ocultando el error; está fabricando activamente una mentira que suena como un conocimiento real.
E. El problema del "Paso Olvidado" (Omisión operativa): El robot debía realizar una tarea, pero al humano se le olvidó accionar el interruptor final para encenderla. O bien, la herramienta utilizada para comprobar si el robot funciona está rota, por lo que le dice al humano: "¡Todo está bien!", cuando el robot lleva muerto semanas.

3. Las grandes sorpresas

El investigador encontró tres cosas que van en contra del sentido común:

Sorpresa n.º 1: La "red de seguridad" del robot no detectó nada.
El sistema tenía más de 4,000 pruebas automatizadas y cientos de controles. Todos estaban en "verde" (aprobados) incluso mientras el robot le mentía al usuario.
- La lección: Lo único que detectó estas mentiras fue un humano leyendo realmente la salida del robot. El 70% de las veces, un humano notó: "Espera, esta historia no tiene sentido", y esa fue la única alarma que sonó.
Sorpresa n.º 2: Los controles son para "después de los hechos", no para "antes".
El investigador comparó sus reglas de seguridad con errores pasados. Las reglas evitaban que el mismo error volviera a ocurrir el 87% de las veces, pero predijeron el 0% de los nuevos tipos de errores.
- La lección: Los controles de seguridad son como un cinturón de seguridad; te impiden sufrir daños otra vez de una forma conocida, pero no pueden predecir un choque de un tipo completamente nuevo.
Sorpresa n.º 3: Los silencios más largos ocurren en las "costuras".
Los errores que duraron más tiempo (¡hasta 60 días!) no ocurrieron en el código complejo y difícil de entender. Ocurrieron en las "costuras": los pequeños huecos entre las diferentes partes del sistema.
- La analogía: No es el motor lo que se rompe; es la pequeña junta de goma entre el motor y el tubo de escape. Como nadie prueba la junta específicamente, la fuga pasa desapercibida durante meses.

4. Cómo solucionarlo (La "Disciplina")

El investigador no se limitó a añadir más alarmas. Se dio cuenta de que añadir más alarmas solo crea más "costuras" donde las cosas pueden romperse. En su lugar, construyó un sistema basado en limpiar el desastre:

La "Ley del Atardecer" (Sunset Law): Antes de añadir una nueva regla de seguridad, debes eliminar una antigua e innecesaria. Mantén el sistema simple.
La "Máquina de la Verdad": Construyeron un sistema que comprueba constantemente si el "plan" de la IA coincide con lo que la IA está haciendo realmente. Si el plan dice "El trabajo A se está ejecutando", pero la computadora dice "El trabajo A está apagado", el sistema lo corrige automáticamente.
La "Prueba de Sabotaje": Rompieron el sistema deliberadamente a propósito para ver si las protecciones de seguridad despertaban. Si una protección no despertaba, la desechaban y construían una mejor.
El "Ojo Humano": Aceptaron que un humano leyendo la salida es el control de seguridad más importante. Programaron tiempo cada semana solo para leer lo que el robot escribió, sin permitir la programación.

La conclusión

El documento concluye que lo más aterrador de la IA no es que se bloquee y deje de funcionar. Lo más aterrador es que seguirá funcionando perfectamente, hablará con una gramática perfecta y te contará una historia detallada y segura sobre una crisis que nunca ocurrió.

La solución no es construir un muro más grande de pruebas; es construir un sistema donde los errores sean ruidosos, donde el humano sea el juez final y donde el sistema se compruebe constantemente para asegurarse de que no se está mintiendo a sí mismo.

Resumen Técnico: Cuando los errores se convierten en narrativas

Declaración del Problema

El artículo aborda el desafío crítico de la fiabilidad de los fallos silenciosos en sistemas de agentes de Modelos de Lenguaje Extensos (LLM) en producción. A diferencia de los sistemas distribuidos tradicionales donde los fallos se manifiestan como caídas o señales de error explícitas, los agentes de LLM poseen un modo de fallo único: falla-plausible (fail-plausible). En este modo, el sistema no solo deja de reportar un error, sino que transforma activamente los errores internos, el contexto contaminado o las señales faltantes en contenido narrativo fluido, coherente y contextualmente apropiado entregado al usuario.

Los autores argumentan que, mientras que los "fallos grises" tradicionales (donde un componente se degrada pero los detectores de fallos reportan salud) privan al observador de señales, los fallos falla-plausibles alimentan al observador con una señal contrahecha. Esto crea un escenario donde el sistema no solo es ciego al fallo, sino que está mintiendo activamente al operador humano. El estudio se centra en el tiempo de ejecución de un agente de asistencia personal en producción continua desde marzo de 2026, el cual orquesta trabajos programados, llamadas a herramientas y síntesis de memoria a través de múltiples proveedores de LLM.

Metodología

La investigación es un estudio de caso empírico longitudinal de un único sistema de producción durante una ventana de ocho semanas (9 de abril – 2 de junio de 2026).

Alcance del Sistema: El sistema comprende ~40 trabajos programados, 8 proveedores de LLM, un proxy de gobernanza de herramientas y un plano de memoria de base de conocimientos. Está defendido por 4,286 pruebas unitarias y 827 controles de gobernanza declarativos.
Selección del Corpus: El estudio analiza 22 incidentes que cumplieron tres criterios: (1) llegaron a producción, (2) tuvieron una "fase silenciosa" donde todos los indicadores automatizados permanecieron en verde, y (3) fueron cerrados con un post-mortem completo de la causa raíz.
Protocolo de Post-mortem: Se aplicó una "constitución de análisis de excepciones" obligatoria a cada incidente, la cual requería:
- Diagramas de cadena causal completos (tiempo × capa × lógica).
- Una descomposición de causa raíz de tres capas: Disparador (chispa externa), Amplificador (defecto arquitectónico que propaga el error) y Concealador (ausencia que oculta el error).
- Análisis de combinación de condiciones para explicar por qué ocurrió el fallo en ese momento.
Construcción de la Taxonomía: Las clases se derivaron iterativamente basadas en el mecanismo de fallo (cómo el error evadió la observación) en lugar de la ubicación del fallo, ya que los mecanismos resultaron recurrentes en componentes no relacionados.
Colaboración con IA: El sistema fue desarrollado y operado por un investigador humano y un colaborador de ingeniería de IA (Claude), una dinámica que también se examina como un hallazgo en el artículo.

Contribuciones Clave

1. Una Taxonomía Orientada a Mecanismos de Cinco Clases

El artículo deriva una taxonomía de fallos silenciosos, categorizándolos por el mecanismo de evasión en lugar de la ubicación del componente:

Clase A: Excentricidades del Entorno y la Plataforma. La lógica es correcta, pero el entorno de producción (por ejemplo, macOS vs. Linux, versiones específicas de shell) se comporta de manera diferente a lo asumido. Signatura: El desarrollo está en verde; la producción es silenciosa.
Clase B: Desajustes de Supuestos de Diseño. El código asume una topología de despliegue, contrato o forma de entrada que la realidad viola (por ejemplo, el parseo posicional de la salida del LLM). Signatura: Las pruebas unitarias reflejan el supuesto, no la realidad.
Clase C: Absorción y Dilución de Errores. Los errores ocurren pero son despojados de contexto o causa al pasar a través de las capas (por ejemplo, mensajes de error genéricos que reemplazan causas específicas ascendentes).
Clase D: Alucinación Encadenada y Fabricación (Falla-Plausible). La clase novedosa y más peligrosa. El LLM convierte el contexto contaminado (logs de error, alertas obsoletas) en narrativas falsas y seguras (por ejemplo, fabricando una "crisis de plataforma" o un "lanzamiento de software"). El sistema transforma el error en un discurso plausible.
Clase E: Omisión Operativa y Puntos Ciegos Forenses. Se saltan pasos de despliegue o los propios instrumentos de diagnóstico están comprometidos (por ejemplo, permisos de sandbox que niegan herramientas forenses, devolviendo una salida vacía que parece "normal").

2. El Fenómeno "Falla-Plausible"

El artículo define falla-plausible como la escalada de los fallos grises en la era de los LLM. Documenta cuatro incidentes específicos donde el sistema generó análisis de industria, instrucciones de remediación y lanzamientos de software fabricados. La defensa contra esto no es del lado del modelo, sino de la higiene del contexto del sistema: imponer disciplina en el stderr, eliminar alertas antes del ensamblaje del contexto y utilizar etiquetado de procedencia.

3. Hallazgos Transversales Cuantificados

Canales de Descubrimiento: Aproximadamente el 70% de los fallos silenciosos fueron descubiertos mediante la observación humana desde la vista del usuario (leyendo la salida real), no por pruebas unitarias, controles de salud o auditorías de gobernanza. El stack automatizado permaneció en verde durante la mayoría de los incidentes.
Latencia del Incidente: La duración del silencio varió de 13 horas a 60 días. La latencia se correlacionó con la capa del mecanismo (por ejemplo, topología de despliegue, política de SO) en lugar de la complejidad del código. Los fallos más largos residían en las "costuras" entre componentes donde no se ejecutan pruebas.
Eficacia de la Auditoría: Una auditoría retrospectiva de 15 incidentes mostró una tasa de prevención ex-ante del 0%, pero una tasa de bloqueo de regresiones ex-post del 87%. Los autores concluyen que las auditorías son motores de regresión, no motores de predicción; codifican el pasado pero no pueden predecir nuevas clases de mecanismos.

4. Marco de Defensa y Ruta de Maduración

El artículo detalla un marco de defensa que surgió de los incidentes, centrado en una ruta de maduración de tres pasos para las lecciones aprendidas:

Corrección de Punto: Reparar un bug específico (insuficiente; las lecciones existen solo como diffs).
Meta-Regla: Escribir la lección como una regla nombrada y trans-caso (por ejemplo, "los diagnósticos deben ir a stderr").
Escáner Mecanizado: Codificar la regla como un control en todo el repositorio en CI y auditorías diarias.

Resultado: Cada meta-regla que alcanzó el Paso 3 tuvo cero recurrencias registradas. Cada recurrencia involucró una lección que se detuvo en el Paso 1.
Validación de Sabotaje: Una práctica crítica de romper deliberadamente el sistema para probar que las protecciones realmente se activan, evitando "controles vacuos" (por ejemplo, 67 controles que ejecutaban cadenas vacías durante meses).

5. El Argumento de las "Costuras"

El artículo argumenta que la ingeniería de fiabilidad debería optimizar la reducción de costuras (unificar representaciones, cerrar la brecha dev-prod, hacer que los observadores sean de solo lectura) en lugar de la acreción de defensas (añadir más protecciones). Los fallos más persistentes ocurrieron en las "costuras" entre componentes simples y correctos (por ejemplo, entre el estado declarado y el estado de ejecución), no dentro de código complejo.

Resultados y Significancia

El artículo afirma que el fallo silencioso es una clase de bug, no una lista finita de bugs. La evidencia empírica sugiere que:

La observación humana sigue siendo el detector primario para los fallos silencios en agentes de LLM, superando a miles de pruebas automatizadas.
La fabricación falla-plausible es un modo de fallo distinto específico de los sistemas generadores de lenguaje, que requiere higiene del lado del sistema en lugar de solo alineación del lado del modelo.
Las auditorías son herramientas retrospectivas. Bloquean eficazmente las regresiones (87% en este estudio), pero no pueden predecir modos de fallo novedosos.
La complejidad es el enemigo. Los fallos más persistentes no estuvieron en algoritmos complejos, sino en las interfaces y los desajustes de estado entre componentes simples.

El artículo concluye ofreciendo una "disciplina" en lugar de solo un marco: el retiro activo de la complejidad, la convergencia del estado declarado y de ejecución mediante sincronización de máquinas, y la validación rigurosa de todas las protecciones mediante sabotaje. La significancia reside en proporcionar una textura longitudinal del fallo silencioso en producción—una visión de la latencia de múltiples semanas, canales de descubrimiento y evolución de la defensa que los estudios de benchmarks horizontales no pueden capturar.

Los autores declaran explícitamente que las frecuencias y participaciones reportadas son estadísticas descriptivas de un único estudio de caso y no pretenden ser estimaciones de población generalizables, aunque argumentan que los mecanismos y estructuras (latencia $\propto$ distancia observacional, disparador/amplificador/concealador, corrección $\to$ regla $\to$ escáner) son generalizables a sistemas de agentes de LLM con autonomía de larga duración.