Thales rileva che le aziende temono i rischi dell'AI più delle familiari minacce informatiche

Thales ha rilevato un'inversione significativa: il 69% delle organizzazioni intervistate ha indicato il rapido mutamento dell'ecosistema dell'AI come principale preoccupazione per la sicurezza dell'AI generativa. Minacce consolidate come malware, phishing e ransomware restano attive, ma le imprese devono ora affrontare un sistema che stanno implementando direttamente.

Il risultato non significa che l'AI causi già più violazioni rispetto a ransomware o malware. Indica che le aziende temono l'incertezza legata all'adozione dell'AI più di qualsiasi singolo tipo di attacco consolidato. I team di sicurezza conoscono i controlli contro il phishing. Hanno meno fiducia nei sistemi che possono accedere ai dati, generare codice e attivare azioni aziendali.

Questa distinzione è importante perché il rischio dell'AI attraversa diversi confini consolidati. Combina cybersecurity, privacy, esposizione legale, affidabilità dei modelli e controllo operativo. Il conflitto centrale non è più tra adozione dell'AI e resistenza. È tra la velocità di implementazione aziendale e la capacità di un'organizzazione di governare ciò che ha già installato.

Il sondaggio rivela un cambiamento nelle preoccupazioni delle imprese

Le aziende non stanno sostituendo le vecchie paure informatiche con l'AI. Stanno riconoscendo che l'AI può amplificare diversi rischi contemporaneamente.

Il rapporto sulle minacce ai dati ha intervistato oltre 3.100 professionisti della tecnologia e della sicurezza in 20 Paesi e 15 settori. S&P Global Market Intelligence 451 Research ha condotto la ricerca per Thales.

Tra gli intervistati, il 69% ha selezionato il rapido mutamento dell'ecosistema dell'AI come principale preoccupazione di sicurezza legata all'AI generativa. L'integrità del modello seguiva al 64%, mentre l'affidabilità si collocava al 57%.

L'espressione “ecosistema in rapida evoluzione” comprende più dei rilasci dei modelli. Include fornitori di modelli, plugin, servizi dati, framework di sviluppo, agenti e l'infrastruttura che li collega. Ogni componente può cambiare indipendentemente, creando una catena di dipendenze che i team di sicurezza non controllano completamente.

Questo differisce da un familiare incidente malware. Un team di sicurezza può identificare un file dannoso, isolare un endpoint e indagarne il percorso. Un sistema di AI può comportarsi in modo errato senza contenere malware né mostrare un tradizionale indicatore di compromissione.

Un modello potrebbe esporre informazioni riservate perché un utente le ha inserite in un servizio non approvato. Un agente potrebbe recuperare dati oltre l'ambito previsto dal richiedente. Il codice generato dall'AI potrebbe introdurre una dipendenza vulnerabile senza attivare un avviso immediato.

Questi esiti possono assomigliare a normali fallimenti di cybersecurity. Tuttavia, le loro cause spesso si trovano al di fuori del tradizionale centro operativo di sicurezza. Acquisti, legale, ingegneria, data science, compliance e team aziendali influenzano tutti il sistema.

Il sondaggio ha inoltre rilevato che il 73% degli intervistati stava investendo in strumenti di sicurezza specifici per l'AI. Alcuni hanno ricevuto nuovi budget, mentre altri hanno riallocato la spesa esistente per la sicurezza. Il dato conferma che la preoccupazione è già entrata nelle decisioni di acquisto e pianificazione.

Tuttavia, software aggiuntivo non risolve automaticamente una proprietà poco chiara. Un prodotto di monitoraggio non può decidere a quali dati aziendali un agente dovrebbe accedere. Non può neppure definire un comportamento accettabile del modello per ogni cliente, dipendente o flusso di lavoro regolamentato.

Le categorie di attacco tradizionali sono rimaste rilevanti nella stessa ricerca. Il malware ha mantenuto la prima posizione tra i tipi di attacco osservati, il phishing è salito al secondo posto e il ransomware si è classificato terzo.

Questo contesto limita il significato del titolo. L'AI è la maggiore preoccupazione emergente relativa all'adozione dell'AI generativa, non la prova che le minacce consolidate siano scomparse. Le aziende devono proteggere due ambienti sovrapposti anziché scegliere tra l'uno e l'altro.

