Avvertimento sull'IA di Robert M. Lee: le infrastrutture critiche stanno adottando l'IA più rapidamente di quanto riescano a vedere i rischi

Robert M. Lee ha lanciato un avvertimento sull'IA dopo che Dragos ha rilevato che solo il 30% delle reti di tecnologia operativa disponeva di visibilità sui propri ambienti. L'avvertimento sull'IA di Robert M. Lee riguarda un conflitto crescente all'interno di utility, fabbriche, data center e sistemi energetici. Gli operatori stanno aggiungendo software autonomo prima che molti riescano a osservare in modo affidabile le apparecchiature già esistenti.

Lee, CEO e cofondatore di Dragos, sostiene che l'adozione dell'IA stia procedendo più rapidamente del monitoraggio della sicurezza nella tecnologia operativa. La tecnologia operativa, o OT, comprende hardware e software che controllano processi fisici. A differenza di una tipica applicazione da ufficio, un guasto OT può interrompere elettricità, acqua, produzione manifatturiera, trasporti o un altro servizio essenziale.

Non si tratta semplicemente di un altro avvertimento sull'uso dell'IA da parte dei criminali. Il problema più difficile deriva dall'inserimento dell'IA in ambienti che già contengono apparecchiature legacy, inventari incompleti e monitoraggio debole. L'IA può migliorare le previsioni e l'efficienza, ma può anche rendere meno chiaro il motivo per cui un processo fisico è cambiato.

Questo compromesso pone gli operatori delle infrastrutture tra la pressione per un'automazione più rapida e la disciplina ingegneristica necessaria per operazioni sicure. Anche gli aggressori stanno studiando più da vicino i sistemi di controllo. La competizione non è quindi tra adozione dell'IA e resistenza alla tecnologia. È tra automazione rapida e visibilità operativa.

L'avvertimento di Lee porta il dibattito sull'IA nelle operazioni fisiche

Il cambiamento importante è che l'IA sta passando da strumenti di supporto a sistemi in grado di influenzare i processi fisici.

Lee ha esposto la sua tesi in un'analisi delle infrastrutture dell'11 settembre 2026 pubblicata dal World Economic Forum. Ha descritto applicazioni di IA che entrano in impianti manifatturieri, reti elettriche, data center, parchi di batterie, siti di energia rinnovabile e operazioni minerarie.

Alcune implementazioni aiutano ancora le persone a esaminare i dati o a prevedere le esigenze di manutenzione. Altre si stanno avvicinando al ciclo di controllo, il processo di feedback che collega sensori, decisioni e apparecchiature fisiche. Questo cambiamento modifica le possibili conseguenze di un errore.

Una raccomandazione errata all'interno di una dashboard può essere esaminata prima che qualcuno agisca. Un controller automatizzato può modificare il comportamento delle apparecchiature prima che un operatore ne comprenda il ragionamento. Una maggiore autonomia riduce la distanza tra l'output di un modello e un risultato fisico.

Consigli di amministrazione e dirigenti vedono ragioni sostanziali per adottare questi sistemi. L'IA può aiutare a prevedere la domanda, ottimizzare l'uso dell'energia, rilevare comportamenti anomali delle apparecchiature e dare priorità alla manutenzione. Gli operatori delle infrastrutture devono inoltre far fronte a carenze di personale, apparecchiature obsolete e richieste di maggiore efficienza.

Questi vantaggi creano pressione per abbreviare i tempi di convalida. Lee avverte che la stessa pressione può ridurre l'esame dei nuovi fornitori e aumentare la complessità dei sistemi. L'organizzazione ottiene un ulteriore livello decisionale mentre il suo team di sicurezza potrebbe ancora non disporre di un inventario completo degli asset.

I sistemi sottostanti hanno già attraversato diverse transizioni tecnologiche. I controlli meccanici sono diventati sistemi digitali. Le reti industriali isolate hanno acquisito connessioni con reti aziendali, servizi remoti e dispositivi basati su protocollo internet.

