L'AI sta accelerando i cyberattacchi, ma le difese di base restano importanti

Google News ha portato alla luce un avvertimento di GovTech con un contrasto evidente: l'AI sta accelerando i cyberattacchi, eppure le difese più efficaci restano familiari e difficili da mantenere.

Il rapporto del 24 giugno ha trattato le discussioni svolte all'ISAC Annual Summit 2026 a Orlando, in Florida. I professionisti della sicurezza a livello statale e locale hanno appreso che gli aggressori ora si muovono più rapidamente, analizzano più obiettivi e realizzano messaggi più convincenti grazie a strumenti AI accessibili. La risposta non è stata una nuova piattaforma di difesa autonoma. È stata un migliore inventario, controlli dell'identità più rigorosi, autenticazione a più fattori e processi operativi disciplinati.

Questo divario conta. L'AI offre agli aggressori modi più economici per scoprire debolezze e ampliare le attività di ingegneria sociale. I difensori governativi dipendono ancora da registri delle risorse, revisioni degli accessi, decisioni sulle patch e dipendenti che seguono le procedure. La tecnologia cambia rapidamente, ma il lavoro difensivo più difficile resta di natura organizzativa.

Il titolo che appare su Google News potrebbe suggerire l'ennesima ampia storia sull'AI che trasforma la cybersicurezza. L'argomento di fondo è più specifico. L'AI comprime il tempo tra la scoperta di una debolezza e il suo sfruttamento, mentre molte agenzie pubbliche faticano ancora a identificare ogni dispositivo, applicazione, account e dipendenza che gestiscono.

La sfida centrale non è quindi tra aggressori AI e difensori AI. È tra sfruttamento alla velocità delle macchine e igiene informatica alla velocità umana. Questo squilibrio sta sottoponendo governi statali, locali, tribali e territoriali a una pressione immediata.

Cosa ha effettivamente cambiato il rapporto di GovTech

La notizia non è che l'igiene informatica continui a essere importante. Il cambiamento è che l'AI rende più costoso ogni ritardo nel lavoro difensivo di base.

La copertura di GovTech ha raccolto un messaggio ricorrente dall'ISAC Annual Summit. I team di sicurezza del settore pubblico hanno chiesto cosa dovrebbero fare mentre i criminali ottengono strumenti d'attacco più rapidi e accessibili. I relatori sono tornati ripetutamente ai controlli fondamentali.

Randy Rose, vicepresidente delle operazioni e dell'intelligence di sicurezza presso il Center for Internet Security, ha sottolineato l'importanza di fare bene le basi. Ha inoltre respinto l'idea che “di base” significhi facile. I controlli fondamentali richiedono un'esecuzione stratificata su tecnologia, persone, approvvigionamenti e gestione.

Questa distinzione è essenziale. Installare un prodotto di sicurezza è un progetto circoscritto. Mantenere registri accurati delle risorse tra servizi cloud, dispositivi remoti, sistemi di appaltatori e applicazioni legacy è una disciplina operativa continua.

La discussione al summit ha identificato l'inventario come punto di partenza. L'inventario hardware rivela quali dispositivi si connettono a un ambiente. L'inventario software mostra da quali applicazioni, versioni, librerie e servizi dipendono tali dispositivi.

Senza questa visibilità, un team di sicurezza non può rispondere in modo affidabile alla prima domanda dopo la divulgazione di una vulnerabilità: siamo esposti?

I CIS Controls collocano l'inventario delle risorse aziendali e l'inventario software all'inizio delle loro salvaguardie prioritarie. La sequenza riflette una dipendenza, non una preferenza amministrativa. Patch, monitoraggio, controllo degli accessi e risposta agli incidenti diventano tutti più deboli quando l'inventario sottostante è incompleto.