Il cambiamento resta importante. I responsabili della sicurezza ora trattano l'AI come un dominio di rischio aziendale, non semplicemente come un'altra applicazione che richiede protezione degli endpoint. I suoi fallimenti possono avere origine all'interno di flussi di lavoro approvati e diffondersi attraverso accessi fidati.

Perché i rischi per la sicurezza dell'AI sfuggono ai controlli familiari

L'AI cambia l'unità di rischio: da un'applicazione prevedibile a un sistema che interpreta istruzioni e seleziona azioni.

Le applicazioni aziendali convenzionali offrono di norma funzioni definite. Gli utenti inseriscono dati strutturati, selezionano azioni consentite e ricevono risultati delimitati. I team di sicurezza possono associare tali funzioni a identità, autorizzazioni, database e registri di audit.

L'AI generativa accetta istruzioni aperte. Il suo output dipende dal prompt, dalle informazioni recuperate, dal comportamento del modello, dalla configurazione del sistema e dagli strumenti connessi. Piccoli cambiamenti in qualsiasi punto di questa catena possono produrre risultati diversi.

Un agente AI aggiunge un ulteriore livello. Un agente è un software che utilizza un modello per pianificare attività e chiamare strumenti con un intervento umano limitato. Questi strumenti possono includere email, repository di codice, database clienti, calendari e sistemi finanziari.

Questa architettura crea rischi ai quali le difese perimetrali non erano progettate per rispondere. Un dipendente autorizzato può impartire un'istruzione rischiosa attraverso un'interfaccia approvata. Il modello può quindi usare connessioni autorizzate in modo non previsto.

Il prompt injection illustra il problema. Un'istruzione dannosa può apparire all'interno di un documento, una pagina web o un messaggio elaborato da un sistema di AI. L'istruzione tenta di deviare il modello dal compito previsto.

Non è necessaria alcuna password rubata quando l'agente dispone già dell'accesso. L'aggressore prende invece di mira il livello di interpretazione del modello. Questo trasforma i normali contenuti aziendali in un possibile canale di controllo.

Il recupero dei dati crea una sfida simile. La retrieval-augmented generation consente a un modello di utilizzare informazioni organizzative selezionate durante la produzione di una risposta. Il modello non deve contenere tali informazioni nei propri dati di addestramento originali.

Tuttavia, la qualità del recupero dipende da autorizzazioni e metadati. Un indice di ricerca che ignora le regole di accesso a livello di documento può esporre materiale che l'utente non potrebbe aprire direttamente. La risposta può nascondere tale fallimento di accesso dietro un linguaggio naturale.

Questo è importante per le aziende che sviluppano assistenti interni su contratti, registri delle riunioni, ticket di supporto o documenti di ingegneria. Un assistente utile necessita di un contesto ampio. Ogni fonte aggiunta aumenta anche le conseguenze di autorizzazioni deboli.

I dipendenti creano un'altra esposizione attraverso la shadow AI, ossia servizi di AI utilizzati senza approvazione o supervisione dell'organizzazione. Il personale può incollare codice sorgente, registri dei clienti o piani aziendali in strumenti pubblici per risparmiare tempo.

Questo comportamento è difficile da controllare con la sola policy. I lavoratori spesso considerano una chat AI come uno spazio di lavoro temporaneo anziché un elaboratore esterno di dati. L'interfaccia sembra meno rischiosa del caricamento di un file su un sito web sconosciuto.

Le conclusioni sulla supervisione dell'AI citano un sondaggio in cui il 78% dei dipendenti ha dichiarato di utilizzare strumenti AI al lavoro. All'interno di quel gruppo, il 58% ha ammesso di aver fornito informazioni aziendali sensibili a grandi modelli linguistici.

Le cifre autodichiarate non misurano perdite di dati confermate. Mostrano comunque perché il rischio dell'AI inizia con utenti autorizzati, non solo con aggressori esterni. L'adozione può superare la revisione formale perché gli strumenti sono facili da utilizzare.