Ogni transizione ha creato capacità utili e nuove dipendenze. Molte organizzazioni non hanno raggiunto una visibilità completa prima dell'arrivo della transizione successiva. L'IA entra ora in questo ambiente incompiuto.

Il rischio non si limita a un modello che produce una risposta errata. Il modello può dipendere da dati esterni, servizi cloud, interfacce di programmazione delle applicazioni o aggiornamenti dei fornitori. Ogni dipendenza crea un ulteriore percorso di guasto che gli operatori devono comprendere.

Un servizio di IA potrebbe scomparire durante un guasto del fornitore o una correzione di mercato. Un aggiornamento del modello potrebbe cambiare un comportamento precedentemente testato dagli ingegneri. Dati compromessi potrebbero distorcere le raccomandazioni senza produrre un errore software evidente.

Le infrastrutture critiche non possono trattare queste possibilità come normali tempi di inattività delle applicazioni. Gli operatori devono preservare stati sicuri, procedure manuali e prove affidabili per le indagini sugli incidenti. L'avvertimento sull'IA di Robert M. Lee pone questi requisiti operativi al centro del dibattito.

Lee non sta chiedendo ai proprietari delle infrastrutture di rifiutare l'IA. Sostiene che governance, visibilità e pianificazione dei guasti debbano precedere un'autonomia più profonda. In caso contrario, l'adozione può aumentare l'incertezza in sistemi in cui l'incertezza comporta già conseguenze fisiche.

Il rischio per le infrastrutture IA secondo Dragos inizia dalla mancanza di visibilità

L'IA non crea ogni debolezza infrastrutturale, ma può moltiplicare le conseguenze delle debolezze che i difensori non riescono a vedere.

Le rilevazioni sulle minacce del 2026 alla base dell'argomentazione di Lee descrivono un grave divario di visibilità. Dragos afferma che solo il 30% delle reti OT valutate disponeva di una visibilità sufficiente sui propri ambienti. Riferisce inoltre che il 56% non riusciva a vedere oltre il confine tra IT e OT.

L'azienda afferma che l'88% ha avuto difficoltà nel rilevamento e nella risposta. Queste cifre provengono da Dragos, un fornitore di sicurezza OT, e non da un censimento governativo indipendente. Dovrebbero essere considerate risultati basati sui clienti, sulle indagini e sulla telemetria dell'azienda.

Anche con questa limitazione, il modello è rilevante. Un'organizzazione non può proteggere asset che non ha identificato. Non può nemmeno indagare su attività sospette quando traffico di rete, modifiche ai controller e azioni ingegneristiche non sono mai stati registrati.

Questo crea uno specifico rischio per le infrastrutture IA secondo Dragos. I nuovi sistemi di IA possono aggiungere flussi di dati, componenti software, credenziali e connessioni esterne. Possono inoltre prendere decisioni su apparecchiature che seguono protocolli industriali specializzati.

Il monitoraggio IT tradizionale non interpreta sempre tali protocolli o processi fisici. Un team di sicurezza aziendale potrebbe rilevare un accesso insolito senza capire se abbia modificato una pompa, un relè, una turbina o una linea di produzione. Il monitoraggio nativo OT collega l'attività informatica al comportamento previsto delle apparecchiature.

Dragos afferma che le organizzazioni con visibilità OT completa hanno rilevato e contenuto incidenti ransomware in media in cinque giorni. Lee ha confrontato questa cifra con una media di 42 giorni a livello industriale. Il confronto suggerisce che la visibilità possa ridurre materialmente la finestra operativa di un aggressore.

Tuttavia, non dimostra che il solo monitoraggio abbia causato la differenza. Le organizzazioni con una visibilità più ampia possono avere anche personale migliore, segmentazione, piani di risposta agli incidenti e supporto dei dirigenti. Le cifre mostrano un'associazione che merita attenzione, non una garanzia universale di prestazioni.

Il problema della visibilità diventa più difficile quando l'IA introduce decisioni probabilistiche anziché deterministiche. La logica di controllo tradizionale segue di solito regole definite che gli ingegneri possono ispezionare. Un sistema di machine learning può rispondere in modo diverso quando cambiano i suoi input, il modello o il contesto circostante.

