«Una de cada diez caídas ya es de IA»: ese dato mide otra cosa

Esta semana han circulado juntos tres estudios sobre IA y fiabilidad, y de los tres el que más se ha compartido es el que dice que una de cada diez caídas ya es de IA. El número es real y sale de un informe serio. Lo que no es cierto es lo que la gente está entendiendo. Y en ese mismo informe hay otra cifra, que nadie ha repetido, que sí debería cambiarte una decisión esta semana.

Qué cuenta exactamente ese 10,7%

La fuente es el State of Reliability 2026 de StackGen, y la ficha del informe es transparente con su método: 109.000 incidentes recogidos de páginas de estado públicas, de más de 390 empresas, repartidos en trece sectores, con una ventana que va de 2018 a 2026. Es un trabajo de recuento, no de atribución de culpas: alguien ha ido a las páginas donde las empresas publican sus propias incidencias y las ha contado.

Dentro de esos trece sectores hay uno que agrupa a los proveedores de modelos y de aplicaciones de IA. La cifra del titular es la cuota de ese sector sobre todos los incidentes publicados: el 10,7% en lo que va de 2026, unas seis veces más que tres años antes. Dicho con las palabras exactas de lo que mide: una de cada diez caídas publicadas la publicó una empresa de IA. Que no es lo mismo que «una de cada diez caídas la causó la IA», y la diferencia no es un matiz de redacción: es la diferencia entre un dato de cuota de mercado y un dato de causalidad.

Parte de esa subida es composición del censo. En 2023 ese sector apenas tenía peso en el recuento porque apenas existía como sector; hoy pesa, y si mañana se duplica el número de empresas de IA con página de estado pública, el porcentaje sube otra vez sin que ningún agente haya roto nada nuevo. Cuánta parte, no lo sabemos: la ficha publica la serie año a año —0,6%, 1,7%, 4,0%, 6,9% y 10,7%— pero no dice si la base de empresas es la misma en cada escalón, y sin eso nadie puede separar cuánto es sector que crece y cuánto es sector que rompe más. Lo que sí queda claro es lo que ese 10,7% no responde: quién rompió.

El propio informe lo dice por el otro lado, y hay que reconocérselo: advierte de que su medición de la IA es un suelo, porque solo cuenta incidencias publicadas por empresas de IA y deja fuera todo lo que la IA rompa dentro de empresas que no lo son. Las dos cosas son verdad a la vez: el número no demuestra lo que el titular insinúa, y la IA como causa el informe la cuenta aparte, no ahí — al menos once casos documentados de agentes que borraron datos o destruyeron sistemas en producción desde mediados de 2025, con el aviso, textual, de que el recuento real es desconocido porque una página de estado no ve eso. La conclusión honesta es incómoda y poco compartible: ese 10,7% no responde a la pregunta que todo el mundo le está haciendo. Ya nos ha pasado otras veces con cifras que suenan a sentencia — lo escribimos hace poco a propósito de un boletín con diez vulnerabilidades en el mismo proceso: el titular no basta para decidir.

El número del mismo informe que sí decide algo

Más abajo, en la misma ficha, hay dos medianas puestas una al lado de la otra. No han salido en ningún titular, y son lo único de todo el informe que nos parece directamente aplicable a una decisión de arquitectura.

Dos horas y media de diferencia, o lo que es lo mismo, dos veces y media el tiempo parado cuando el que rompe es un proveedor tuyo. Y no es porque tu gente sea peor en esos casos: es que en esos casos tu gente no puede hacer nada más que refrescar una página de estado ajena y contestar correos. El informe añade que el 26% de los incidentes evaluados de 2026 son cascadas de terceros, y avisa de que ese 26% también es un suelo porque alrededor de un 16% de las incidencias recientes está sin clasificar y lo no clasificado cuenta como «no es cascada».

Un acumulado anual de disponibilidad no te dice nada de esto; lo escribimos ayer con la aritmética entera: el 99,9% no te dice cuánto dura la caída. Lo que la oficina nota es la anchura del hueco, y aquí hay dos anchuras muy distintas según de quién sea la pieza que se ha roto.