L'AI intensifica questa dipendenza. Un aggressore può usare sistemi automatizzati per analizzare infrastrutture pubbliche, correlare servizi esposti, riassumere documentazione tecnica e preparare messaggi di phishing plausibili. L'organizzazione deve comunque determinare quali risultati corrispondono ai sistemi di sua proprietà.

Questo crea una corsa asimmetrica. Agli aggressori basta una sola debolezza raggiungibile. I difensori hanno bisogno di visibilità affidabile sull'intero ambiente.

L'AI abbassa inoltre la soglia di competenza necessaria per alcune fasi di un attacco. GovTech ha riferito che i partecipanti al summit hanno discusso di aggressori meno esperti che usano sistemi AI pubblici per puntare a bersagli facili. Questi aggressori non devono inventare un nuovo exploit quando un'agenzia espone un vecchio servizio o lascia attivo un account inattivo.

Il cambiamento immediato è quindi la pressione operativa. Un record di inventario obsoleto, la rimozione ritardata di un account o un'applicazione non supportata offrono ora alla ricognizione automatizzata più margine d'azione.

Gli utenti di Google News possono imbattersi nell'evento come nell'ennesimo titolo sulla sicurezza dell'AI. Il segnale duraturo è più circoscritto e più rilevante. Le agenzie pubbliche devono eseguire controlli familiari a un ritmo che corrisponda alla scoperta automatizzata.

Perché Google News si sta riempiendo di avvertimenti sull'igiene informatica nell'era dell'AI

L'AI sta aumentando la velocità e il volume del lavoro di sicurezza senza eliminare la necessità del giudizio umano.

Il rapporto di GovTech non è emerso isolatamente. Anche gli organismi governativi per la sicurezza stanno avvertendo che la ricerca di vulnerabilità assistita dall'AI produrrà più rilevamenti e tentativi di sfruttamento più rapidi.

Il National Cyber Security Centre del Regno Unito prevede una “patch wave”, ossia un'ondata di aggiornamenti software volta ad affrontare il debito tecnico accumulato. Le sue indicazioni sulla patch wave affermano che utenti esperti possono applicare l'AI per sfruttare tale debito nell'intero ecosistema tecnologico a maggiore velocità e scala.

Il debito tecnico include componenti obsoleti, prodotti non supportati, integrazioni fragili e miglioramenti di sicurezza rinviati. Queste debolezze possono persistere perché sostituirle rischia di interrompere i servizi o richiede finanziamenti che le agenzie non controllano.

L'AI non crea tutto quel debito. Rende il debito più facile da cercare.

Questa differenza spiega perché sempre più storie sulla cybersicurezza dell'AI arrivano su Google News. Il cambiamento rilevante non è il rilascio di un singolo modello. Le organizzazioni di sicurezza ora si aspettano che sistemi automatizzati trovino più debolezze nel software commerciale, nei progetti open source, negli ambienti cloud e nelle infrastrutture legacy.

Più scoperte dovrebbero migliorare la sicurezza quando i fornitori ricevono segnalazioni e rilasciano correzioni. Creano però anche un pericoloso periodo di transizione. Una vulnerabilità divulgata diventa al tempo stesso informazione utilizzabile per difensori e aggressori.

Applicare immediatamente patch a ogni problema è raramente possibile. Le agenzie devono testare gli aggiornamenti, proteggere la disponibilità dei servizi, coordinarsi con i fornitori e considerare i sistemi che non possono tollerare tempi di inattività. La tecnologia operativa presenta un caso particolarmente difficile, poiché i processi fisici possono dipendere da dispositivi datati e protocolli specializzati.

L'NCSC raccomanda di dare priorità ai sistemi esposti esternamente, quindi ai sistemi di sicurezza critici. Incoraggia inoltre gli aggiornamenti automatici e il secure hot patching quando tali opzioni sono adatte. L'hot patching applica una correzione di sicurezza senza la consueta interruzione del servizio.