Questa variabilità non rende automaticamente l'IA insicura. Rende però più impegnativi i test e la documentazione. Gli operatori necessitano di registri che mostrino quale versione del modello è stata eseguita, quali dati ha ricevuto, quale azione ha raccomandato e se una persona l'ha approvata.

Devono inoltre distinguere il comportamento del modello da interferenze dannose. Un'azione inattesa potrebbe derivare da dati corrotti, un account compromesso, un'istruzione non sicura, un difetto software o una normale variazione del modello. Senza registri sufficienti, questi scenari possono apparire identici.

Le organizzazioni infrastrutturali dovrebbero quindi mappare ogni dipendenza dall'IA prima di assegnarle autorità operativa. Questa mappa include dati di addestramento e operativi, fornitori di modelli, servizi cloud, integrazioni, utenti, credenziali, canali di aggiornamento e asset fisici interessati.

Questo lavoro assomiglia alla creazione di una base di conoscenza tecnica ricercabile, ma i requisiti sono più rigorosi. I team necessitano di registri controllati, responsabilità chiare e procedure di ripristino testate. Una più ampia base di conoscenza ingegneristica può supportare la documentazione, ma non sostituisce il monitoraggio della sicurezza OT.

La visibilità ha anche una dimensione umana. Gli operatori devono sapere quando l'automazione è attiva e quale autorità detiene. I team di sicurezza necessitano di una conoscenza sufficiente dei processi per riconoscere quando un comando tecnicamente valido crea uno stato fisico non sicuro.

L'obiettivo non è registrare più dati senza uno scopo. È preservare un contesto sufficiente per il rilevamento, l'intervento e l'analisi delle cause profonde. La sicurezza delle infrastrutture critiche basata sull'IA dipende da queste prove per l'intera vita operativa del sistema.

Gli aggressori stanno mappando gli stessi cicli di controllo in cui entrerà l'IA

Gli operatori delle infrastrutture stanno aggiungendo intelligenza agli ambienti di controllo mentre gli avversari imparano come tali ambienti si comportano.

Dragos riferisce di aver monitorato 26 gruppi di minacce OT durante il suo ciclo di rendicontazione del 2026. Afferma che gli avversari sono andati oltre l'accesso di base e hanno iniziato a mappare i cicli di controllo. Questo lavoro includeva l'identificazione delle workstation di ingegneria e la raccolta di file di configurazione o dati di allarme.

Un file di configurazione può rivelare come comunicano le apparecchiature industriali e quali limiti regolano un processo. I dati di allarme possono mostrare ciò che gli operatori considerano anomalo. Le workstation di ingegneria spesso forniscono accesso privilegiato ai controller e ad altri asset sensibili.

Questa ricognizione è importante perché interrompere un processo fisico richiede più che entrare in una rete. Gli aggressori devono comprendere apparecchiature, tempistiche, controlli di sicurezza e dipendenze operative. Una mappatura dettagliata riduce questa barriera di conoscenza.

Lee ha identificato ELECTRUM e KAMACITE come esempi di gruppi che perseguono questa comprensione più profonda. Ha affermato che KAMACITE ha trascorso mesi a mappare cicli di controllo nelle infrastrutture degli Stati Uniti. ELECTRUM aveva in precedenza preso di mira la rete elettrica ucraina e ha continuato a sviluppare capacità contro i sistemi energetici.

Secondo Lee, ELECTRUM ha attaccato risorse energetiche distribuite in Polonia nel dicembre 2025. Tali risorse includevano sistemi di gestione dell'energia rinnovabile. Assomigliano agli ambienti in cui gli operatori desiderano sempre più utilizzare l'IA per ottimizzare produzione e accumulo.

Questo non significa che l'IA abbia causato quell'incidente. Mostra che gli ambienti di controllo sottostanti attraggono già avversari capaci. L'aggiunta di automazione governata in modo inadeguato potrebbe aumentare il numero di componenti che gli aggressori possono studiare o manipolare.

