Il 93% delle aziende ha già subito incidenti infrastrutturali causati dall’intelligenza artificiale. Il dato emerge dal report 2026 State of Infrastructure Automation di Spacelift e Panterra Group, che ha intervistato 406 decision maker IT nel mese di aprile. Solo il 19% di queste organizzazioni ha una governance adeguata per gestire il codice che l’AI genera — e il 97% di quelle che adottano AI senza controlli ha già pagato il prezzo in produzione.
La cifra del 93% sembra alta al punto da sembrare esagerata. Non lo è: quando si analizza la composizione degli “incidenti”, emerge un universo che va ben oltre le violazioni di sicurezza gravi. Il 37% delle organizzazioni ha subito costosi lavori di rework — codice AI-generated che ha richiesto riscrittura significativa dopo il deploy. Il 36% ha trovato configurazioni di sicurezza errate in produzione. Il 35% ha sperimentato infrastructure drift, ovvero divergenza tra l’infrastruttura dichiarata nel codice e quella effettivamente in esecuzione. Questi non sono incidenti drammatici con downtime visibile: sono inefficienze strutturali che erodono la produttività e aumentano il rischio in modo silenzioso.
L’82% scrive codice con l’AI. Il 19% sa cosa fa con quel codice.
L’82% delle organizzazioni intervistate usa l’AI per generare codice di infrastruttura — Terraform, Kubernetes manifests, CloudFormation template, pipeline CI/CD. Questo dato è coerente con la tendenza generale: i tool di codice AI come GitHub Copilot, Cursor e Claude Code si sono diffusi rapidamente tra i team di infrastructure e DevOps come tra i developer applicativi.
Il problema non è nel codice generato dall’AI in sé — che spesso è tecnicamente corretto sulla singola istruzione. Il problema è nel contesto che l’AI non ha: non conosce i constraint specifici dell’ambiente di produzione, le policy di sicurezza interne, le limitazioni del cloud account, le dipendenze con i sistemi legacy. Un modello AI addestrato su codice open-source generico non sa che la tua organizzazione ha una policy che vieta certi tipi di security group aperti su internet, o che il tuo ambiente AWS ha quota limits specifici che rendono certi pattern di scaling non applicabili.
Il 86% dei respondent dichiara di governare l’uso dell’AI — ma solo il 30% ha policy formali scritte. Questo gap tra percezione e realtà è il dato più rivelatore dell’intero report. Governare l’AI non significa avere una slide in un deck di onboarding che dice “usa l’AI in modo responsabile.” Significa avere policy-as-code integrate nelle pipeline, validazione automatica dell’output AI prima del deploy, audit trail che documenta quale codice è stato generato da AI e quale da umani, e processi di review specifici per il codice AI-generated che tengono conto dei suoi pattern di errore caratteristici.
L’86% dice di governare l’AI. Il 30% ha policy scritte. Il gap è il rischio che non vedi.
Un breach su cinque è causato da codice AI-generated
Un breach di sicurezza su cinque nelle organizzazioni enterprise è causato da codice AI-generated, secondo i dati ITPro aggregati su incidenti documentati nel 2025-2026. Il dato è difficile da verificare indipendentemente, ma è coerente con i pattern di vulnerabilità che i ricercatori di sicurezza hanno identificato nell’output degli LLM per il codice.
I pattern di errore del codice AI-generated nel dominio della sicurezza sono documentati e prevedibili: overexposure di credenziali nei log, configurazioni di autenticazione con default insicuri, permessi IAM eccessivamente permissivi, gestione dei segreti con pattern deprecati. L’AI genera questi pattern non perché sia “malevola” ma perché li ha visti nel codice di addestramento — dove erano comuni prima che le best practice di sicurezza diventassero standard. Il modello replica quello che ha visto, e quello che ha visto include anni di codice con pratiche di sicurezza insufficienti.
Il MIT AI Incident Tracker documenta una crescita degli incidenti legati a codice AI nel settore infrastrutturale del 340% tra il 2024 e il 2025. La maggior parte degli incidenti non è classificata come “attacco AI” ma come “errore di configurazione” o “vulnerability in software” — il che significa che la causalità AI è spesso invisibile nelle statistiche di sicurezza tradizionali. La cybersecurity nell’era AI pone nuovi rischi specifici che i framework di scanning tradizionali non rilevano automaticamente.
Il framework normativo che arriva: AI Act, DORA, legge 56/2025
Il 97% delle organizzazioni che adottano AI senza governance adeguata ha già subito incidenti. Ma il costo degli incidenti sta per aumentare in modo significativo per effetto del framework normativo che si sta consolidando.
L’AI Act europeo ha introdotto sanzioni fino al 7% del fatturato globale per le violazioni più gravi — quelle relative ai sistemi AI ad alto rischio, categoria che include applicazioni nel settore della cybersecurity, delle infrastrutture critiche e dei sistemi decisionali automatizzati. DORA — Digital Operational Resilience Act — è in vigore dal gennaio 2025 per il settore finanziario e impone requisiti stringenti sulla resilienza dei sistemi digitali, inclusi quelli che integrano AI. La normativa specificatamente italiana sull’AI — legge 56/2025, in vigore dal maggio 2025 — aggiunge un layer di obblighi domestici che si sovrappongono all’AI Act europeo.
Le aziende che oggi non hanno governance adeguata non stanno solo subendo rischi tecnici: stanno accumulando rischi normativi che possono materializzarsi in sanzioni significative nel momento in cui un incidente attira l’attenzione delle autorità di vigilanza. La combinazione di un incidente documentato e di una governance insufficiente è esattamente il profilo che le autorità cercano nei procedimenti sanzionatori.
Il 93% ha già avuto un incidente. L’AI Act ha già iniziato a fare sanzioni. Il timing è pessimo.
Policy-as-code: la risposta strutturale, non quella di immagine
La risposta alla governance dell’AI nell’infrastruttura non è un documento di policy approvato dal board — è l’implementazione di controlli tecnici automatizzati che rendono impossibile o difficile fare le cose sbagliate. Questo è il principio della policy-as-code: le regole di governance vengono codificate come vincoli che operano nelle pipeline automaticamente, non come raccomandazioni che gli ingegneri devono ricordarsi di rispettare.
Strumenti come Open Policy Agent, HashiCorp Sentinel, e le funzionalità native di governance dei cloud provider principali permettono di definire policy che vengono verificate automaticamente prima di ogni deploy. Una policy che vieta security group aperti a internet, o che richiede la crittografia su tutti i bucket di storage, o che impone il tagging obbligatorio delle risorse — quando queste policy sono codificate e automaticamente enforced, l’AI che genera configurazioni non conformi viene bloccata prima che il codice raggiunga la produzione, non dopo che l’incidente è già avvenuto.
Il 19% delle organizzazioni con governance adeguata non si distingue per avere team di sicurezza più grandi o policy più elaborate. Si distingue per aver integrato i controlli nelle pipeline, rendendoli automatici e sistematici invece che dipendenti dall’attenzione umana in ogni singolo deploy. La disciplina non viene dai developer che scelgono di fare le cose bene: viene dal sistema che li fa atterrare in sicurezza anche quando non pensano attivamente alla sicurezza. La differenza tra chi governa un agente AI prima di accenderlo e chi lo governa dopo il primo incidente è misurabile in settimane di rework e in sanzioni normative.
Il costo vero: rework invisibile e debito tecnico accelerato
Il 37% di rework documentato dal report Spacelift è probabilmente sottostimato — perché include solo il rework che le organizzazioni hanno identificato e attribuito al codice AI-generated. Il rework non identificato, quello che viene trattato come “un bug normale” senza tracciare la causalità AI, probabilmente supera di molto la cifra documentata.
Il debito tecnico generato da codice AI-generated ha caratteristiche specifiche che lo rendono più difficile da gestire del debito tecnico tradizionale. Il codice AI è spesso “coerente in superficie ma fragile in profondità”: supera i test unitari, rispetta la sintassi, produce output corretto nei casi standard — ma contiene assunzioni implicite sul contesto che non reggono quando le condizioni cambiano. Identificare questo debito richiede review più attenta e più esperta del codice AI-generated rispetto al codice umano, perché i pattern di errore sono meno prevedibili.
Per ogni organizzazione che ha implementato AI nel codice di infrastruttura senza audit sistematici del codice generato, esiste una quantità non quantificata di debito tecnico nascosto che si manifesterà come incidenti, rework e costi di manutenzione nei prossimi 12-24 mesi. Il costo della governance preventiva — stimato in 5-15% del costo del progetto AI — è una frazione del costo atteso del debito non gestito.
La conclusione del report Spacelift non è “l’AI è pericolosa”: è che adottare AI senza governance è una scelta con costi certi e prevedibili, che le organizzazioni stanno pagando già ora — e che pagheranno di più quando il framework normativo sarà pienamente operativo. Chi costruisce governance adesso ha un vantaggio competitivo concreto rispetto a chi la costruirà dopo il primo incidente grave.
Dagli agenti AI personalizzati alla formazione.
C’è molto che possiamo fare insieme.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Sara Romano
Source link
