«Una de cada deu caigudes ja és d'IA»: aquesta dada mesura una altra cosa

Aquesta setmana han circulat junts tres estudis sobre IA i fiabilitat, i dels tres el que més s'ha compartit és el que diu que una de cada deu caigudes ja és d'IA. El número és real i surt d'un informe seriós. El que no és cert és el que la gent n'entén. I en aquest mateix informe hi ha una altra xifra, que ningú no ha repetit, que sí que t'hauria de canviar una decisió aquesta setmana.

Què compta exactament aquest 10,7%

La font és el State of Reliability 2026 de StackGen, i la fitxa de l'informe és transparent amb el seu mètode: 109.000 incidents recollits de pàgines d'estat públiques, de més de 390 empreses, repartits en tretze sectors, amb una finestra que va del 2018 al 2026. És un treball de recompte, no d'atribució de culpes: algú ha anat a les pàgines on les empreses publiquen les seves pròpies incidències i les ha comptat.

Dins d'aquests tretze sectors hi ha un que agrupa els proveïdors de models i d'aplicacions d'IA. La xifra del titular és la quota d'aquest sector sobre tots els incidents publicats: el 10,7% del que portem del 2026, unes sis vegades més que tres anys abans. Dit amb les paraules exactes del que mesura: una de cada deu caigudes publicades la va publicar una empresa d'IA. Que no és el mateix que «una de cada deu caigudes la va causar la IA», i la diferència no és un matís de redacció: és la diferència entre una dada de quota de mercat i una dada de causalitat.

Una part d'aquesta pujada és composició del cens. El 2023 aquell sector gairebé no tenia pes al recompte perquè gairebé no existia com a sector; avui pesa, i si demà es duplica el nombre d'empreses d'IA amb pàgina d'estat pública, el percentatge puja un altre cop sense que cap agent hagi trencat res de nou. Quina part, no ho sabem: la fitxa publica la sèrie any rere any —0,6%, 1,7%, 4,0%, 6,9% i 10,7%— però no diu si la base d'empreses és la mateixa a cada graó, i sense això ningú no pot separar quant és sector que creix i quant és sector que trenca més. El que sí que queda clar és el que aquest 10,7% no respon: qui va trencar.

El mateix informe ho diu per l'altre costat, i cal reconèixer-l'hi: adverteix que la seva mesura de la IA és un sòl, perquè només compta incidències publicades per empreses d'IA i deixa fora tot el que la IA trenqui dins d'empreses que no ho són. Les dues coses són veritat alhora: el número no demostra el que el titular insinua, i la IA com a causa l'informe la compta a part, no aquí — almenys onze casos documentats d'agents que van esborrar dades o van destruir sistemes en producció des de mitjan 2025, amb l'avís, textual, que el recompte real és desconegut perquè una pàgina d'estat no veu això. La conclusió honesta és incòmoda i poc compartible: aquest 10,7% no respon la pregunta que tothom li està fent. Ja ens ha passat altres vegades amb xifres que sonen a sentència — ho vam escriure fa poc a propòsit d'un butlletí amb deu vulnerabilitats al mateix procés: el titular no basta per decidir.

El número del mateix informe que sí que decideix alguna cosa

Més avall, a la mateixa fitxa, hi ha dues medianes posades una al costat de l'altra. No han sortit en cap titular, i són l'única cosa de tot l'informe que ens sembla directament aplicable a una decisió d'arquitectura.

Dues hores i mitja de diferència, o el que és el mateix, dues vegades i mitja el temps aturat quan el que trenca és un proveïdor teu. I no és perquè la teva gent sigui pitjor en aquests casos: és que en aquests casos la teva gent no pot fer res més que refrescar una pàgina d'estat aliena i contestar correus. L'informe afegeix que el 26% dels incidents avaluats del 2026 són cascades de tercers, i avisa que aquest 26% també és un sòl perquè al voltant d'un 16% de les incidències recents està sense classificar i el que no està classificat compta com a «no és cascada».

Un acumulat anual de disponibilitat no et diu res d'això; ho vam escriure ahir amb l'aritmètica sencera: el 99,9% no et diu quant dura la caiguda. El que l'oficina nota és l'amplada del buit, i aquí hi ha dues amplades molt diferents segons de qui sigui la peça que s'ha trencat.

