Non serve sempre un attacco informatico per far uscire informazioni da un’azienda. A volte basta molto meno: un browser aperto, un chatbot e un documento copiato nel posto sbagliato. È una scena ormai abbastanza facile da immaginare. Un dipendente riceve un contratto lungo e deve capirne rapidamente i punti principali. Invece di leggerlo tutto, apre un assistente AI, carica il file e chiede di riassumerlo.
Uno sviluppatore ha davanti una funzione che non funziona come dovrebbe e decide di incollare codice e log per capire dove sia l’errore. Qualcuno nelle risorse umane carica un curriculum per sintetizzarlo; nel reparto commerciale viene copiata una conversazione con un cliente per preparare una risposta.
Indice degli argomenti
Shadow AI aziendale: un’adozione nata prima delle strategie
Non c’è necessariamente superficialità dietro questi comportamenti. Nella maggior parte dei casi c’è semplicemente una persona che sta cercando di svolgere il proprio lavoro più velocemente. Ed è proprio questo a rendere il tema interessante. L’intelligenza artificiale generativa si è infilata nei processi di lavoro senza aspettare che le aziende finissero di scrivere policy, valutare fornitori o organizzare corsi di formazione. È entrata dalle abitudini delle persone, spesso prima ancora che l’organizzazione decidesse ufficialmente se adottarla oppure no.
Il risultato è che una parte dell’uso dell’AI nelle aziende avviene in una zona poco visibile. È quello che viene generalmente definito Shadow AI: l’utilizzo di chatbot, modelli generativi, assistenti di coding, strumenti di trascrizione o altri servizi basati sull’intelligenza artificiale senza che quell’utilizzo sia stato necessariamente approvato, configurato o conosciuto dall’organizzazione.
Dalla Shadow IT agli assistenti AI
Il termine ricorda volutamente la Shadow IT, un problema con cui i reparti IT convivono da anni. Account Dropbox personali, software installati autonomamente, applicazioni SaaS acquistate dai singoli reparti, repository privati creati senza coordinamento centrale: la logica è molto simile. Con l’AI, però, tutto accade con ancora meno attrito. Non bisogna installare necessariamente un software, non serve acquistare un’infrastruttura e spesso non è necessario nemmeno coinvolgere l’IT. Si apre una pagina web, si crea un account e si comincia a lavorare. È difficile immaginare un’adozione tecnologica più semplice di questa.
L’adozione spontanea nei processi di lavoro
In molti casi l’intelligenza artificiale generativa non è entrata in azienda attraverso un progetto strutturato deciso dal management. È successo quasi al contrario. Qualcuno ha iniziato a provare ChatGPT per curiosità, poi ha scoperto che poteva riscrivere una mail. Successivamente lo ha usato per tradurre un testo, preparare una presentazione, sintetizzare un documento o spiegare una formula Excel. A quel punto il passaggio dal “lo uso ogni tanto” al “lo uso mentre lavoro” è stato piuttosto breve.
Per gli sviluppatori è successo qualcosa di simile con gli assistenti integrati negli IDE. Per chi lavora con molti meeting, con i servizi che trascrivono e riassumono automaticamente le riunioni. Per chi scrive, con strumenti di revisione e generazione del testo. Non sempre, quindi, è possibile individuare un momento preciso in cui l’intelligenza artificiale “entra” nell’organizzazione. A volte era già lì prima che qualcuno decidesse di chiamarla progetto AI.
È anche per questo che la visibilità è diventata uno dei problemi principali. Una ricerca Cisco pubblicata nel 2025 rilevava, per esempio, che in Europa il 21% dei dipendenti aveva accesso senza restrizioni a strumenti pubblici di intelligenza artificiale generativa, mentre il 69% dei team IT dichiarava di non avere visibilità sulle interazioni dei dipendenti con questi strumenti. Nello stesso studio, il 65% delle organizzazioni europee affermava di non sentirsi sufficientemente sicuro della propria capacità di individuare implementazioni AI non regolamentate.
Il dato interessante non è soltanto la percentuale in sé, ma il tipo di problema che descrive. Un’azienda può sapere perfettamente quali software ha acquistato, quali licenze ha assegnato e quali piattaforme sono presenti nel proprio inventario, senza sapere davvero quali servizi AI vengano utilizzati durante la giornata lavorativa. E ormai non si parla più soltanto dei chatbot più conosciuti. L’AI è presente negli editor di codice, nei browser, nelle piattaforme di produttività, nei sistemi di traduzione, nei software di grafica, negli strumenti per lavorare con PDF, nelle applicazioni di videoconferenza e nei servizi che elaborano email o documenti.
Per questo ridurre il problema alla formula “dipendenti che usano ChatGPT di nascosto” rischia di far perdere di vista una parte importante della questione. La domanda, in realtà, è più ampia: quali servizi ricevono informazioni aziendali durante il lavoro quotidiano e che cosa fanno con quei dati? Non è detto che chi li usa sappia sempre rispondere.
Dati nei chatbot: il rischio centrale della Shadow AI aziendale
Quando si parla di perdita di dati, l’immaginario della cybersecurity è ancora legato soprattutto agli incidenti classici: database sottratti, allegati inviati al destinatario sbagliato, server compromessi, cartelle cloud esposte, dispositivi persi. Con i chatbot il meccanismo può essere molto meno evidente. Il dato non viene necessariamente rubato: può essere l’utente stesso a trasferirlo verso un servizio esterno, semplicemente perché è il modo più rapido per ottenere un risultato.
Più contesto, più informazioni esposte
Qui nasce una piccola contraddizione. Per funzionare bene, un modello ha bisogno di contesto. Più informazioni riceve, più riesce normalmente a produrre una risposta utile. Se si chiede genericamente a un assistente AI come effettuare il debug di una funzione, la risposta resterà necessariamente generica.
Se invece gli vengono forniti il codice reale, il messaggio di errore, i log e magari parte della configurazione, l’analisi diventa molto più precisa. Con un contratto avviene la stessa cosa: chiedere “quali clausole sono normalmente rischiose in un contratto di fornitura?” produce indicazioni generali; caricare il contratto reale e chiedere “quali problemi vedi qui?” è molto più utile.
Dal punto di vista dell’utente è perfettamente logico. Dal punto di vista della sicurezza, però, succede qualcosa di particolare: il vantaggio dello strumento incoraggia a fornire più dati proprio mentre molte politiche di sicurezza cercano di ottenere l’effetto opposto. Il prompt, a quel punto, non è più soltanto una domanda. Dentro possono finire codice sorgente, nomi di clienti, dati commerciali, ticket di assistenza, informazioni relative a un’infrastruttura, curriculum, documenti contrattuali, schemi di database o conversazioni interne.
Non serve nemmeno caricare un file intero perché qualcosa di riservato finisca fuori dal perimetro previsto. È sufficiente un dettaglio. Uno sviluppatore incolla un log e dentro resta un token. Qualcuno chiede di riscrivere una mail e mantiene nomi, indirizzi e riferimenti interni. Un commerciale copia la cronologia di una trattativa e insieme al testo finiscono nel prompt prezzi o condizioni concordate con il cliente. Sono situazioni banali, proprio per questo difficili da intercettare soltanto con il buon senso.
Durante l’utilizzo di questi strumenti, infatti, l’attenzione dell’utente è quasi sempre rivolta a ciò che vuole ottenere, molto meno a tutto ciò che ha dovuto consegnare al sistema per arrivare a quel risultato.
Privacy, account e fornitori nella Shadow AI aziendale
È probabilmente una delle prime domande che vengono poste quando si parla di privacy e chatbot. Ed è una domanda importante, ma non può essere l’unica. Le condizioni cambiano da servizio a servizio e possono cambiare anche in base al tipo di account utilizzato. Nel caso di OpenAI, per esempio, i dati dei prodotti Business, Enterprise, Edu e della piattaforma API non vengono utilizzati per l’addestramento dei modelli per impostazione predefinita. Per i prodotti destinati ai singoli utenti esistono invece impostazioni e controlli differenti.
Questo tipo di distinzione mostra bene perché parlare genericamente di “uso di ChatGPT” o “uso dell’AI” sia poco utile dal punto di vista aziendale. Lo stesso servizio, utilizzato attraverso un account governato dall’azienda o attraverso un account personale, può collocarsi in contesti di rischio molto diversi.
E comunque la questione del training è soltanto una parte del problema. Un’organizzazione deve capire anche se i dati vengono conservati, per quanto tempo, in quali regioni, quali funzioni amministrative sono disponibili, chi può accedere ai contenuti, quali integrazioni sono attive e quali altri soggetti potrebbero essere coinvolti nel trattamento.
In altre parole, il problema non dovrebbe essere ridotto a: “questo documento verrà usato per addestrare il modello?”. Prima ancora bisognerebbe capire se quel documento poteva essere trasferito a quel servizio. Sembra una distinzione sottile, ma non lo è. Un’informazione può non essere utilizzata per addestrare alcun modello e allo stesso tempo essere stata comunque inviata a un fornitore che l’azienda non aveva autorizzato a riceverla.
Account personali e strumenti aziendali
Un caso particolarmente interessante riguarda gli account personali. Supponiamo che un’organizzazione decida di adottare ufficialmente un assistente AI. Il fornitore viene valutato, vengono analizzate le condizioni contrattuali, configurati gli account, impostata l’autenticazione e stabiliti alcuni criteri per l’utilizzo.
Poi uno dei dipendenti apre lo stesso servizio con il proprio account personale. Dal suo punto di vista potrebbe sembrare una differenza trascurabile: l’interfaccia è la stessa, il modello probabilmente è simile, le funzioni disponibili sembrano quasi identiche. Per l’azienda, però, il contesto può essere completamente diverso. Potrebbero cambiare le impostazioni di conservazione delle conversazioni, le condizioni contrattuali, le funzioni amministrative e soprattutto la possibilità di sapere che cosa sta succedendo.
È uno dei motivi per cui una lista del tipo “questi chatbot sono consentiti, questi no” spesso non basta. Non conta soltanto quale servizio viene utilizzato. Conta con quale account, in quale configurazione, per quale attività e con quali informazioni. Anche questo è un elemento che le policy aziendali dovrebbero riuscire a spiegare in maniera molto più semplice di quanto normalmente accada.
Se per capire se sia consentito correggere una mail con un assistente AI un dipendente deve aprire un documento di venti pagine scritto in linguaggio legale, è abbastanza probabile che non lo faccia.
Policy e divieti: perché la Shadow AI resta invisibile
Davanti alla difficoltà di controllare questi strumenti, la risposta più immediata può essere vietarli. Da un punto di vista formale è la soluzione più semplice: “Non utilizzate chatbot pubblici per attività aziendali”. La frase entra nella policy e il problema sembra sotto controllo. Nella pratica, però, la situazione è più complicata.
L’intelligenza artificiale generativa offre un vantaggio molto concreto in tante attività: scrittura, ricerca, traduzione, programmazione, sintesi, analisi di documenti. E una volta che una persona si è abituata a svolgere una certa attività in venti minuti anziché in un’ora, convincerla a tornare indietro non è così scontato.
Il divieto può eliminare l’utilizzo oppure può semplicemente renderlo meno visibile. Il dipendente può utilizzare il proprio telefono, un account personale o un altro servizio che non compare nella lista dei domini bloccati. In quel momento l’azienda non ha necessariamente aumentato la propria sicurezza; ha soltanto perso una parte della capacità di osservare il comportamento reale.
Naturalmente questo non significa che qualsiasi strumento debba essere permesso o che ogni utilizzo sia accettabile. Ci saranno servizi da bloccare e categorie di dati che non dovranno essere caricate in sistemi esterni. Ma un divieto funziona molto meglio quando esiste un’alternativa. Se un’azienda non vuole che un dipendente carichi un contratto su un chatbot pubblico per ottenerne una sintesi, dovrebbe anche indicargli con quale strumento può ottenere quello stesso risultato. Altrimenti l’utente si trova davanti a una scelta poco realistica: rinunciare a un vantaggio operativo oppure aggirare la regola.
Prima o poi qualcuno sceglierà la seconda strada.
Regole concrete per l’uso quotidiano dell’AI
“È vietato inserire dati sensibili nei sistemi di intelligenza artificiale generativa.” È una frase che compare facilmente in una policy e, naturalmente, ha senso. Il problema è capire che cosa significhi nella vita di tutti i giorni.
Una password è un dato da non inserire. Fin qui è semplice. Ma una funzione scritta internamente? Una query SQL? Un ticket di assistenza? Il curriculum di un candidato? Una registrazione di una riunione? Un preventivo? Una mail ricevuta da un cliente? Sono situazioni molto più sfumate.
Per questo una policy realmente utilizzabile dovrebbe partire dai casi concreti e non soltanto dalle categorie astratte. Può essere perfettamente legittimo chiedere a un assistente autorizzato di riscrivere un testo generico o suggerire la struttura di una presentazione. In altri casi può essere sufficiente anonimizzare le informazioni prima di inserirle. Altrove, invece, il trasferimento dovrebbe essere escluso del tutto.
Credenziali, segreti, informazioni sottoposte a particolari vincoli contrattuali o documenti ricevuti da clienti con precise condizioni di riservatezza richiedono evidentemente un trattamento diverso. Il punto non è arrivare a una policy capace di prevedere qualsiasi scenario, probabilmente sarebbe impossibile. L’obiettivo dovrebbe essere dare alle persone un criterio sufficientemente chiaro da applicare anche nelle situazioni che non sono state descritte esplicitamente.
Più che chiedersi genericamente “posso usare l’AI?”, quindi, sarebbe utile abituarsi a ragionare in termini più specifici: che strumento sto usando? Che cosa gli sto inviando? Per quale motivo? È un ragionamento un po’ più scomodo del semplice sì o no, ma è anche molto più vicino al modo in cui questi sistemi vengono utilizzati davvero.
Formazione e controlli per governare la Shadow AI aziendale
Sul tema dell’intelligenza artificiale la formazione aziendale si è concentrata spesso sull’utilizzo degli strumenti: come scrivere prompt migliori, come verificare una risposta, come individuare un’allucinazione. Sono competenze utili, ma una formazione realmente efficace dovrebbe includere anche un altro pezzo: cosa succede alle informazioni utilizzate per costruire quei prompt.
Non serve farlo con scenari apocalittici. Anzi, probabilmente funziona meglio partire da casi assolutamente normali: devo correggere una funzione, che cosa posso incollare? Ho la trascrizione di una riunione e voglio ottenere un riepilogo, posso caricarla? Sto lavorando su alcuni curriculum, quali dati posso utilizzare e in quale ambiente? Ho ricevuto un contratto da un cliente, posso farlo analizzare da un modello?
Sono situazioni in cui è molto più facile riconoscersi rispetto alla generica raccomandazione di “prestare attenzione ai dati”.
AI literacy e responsabilità sui dati
Il tema della formazione assume inoltre un peso particolare anche nel quadro normativo europeo. L’articolo 4 dell’AI Act richiede a provider e deployer di adottare misure affinché il personale e le altre persone che utilizzano sistemi di intelligenza artificiale per loro conto abbiano un livello adeguato di AI literacy, considerando competenze, esperienza e contesto di utilizzo.
L’AI literacy, però, non dovrebbe essere interpretata soltanto come la capacità di utilizzare bene un chatbot. Sapere che cosa non bisogna consegnargli, o in quali condizioni lo si può fare, è parte della stessa competenza. Anche perché una persona formata correttamente può rappresentare una misura preventiva molto più efficace di quanto si pensi. Intervenire dopo che un documento riservato è stato caricato nel servizio sbagliato è necessario; fare in modo che l’utente si accorga del rischio prima di premere “Invio” è decisamente meglio.
DLP e controlli tecnici sui trasferimenti
Affidarsi soltanto al comportamento degli utenti, naturalmente, non sarebbe realistico. Una policy può essere chiara, il corso può essere stato fatto e l’utente può essere perfettamente consapevole delle regole. Gli errori continueranno comunque a esistere.
È qui che le tecnologie di Data Loss Prevention tornano ad avere un ruolo centrale. Il DLP non nasce con l’intelligenza artificiale: da anni viene utilizzato per individuare o bloccare la fuoriuscita di determinate categorie di informazioni attraverso email, dispositivi rimovibili, servizi cloud o altri canali. Con i chatbot cambia il canale, non il principio.
A seconda dell’ambiente possono essere utilizzati controlli sugli endpoint, Secure Web Gateway, CASB, browser gestiti o sistemi in grado di riconoscere upload e trasferimenti verso piattaforme AI. Non sempre la risposta deve essere il blocco. In alcuni casi può essere sufficiente generare un alert, in altri si può informare l’utente che sta cercando di trasferire una determinata categoria di dati, altrove può essere sensato impedirne completamente l’invio.
Il modo in cui viene configurato il controllo dipende dal livello di rischio e dal contesto. È importante però non immaginare il DLP come una soluzione autonoma. Se un sistema blocca continuamente operazioni che gli utenti non comprendono, verrà percepito soltanto come un ostacolo. E quando un controllo diventa un ostacolo inspiegabile, qualcuno inizia a cercare un modo per aggirarlo.
Il contrario non funziona molto meglio: una policy impeccabile senza nessun controllo tecnico resta affidata alla capacità di ogni singola persona di ricordare sempre la regola corretta. L’approccio più sensato sta nell’integrazione delle due cose. Il NIST, nel proprio profilo dedicato ai rischi dell’intelligenza artificiale generativa, insiste proprio sulla necessità di gestire il rischio lungo l’intero ciclo di vita e di non ridurlo a una singola misura tecnica. In fondo il problema della Shadow AI nasce proprio dal fatto che non esiste un unico punto in cui intervenire.
Strumenti autorizzati e bisogni dietro la Shadow AI
C’è poi un aspetto che viene spesso sottovalutato perché sembra avere poco a che fare con la sicurezza: la qualità dell’esperienza offerta all’utente.
Immaginiamo che un’azienda disponga di un assistente approvato e sicuro. Per usarlo, però, bisogna accedere a un portale interno, effettuare una seconda autenticazione, selezionare una serie di impostazioni poco chiare e lavorare con un’interfaccia lenta. Dall’altra parte c’è un chatbot pubblico che la persona usa già quotidianamente e che si apre in pochi secondi.
Formalmente non c’è dubbio su quale dei due strumenti debba essere utilizzato. Nella pratica, invece, la scelta può essere meno scontata.
Alternative aziendali semplici da usare
La sicurezza dipende anche da questo. Un’alternativa aziendale funziona se riesce davvero a sostituire il comportamento che l’organizzazione vuole evitare. Può trattarsi di una versione enterprise di un servizio già conosciuto, di un modello distribuito attraverso un’infrastruttura controllata, di un gateway interno o di un assistente realizzato direttamente dall’azienda.
Per alcuni casi d’uso può essere utile introdurre meccanismi di anonimizzazione automatica. In altri può essere sensato collegare il sistema alle basi documentali interne applicando gli stessi permessi già utilizzati dall’organizzazione. A quel punto l’utente non deve più scaricare un file e caricarlo da qualche altra parte: può interrogare direttamente le informazioni a cui ha già diritto di accedere.
È un modello più complesso da costruire, ma risolve una parte del problema alla radice, perché riduce la necessità di esportare dati verso strumenti esterni. E soprattutto rende il comportamento corretto meno faticoso, che nella pratica conta moltissimo.
I bisogni che emergono dagli usi spontanei
Guardare alla Shadow AI soltanto come a un insieme di comportamenti da reprimere significa perdere un’altra informazione interessante. Se molte persone utilizzano spontaneamente un certo tipo di strumento, probabilmente stanno segnalando un bisogno.
Gli sviluppatori usano assistenti di coding perché li trovano utili. Le risorse umane usano chatbot perché devono riscrivere annunci, sintetizzare curriculum o preparare comunicazioni. Altri dipendenti li usano perché passano molto tempo a leggere documenti e vogliono trovare più rapidamente ciò che interessa.
Naturalmente non significa che qualsiasi utilizzo debba essere autorizzato, ma vale la pena chiedersi perché si sia diffuso. La Shadow AI può diventare, in questo senso, una specie di osservatorio involontario sui processi aziendali. Mostra dove le persone percepiscono attività ripetitive, dove vedono possibilità di automatizzazione e dove gli strumenti messi a disposizione dall’organizzazione non sono sufficienti.
Prima di bloccare un servizio, quindi, potrebbe essere utile capire quale problema stava risolvendo. Se il problema è reale, sparirà difficilmente insieme al dominio inserito nella blacklist: l’utente cercherà un’altra soluzione.
Ed è forse questo il motivo per cui la governance dell’intelligenza artificiale non può essere affidata soltanto alla sicurezza informatica. Entrano in gioco l’IT, la privacy, il legale, le risorse umane e soprattutto le funzioni che conoscono realmente il lavoro quotidiano svolto dalle persone.
Dalla Shadow AI aziendale all’adozione governata
Pensare di tenere completamente l’intelligenza artificiale fuori dall’azienda sta diventando progressivamente meno realistico. Non perché ogni organizzazione debba necessariamente utilizzarla in qualsiasi processo, ma perché l’AI non arriva più sotto forma di un singolo prodotto che può essere installato o rifiutato. È già presente negli strumenti di produttività, nei browser, nei motori di ricerca, negli IDE, nei servizi cloud, nelle piattaforme di videoconferenza e, soprattutto, nelle abitudini degli utenti.
Per questo forse la domanda “i dipendenti useranno l’intelligenza artificiale?” ha perso parte della propria utilità. Molti la stanno già usando, a volte senza nemmeno percepire quel comportamento come qualcosa di particolare. La questione, per le aziende, diventa un’altra: capire dove la stanno usando, con quali account, per quali attività e soprattutto quali informazioni entrano in quei sistemi.
È qui che passa la differenza tra un’adozione governata e la Shadow AI. Non si tratta di rendere impossibile qualsiasi utilizzo non previsto, probabilmente sarebbe un obiettivo irrealistico. Si tratta piuttosto di ridurre quella parte dell’utilizzo che oggi rimane invisibile, offrendo regole comprensibili, strumenti adeguati e controlli sufficientemente intelligenti da non trasformare la sicurezza in un ostacolo permanente.
Servono strumenti tecnici, naturalmente: DLP, controllo degli accessi, gestione degli account, valutazione dei fornitori. Ma questi strumenti funzionano soltanto se l’organizzazione accetta un dato piuttosto semplice: le persone stanno utilizzando l’intelligenza artificiale perché, in molti casi, permette davvero di lavorare più velocemente.
Ignorare questo elemento non impedisce l’utilizzo, lo rende soltanto più difficile da vedere. Ed è proprio quando non si vede più dove finiscono i dati che la Shadow AI smette di essere soltanto una questione di produttività e diventa un problema di sicurezza.
Partecipa alla community