Artificial Intelligence Risk Management Framework:
Trustworthy AI in Critical Infrastructure Profile
La narrativa dominante sull’intelligenza artificiale negli ultimi cinque anni si è costruita su un presupposto fragile, quasi infantile nella sua ingenuità: che i modelli, una volta sufficientemente addestrati e “validati”, possano essere inseriti in qualsiasi contesto operativo come un microservizio qualsiasi. Il problema è che questa fantasia, che può anche funzionare in un CRM o in un sistema di raccomandazione e-commerce, si dissolve brutalmente quando si entra nel dominio delle infrastrutture critiche. Qui non si tratta di suggerire un prodotto o completare un’email; si tratta di orchestrare flussi energetici, gestire reti idriche, assistere decisioni cliniche in tempo reale. E quando un modello allucina, il risultato non è un errore semantico ma un evento fisico.
Il richiamo del National Institute of Standards and Technology, nella sua apparente sobrietà istituzionale, è in realtà una dichiarazione piuttosto brutale: la maggior parte dei sistemi AI oggi distribuiti in contesti critici rappresenta un rischio sistemico. Non perché l’intelligenza artificiale sia intrinsecamente pericolosa, ma perché il modo in cui la stiamo ingegnerizzando e integrando è ancora profondamente immaturo. L’industria ha scambiato l’accuratezza statistica per affidabilità operativa, confondendo metriche di laboratorio con garanzie nel mondo reale. Una confusione che, in ambienti ad alta criticità, diventa letale.
Il punto più interessante, e forse più sottovalutato, riguarda la nozione di comportamento deterministico. Per decenni, l’ingegneria dei sistemi critici si è basata su modelli prevedibili, verificabili, formalmente analizzabili. L’introduzione di modelli probabilistici opachi, come le reti neurali profonde, ha incrinato questo paradigma senza sostituirlo con un’alternativa altrettanto solida. Il risultato è un ibrido instabile: sistemi che appaiono sofisticati ma che non possono garantire né consistenza né degradazione controllata in condizioni di stress.
La degradazione elegante, concetto caro all’ingegneria aerospaziale e nucleare, è quasi assente nei moderni sistemi AI. Quando un modello fallisce, spesso lo fa in modo catastrofico o, peggio, silenzioso. Non segnala l’errore, non riduce progressivamente la propria operatività, non restituisce il controllo in modo chiaro a un sistema umano o deterministico. Semplicemente continua a produrre output plausibili, anche quando ha perso completamente aderenza alla realtà. Questa caratteristica, che nei contesti consumer viene tollerata con un sorriso ironico, in una rete elettrica diventa un incubo.
Il documento tecnico evidenzia anche un cambiamento più profondo, quasi filosofico, nel modo in cui definiamo la “fiducia” nei sistemi AI. Non è più sufficiente testare, validare, certificare in condizioni controllate. Si richiede ora qualcosa di più ambizioso e, per molti team, francamente destabilizzante: garanzie verificabili di performance. Non probabilità, non benchmark, ma vincoli dimostrabili. In altre parole, l’AI deve iniziare a comportarsi come un sistema ingegneristico tradizionale, senza però perdere la sua capacità adattiva.
Qui entra in gioco un concetto che fino a pochi anni fa era confinato a circoli accademici piuttosto elitari: i sistemi neuro-simbolici informati dalla fisica. Una combinazione che, detta in modo brutale, tenta di mettere un guinzaglio matematico a modelli che altrimenti vagano nello spazio delle probabilità. L’idea è semplice ma potente: incorporare vincoli fisici, leggi deterministiche e rappresentazioni simboliche all’interno o accanto ai modelli neurali, in modo da limitare lo spazio degli errori possibili. Non si tratta di nostalgia per i sistemi esperti degli anni Ottanta, ma di una necessità evolutiva.
La realtà operativa, tuttavia, è meno elegante della teoria. Gli operatori di infrastrutture critiche si trovano oggi in una posizione paradossale. Da un lato, subiscono una pressione crescente per adottare soluzioni AI, spinte da narrative di efficienza, ottimizzazione e resilienza. Dall’altro, non dispongono degli strumenti concettuali e organizzativi per tradurre requisiti di “trustworthiness” in specifiche tecniche actionable per i team di sviluppo. Il risultato è una comunicazione disallineata, quasi schizofrenica: richieste vaghe di sicurezza che si traducono in implementazioni altrettanto vaghe.
Il problema si amplifica ulteriormente quando si considera la convergenza tra OT, IT e ICS. Tre mondi che storicamente hanno parlato linguaggi diversi, con priorità e modelli di rischio divergenti. L’IT è abituato a patch, aggiornamenti continui, cicli DevOps rapidi. L’OT privilegia la stabilità, la prevedibilità, la continuità operativa. Gli ICS vivono in una zona intermedia, con vincoli legacy e requisiti di sicurezza estremamente rigidi. Integrare un sistema AI in questo ecosistema non è solo una sfida tecnica, è un esercizio di diplomazia ingegneristica.
La questione della robustezza adversariale aggiunge un ulteriore livello di complessità. Per anni è stata trattata come un problema di nicchia, confinato a scenari di laboratorio o a dimostrazioni accademiche. Oggi, invece, emerge come un requisito fondamentale lungo l’intero ciclo di vita del sistema. Non basta “testare” la resistenza agli attacchi dopo il deployment; bisogna progettare, addestrare, validare e monitorare i modelli con questa dimensione in mente fin dall’inizio. In altre parole, la sicurezza non è più un layer, ma una proprietà intrinseca.
Questo cambio di paradigma ha implicazioni economiche significative, anche se raramente discusse apertamente. Costruire sistemi AI con garanzie verificabili, integrazione neuro-simbolica e robustezza adversariale end-to-end è costoso. Richiede competenze rare, infrastrutture sofisticate e tempi di sviluppo più lunghi. In un mercato ossessionato dalla velocità e dal time-to-market, questo rappresenta una frizione notevole. Non sorprende quindi che molte organizzazioni scelgano scorciatoie, sperando che i problemi emergano più tardi, possibilmente sotto la responsabilità di qualcun altro.
Una frase che circola spesso nei corridoi delle grandi aziende tecnologiche recita, con un certo cinismo, che “se non è in produzione, non esiste”. Nel contesto delle infrastrutture critiche, questa filosofia si trasforma in una roulette russa. Mettere in produzione un sistema AI non completamente compreso equivale a introdurre una variabile non controllata in un sistema già complesso. La differenza rispetto al passato è che questa variabile non è lineare, non è facilmente modellabile, e può interagire con il resto del sistema in modi emergenti e imprevedibili.
Il tema della verificabilità merita un’ulteriore riflessione. Nei sistemi tradizionali, la verifica si basa su modelli matematici chiari, su specifiche formali, su test esaustivi. Nei sistemi AI, soprattutto quelli basati su deep learning, questa chiarezza è assente. Si lavora con distribuzioni, con approssimazioni, con spazi di stato enormi. Trasformare questo paradigma in qualcosa di verificabile richiede non solo nuovi strumenti, ma una revisione profonda del modo in cui pensiamo l’ingegneria del software.
Alcuni osservatori più ottimisti vedono in questa crisi un’opportunità. L’obbligo di rendere l’AI più affidabile potrebbe accelerare lo sviluppo di nuove metodologie, nuovi framework, nuove discipline ibride. Altri, più realistici, notano che il gap tra ciò che è teoricamente desiderabile e ciò che è economicamente sostenibile rimane ampio. Nel frattempo, le infrastrutture critiche continuano a evolversi, e con esse cresce la superficie di attacco e la complessità operativa.
Una delle ironie più sottili di questa fase storica è che, mentre l’AI viene spesso presentata come la soluzione a problemi di complessità crescente, la sua introduzione non fa che aumentare quella stessa complessità. È un effetto ben noto in economia, dove ogni nuova tecnologia tende inizialmente a complicare il sistema prima di semplificarlo. La differenza è che, nel caso delle infrastrutture critiche, il margine di errore è drasticamente più ridotto.
Il quadro che emerge è quello di un’industria che sta correndo più veloce della propria capacità di comprendere le implicazioni delle proprie innovazioni. Il richiamo degli standard, come quelli del NIST, non è un esercizio burocratico, ma un tentativo di reintrodurre disciplina in un ecosistema che ha privilegiato l’esplorazione rispetto alla stabilità. La domanda, a questo punto, non è se riusciremo a costruire sistemi AI affidabili per le infrastrutture critiche, ma quanto costerà arrivarci e quanti incidenti saranno necessari per convincere il mercato che la scorciatoia non esiste.