La sfida si estende allo sviluppo software. Gli assistenti AI possono proporre codice più rapidamente di quanto i team riescano a revisionarlo. Una funzione generata può funzionare nei test pur contenendo impostazioni predefinite non sicure, convalide deboli o una dipendenza obsoleta.

Gli scanner di sicurezza possono rilevare schemi noti, ma non possono garantire che la logica generata corrisponda al requisito aziendale. La revisione umana resta necessaria, soprattutto quando il codice gestisce autenticazione, pagamenti o informazioni regolamentate.

L'output del modello crea inoltre un rischio di integrità. Un sistema può produrre contenuti falsi con grande sicurezza, un comportamento comunemente chiamato allucinazione. Il risultato diventa pericoloso quando un'altra applicazione lo tratta come input verificato.

Un riepilogo errato è scomodo. Una decisione di accesso o un'istruzione finanziaria errata ha conseguenze operative. Lo stesso comportamento del modello comporta rischi diversi a seconda degli strumenti e dell'autorità che lo circondano.

Per questo la sicurezza dell'AI non può essere ridotta all'accuratezza del modello. La domanda rilevante è cosa accade quando il modello sbaglia, viene manipolato o riceve un accesso eccessivo.

Il vero conflitto è tra velocità di implementazione e controllo

I dirigenti vogliono ora vantaggi misurabili dall'AI, mentre i team di sicurezza ereditano sistemi le cui autorizzazioni e percorsi di fallimento restano poco chiari.

La pressione inizia al di sopra dell'organizzazione della sicurezza. Consigli di amministrazione e team esecutivi si aspettano che i CIO trovino usi produttivi dell'AI, riducano gli attriti operativi ed evitino di restare indietro rispetto ai concorrenti.

I team aziendali possono avviare un progetto pilota AI in pochi giorni. Costruire un inventario completo, un modello di autorizzazioni, un processo di valutazione e un piano di risposta agli incidenti richiede più tempo. Questo divario temporale crea il conflitto principale dell'articolo.

Un sondaggio Logicalis del 2026 ha rilevato che più di un quarto dei CIO considerava l'AI un rischio significativo. Gli intervistati l'hanno collocata accanto a malware, ransomware e phishing, secondo le conclusioni sulla sicurezza dei CIO.

La stessa ricerca ha rilevato che due terzi consideravano insufficiente la formazione dei dipendenti sulla gestione dei rischi dell'AI. Ha inoltre riportato che il 94% dei CIO affrontava una carenza di competenze in cybersecurity.

Questi risultati rivelano un problema di capacità, non semplicemente un problema tecnologico. Le organizzazioni stanno aggiungendo una classe di sistemi non familiare mentre i team di sicurezza esistenti già non dispongono di abbastanza lavoratori specializzati.

Anche la responsabilità può diventare frammentata. Il CIO può essere proprietario della strategia tecnologica, mentre il CISO è responsabile della sicurezza. I team legali supervisionano la proprietà intellettuale e l'esposizione normativa. I responsabili dei dati gestiscono la governance, mentre le unità aziendali selezionano i casi d'uso.

Un fallimento dell'AI può riguardare ogni gruppo senza rientrare chiaramente in un solo dipartimento. Quando la titolarità rimane ambigua, le approvazioni diventano incoerenti e la risposta agli incidenti rallenta.

I programmi di cybersecurity consolidati offrono un confronto utile. Le organizzazioni hanno trascorso anni a definire processi per la gestione delle vulnerabilità, la protezione degli endpoint, l'identità, i backup e il ripristino.

Questi controlli restano essenziali. I sistemi AI continuano a funzionare su normali servizi cloud, applicazioni e account utente. Un'identità compromessa può esporre un flusso di lavoro AI proprio come espone altri software.

Tuttavia, l'AI aggiunge decisioni che i controlli tradizionali non possono prendere da soli. Un firewall non può determinare se una raccomandazione generata contiene un pregiudizio inaccettabile. Il software per endpoint non può valutare se un modello abbia citato la corretta policy interna.

Questo non giustifica la creazione di una burocrazia isolata per la governance dell'AI. Separare completamente l'AI dalla cybersecurity duplicherebbe i controlli e creerebbe nuove lacune.