Y aquí es donde entra tu agente

Un agente de IA metido en un proceso de negocio no es, desde el punto de vista de la fiabilidad, una función nueva de tu software. Es un proveedor más en el camino crítico: una API de un tercero que puede estar lenta, puede estar caída, puede cortarte por cuota un martes a las once y puede devolverte algo distinto de lo que devolvía ayer sin que tú hayas cambiado una sola línea. Esas cuatro cosas son el perfil exacto de lo que el informe llama cascada de terceros. Los 247 minutos no son el castigo por usar IA: son el precio de meter una dependencia que no administras en un sitio del que depende tu facturación.

De ahí sale la primera decisión aburrida, y es la misma que tomamos con las imágenes de contenedor: fija la versión del modelo. Si llamas a un alias que el proveedor va moviendo, has aceptado que el componente cambie debajo sin tu permiso y sin tu calendario. Es exactamente el error del que ya escribimos en «latest» no es una versión, trasladado a un sitio donde pocos lo están mirando. Y la segunda decisión aburrida es la identidad: un agente que trabaja con el token de una persona no deja rastro propio, y eso lo contamos entero en en el registro no sale el agente, sale quien le prestó el token.

Los otros dos estudios, leídos con la misma lupa

El segundo es de IBM, lo ha hecho Censuswide y se publicó el 14 de octubre. Son 3.221 directivos de organizaciones de más de mil empleados en ocho países —entre ellos España—, encuestados entre el 14 y el 24 de septiembre. Dos pares de cifras que conviene leer juntas:

Del mismo estudio: el 35% dice tener IA agéntica en producción hoy, el 75% espera que para 2027 sus agentes tengan algún grado de autonomía en decisiones, y solo el 37% cree que su gobernanza está diseñada para escalar con eso. Hay una brecha de casi cuarenta puntos entre lo que se espera delegar y lo que se cree poder gobernar, y encima es una brecha declarada por los propios responsables.

El tercero es el que más circula entre técnicos: una encuesta de VB Intelligence según la cual, entre las empresas que ya despliegan agentes autónomos, la proporción que permite ciertos cambios en producción solo con el resultado de una evaluación automática —o que está montando sus sistemas para permitirlo dentro de un año— bajó del 75% al 56%. Antes de usarlo en una reunión, su propio método: son dos oleadas, de 108 y 140 respuestas, separadas por un mes —julio y agosto de 2026—. Eso no es una serie temporal, es una foto movida; con esas muestras y ese intervalo, el salto puede ser un cambio de ánimo del sector o puede ser que en agosto contestara gente distinta. Que es, además, lo que dice la propia ficha metodológica: los dos grupos fueron independientes y autoseleccionados, y entre los de agosto había más gente con decisión final de compra que entre los de julio —53% frente a 44%—. Nosotros no lo usaríamos como prueba de nada.

Lo que sí vale de ese mismo trabajo es otro dato, menos citado y mucho más útil: del grupo que hace evaluaciones antes de desplegar, el 61% reconoce al menos un caso en el último año en que un agente o una función con modelo de lenguaje pasó las pruebas internas y luego falló delante del cliente; el 22% más de una vez. Y eso, leído con calma, no es un problema de IA. Es el síntoma clásico de un entorno de pruebas que no se parece a producción, el mismo que describieron Oppenheimer, Ganapathi y Patterson en USENIX en 2003 cuando encontraron que el error de operador era la mayor causa individual de caídas en dos de los tres servicios que midieron, y que dentro de ese error la categoría más grande era la de configuración. El agente no trae un modo de fallo nuevo: trae un operador más que toca producción, que trabaja de noche, que no se cansa y que no le pregunta a nadie.

La prueba del apagón

Antes de dejar un agente dentro de un proceso que le importa a alguien, hay una prueba que cuesta veinte minutos y que no requiere comprar nada: apágalo a propósito, un martes a las once de la mañana, con la gente delante. Es chaos engineering de andar por casa, la versión barata de lo que los grandes hacen con herramientas que rompen cosas solas, y de la que ya escribimos con hipótesis y radio de alcance en probar el sistema vivo evitaba 26 de 40 caídas. Y da uno de estos tres resultados:

