Oltre l’80% dei dipendenti usa sul lavoro strumenti AI mai passati da una revisione di sicurezza, e quasi la metà continuerebbe a farlo anche sotto divieto esplicito. Lo ha spiegato David Smith, Data Protection Officer di The DPO Centre Ltd, in un’analisi pubblicata da TechRadar Pro: la “shadow AI” non è un problema di disciplina dei dipendenti, è un problema di design aziendale. Lo strumento approvato, quando esiste, è più lento o più scomodo di ChatGPT aperto in una scheda del browser personale. Per questo motivo, la domanda insoddisfatta spinge all’adozione spontanea.
Rientrano nella “shadow AI” i chatbot generativi consumer usati con account personale, le funzioni AI incorporate in software SaaS già approvati ma mai valutate per quello scopo, le estensioni browser, i servizi di trascrizione automatica, gli agenti autonomi installati senza passare da IT. È l’erede diretta dello shadow IT di fine anni Duemila, con un salto di rischio netto: lo shadow IT duplicava dati su uno storage non autorizzato, la shadow AI quei dati li elabora e li ricombina, e ne genera output che finiscono altrove.
Il gap di percezione tra chi governa e chi usa questi strumenti misura il problema meglio di ogni altro dato. Un sondaggio ManageEngine del 2025 registra che il 97% dei decision maker IT nordamericani vede rischi seri nello shadow AI. Tra i dipendenti il consenso crolla al 9%: la maggioranza non percepisce il rischio, o lo ritiene compensato dal beneficio immediato della strumento più veloce e intuitivo.
Netskope rileva che il 47% dell’uso aziendale di AI generativa passa da account personali non monitorati. Telus Digital arriva a numeri simili da un’altra angolazione: il 68% dei dipendenti che usa GenAI sul lavoro lo fa con credenziali personali, e il 57% ammette di avervi caricato informazioni sensibili. Software AG aggiunge il dato più scomodo per chi pensa che il divieto risolva tutto: il 48% dei dipendenti continuerebbe a usare AI non autorizzata anche sotto divieto esplicito.
Lo strumento non autorizzato vince quasi sempre perché quello autorizzato non esiste, o è peggiore.
Sul piano legale il rischio non è teorico. Il GDPR impone, all’articolo 5, liceità e trasparenza del trattamento: condizione impossibile se l’azienda non sa che un trattamento sta avvenendo. L’articolo 28 richiede un accordo di trattamento dati (DPA) con ogni fornitore terzo; quando un dipendente incolla un contratto in un account ChatGPT personale, quell’accordo non esiste. L’articolo 35 impone una valutazione d’impatto per i trattamenti ad alto rischio, ma non si può valutare l’impatto di uno strumento che l’azienda non sa di avere in uso. Le sanzioni GDPR arrivano fino a 20 milioni di euro o il 4% del fatturato globale; l’AI Act aggiunge obblighi di due diligence per i sistemi ad alto rischio, con un tetto teorico del 6%.
Il caso Samsung del 2023 resta l’esempio più citato. Nelle settimane successive all’autorizzazione a usare ChatGPT nella divisione semiconduttori, gli ingegneri hanno incollato codice sorgente proprietario e specifiche hardware nell’interfaccia consumer, in almeno tre episodi distinti. Samsung ha risposto con un divieto totale, poi revocato: la lezione è che il divieto da solo non basta, senza un’alternativa sanzionata sposta l’uso nell’ombra invece di eliminarlo.
C’è un’asimmetria in più rispetto ai leak tradizionali: un file caricato per errore su uno storage condiviso si può cancellare, un testo incollato in un modello gratuito che lo usa per il training può restare recuperabile per sempre. IBM calcola che 1 organizzazione su 5 ha già subito una violazione legata a shadow AI, con un costo incrementale di 670.000 dollari rispetto a un incidente tradizionale: il 65% di quei casi ha esposto dati personali, il 40% ha causato furto di proprietà intellettuale.
I rischi 2026 vanno oltre la chat generativa. Il social network Moltbook, costruito con tecniche di “vibe coding”, ha esposto 1,5 milioni di chiavi API e le email di 35.000 utenti, violazione diretta del principio di sicurezza del GDPR nata da codice generato senza revisione sistematica. Le aziende che hanno tentato di arginare il fenomeno solo con divieti hanno ottenuto un uso ancora più diffuso: il 66% degli impiegati continua a usare strumenti non autorizzati anche dove la policy li vieta esplicitamente, secondo un report PagerDuty. Colmare il gap richiede trattare lo shadow AI come segnale di una domanda insoddisfatta, non come un’infrazione da punire.
Come costruire una policy che i dipendenti userebbero davvero
La prima azione concreta non è un documento legale di venti pagine che nessuno legge, ma un testo breve, due o quattro pagine, organizzato su tre fasce di rischio: dati condivisibili liberamente, dati condivisibili solo con strumenti approvati, dati mai condivisibili con AI. Nella terza fascia rientrano sempre dati clienti, clausole contrattuali, codice proprietario, proiezioni finanziarie e dati personali dei dipendenti. Una matrice a tre fasce di questo tipo, già pubblicata da Tom’s Hardware nella guida ai prompt per creare policy AI aziendali, riduce la stesura a poche ore invece che a settimane di consulenza legale.
La policy funziona solo se è permissiva sui casi comuni e restrittiva sui casi sensibili: un testo che vieta tutto spinge l’uso sotto traccia, un testo che elenca cosa si può fare e con quali strumenti riduce l’incentivo ad aggirarlo. Va scritta insieme a chi userà davvero gli strumenti, non calata dall’alto da Legal in isolamento: un documento scritto senza ascoltare chi lavora sui casi reali finisce per bloccare gli usi più utili e ignorare i rischi più concreti, come spiega anche questa guida all’uso responsabile dell’AI scritta con esperti del settore.
Whitelist pubblica, non un PDF dimenticato in una cartella condivisa
Un elenco di strumenti approvati serve solo se resta vivo: deve stare in intranet, con data di ultima revisione visibile, non archiviato in un PDF che nessuno riapre. Deve coprire almeno un’alternativa enterprise per categoria di uso comune: scrittura e sintesi, analisi dati, generazione di codice, trascrizione riunioni. Quasi tutti gli strumenti gratuiti più diffusi hanno oggi una controparte enterprise con garanzie contrattuali equivalenti o superiori.
Le versioni enterprise di Claude, ChatGPT e Gemini offrono un DPA conforme all’articolo 28, l’esclusione esplicita dei dati aziendali dal training, e log di audit verificabili. Il costo di questi piani, quasi sempre tra pochi euro e poche decine di euro per utente al mese, resta marginale rispetto al costo medio di un incidente da 670.000 dollari. Chiudere il gap tra strumento gratuito e strumento sanzionato è la leva più diretta per ridurre l’incentivo economico a restare nell’ombra.
DPIA prima dell’adozione, non dopo l’incidente
Ogni nuovo strumento AI ad alto rischio andrebbe sottoposto a una valutazione d’impatto sulla protezione dei dati prima di essere autorizzato, non dopo che qualcuno lo ha già adottato spontaneamente. È un obbligo dell’articolo 35 GDPR, e si lega ai principi di due diligence dell’AI Act per i sistemi che impattano decisioni su persone: assunzioni, credito, accesso a servizi. La DPIA è l’unico modo per sapere, prima che il dato esca dall’azienda, quali informazioni lo strumento tratterà. Va ripetuta quando cambia in modo sostanziale la funzione dello strumento, non solo alla prima adozione.
Un accordo di trattamento dati per ogni fornitore, senza eccezioni
Nessun account personale può sostituire un DPA firmato dall’azienda. Se un dipendente usa un account ChatGPT personale per un documento aziendale, non esiste alcun accordo tra l’azienda e il fornitore che regoli quel trattamento, perché il rapporto contrattuale è tra l’individuo e il fornitore. La soluzione pratica è collegare la whitelist all’esistenza verificata di un DPA attivo: nessuno strumento entra in whitelist senza che Legal ne abbia confermato l’accordo. Un controllo procedurale semplice, che però richiede un presidio continuo, non una verifica una tantum alla firma del contratto quadro.
Un canale che risponde in giorni, non in mesi
Una delle cause più concrete della shadow AI è la lentezza della pipeline IT per approvare nuovi strumenti: se richiederne uno significa aprire un ticket e aspettare mesi, il dipendente trova da solo una scorciatoia, quasi sempre non autorizzata. Tom’s Hardware ha già documentato questa dinamica: tra le mosse più efficaci per invertirla c’è l’apertura di un canale dedicato con SLA garantito, un modulo o un canale Slack/Teams specifico, con risposta entro pochi giorni lavorativi. La riduzione dei tempi di risposta riduce l’incentivo a aggirare il controllo: anche un rifiuto motivato è più deterrente di un’assenza di risposta che il dipendente interpreta come autorizzazione implicita.
Formazione continua, non un corso annuale che invecchia in fretta
La classificazione dei dati è la competenza che manca quasi sempre, non la conoscenza dei rischi in astratto. Un corso di due ore fatto una volta all’anno, con esempi generici, non prepara nessuno a riconoscere in tempo reale se il documento che sta per incollare in un chatbot contiene dati della fascia “mai condivisibile”. Servono sessioni brevi e ricorrenti, costruite su casi presi dai flussi di lavoro reali: un contratto tipico, un’email con dati clienti, uno screenshot di codice proprietario. Va aggiornata ogni volta che cambia il set di strumenti approvati, incluse le funzioni AI che arrivano silenziosamente dentro software già in uso, un problema legato al più ampio fenomeno dell’AI sprawl che sta sfuggendo di mano a gran parte delle grandi aziende.
Osservare il traffico di rete, non per punire ma per capire
Gli strumenti di monitoraggio della rete e di SaaS discovery permettono di vedere quali servizi AI sono davvero in uso, e con quali volumi di dati, prima ancora di scrivere una policy. I risultati di questa mappatura vanno trattati come materiale di ricerca per identificare la domanda latente, non come prova per procedimenti disciplinari. Un’azienda che scopre, tramite questi strumenti, che un intero reparto usa la stessa estensione browser non autorizzata ha di fronte un segnale chiaro: quello strumento risponde a un bisogno vero, e la risposta corretta è valutarne una versione enterprise, non un richiamo formale a chi lo usa.
Le sette azioni non sono indipendenti: la whitelist regge solo se collegata ai DPA verificati, la policy regge solo se nasce dall’ascolto dei dipendenti, il monitoraggio di rete serve solo se alimenta la whitelist invece di un registro sanzioni. Prese insieme formano un ciclo che si aggiorna: mappare, ascoltare, colmare il gap con un’alternativa valida, formare, ripetere.
Chi continua a pensare che un divieto scritto basti a chiudere il problema sta, di fatto, garantendo che ogni nuovo strumento AI che arriverà da qui in avanti restará usato senza controllo. Le sanzioni GDPR e AI Act non colpiscono chi adotta l’AI, colpiscono chi non riesce a dimostrare di sapere cosa i propri dipendenti stanno facendo con essa. Una distinzione che nessun regolamento interno, per quanto severo sulla carta, riesce a colmare da solo.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Tom’s Hardware
Source link