I aquí és on entra el teu agent

Un agent d'IA ficat en un procés de negoci no és, des del punt de vista de la fiabilitat, una funció nova del teu programari. És un proveïdor més al camí crític: una API d'un tercer que pot estar lenta, pot estar caiguda, pot tallar-te per quota un dimarts a les onze i pot tornar-te una cosa diferent del que tornava ahir sense que tu hagis canviat una sola línia. Aquestes quatre coses són el perfil exacte del que l'informe anomena cascada de tercers. Els 247 minuts no són el càstig per fer servir IA: són el preu de ficar una dependència que no administres en un lloc del qual depèn la teva facturació.

D'aquí surt la primera decisió avorrida, i és la mateixa que prenem amb les imatges de contenidor: fixa la versió del model. Si crides un àlies que el proveïdor va movent, has acceptat que el component canviï a sota sense el teu permís i sense el teu calendari. És exactament l'error del qual ja vam escriure a «latest» no és una versió, traslladat a un lloc on pocs ho estan mirant. I la segona decisió avorrida és la identitat: un agent que treballa amb el token d'una persona no deixa rastre propi, i això ho expliquem sencer a al registre no surt l'agent, surt qui li va deixar el token.

Els altres dos estudis, llegits amb la mateixa lupa

El segon és d'IBM, l'ha fet Censuswide i es va publicar el 14 d'octubre. Són 3.221 directius d'organitzacions de més de mil empleats en vuit països —entre ells Espanya—, enquestats entre el 14 i el 24 de setembre. Dos parells de xifres que convé llegir juntes:

Del mateix estudi: el 35% diu tenir IA agèntica en producció avui, el 75% espera que el 2027 els seus agents tinguin algun grau d'autonomia en decisions, i només el 37% creu que la seva governança està dissenyada per escalar amb això. Hi ha una escletxa de gairebé quaranta punts entre el que s'espera delegar i el que es creu poder governar, i a sobre és una escletxa declarada pels mateixos responsables.

El tercer és el que més circula entre tècnics: una enquesta de VB Intelligence segons la qual, entre les empreses que ja despleguen agents autònoms, la proporció que permet certs canvis en producció només amb el resultat d'una avaluació automàtica —o que està muntant els seus sistemes per permetre-ho d'aquí a un any— va baixar del 75% al 56%. Abans de fer-lo servir en una reunió, el seu propi mètode: són dues onades, de 108 i 140 respostes, separades per un mes —juliol i agost del 2026—. Això no és una sèrie temporal, és una foto moguda; amb aquestes mostres i aquest interval, el salt pot ser un canvi d'ànim del sector o pot ser que a l'agost contestés gent diferent. Que és, a més, el que diu la mateixa fitxa metodològica: els dos grups van ser independents i autoseleccionats, i entre els d'agost hi havia més gent amb decisió final de compra que entre els de juliol —53% davant del 44%—. Nosaltres no ho faríem servir com a prova de res.

El que sí que val d'aquest mateix treball és una altra dada, menys citada i molt més útil: del grup que fa avaluacions abans de desplegar, el 61% reconeix almenys un cas l'últim any en què un agent o una funció amb model de llenguatge va passar les proves internes i després va fallar davant del client; el 22%, més d'una vegada. I això, llegit amb calma, no és un problema d'IA. És el símptoma clàssic d'un entorn de proves que no s'assembla a producció, el mateix que van descriure Oppenheimer, Ganapathi i Patterson a USENIX el 2003 quan van trobar que l'error d'operador era la causa individual més gran de caigudes en dos dels tres serveis que van mesurar, i que dins d'aquest error la categoria més gran era la de configuració. L'agent no porta un mode d'errada nou: porta un operador més que toca producció, que treballa de nit, que no es cansa i que no pregunta a ningú.

La prova de l'apagada