L'IA modifica anche l'economia del lavoro offensivo. I modelli possono assistere nell'analisi del codice, nella ricognizione, nella traduzione, nella revisione della documentazione e nella creazione di script. Possono aiutare aggressori meno esperti a comprendere più rapidamente apparecchiature non familiari.

Rapporti recenti suggeriscono che l'IA spesso accelera tecniche esistenti anziché inventarne di completamente nuove. Gli aggressori traggono ancora vantaggio da dispositivi esposti, credenziali predefinite, segmentazione debole e applicazione tardiva delle patch. L'IA può aiutarli a trovare e sfruttare più velocemente queste debolezze familiari.

Questa distinzione evita che il racconto scivoli nella fantascienza. Una utility non deve affrontare una superintelligenza completamente autonoma prima di sperimentare un pericolo legato all'IA. Un gruppo guidato da persone che usa l'IA per ampliare la ricognizione di routine può creare pressione immediata.

L’opportunità difensiva è altrettanto concreta. L’AI può aiutare i team di sicurezza a stabilire le priorità degli avvisi, analizzare grandi set di dati, identificare sequenze insolite e recuperare contesto tecnico. Questi utilizzi possono essere preziosi quando persone qualificate mantengono l’autorità sulle azioni consequenziali.

Il conflitto emerge quando le organizzazioni trattano l’AI difensiva come un sostituto dei controlli fondamentali. Un modello di allerta non può compensare un accesso remoto non gestito. L’analisi automatizzata non può recuperare registri che l’organizzazione non ha mai raccolto.

I principi di sicurezza OT di CISA sottolineano decisioni che preservano ambienti operativi sicuri e protetti. La guida precede questo specifico avvertimento, ma le sue priorità restano pertinenti.

I proprietari delle infrastrutture necessitano ancora di inventari accurati degli asset, configurazioni sicure, segmentazione di rete, accesso remoto controllato e risposta agli incidenti testata. L’AI dovrebbe operare all’interno di questi controlli. Non dovrebbe diventare una scorciatoia per aggirarli.

Il modello di implementazione più solido assegna all’AI responsabilità limitate e osservabili. Un modello potrebbe classificare i casi di manutenzione senza modificare direttamente le apparecchiature. Potrebbe redigere una sintesi investigativa mentre gli analisti ne verificano le prove.

I sistemi a rischio più elevato richiedono confini più robusti. Gli operatori possono limitare i comandi, applicare limiti di sicurezza deterministici, richiedere l’approvazione umana e isolare le funzioni critiche. Possono anche testare il comportamento del sistema quando i dati diventano indisponibili o fuorvianti.

Questo approccio considera l’AI come un componente di un sistema di sicurezza, non come l’operatore indiscusso del sistema. Preserva i vantaggi di un’analisi più rapida, limitando al contempo il percorso che può portare da un guasto del modello a un’interruzione fisica.

L’avvertimento sull’AI di Robert M. Lee espone un compromesso dell’automazione

La scelta principale non è se usare l’AI, ma se l’automazione resterà osservabile, reversibile e subordinata ai controlli di sicurezza.

L’avvertimento sull’AI di Robert M. Lee descrive un compromesso che le normali implementazioni aziendali possono nascondere. Maggiore autonomia può ridurre i carichi di lavoro e i tempi di reazione. Può anche ridurre il tempo a disposizione di una persona per contestare una decisione non sicura.

Gli operatori delle infrastrutture gestiscono da tempo l’automazione attraverso revisioni ingegneristiche, controlli sulle modifiche, ridondanza e progettazione fail-safe. L’AI non invalida queste pratiche. Aumenta la necessità di applicarle con attenzione.

Un’implementazione dovrebbe iniziare da un problema operativo definito. I team devono stabilire a cosa il modello può accedere, cosa può raccomandare e cosa può modificare. Dovrebbero inoltre identificare le azioni che il modello non potrà mai intraprendere.

Questi confini necessitano di un’applicazione tecnica. Un documento di policy non può impedire a un’integrazione con privilegi eccessivi di impartire comandi. I controlli di accesso, l’architettura di rete e i sistemi di sicurezza devono limitare l’autorità effettiva del modello.