L'approccio più solido parte dall'identità esistente, dalla classificazione dei dati, dalla revisione del software e dalla gestione degli incidenti. I team possono poi aggiungere valutazioni dei modelli e controlli specifici per gli agenti laddove i processi ordinari non siano sufficienti.

L'identità merita particolare attenzione perché gli agenti agiscono tramite credenziali. Ogni agente dovrebbe avere una propria identità, autorizzazioni limitate e un proprietario documentato. Gli account condivisi rendono difficile l'attribuzione delle responsabilità.

Le autorizzazioni dovrebbero corrispondere al più piccolo insieme di azioni richieste per l'attività assegnata. Un assistente che riassume casi di supporto non necessita dell'autorità per eliminare record. Un agente di coding non necessita di accesso illimitato alla produzione.

Anche le organizzazioni hanno bisogno di un inventario aggiornato. I team non possono governare modelli, plugin e connessioni dati di cui non conoscono l’esistenza. I soli registri degli acquisti non rileveranno gli strumenti del browser e le integrazioni create dai dipendenti.

Un inventario dovrebbe registrare il fornitore del modello, il responsabile aziendale, le fonti dati, gli strumenti collegati, gli utenti previsti e l’autorità decisionale. Dovrebbe inoltre indicare se gli output sono sottoposti a revisione umana.

Per le attività ad alta intensità di conoscenza, le aziende possono ridurre l’esposizione mantenendo il materiale di origine all’interno di sistemi approvati. Una base di conoscenza AI controllata può preservare i confini di accesso aiutando al contempo i team a recuperare il contesto pertinente.

Questa scelta non elimina il rischio dell’AI. Offre un percorso dei dati più chiaro rispetto alla copia di materiale sensibile tra servizi consumer non correlati. La titolarità chiara e l’applicazione dei permessi restano decisive.

L’obiettivo non è bloccare ogni sperimentazione. Restrizioni eccessivamente ampie possono spingere i dipendenti verso strumenti non autorizzati. La governance funziona meglio quando le opzioni approvate restano utili e accessibili.

Cosa non dimostra il titolo

Le misure di preoccupazione raccolte dal sondaggio rilevano l’esposizione percepita, non la frequenza effettiva o l’impatto finanziario degli incidenti AI.

Il titolo invita a una conclusione semplice: l’AI è diventata più pericolosa del ransomware, del malware o del phishing. Le prove disponibili non supportano questa affermazione.

Thales ha chiesto ai partecipanti delle loro preoccupazioni relative all’AI generativa e ha riportato separatamente le categorie di attacchi osservati. Queste misurazioni rispondono a domande diverse e non possono costituire una classifica diretta dei rischi.

Un sondaggio sulle preoccupazioni cattura incertezza, attenzione e conseguenze attese. I dati sugli incidenti misurano eventi che le organizzazioni hanno rilevato e classificato. Nessuno dei due rappresenta automaticamente la perdita complessiva.

I partecipanti possono classificare l’AI in alto perché i suoi confini restano poco chiari. Una minaccia conosciuta può sembrare più gestibile anche quando causa danni misurabili maggiori.

Anche la novità può influenzare le risposte. I responsabili della sicurezza ricevono frequenti domande sull’AI da consigli di amministrazione, clienti, autorità di regolamentazione e dipendenti. Questa visibilità può elevare il rischio percepito senza dimostrare un volume di incidenti più alto.

La ricerca sponsorizzata dai fornitori richiede ulteriore cautela. Thales vende prodotti per la cybersicurezza e la protezione dei dati, e ha quindi un interesse commerciale nella spesa per la sicurezza dell’AI. S&P Global Market Intelligence 451 Research ha condotto il sondaggio, ma i lettori dovrebbero comunque esaminarne l’impostazione.

Questo non invalida i risultati. Significa che le percentuali dovrebbero sostenere una conclusione circoscritta: le imprese segnalano un’elevata preoccupazione e stanno indirizzando risorse verso una sicurezza specifica per l’AI.

I dati provengono inoltre da più Paesi e settori. Una banca che utilizza agenti per transazioni dei clienti affronta conseguenze diverse rispetto a un produttore che testa un assistente interno per la scrittura.

