Il 22 aprile 2026, in una sessione di 15 minuti a EmTech AI, MIT Technology Review ha messo al centro una tesi precisa: la cybersecurity AI non può più essere trattata come un controllo aggiunto dopo il rilascio dei sistemi.
Per chi usa AI in azienda, questo non è un tema da reparto sicurezza. Significa che ogni assistente collegato a email, CRM, repository documentali o ticket interni diventa anche un nuovo punto di accesso ai dati, alle credenziali e alle decisioni operative. La domanda pratica non è più “abbiamo autorizzato questo tool?”, ma “sappiamo davvero cosa può leggere, modificare o inoltrare?”
Perché la cybersecurity AI cambia la superficie d'attacco
La sessione “Cyber-Insecurity in the AI Era”, presentata da GC Cybersecurity con Tarique Mustafa, cofondatore, CEO e CTO della società, parte da un presupposto semplice: la sicurezza tradizionale è stata progettata per applicazioni, reti, endpoint e identità relativamente prevedibili. L'AI aggiunge un livello diverso, perché interpreta input ambigui, collega sistemi, produce output e, nei casi agentici, può eseguire azioni.
La scheda ufficiale dell'evento EmTech AI riassume così il punto centrale:
“Security must be rethought with AI at its core, not layered on after the fact.”
Tradotto per un'azienda: non basta comprare un chatbot, vietare qualche prompt e aggiornare la policy privacy. La superficie d'attacco cresce perché l'AI si inserisce nel punto in cui dati, permessi e automazione si incontrano. Se un modello può interrogare un database clienti, riassumere contratti o aprire ticket di assistenza, allora l'attaccante non cerca solo una vulnerabilità software. Può cercare un modo per manipolare il comportamento del modello.
Il punto tecnico: dati, agenti e permessi
Il rischio più concreto riguarda la catena tra dati sensibili e strumenti connessi. Mustafa arriva da un background in DLP, cioè data loss prevention, e DSPM, data security posture management: due aree che servono a capire dove si trovano i dati sensibili, chi li può usare e quando rischiano di uscire dal perimetro autorizzato.
Con i sistemi AI, questa catena diventa più difficile da controllare. Un assistente interno può avere accesso a documenti riservati, ticket IT, knowledge base e strumenti di produttività. Se riceve istruzioni ostili, attraverso prompt injection, può essere spinto a ignorare vincoli, rivelare informazioni o compiere azioni non previste. Se usa connettori esterni, il problema non è solo il modello: sono i permessi assegnati intorno al modello.
Chi segue il settore da vicino sa che la parola “AI governance” spesso viene usata come etichetta elegante per documenti interni. Qui, invece, indica una necessità operativa: inventario degli strumenti, controllo degli accessi, tracciamento dei prompt, log delle azioni, test sui comportamenti anomali e procedure di risposta agli incidenti.
Il punto tecnico è questo: un sistema AI sicuro non è solo un modello meno vulnerabile. È un ambiente in cui il modello non può vedere tutto, non può fare tutto e lascia tracce verificabili quando qualcosa va storto.
I numeri dicono che il problema è già operativo
Il contesto conferma che non si tratta di una preoccupazione astratta. L'IBM X-Force Threat Intelligence Index 2026 segnala un aumento del 44% anno su anno nello sfruttamento di applicazioni o sistemi esposti pubblicamente. Lo stesso rapporto indica che il 56% delle vulnerabilità divulgate non richiedeva autenticazione per essere sfruttato e che 300.000 credenziali di chatbot AI sono state osservate in vendita nel dark web.
Questi dati non dimostrano che ogni attacco sia generato dall'AI. Dimostrano qualcosa di più utile: gli attaccanti hanno già un mercato, una superficie tecnica e un incentivo economico per automatizzare la ricerca di accessi deboli. In questo scenario, l'AI non crea il rischio dal nulla. Lo rende più veloce, più scalabile e più difficile da distinguere dal traffico legittimo.
Cosa cambia per le aziende italiane
Per le aziende italiane, la notizia arriva in un momento in cui AI generativa, cloud e compliance si stanno sovrapponendo. GDPR, NIS2 e DORA non chiedono solo buone intenzioni: chiedono controllo, tracciabilità e responsabilità. Se un sistema AI accede a dati personali o processi critici, deve essere trattato come parte dell'infrastruttura di sicurezza, non come un esperimento laterale del team innovazione.
La conseguenza concreta è che ogni progetto AI dovrebbe partire da tre verifiche prima del rilascio: quali dati può leggere, quali azioni può eseguire e quali evidenze produce in caso di incidente. Senza queste risposte, l'azienda non sta solo adottando AI; sta delegando una parte del proprio perimetro operativo a un sistema che potrebbe non essere auditabile.
Per il lettore italiano, il cambiamento pratico è immediato: la prossima valutazione di un tool AI non dovrebbe fermarsi a prezzo, modello usato e promessa di produttività. Dovrebbe includere permessi, log, gestione delle credenziali, test contro prompt malevoli e una domanda di governance molto concreta: chi risponde, in azienda, se l'assistente AI espone dati che nessuno pensava potesse vedere?