I test devono coprire più dell’accuratezza media. Gli operatori hanno bisogno di scenari che includano sensori mancanti, input corrotti, istruzioni in conflitto, servizi cloud non disponibili e stati imprevisti delle apparecchiature. Devono testare il ripristino dopo il guasto del componente AI.

Il framework NIST sui rischi dell’AI organizza il lavoro sui rischi attorno a governance, mappatura, misurazione e gestione. Nell’aprile 2026, NIST ha inoltre annunciato il lavoro su un profilo per le infrastrutture critiche relativo al framework.

Questo profilo è destinato ad aiutare gli operatori delle infrastrutture a tradurre i principi di AI affidabile in pratiche specifiche per settore. Il suo sviluppo segnala che le policy generali sull’AI non sono sufficienti per le operazioni fisiche. Energia, acqua, trasporti e manifattura affrontano conseguenze e vincoli diversi.

NIST considera inoltre sicurezza e resilienza caratteristiche fondamentali di un’AI affidabile. La resilienza significa che un sistema può resistere ai problemi e riprendersi senza danni inaccettabili. Per un’implementazione industriale, ciò include operare in sicurezza quando il modello non è disponibile.

Il funzionamento manuale resta quindi un test importante. I team dovrebbero sapere se il personale può continuare a fornire i servizi essenziali dopo aver perso un fornitore di AI, un endpoint del modello o un set di dati di supporto. Hanno inoltre bisogno di stime realistiche sulla durata di tale soluzione di emergenza.

Una modalità manuale di fallback che esiste solo nella documentazione può fallire durante un’emergenza. Gli operatori devono esercitarla in condizioni controllate. Il ricambio del personale, le modifiche alle apparecchiature e la crescente automazione possono rendere silenziosamente inutilizzabili le vecchie procedure.

La continuità del fornitore crea un’altra preoccupazione. Un operatore infrastrutturale può dipendere da una startup, da un modello proprietario o da un’integrazione cloud che cambia rapidamente. Le garanzie contrattuali non possono sostituire piani di uscita tecnici.

Le organizzazioni dovrebbero conservare i dati e le configurazioni necessari per passare a un altro fornitore. Dovrebbero comprendere quali funzioni si interrompono quando un servizio scompare. Hanno inoltre bisogno di controlli per gli aggiornamenti che potrebbero alterare comportamenti già convalidati.

La governance dei dati appartiene allo stesso piano operativo. Gli strumenti di AI possono esporre dettagli sensibili della rete, documentazione delle apparecchiature o informazioni sugli incidenti quando i team inviano materiale a servizi esterni. Prompt non controllati possono diventare un ulteriore canale di esfiltrazione dei dati.

Un flusso di lavoro informativo governato può aiutare i team a organizzare il materiale approvato e ridurre la gestione frammentata. Gli operatori delle infrastrutture critiche necessitano comunque di controlli specifici per settore che disciplinino classificazione, conservazione, accesso ed elaborazione esterna.

La domanda scettica è se fornitori e operatori possano convalidare modelli in rapida evoluzione con il rigore atteso per apparecchiature industriali di lunga durata. I modelli possono aggiornarsi ogni mese, mentre i sistemi di controllo restano implementati per decenni. Queste tempistiche non si allineano naturalmente.

Nessun framework può eliminare questa discrepanza. Gli operatori devono gestirla tramite controllo delle versioni, test ripetibili, implementazioni graduali, monitoraggio e capacità di rollback. Dovrebbero presumere che il comportamento dei modelli e le condizioni di minaccia cambieranno.

La sicurezza dell’AI nelle infrastrutture critiche dipende quindi dalla limitazione delle sorprese. I team non possono prevedere ogni guasto, ma possono preservare le prove, i confini di autorità e percorsi di ripristino sicuri. Queste capacità determinano se un’anomalia diventa un incidente gestibile o un’interruzione inspiegabile.

La regolamentazione avanza, ma gli operatori non possono attendere un regolamento perfetto

Le linee guida governative riconoscono sempre più il rischio, ma la responsabilità resta agli operatori che prendono decisioni di implementazione oggi.