Si sale el tercer resultado, el trabajo que falta no es de IA, es de oficio: versión del modelo fijada, credencial propia del agente y acotada a lo que necesita, una lista corta de lo que puede escribir y lo que solo puede leer, un nombre de persona que puede apagarlo, una alerta que salte cuando deja de contestar —no cuando el cliente se queja— y el camino sin él, escrito. Son las mismas seis casillas que le pedimos a cualquier servicio de producción desde mucho antes de que existieran los agentes. Nosotros tenemos nuestra propia automatización con n8n autoalojado haciendo tareas internas todos los días, y está en el inventario con dueño y con ventana de actualización, como el resto. No porque sea de IA, sino porque hace trabajo del que alguien depende.

Cuándo no meter el agente

Vendemos automatización, así que esta parte conviene leerla con los ojos abiertos. Hay dos casos en los que decimos que no, y los decimos pronto porque luego cuesta más.

El primero: si el proceso no se puede hacer a mano, aunque sea lentísimo y de mala manera, el agente no es el problema — el proceso no está listo para automatizarse. Automatizar algo que nadie sabe hacer manualmente no quita trabajo, lo esconde, y lo devuelve entero el día que el proveedor tenga un mal día. El segundo: si el único motivo para meterlo es que este trimestre toca poder decir que usáis IA, el coste real no es lo que cuestan las llamadas al modelo. Son los 247 minutos del día que no conteste, multiplicados por lo que factura tu empresa en una mañana.

El eje con el que medimos cualquier diseño no cambia porque el componente nuevo sea un modelo de lenguaje: el fallo es inevitable, la avería es una decisión de diseño. Tu agente se va a caer, igual que se cae un disco o un proveedor grande. Si el proceso está montado para seguir cojeando sin él, eso es papeleo. Si está montado de forma que sin él no hay proceso, eso son cuatro horas de empresa parada, y las eligió alguien el día que lo enchufó sin hacer la prueba del apagón.

Fuentes y método: las cifras de recuento de incidencias, las dos medianas (247 y 96 minutos) y la cuota de cascadas de terceros salen de la ficha pública del State of Reliability 2026 de StackGen — stackgen.com. Advertencia de lectura: distintas coberturas de prensa citan cifras de volumen distintas de las de la ficha (hemos visto «casi 180.000 registros» frente a los 109.000 incidentes de la propia ficha); lo más probable es que sean entradas totales de página de estado frente a incidencias no planificadas, que es lo que la ficha cuenta y lo que corresponde a «caída», pero no hemos podido confirmarlo, así que usamos siempre la cifra de la ficha. La interpretación de que el 10,7% mide cuota de sector y no causalidad es nuestra, no del informe; el informe apunta en la dirección opuesta (avisa de que su propia medición de la IA es un suelo) y ambas cosas pueden ser ciertas a la vez. Los datos de gobernanza son de The New Realities of AI Governance Report, de IBM, realizado por Censuswide entre el 14 y el 24 de septiembre de 2026 con 3.221 directivos de organizaciones de más de 1.000 empleados en Reino Unido, Francia, Alemania, Italia, España, Países Bajos, Arabia Saudí y Emiratos — newsroom.ibm.com. Las cifras de confianza en cambios sin revisión y de fallos tras pasar las evaluaciones son de la encuesta de VB Intelligence (oleadas de julio y agosto de 2026, 108 y 140 respuestas) — venturebeat.com; las citamos con su tamaño de muestra puesto porque sin él se leen peor. El estudio sobre causas de caída es D. Oppenheimer, A. Ganapathi y D. A. Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX USITS 2003 — usenix.org; mide solo tres servicios concretos, así que lo citamos por la dirección que señala y no como estadística universal. Lo que decimos de nuestra propia automatización con n8n es nuestro, y no lleva número: no publicamos métricas internas que nadie pueda comprobar.