Tuttavia, la velocità da sola non può determinare ogni decisione. Un aggiornamento non testato può interrompere le comunicazioni di emergenza, i sistemi di assistenza, le piattaforme di trasporto o i servizi clinici. I team di sicurezza devono valutare il rischio di sfruttamento rispetto al rischio operativo.

È qui che l'AI può assistere senza assumere la decisione. I modelli possono riassumere gli avvisi, mappare i nomi dei prodotti, raggruppare rilevamenti duplicati e aiutare gli analisti a confrontare le prove di esposizione. Possono anche generare corrispondenze rumorose o trascurare il contesto locale.

I team governativi hanno bisogno di prove che un componente vulnerabile sia effettivamente presente, raggiungibile e importante. Un punteggio di gravità generico non può fornire da solo quel contesto.

La pressione ricade pesantemente sulle giurisdizioni più piccole. Spesso gestiscono servizi essenziali con personale di sicurezza limitato, registri di approvvigionamento frammentati e infrastrutture ereditate. Un aggressore abilitato dall'AI può analizzare questi ambienti continuamente, mentre l'organizzazione difensiva può dipendere da revisioni periodiche.

La collaborazione attraverso organizzazioni per la condivisione delle informazioni può ridurre questo svantaggio. Indicatori condivisi, indicazioni di remediation testate e comunicazioni coordinate con i fornitori evitano che ogni team locale ripeta la stessa analisi.

Eppure l'intelligence condivisa non può riparare un dispositivo sconosciuto o disabilitare un account non documentato. L'azione difensiva finale avviene ancora all'interno di ogni organizzazione.

Gli attacchi alla velocità delle macchine incontrano il governo alla velocità umana

L'AI comprime la preparazione degli attacchi, ma le decisioni sulla sicurezza governativa restano vincolate da organico, obblighi di servizio e registri di proprietà incompleti.

Un aggressore tradizionale potrebbe trascorrere ore a ricercare un obiettivo, adattare un messaggio di phishing o esaminare informazioni tecniche pubbliche. L'AI può accelerare alcune fasi di questo lavoro. Può tradurre contenuti, imitare il linguaggio organizzativo, generare varianti e aiutare a collegare indizi dispersi.

Questo non rende sofisticato ogni attacco assistito dall'AI. Rende più economica la ripetizione.

Un criminale può testare più messaggi, prendere di mira più dipendenti e rivedere approcci falliti con minore sforzo manuale. L'audio deepfake può aggiungere pressione a un tentativo di impersonificazione. I messaggi generati possono evitare gli evidenti errori grammaticali che un tempo aiutavano i destinatari a identificare le frodi.

Le agenzie pubbliche sono obiettivi interessanti perché detengono dati personali e gestiscono servizi che le comunità non possono facilmente abbandonare. Pubblicano inoltre informazioni organizzative per ragioni di trasparenza, inclusi elenchi del personale, registri delle riunioni, contratti e acquisti tecnologici.

Questa apertura sostiene la responsabilità democratica. Può anche offrire agli aggressori materiale per pretesti convincenti.

I controlli dell'identità diventano critici in queste condizioni. L'autenticazione a più fattori, o MFA, richiede una prova aggiuntiva oltre a una password. Riduce il valore delle credenziali rubate, sebbene implementazioni deboli possano comunque essere sconfitte tramite ingegneria sociale o furto di sessione.

Le agenzie devono inoltre riesaminare gli ambienti di directory, i privilegi amministrativi, gli account di servizio e le identità inattive. Un sistema di autenticazione tecnicamente solido non può proteggere un account che non dovrebbe più esistere.

Inventario e identità sono strettamente collegati. I team devono sapere chi possiede un'applicazione, quali account possono amministrarla, quali dati raggiunge e come viene rimosso l'accesso. Informazioni mancanti sulla proprietà ritardano ogni risposta.