La roadmap di CISA sulla sicurezza dell’AI affronta esplicitamente l’adozione dell’AI nelle infrastrutture critiche. L’agenzia ha affermato che l’implementazione potrebbe aumentare l’esposizione a guasti, attacchi fisici e attacchi informatici.

La roadmap ha richiesto pratiche secure-by-design, red teaming, gestione delle vulnerabilità e coinvolgimento degli stakeholder infrastrutturali. Questi obiettivi hanno stabilito una direzione. Non hanno creato requisiti tecnici vincolanti per ogni settore o implementazione.

La regolamentazione delle infrastrutture critiche è frammentata perché i settori differiscono in modo sostanziale. Una rete elettrica, un servizio idrico, un ospedale, un oleodotto e una rete di trasporto non condividono tecnologie o modelli di rischio identici. Anche la proprietà e l’autorità regolatoria variano.

Questa frammentazione può produrre una governance dell’AI disomogenea. Un grande operatore può istituire un programma di revisione specializzato. Una piccola utility municipale può affidarsi alle garanzie del fornitore perché non dispone di competenze di sicurezza AI.

È qui che l’avvertimento sull’AI di Robert M. Lee mette sotto pressione consigli di amministrazione e team di approvvigionamento. Non possono presumere che regolatori o fornitori di modelli abbiano risolto ogni rischio operativo. Le decisioni di acquisto diventano decisioni di architettura della sicurezza.

I contratti dovrebbero richiedere documentazione su dipendenze del modello, processi di aggiornamento, incidenti di sicurezza, gestione dei dati e obblighi di supporto. Gli operatori necessitano inoltre del diritto di testare i sistemi e ricevere informazioni sulle modifiche significative.

La valutazione indipendente può aiutare, ma il valutatore deve comprendere l’OT. Una valutazione generica delle applicazioni può non rilevare la sicurezza di processo, il comportamento dei controller o il ripristino operativo. La sicurezza delle infrastrutture richiede cooperazione tra specialisti di cybersicurezza, ingegneri, fornitori e operatori in prima linea.

I regolatori possono migliorare la coerenza definendo prove minime per le implementazioni a rischio più elevato. Tali prove potrebbero includere modelli di minaccia, risultati di convalida, requisiti di controllo umano, segnalazione degli incidenti e procedure di fallback dimostrate.

Tuttavia, la conformità non dovrebbe diventare l’unico obiettivo. Un sistema può soddisfare una checklist lasciando inesplorate importanti dipendenze fisiche. La domanda rilevante è se l’organizzazione possa mantenere operazioni sicure durante un attacco, un errore o la perdita di un servizio.

La sfida economica resta significativa. Molte organizzazioni infrastrutturali dispongono di personale limitato e apparecchiature obsolete. Nuovi obblighi senza finanziamenti o supporto all’implementazione possono creare burocrazia senza una significativa riduzione del rischio.

Per questo i controlli di base sono importanti. Gli obiettivi di performance di CISA danno priorità a pratiche con un ampio valore di riduzione del rischio. Includono protezioni sia per l’information technology sia per l’operational technology.

Gli operatori dovrebbero stabilire queste basi prima di conferire all’AI un’autorità più ampia. Autenticazione robusta, accesso remoto sicuro, segmentazione, backup, logging e piani di risposta proteggono i sistemi indipendentemente dal fatto che un incidente coinvolga l’AI.

Le policy dovrebbero inoltre distinguere tra categorie di rischio AI. Gli attaccanti possono usare l’AI contro le infrastrutture. Gli avversari possono colpire un sistema AI o i suoi dati. Un’implementazione AI può anche fallire senza alcun attaccante.

Queste categorie richiedono controlli diversi. La threat intelligence aiuta contro le attività malevole. La valutazione dei modelli affronta le prestazioni e le modalità di guasto. La governance determina chi può approvare, monitorare, modificare o disabilitare il sistema.