Le percentuali aggregate possono nascondere tali differenze. Il rischio dipende dalla sensibilità dei dati, dal livello di automazione, dalla popolazione di utenti, dagli obblighi normativi e dall’autorità concessa al modello di agire.

Le aziende dovrebbero quindi evitare di copiare una checklist universale per la sicurezza dell’AI. Uno strumento di redazione a basso impatto non richiede gli stessi controlli di un agente che modifica gli account dei clienti.

Un’altra incertezza riguarda la classificazione degli incidenti. Un attaccante potrebbe usare l’AI per scrivere un messaggio di phishing, ma l’organizzazione potrebbe registrare l’evento come phishing. L’AI ha assistito l’attacco senza diventare la categoria segnalata.

Può verificarsi anche il contrario. Un errore convenzionale nelle autorizzazioni all’interno di un’applicazione AI potrebbe ricevere un’etichetta AI perché la nuova interfaccia ha reso visibile il problema.

I ricercatori hanno bisogno di definizioni coerenti prima che i confronti diventino affidabili. Devono distinguere tra attacchi che usano l’AI, attacchi contro sistemi AI e guasti causati dall’uso approvato dell’AI.

L’analisi sulla sicurezza degli agenti del NIST ha rilevato un ampio consenso sul fatto che le pratiche fondamentali di cybersicurezza restino rilevanti. I partecipanti hanno anche affermato che tali pratiche devono essere adattate alla sicurezza degli agenti.

Questo è un inquadramento più utile che dichiarare obsoleta la cybersicurezza tradizionale. L’AI eredita rischi infrastrutturali noti, aggiungendo al contempo nuovi percorsi per istruzioni, accesso e azione autonoma.

C’è anche il pericolo di spostare i budget troppo rapidamente. Le aziende hanno ancora bisogno di patching, autenticazione a più fattori, backup, sicurezza della posta elettronica e piani di ripristino testati. I controlli AI non possono compensare fondamenta trascurate.

Gli attaccanti sfruttano spesso debolezze note perché tali metodi restano efficaci. Aggiungere un livello di monitoraggio AI sopra controlli di identità deboli può creare l’impressione di progresso senza ridurre l’esposizione di base.

I dirigenti dovrebbero chiedersi come ogni investimento modifichi un risultato misurabile. Misure utili includono l’accesso non autorizzato ai dati, le azioni degli agenti ad alto rischio, le violazioni delle policy e il tempo necessario per contenere un incidente legato all’AI.

I team di sicurezza dovrebbero testare le affermazioni dei fornitori in condizioni realistiche. Un prodotto che rileva un’evidente prompt injection può fallire contro istruzioni nascoste in documenti aziendali o codificate in più passaggi.

Gli esercizi di red team possono far emergere queste debolezze. Un red team AI verifica come un sistema risponde a manipolazione, richieste non sicure, autorizzazioni eccessive e dati inattesi.

I test devono includere l’applicazione completa, non solo il modello. Un modello sicuro può diventare pericoloso quando è collegato a strumenti ampi. Un modello più debole può restare a basso rischio all’interno di un flusso di lavoro strettamente limitato.

Anche la revisione umana non è una risposta universale. I revisori possono trasformarsi in un semplice timbro di approvazione quando i sistemi generano troppe decisioni o quando le scadenze premiano la velocità.

Il controllo giusto dipende dalle conseguenze. I contenuti a basso rischio possono usare il campionamento. Le azioni ad alto impatto dovrebbero richiedere un’approvazione esplicita, una convalida indipendente o un limite tecnico che impedisca l’esecuzione autonoma.

La governance dell’AI entra nel consiglio di amministrazione

Il rischio AI è diventato una questione di governance perché i controlli tecnici non possono risolvere responsabilità poco chiare o incentivi aziendali in conflitto.

Le comunicazioni pubbliche mostrano quanto rapidamente la questione si sia ampliata. The Conference Board ha rilevato che le aziende dell’S&P 500 che menzionano i rischi dell’AI sono passate dal 12% nel 2023 all’83% nel 2025.