Gli agenti AI aggiungono un ulteriore livello di identità. Un agente combina un modello con strumenti, accesso ai dati e la capacità di compiere azioni. Può interrogare sistemi interni, chiamare servizi esterni, aggiornare record o eseguire workflow approvati.

La guida sugli agenti AI del Center for Internet Security identifica rischi quali azioni non autorizzate, fuga di dati e modifiche involontarie ai sistemi. Questi rischi vanno oltre il modello, perché l'agente interagisce con API, credenziali, software di orchestrazione e dati aziendali.

Un'organizzazione che implementa agenti deve inventariarli come altre risorse attive. Deve documentarne proprietari, strumenti, autorizzazioni, fonti di dati e confini operativi. Ha inoltre bisogno di log che mostrino cosa un agente ha tentato di fare e cosa è effettivamente accaduto.

Il privilegio minimo diventa più complicato quando un agente gestisce diverse attività. Concedergli un ampio accesso semplifica l'integrazione, ma amplia i danni causati da manipolazione dei prompt, credenziali rubate o ragionamenti errati.

L'alternativa più sicura consiste in autorizzazioni più ristrette, credenziali a breve durata e passaggi di approvazione per azioni sensibili. Questi controlli possono rallentare l'automazione, creando il compromesso centrale dell'articolo. Le organizzazioni vogliono la velocità dell'AI, ma un'implementazione sicura richiede vincoli deliberati.

Lo stesso compromesso si applica all'AI difensiva. Un sistema che mette automaticamente in quarantena i dispositivi o modifica le regole del firewall può reagire rapidamente. Un'azione errata può anche interrompere i servizi pubblici.

La revisione umana resta necessaria per le decisioni ad alto impatto. La sfida consiste nel decidere dove collocarla. Richiedere l'approvazione per ogni azione minore elimina gran parte del valore dell'automazione, mentre rimuovere la supervisione crea un rischio operativo inaccettabile.

Le agenzie hanno bisogno di un'autorità a livelli. Le attività a basso rischio possono essere eseguite automaticamente entro limiti testati. Le azioni a rischio più elevato dovrebbero richiedere prove, revisione e un percorso di esecuzione reversibile.

Questa progettazione dipende da processi solidi. L'AI non sostituisce l'igiene informatica. Impone che l'igiene informatica copra sia le identità umane sia quelle delle macchine.

Oltre la patch, la visibilità diventa il vero controllo

L'applicazione delle patch resta essenziale, ma un'agenzia non può aggiornare sistemi che non riesce a vedere, classificare o modificare in sicurezza.

La gestione delle patch riceve spesso attenzione perché produce un'azione chiara: installare un aggiornamento. Il problema difensivo più profondo inizia prima.

Un team deve sapere di gestire il prodotto interessato. Deve identificare la versione distribuita, determinare se la funzione vulnerabile sia raggiungibile, individuare il responsabile del sistema e comprendere le conseguenze della sua modifica.

Registri incompleti trasformano una correzione tecnica in un'indagine.

Il problema è particolarmente serio nella tecnologia operativa, o OT, che controlla apparecchiature e processi fisici. Gli ambienti OT possono includere dispositivi legacy, software specializzato, sedi remote e sistemi con requisiti rigorosi di disponibilità.

Un progetto NIST del 2026 sulla gestione delle risorse OT descrive l'inventario come fondamento di un'architettura difendibile e di decisioni basate sul rischio. NIST osserva che le organizzazioni non possono proteggere ambienti che non riescono a vedere.

Questo principio si applica oltre l'OT. Gli abbonamenti cloud possono comparire al di fuori degli acquisti centralizzati. I dipartimenti possono adottare software in modo indipendente. I fornitori possono introdurre piattaforme gestite e i dipendenti possono collegare applicazioni non autorizzate ai dati dell'organizzazione.

L'adozione dell'AI generativa aggiunge ulteriore infrastruttura ombra. Un membro del personale potrebbe caricare informazioni su un modello pubblico, autorizzare un assistente AI o collegare un agente a un repository di documenti senza una revisione formale.