Trattare ogni problema come un “attacco informatico AI” nasconde queste differenze. Può anche incoraggiare acquisti costosi che non affrontano la debolezza effettiva. Una chiara classificazione degli incidenti diventerà sempre più importante con la crescita delle implementazioni.

Il test normativo è se le linee guida cambino il comportamento operativo prima che un grave guasto imponga la questione. Pubblicare un altro framework non basta. Revisioni dell’adozione, requisiti di approvvigionamento, esercitazioni e divulgazioni degli incidenti mostreranno se la governance sta diventando concreta.

Tre segnali mostreranno se la visibilità riuscirà a recuperare

Il prossimo test è se i proprietari delle infrastrutture costruiranno salvaguardie misurabili prima che l’AI riceva un controllo più ampio sui sistemi fisici.

Il primo segnale è il profilo NIST per le infrastrutture critiche relativo all’AI Risk Management Framework. Le sue raccomandazioni dovrebbero tradurre principi generali in azioni che gli operatori possano testare. Indicazioni specifiche su modifiche dei modelli, logging OT, operazioni di fallback e dipendenze dai fornitori rafforzerebbero la tesi di Lee.

Un profilo vago lascerebbe alle organizzazioni l’interpretazione del rischio in modi diversi. Un profilo dettagliato, soprattutto se adottato da regolatori e acquirenti di settore, creerebbe una base comune. Ridurrebbe lo spazio per implementazioni affrettate supportate soltanto dalle dichiarazioni dei fornitori.

Il secondo segnale è l’evoluzione delle metriche di visibilità OT. Dragos riporta attualmente che solo il 30% delle reti OT dispone di visibilità, mentre il 56% non riesce a vedere oltre il confine tra IT e OT. I rapporti futuri dovrebbero mostrare se questi numeri migliorano con l’espansione dell’adozione dell’AI.

Un miglioramento suggerirebbe che le organizzazioni stanno costruendo il monitoraggio prima di assegnare maggiore autonomia. Una visibilità stagnante accanto a una rapida adozione rafforzerebbe il rischio per le infrastrutture AI indicato da Dragos. Significherebbe che la complessità cresce più rapidamente della capacità dei difensori di osservarla.

Il terzo segnale è la prima ondata di incidenti OT legati all’AI resi pubblici. Le segnalazioni devono distinguere tra uso malevolo, attacchi ai modelli, integrazioni non sicure e normali guasti software. Senza questi dettagli, le organizzazioni non possono individuare quali controlli abbiano fallito.

Un registro trasparente degli incidenti aiuterebbe gli operatori a imparare prima di affrontare lo stesso problema. Verificherebbe inoltre se l’attuale registrazione dei log supporta un’analisi significativa delle cause profonde. Incidenti ripetutamente privi di spiegazione confermerebbero la preoccupazione di Lee riguardo alla crescita dei punti ciechi.

I responsabili dell’infrastruttura non dovrebbero attendere tutti e tre i segnali. Possono già censire le implementazioni AI, identificare i processi fisici coinvolti e verificare chi detiene l’autorità di arresto. Possono anche testare le operazioni senza il modello né i suoi servizi esterni.

Gli sviluppatori dovrebbero pretendere interfacce chiare, autorizzazioni limitate, comportamenti versionati e tracciati di audit completi. Gli acquirenti aziendali dovrebbero chiedere ai fornitori prove concrete, anziché ampie promesse di sicurezza. I lavoratori della conoscenza dovrebbero evitare di inviare informazioni sensibili sulle infrastrutture a strumenti non approvati.

L’avvertimento di Robert M. Lee sull’AI offre, in definitiva, una regola decisionale pratica. L’automazione non dovrebbe acquisire autorità operativa più rapidamente di quanto l’organizzazione acquisisca visibilità, controllo e capacità di ripristino.

L’AI può comunque migliorare i servizi critici. Tuttavia, l’implementazione deve restare sufficientemente comprensibile da poter essere analizzata e sufficientemente vincolata da poter essere fermata. Prima di approvare la prossima integrazione, ponetevi una domanda: se domani agisse in modo errato, il vostro team riuscirebbe a capire perché e a ripristinare la situazione in sicurezza?