La sua ricerca sulla governance ha inoltre rilevato che il 58% ha identificato la cybersicurezza e le violazioni dei dati come il rischio più significativo legato all’AI. Meno del 10% dei dirigenti intervistati ha affermato che le proprie aziende fossero pienamente preparate alla regolamentazione dell’AI.

Le divulgazioni dei rischi non confermano che si siano verificati incidenti. Le aziende usano le comunicazioni regolamentari per descrivere possibili minacce materiali e la cautela legale può incoraggiare un linguaggio ampio.

Tuttavia, il cambiamento segnala che l’AI è andata oltre i team di innovazione. I consigli di amministrazione devono ora considerare supervisione, escalation e responsabilità del management.

Il ruolo del consiglio non è approvare singoli modelli. Gli amministratori devono verificare che il management comprenda dove l’AI influisce su prodotti, operazioni, dipendenti e clienti.

Dovrebbero inoltre sapere quali implementazioni possono prendere decisioni rilevanti. Un assistente che redige testi interni è diverso da un agente che aggiorna prezzi, sposta denaro o modifica le autorizzazioni di accesso.

La reportistica del management dovrebbe collegare i segnali tecnici all’impatto sul business. I punteggi dei test del modello significano poco senza una spiegazione delle decisioni che il sistema supporta.

Un report utile potrebbe mostrare quanti sistemi AI possono accedere a dati riservati. Potrebbe identificare gli agenti con permessi di scrittura, i rilievi ad alto rischio non risolti e le eccezioni in attesa di revisione.

I consigli dovrebbero anche esaminare il rischio di concentrazione. Diverse applicazioni interne possono dipendere da un unico fornitore di modelli, servizio di identità o piattaforma di retrieval. Un singolo guasto può quindi influire su più funzioni aziendali.

Le dipendenze da terze parti complicano la garanzia. Un’impresa può proteggere la propria applicazione pur dipendendo da un fornitore che modifica il comportamento del modello, i termini di conservazione o le funzionalità di integrazione.

I contratti possono stabilire obblighi di notifica, audit e gestione dei dati. Non possono impedire ogni modifica tecnica. I team hanno comunque bisogno di monitoraggio e piani di contingenza.

La regolamentazione aggiunge un’ulteriore fonte di pressione. Diverse giurisdizioni classificano i sistemi AI in base a finalità, settore e potenziale danno. Un’azienda multinazionale può affrontare requisiti sovrapposti in materia di privacy, cybersicurezza, tutela dei consumatori e AI.

La conformità non dovrebbe diventare l’unica definizione di sicurezza. Un sistema può soddisfare i requisiti di documentazione pur mantenendo autorizzazioni eccessive o producendo decisioni inaffidabili.

Al contrario, un team tecnico può ridurre il rischio immediato per la sicurezza senza affrontare gli obblighi legali relativi a trasparenza, discriminazione o proprietà intellettuale.

Questa intersezione spiega perché, in alcuni sondaggi, il timore dell’AI abbia superato qualsiasi singola minaccia familiare. Il rischio non è un unico metodo di attacco. È un problema di governance che attraversa l’intero ciclo di vita della tecnologia.

Le organizzazioni hanno bisogno di chiari punti di controllo prima dell’implementazione, ma anche di una revisione continua. Modelli, dati, utenti e integrazioni cambiano dopo un’approvazione iniziale.

Il monitoraggio dovrebbe rilevare chiamate agli strumenti insolite, retrieval non autorizzato, movimenti anomali di dati e cambiamenti nella qualità degli output. I log devono mostrare quale identità ha avviato ogni azione e quali fonti l’hanno influenzata.

I piani di gestione degli incidenti dovrebbero includere scenari specifici per l’AI. I team hanno bisogno di procedure per disabilitare un agente, revocare credenziali, conservare i prompt e identificare i dati interessati.

Devono anche stabilire quando un output inaffidabile diventa un incidente da segnalare. Questa decisione può coinvolgere responsabili della sicurezza, della privacy, dell’area legale e delle operazioni.

La formazione dovrebbe riflettere i ruoli dei dipendenti. Gli avvisi generici sui dati riservati sono facili da ignorare. Sviluppatori, team commerciali, analisti e dirigenti incontrano modalità di guasto diverse.