I team di sicurezza hanno bisogno di processi di individuazione che identifichino queste connessioni. Hanno anche bisogno di una risposta che non spinga gli utenti ancora più nell'ombra.

Un divieto generalizzato può essere difficile da applicare quando i servizi AI pubblici restano facilmente accessibili. Un programma pratico offre ai dipendenti opzioni approvate, regole chiare sui dati e un processo per richiedere nuovi casi d'uso.

La visibilità deve includere il movimento dei dati. Sapere che esiste un'applicazione AI non è sufficiente. I team devono comprendere quali record possa recuperare, quali prompt riceva, se gli output vengano conservati e quali servizi esterni elaborino le informazioni.

Lo stesso principio si applica ai sistemi difensivi. Uno strumento di triage AI può acquisire log, rapporti sulle vulnerabilità, eventi di identità e intelligence sulle minacce. Se le sue fonti di dati sono incomplete, la sua classificazione può apparire precisa pur riflettendo solo una parte dell'ambiente.

Per questo i punteggi di rischio generati dall'AI non dovrebbero diventare verità automatiche. Sono input per le decisioni. Gli analisti devono avere accesso alle prove sottostanti e un modo per contestare la raccomandazione.

Un flusso di lavoro efficace collega diversi registri: inventario delle risorse, versioni del software, titolarità dei sistemi, privilegi di identità, esposizione esterna, criticità del servizio e vulnerabilità note. L'AI può aiutare a riconciliare questi registri, ma la governance determina quale fonte sia autorevole.

Anche la documentazione è importante durante il ricambio del personale. I governi locali possono dipendere da un numero ridotto di dipendenti che comprendono i sistemi ereditati. Quando questa conoscenza resta in caselle di posta personali o note informali, la risposta agli incidenti rallenta.

Una base di conoscenza ricercabile può preservare runbook, decisioni architetturali, istruzioni dei fornitori e cronologia delle attività correttive. I controlli di accesso devono corrispondere alla sensibilità di questi materiali.

L'obiettivo non è la documentazione fine a sé stessa. I team hanno bisogno di risposte aggiornate durante una breve finestra di risposta.

L'applicazione delle patch rientra quindi in un ciclo di controllo più ampio. Scoprire le risorse, assegnare la responsabilità, valutare l'esposizione, definire le priorità, testare la modifica, distribuirla, verificarne il completamento e registrare le eccezioni.

L'AI può accelerare diverse fasi. Non può compensare un ciclo privo di input affidabili o responsabili identificabili.

Ciò che la narrazione sulla sicurezza dell'AI non dimostra ancora

Gli attacchi più rapidi assistiti dall'AI sono credibili, ma le organizzazioni non dovrebbero scambiare ogni affermazione sui modelli o dimostrazione di prodotto per una capacità operativa misurata.

Il marketing della sicurezza spesso procede più rapidamente delle prove. I fornitori possono dimostrare che un modello individua vulnerabilità in ambienti controllati, ma le reti reali contengono dati incompleti, configurazioni insolite, restrizioni di accesso e vincoli operativi.

Un risultato di laboratorio non prevede automaticamente il successo di un attacco contro le infrastrutture pubbliche.

La stessa cautela si applica alle affermazioni sulla difesa autonoma. Un modello può classificare accuratamente gli avvisi in un dataset selezionato. I sistemi di produzione devono gestire il cambiamento del comportamento degli aggressori, falsi positivi, contesto non disponibile e input avversari.

I falsi positivi comportano costi reali. Gli analisti dedicano tempo a indagare eventi innocui, mentre il contenimento automatizzato può interrompere attività legittime. Un rumore eccessivo può inoltre indebolire la fiducia nel sistema.