Abans de deixar un agent dins d'un procés que li importa a algú, hi ha una prova que costa vint minuts i que no requereix comprar res: apaga'l a propòsit, un dimarts a les onze del matí, amb la gent al davant. És chaos engineering casolà, la versió barata del que els grans fan amb eines que trenquen coses soles, i de la qual ja vam escriure amb hipòtesi i radi d'abast a provar el sistema viu evitava 26 de 40 caigudes. I dona un d'aquests tres resultats:

Si surt el tercer resultat, la feina que falta no és d'IA, és d'ofici: versió del model fixada, credencial pròpia de l'agent i acotada al que necessita, una llista curta del que pot escriure i el que només pot llegir, un nom de persona que el pot apagar, una alerta que salti quan deixa de contestar —no quan el client es queixa— i el camí sense ell, escrit. Són les mateixes sis caselles que demanem a qualsevol servei de producció des de molt abans que existissin els agents. Nosaltres tenim la nostra pròpia automatització amb n8n autoallotjat fent tasques internes cada dia, i està a l'inventari amb responsable i amb finestra d'actualització, com la resta. No perquè sigui d'IA, sinó perquè fa feina de la qual algú depèn.

Quan no ficar l'agent

Venem automatització, així que aquesta part convé llegir-la amb els ulls oberts. Hi ha dos casos en què diem que no, i els diem aviat perquè després costa més.

El primer: si el procés no es pot fer a mà, encara que sigui lentíssim i de mala manera, l'agent no és el problema — el procés no està llest per automatitzar-se. Automatitzar una cosa que ningú no sap fer manualment no treu feina, l'amaga, i la torna sencera el dia que el proveïdor tingui un mal dia. El segon: si l'únic motiu per ficar-lo és que aquest trimestre toca poder dir que feu servir IA, el cost real no és el que costen les trucades al model. Són els 247 minuts del dia que no contesti, multiplicats pel que factura la teva empresa en un matí.

L'eix amb què mesurem qualsevol disseny no canvia perquè el component nou sigui un model de llenguatge: la fallada és inevitable, l'avaria és una decisió de disseny. El teu agent caurà, igual que cau un disc o un proveïdor gran. Si el procés està muntat per continuar coixejant sense ell, això és paperassa. Si està muntat de manera que sense ell no hi ha procés, això són quatre hores d'empresa aturada, i les va triar algú el dia que el va endollar sense fer la prova de l'apagada.

Fonts i mètode: les xifres de recompte d'incidències, les dues medianes (247 i 96 minuts) i la quota de cascades de tercers surten de la fitxa pública del State of Reliability 2026 de StackGen — stackgen.com. Advertència de lectura: diverses cobertures de premsa citen xifres de volum diferents de les de la fitxa (hem vist «gairebé 180.000 registres» davant dels 109.000 incidents de la mateixa fitxa); el més probable és que siguin entrades totals de pàgina d'estat davant d'incidències no planificades, que és el que la fitxa compta i el que correspon a «caiguda», però no ho hem pogut confirmar, així que fem servir sempre la xifra de la fitxa. La interpretació que el 10,7% mesura quota de sector i no causalitat és nostra, no de l'informe; l'informe apunta en la direcció oposada (avisa que la seva pròpia mesura de la IA és un sòl) i les dues coses poden ser certes alhora. Les dades de governança són de The New Realities of AI Governance Report, d'IBM, fet per Censuswide entre el 14 i el 24 de setembre del 2026 amb 3.221 directius d'organitzacions de més de 1.000 empleats al Regne Unit, França, Alemanya, Itàlia, Espanya, Països Baixos, Aràbia Saudita i Emirats — newsroom.ibm.com. Les xifres de confiança en canvis sense revisió i d'errades després de passar les avaluacions són de l'enquesta de VB Intelligence (onades de juliol i agost del 2026, 108 i 140 respostes) — venturebeat.com; les citem amb la seva mida de mostra posada perquè sense ella es llegeixen pitjor. L'estudi sobre causes de caiguda és D. Oppenheimer, A. Ganapathi i D. A. Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX USITS 2003 — usenix.org; mesura només tres serveis concrets, així que el citem per la direcció que assenyala i no com a estadística universal. El que diem de la nostra pròpia automatització amb n8n és nostre, i no porta número: no publiquem mètriques internes que ningú no pugui comprovar.