Uno sviluppatore ha bisogno di indicazioni sul codice generato e sulle dipendenze. Un commerciale ha bisogno di regole sui dati dei clienti. Un dirigente deve saper riconoscere l’impersonificazione tramite deepfake e materiale decisionale manipolato.

Una governance efficace rende quindi più facile un comportamento sicuro. Gli strumenti approvati dovrebbero offrire abbastanza valore da evitare che i dipendenti abbiano bisogno di alternative non ufficiali per il lavoro ordinario.

Tre segnali indicheranno se le difese aziendali stanno recuperando terreno

La prossima fase sarà misurata attraverso le autorizzazioni degli agenti, dati verificati sugli incidenti ed evidenze che la governance modifica le decisioni di implementazione.

Il primo segnale è un accesso più limitato degli agenti. Le imprese dovrebbero iniziare a riportare quanti agenti AI dispongono di identità univoche, autorizzazioni limitate e approvazione umana per azioni rilevanti.

Questa misura va oltre il conteggio delle applicazioni approvate. Verifica se le aziende comprendono l’autorità che stanno concedendo al software.

I progressi saranno visibili quando le organizzazioni sostituiranno credenziali condivise e connettori senza restrizioni. Il fallimento emergerà attraverso agenti che ereditano ampi privilegi da dipendenti o amministratori.

Il secondo segnale è una migliore classificazione degli incidenti. I report di sicurezza devono separare gli attacchi assistiti dall’AI, gli attacchi contro sistemi AI e i guasti causati dall’uso interno dell’AI.

Categorie affidabili consentirebbero alle aziende di confrontare frequenza, gravità ed efficacia dei controlli. Verificherebbero inoltre se il timore attuale corrisponde al danno osservato.

Un aumento degli incidenti segnalati non significherebbe automaticamente che le difese hanno fallito. Un rilevamento migliore produce spesso numeri più alti prima di produrre perdite più basse.

Il terzo segnale è se la governance modifica le implementazioni reali. Le policy contano solo quando limitano i dati, riducono l’autorità, rinviano rilasci non sicuri o richiedono test aggiuntivi.

Le prove più solide verranno da modifiche documentate dell’ambito. Un’azienda potrebbe rimuovere la capacità di un agente di inviare messaggi, limitare le fonti di retrieval o mantenere l’approvazione umana per le azioni finanziarie.

Un segnale più debole è la creazione di un altro comitato di supervisione privo di autorità operativa. Una governance che non può modificare una decisione di lancio farà fatica a controllare le pressioni aziendali.

Le aziende dovrebbero inoltre osservare come gli assicuratori informatici e le autorità di regolamentazione trattano gli incidenti connessi all'AI. Requisiti più specifici costringerebbero le organizzazioni a documentare i controlli e a distinguere le dichiarazioni dalle capacità effettivamente testate.

La lezione essenziale non è che l'AI abbia sconfitto la cybersecurity. È che le imprese stanno collegando sistemi probabilistici a dati di valore e a strumenti aziendali affidabili più rapidamente di quanto maturino i controlli.

Questo squilibrio spiega il timore. Malware, phishing e ransomware sono pericolosi, ma i loro modelli operativi sono noti. L'AI introduce incertezza nei flussi di lavoro che le aziende desiderano attivamente ampliare.

I responsabili della sicurezza devono ora preservare le pratiche fondamentali di igiene informatica, aggiungendo al contempo valutazione dei modelli, identità degli agenti, controlli sui dati e responsabilità interfunzionale. Trascurare uno dei due aspetti crea una lacuna evitabile.

Per gli acquirenti di tecnologia, gli sviluppatori e i lavoratori della conoscenza, la domanda pratica è diretta: uno strumento di AI riceve solo le informazioni e l'autorità necessarie per svolgere il proprio compito?

Ponetevi questa domanda prima che la prossima integrazione venga messa in produzione. Registrate la risposta, testate il confine e decidete chi può fermare il sistema quando si comporta in modo imprevisto. Queste prove conteranno più dell'ennesima promessa generica che un'organizzazione utilizza l'AI in modo responsabile.