I falsi negativi sono altrettanto pericolosi, perché un riepilogo sicuro di sé può nascondere prove mancate. I team di sicurezza dovrebbero valutare entrambi i tipi di errore in condizioni che assomiglino ai propri ambienti.

La supervisione umana non è una risposta completa. Gli analisti possono affidarsi troppo facilmente a un output del modello ben rifinito, soprattutto durante incidenti ad alto volume. I team necessitano di procedure che richiedano verifiche delle prove per le raccomandazioni con conseguenze rilevanti.

I sistemi AI creano anche nuove superfici di attacco. Il prompt injection tenta di manipolare un modello attraverso istruzioni create ad arte incorporate nei contenuti. Un agente che legge email, documenti o pagine web può incontrare testo ostile progettato per reindirizzarne il comportamento.

L'accesso agli strumenti trasforma tale manipolazione in un rischio operativo. Un chatbot che si limita a redigere testo ha un raggio d'impatto limitato. Un agente con credenziali, accesso ai file e diritti di esecuzione può esporre o alterare sistemi reali.

I difensori devono quindi trattare gli input degli agenti come dati non affidabili. Dovrebbero separare le istruzioni dai contenuti recuperati, limitare gli strumenti, convalidare gli output e registrare le azioni. Le operazioni sensibili richiedono un'autorizzazione indipendente.

Anche le catene di fornitura dei modelli richiedono attenzione. Le agenzie possono dipendere da API ospitate, componenti open source, sistemi di recupero, plugin e connettori di terze parti. Ogni livello introduce aggiornamenti, credenziali, autorizzazioni e questioni contrattuali.

È qui che l'argomento dei controlli di base diventa più forte. La gestione delle risorse deve includere i servizi AI. L'inventario software deve includere le librerie di supporto e i componenti di orchestrazione. La gestione degli account deve includere identità di servizio e credenziali delle macchine.

I piani di risposta agli incidenti devono inoltre affrontare i guasti dell'AI. I team dovrebbero sapere come disabilitare un agente, revocarne le credenziali, conservare i log e determinare quali azioni abbia intrapreso.

La conclusione scettica non è che l'AI non abbia valore per la sicurezza. I modelli possono aiutare i difensori a riepilogare gli avvisi, analizzare il codice, identificare schemi e dare priorità alle indagini. L'incertezza riguarda affidabilità, autorità e misurazione.

Il Verizon DBIR resta utile perché fonda le priorità di sicurezza su incidenti e violazioni osservati. Le organizzazioni dovrebbero confrontare le affermazioni sui prodotti AI con le prove provenienti dai propri incidenti, esercitazioni e metriche operative.

Un'implementazione credibile dovrebbe migliorare risultati misurabili. Tali risultati includono finestre di esposizione più brevi, indagini più rapide, migliore copertura dell'inventario, minori privilegi eccessivi e un ripristino più affidabile.

I team dovrebbero evitare metriche di vanità come il numero di avvisi o riepiloghi generati dall'AI. Una maggiore quantità di output non significa necessariamente un rischio minore.

La copertura di Google News può amplificare esempi drammatici di hacking o difesa autonoma. I responsabili della sicurezza devono comunque porsi una domanda più silenziosa: il sistema ha migliorato un controllo testato senza creare accessi non gestiti?

Tre segnali che mostreranno se l'igiene informatica sta recuperando terreno

La prossima fase sarà decisa dall'esecuzione misurabile, non dal numero di agenzie che annunciano strategie AI.

Il primo segnale è la latenza delle patch per i sistemi esposti esternamente. La latenza delle patch misura il tempo tra la disponibilità di una correzione pertinente e la sua distribuzione verificata sulle risorse interessate.

Un intervallo in diminuzione sosterrebbe l'argomento secondo cui il triage assistito dall'AI e la definizione delle priorità di rischio aiutano i difensori a eguagliare la velocità degli aggressori. Un intervallo in aumento mostrerebbe che l'individuazione sta generando più lavoro di quanto le agenzie possano assorbire.

