Una valutazione pubblicata su arXiv il 6 luglio 2026 ha fatto passare 302 incidenti Kubernetes sottoposti a controllo di qualità attraverso modelli con retrieval augmentation e ha misurato separatamente due capacità. Individuare il servizio all'origine dell'incidente: corretto tra il 91,4% e il 99,7% delle volte. Scegliere un'azione di ripristino valida per l'incidente appena diagnosticato: dal 36,8% al 60,3%. Tra quelle due colonne ci sono da quaranta a cinquantacinque punti, e quella distanza è il numero più utile pubblicato sull'AIOps quest'anno.
È un'affermazione sui tipi di lavoro, non sulla qualità dei modelli. Il modello legge bene e decide male, e questo divide il mercato in due mucchi. Una parte del lavoro operativo fallisce in modo visibile, davanti alla persona che lo ha in mano. Un'altra parte fallisce trasformandosi in un'azione contro la produzione. L'AIOps si ripaga nel primo tipo e al momento è un rischio nel secondo, e quasi tutta la delusione in questo mercato nasce dal comprarlo per il secondo dopo una demo del primo.
Correlazione degli alert, deduplicazione e la prima stesura del racconto
PagerDuty promuove il proprio prodotto AIOps come capace di tagliare il rumore degli alert fino al 91%. Mettilo accanto a un sondaggio del febbraio 2026 su 1.039 professionisti SRE, DevOps e IT operations, sponsorizzato da NeuBird, in cui il 44% ha riferito un disservizio nell'ultimo anno legato ad alert soppressi o ignorati. Una correlazione che comprime quaranta chiamate di reperibilità in un unico incidente è un guadagno reale. Una correlazione che decide in silenzio quali chiamate non vedrai mai è il modo in cui si arriva a quel 44%, e ciò che le distingue è se il raggruppamento sia ispezionabile.
I casi più solidi sono quelli che una persona può verificare in pochi secondi. Un modello che legge la storia dei deploy, lo scostamento di una metrica e tre stream di log e scrive la prima stesura del racconto dell'incidente sta facendo un lavoro che altrimenti tocca alle 3 del mattino a qualcuno con poca memoria, e quando sbaglia la prova sta lì nel paragrafo. Spiegare perché una bolletta si è mossa è lo stesso tipo di compito, pieno di correlazioni che una persona coglie un mese dopo, e lo State of FinOps 2026 della FinOps Foundation, uscito il 19 febbraio 2026 su 1.192 rispondenti che gestiscono oltre 83 miliardi di dollari di spesa annua, ha rilevato che il 98% di loro gestisce ormai spesa per l'IA, in crescita dal 31% di due anni prima. Trasformare un incidente risolto in un runbook scritto è ancora meglio: i fatti sono ormai fermi, e il peggio che può capitare è che una persona corregga una frase.
L'AI code review sull'infrastruttura coglie una classe di errori ed è cieca su un'altra
Il GenAI Code Security Report 2026 di Veracode, pubblicato il 28 luglio 2026, ha testato più di 100 modelli e ha rilevato che il tasso medio di superamento dei test di sicurezza è fermo al 56%, un punto sopra il 55% precedente. Circa il 44% dei compiti di generazione ha introdotto una vulnerabilità rischiosa quando nessuno aveva chiesto esplicitamente della sicurezza. Il migliore, GPT-5.5, ha raggiunto il 68%, fallendo comunque un compito di sicurezza su tre.
La parte irregolare è la parte utile. Quei modelli hanno superato i compiti di SQL injection l'83% delle volte e quelli di crittografia l'87%, ma il cross-site scripting solo il 15% e la log injection il 12%. Un revisore IA è forte su ciò che ha visto etichettato mille volte, quasi cieco altrove, e non ti dirà in quale delle due modalità si trova. Su un diff di infrastructure-as-code usalo come secondo lettore per gli errori ovvi col senno di poi: il security group aperto a 0.0.0.0/0, la modifica che è una sostituzione e non un aggiornamento. Non farne il gate: le classi che si perde sono quelle per cui nessuno ha scritto una regola.
La remediation autonoma è il punto in cui le prove smettono di sostenere il pitch
Lo stesso studio porta il risultato che dovrebbe chiudere per un altro anno la conversazione sul self-healing. Anche quando il modello aveva identificato correttamente sia il servizio all'origine sia il tipo di guasto, ha scelto una remediation non valida in una quota compresa tra il 39,5% e il 62,0% di quegli incidenti diagnosticati correttamente. La diagnosi non si trasferisce nell'azione. La previsione di Gartner del giugno 2025, secondo cui oltre il 40% dei progetti di IA agentica sarebbe stato cancellato entro la fine del 2027, citava controlli del rischio inadeguati accanto ai costi, ed è proprio quello che manca.
La pianificazione della capacità fallisce per una ragione affine: il modello produce un numero perentorio a partire da prove scarse, e un numero perentorio è esattamente ciò che una riunione di pianificazione vuole. L'Articolo 14 dell'AI Act europeo è scritto proprio contro questo, e richiede che una persona incaricata della sorveglianza possa interrompere un sistema ad alto rischio e portarlo a un arresto in uno stato sicuro, e nomina la distorsione dell'automazione come la cosa a cui la sorveglianza deve resistere.
Il tetto di spesa deve stare sopra la console di fatturazione del provider
Nel maggio 2026 a un agente autonomo sono state date credenziali AWS senza restrizioni e il compito di fare port scanning su DN42, una rete amatoriale. Ha fatto il provisioning di cinque istanze m8g.12xlarge, 48 vCPU ciascuna, più load balancer e funzioni Lambda, e poi ha continuato a riapplicare lo stesso template CloudFormation. L'operatore se n'è accorto circa 24 ore dopo, da addebiti sulla carta di credito per un totale di 6.531,30 dollari, per un workload che secondo la comunità sarebbe entrato in un VPS da 5 dollari al mese. AWS ha poi ridotto il conto a 1.894 dollari. La protezione che ha funzionato è stata un credito di cortesia.
Gli strumenti di budget dei grandi provider non lo avrebbero fermato, nessuno dei tre, e tutti e tre lo mettono per iscritto. Amazon documenta che AWS Budgets si aggiorna fino a tre volte al giorno, e che ogni aggiornamento arriva tipicamente tra le 8 e le 12 ore dopo il precedente, una cadenza pensata per esseri umani che fanno errori costosi uno alla volta. Microsoft dichiara che il superamento di una soglia di budget Azure non incide sulle risorse e non ferma il consumo, con i dati di costo tipicamente disponibili tra le 8 e le 24 ore. Google Cloud dichiara che un budget di soli avvisi non limita automaticamente l'utilizzo o la spesa. AWS distribuisce una soluzione open source Budget Controls che interviene al 90% di un budget, copre quattro servizi in una region e ammette che storage e rete continuano ad accumulare addebiti. Un'agenzia di tre persone, raccontata nel luglio 2026, si è vista arrivare un addebito AWS di 14.000 dollari in un solo giorno a fronte di una bolletta mensile normale da 10 a 15 dollari, dopo che degli attaccanti hanno estratto chiavi statiche da un'istanza e le hanno spese in chiamate a modelli Bedrock.
La nostra risposta è mettere il limite dove vengono emesse le credenziali, non dove viene assemblata la fattura. La spesa su Sencai è tracciata mentre avviene, per provider, progetto e ambiente, con cap e budget che avvisano mentre la spesa matura e non su un ciclo di fatturazione tra le 8 e le 24 ore. Agire automaticamente su un cap superato è nella nostra roadmap e non è rilasciato, quindi oggi è ancora una persona a togliere la credenziale. L'IA è l'unico budget che possiamo delimitare in anticipo: si compra in crediti, e un credito è una somma di denaro fissa e non un conteggio di token, quindi un cambio di prezzo del modello sposta quanti token compra un credito e mai quanto vale. Ogni piano personale a pagamento ha un'allowance mensile e un tetto rigido fissato a un multiplo di essa, così che uno script fuori controllo non possa produrre una fattura illimitata. I runbook sono soggetti ad approvazione per la stessa ragione: il modello propone, una persona con nome e cognome esegue.
Una audit trail capace di dire se è stata una persona o un modello
L'Articolo 12, paragrafo 1, dell'AI Act europeo richiede che i sistemi ad alto rischio consentano tecnicamente la registrazione automatica degli eventi lungo l'intero ciclo di vita del sistema, e l'Articolo 26, paragrafo 6, impone ai deployer di conservare quei log per almeno sei mesi, salvo che un'altra legge chieda di più. Se stai pianificando su una data di agosto 2026, correggila. Il regolamento (UE) 2026/1744, il Digital Omnibus sull'IA, in vigore dal 27 luglio 2026, ha spostato i sistemi ad alto rischio autonomi dell'Allegato III al 2 dicembre 2027 e i sistemi incorporati nei prodotti dell'Allegato I al 2 agosto 2028. Le date si sono spostate; gli obblighi no.
La ragione operativa per costruirlo non ha nulla a che fare con la scadenza. Sei mesi dopo un incidente la domanda è se la modifica l'abbia fatta una persona o un modello, e un impianto che registra le azioni dell'IA in un sistema e quelle umane in un altro non può rispondere senza una join di cui nessuno si fida. Ci siamo rifiutati di tenere due registri: le azioni dei modelli e quelle delle persone finiscono in un'unica trail append-only. Sencai la esporta come CSV con entry_hash e prev_hash su ogni riga, così un lettore che non vuole fidarsi della nostra parola può ricalcolare la catena. Il campo che si guadagna il posto è quello piccolo accanto all'attore, che dice se la modifica è arrivata da una persona o da un modello che sta spendendo l'allowance di una persona.
La regola che esce dalle prove non è affascinante e regge. Lascia che un modello legga qualsiasi cosa, comprese quelle che legge male, perché una lettura sbagliata è visibile nel paragrafo che ha scritto. Lascia che scriva solo dove una persona con nome e cognome firma la modifica e sotto c'è un limite sulle credenziali nel caso in cui sbagli anche quella persona. Tra una notifica del provider su un ciclo tra le 8 e le 24 ore e qualcuno che legge la posta nei giorni feriali c'è un rilevatore di fumo e nessun impianto antincendio. L'operatore di DN42 aveva un rilevatore di fumo.