La misurazione deve includere le eccezioni. Un dashboard che escluda sistemi legacy o non gestiti può segnalare progressi preservando al contempo l'esposizione più grave. I responsabili dovrebbero chiedere quale parte dell'ambiente sia coperta e quali risorse restino al di fuori del normale processo di aggiornamento.

Il secondo segnale è la copertura di identità e inventario per gli agenti AI. Le agenzie dovrebbero essere in grado di enumerare gli agenti distribuiti, assegnare responsabili, documentare gli strumenti, identificare l'accesso ai dati e revocare rapidamente le credenziali.

Una copertura in miglioramento mostrerebbe che le organizzazioni stanno estendendo i controlli consolidati a una nuova classe di attori macchina. Una persistente adozione ombra indebolirebbe le affermazioni secondo cui la governance dell'AI sia diventata operativa.

Il test dovrebbe essere pratico. Durante un'esercitazione, il team di sicurezza riesce a localizzare ogni agente collegato a un repository sensibile? Riesce a identificare quali credenziali abbia usato ciascun agente e a disabilitarle senza cercare in vari dipartimenti?

Il terzo segnale sono le prove provenienti da esercitazioni del settore pubblico e da incidenti reali. Gli strumenti di difesa AI dovrebbero dimostrare di ridurre i tempi di indagine o l'esposizione senza causare interruzioni inaccettabili.

Le valutazioni indipendenti conteranno più dei benchmark dei fornitori. I rapporti utili dovrebbero descrivere l'ambiente, i limiti dell'attività, i tassi di errore, il coinvolgimento umano e le conseguenze degli errori.

Questi segnali dovrebbero comparire nelle decisioni di approvvigionamento. Le agenzie possono richiedere ai fornitori di supportare logging dettagliato, accesso con privilegi minimi, registri esportabili, rapida revoca delle credenziali e test indipendenti.

I contratti dovrebbero inoltre affrontare le modifiche ai modelli e ai servizi. Un fornitore ospitato può aggiornare un modello senza modificare il nome del prodotto rivolto al cliente. Le agenzie hanno bisogno di essere avvisate quando tali modifiche influenzano il comportamento di sicurezza, la gestione dei dati o l'uso degli strumenti.

La collaborazione nel settore pubblico resta importante perché le giurisdizioni più piccole non possono valutare ogni sistema in modo indipendente. Risultati di test condivisi e requisiti di approvvigionamento possono elevare lo standard minimo per molte agenzie.

Tuttavia, le linee guida comuni devono lasciare spazio al contesto locale. Un sistema di registri di contea e una rete di controllo dei trasporti non condividono lo stesso rischio operativo. Il livello appropriato di automazione sarà diverso.

Il rapporto GovTech offre una correzione utile alla più rumorosa narrazione sulla sicurezza dell'AI. I difensori non devono abbandonare i controlli familiari e ricominciare da capo. Devono eseguire tali controlli contro minacce più rapide, patrimoni software in espansione e una popolazione crescente di identità macchina.

È un incarico impegnativo. Il lavoro di inventario non ha la visibilità di un nuovo lancio AI. Le revisioni degli accessi non producono dimostrazioni spettacolari. La verifica delle patch raramente diventa un titolo di Google News.

Eppure, questi processi determinano se gli strumenti avanzati rafforzano un’organizzazione o aggiungono un ulteriore livello non gestito.

I responsabili della sicurezza dovrebbero iniziare con tre domande. Quali asset esposti a Internet restano al di fuori di un inventario verificato? Quali identità umane o di macchina mantengono accessi di cui non hanno più bisogno? Con quale rapidità l’organizzazione può agire quando emerge una vulnerabilità ad alto rischio?

Le risposte riveleranno più di un documento strategico sull’AI. Mostreranno se l’igiene informatica opera alla velocità richiesta dal nuovo contesto delle minacce.