Vai al contenuto principale
Aziende2026-06-0210 min read

Shadow AI in Azienda: Rischi Legali, GDPR e Come Costruire una Governance

La Shadow AI colpisce il 98% delle aziende europee: dipendenti che usano strumenti IA non autorizzati espongono l'organizzazione a violazioni GDPR, perdita di proprietà intellettuale e sanzioni AI Act. Guida alla governance.

Avv. Antonino Ingoglia

Ordine degli Avvocati di Sciacca n. 747 · Avvocato & Sviluppatore · IT Law

Cos'è la Shadow AI e perché rappresenta un rischio legale per l'azienda?

La Shadow AI è l'uso di sistemi di intelligenza artificiale da parte dei dipendenti al di fuori di qualsiasi autorizzazione, supervisione o policy aziendale. A differenza della Shadow IT tradizionale, il rischio è amplificato perché i dati immessi nei prompt di LLM pubblici possono essere usati per addestrare i modelli: l'azienda perde il controllo su informazioni riservate, dati personali e proprietà intellettuale. Il 98% delle organizzazioni europee conta dipendenti che usano strumenti AI non approvati dall'IT. Questa condizione configura potenziali violazioni dirette del GDPR e dell'AI Act europeo.

Fonti: Netskope Threat Labs Report 2025/2026 · MIT State of AI in Business 2025 · Reg. UE 2016/679 (GDPR) artt. 5, 13, 28 · Reg. UE 2024/1689 (AI Act) art. 4 · EDPB — ChatGPT Task Force Opinion

Il termine "Shadow AI" descrive una condizione organizzativa endemica: i lavoratori, in assenza di strumenti approvati e formati, si rivolgono autonomamente a piattaforme AI consumer per svolgere le proprie mansioni. Questa dinamica è intrinsecamente diversa dall'installazione di software non autorizzato (Shadow IT tradizionale): nei LLM pubblici, il dato inserito può essere trattenuto, elaborato e potenzialmente riutilizzato per l'addestramento del modello, sfuggendo definitivamente al controllo dell'azienda. Per il quadro normativo integrato in cui si inscrive il problema, si veda la guida alla AI Policy aziendale: GDPR, AI Act e roadmap in 4 fasi.


Perché la Shadow AI è diversa dalla Shadow IT tradizionale

Il dato inserito in un LLM smette di essere sotto il controllo aziendale

In un'applicazione SaaS tradizionale non autorizzata, il rischio principale è l'accesso non controllato a una funzionalità o la mancanza di un contratto di manutenzione. Il dato resta in un database segregato. In un LLM consumer aperto al pubblico, il dato inserito tramite prompt può essere memorizzato e incorporato nei pesi neurali del modello durante le successive sessioni di addestramento: il segreto commerciale, la lista clienti, il codice sorgente inseriti in un prompt per "velocizzare il lavoro" diventano parte del patrimonio del fornitore esterno e possono riemergere nelle risposte generate per altri utenti, anche concorrenti.

Secondo il Netskope Threat Labs Report 2025/2026, l'89% degli utenti interagisce con applicazioni AI che usano i dati immessi per addestrare i propri modelli. Il 59% degli incidenti di esposizione dati tramite AI coinvolge informazioni strettamente regolamentate dal GDPR. Il 15% del codice sorgente aziendale viene incollato in LLM pubblici per attività di debugging.

L'effetto perverso dei divieti formali

Circa un'organizzazione su quattro ha risposto all'avvento della Shadow AI vietandone formalmente l'uso sui dispositivi aziendali. Il risultato è stato paradossale: il divieto ha spostato l'adozione verso i dispositivi personali dei dipendenti, fuori da qualsiasi perimetro di visibilità dell'IT. La ricerca MIT "State of AI in Business 2025" documenta che solo il 40% delle aziende ha acquistato abbonamenti LLM ufficiali, ma i lavoratori del 90% delle aziende intervistate dichiarano di usare strumenti AI personali per le proprie attività lavorative. Il divieto non elimina il rischio: lo rende invisibile.


I profili di rischio legale della Shadow AI

Violazione del GDPR: tre scenari critici

Assenza di base giuridica per il trattamento. Quando un dipendente inserisce dati personali di clienti, candidati o colleghi in un LLM pubblico senza DPA, l'azienda sta de facto trasferendo dati a un Responsabile del Trattamento non contrattualizzato. Questo viola l'art. 28 GDPR, che impone la formalizzazione scritta di ogni rapporto di trattamento esterno. Non è necessario un data breach per incorrere in sanzioni: la sola mancanza del contratto è già una violazione documentabile.

Trasferimento di dati verso Paesi terzi. Molti LLM consumer operano su infrastrutture cloud extra-UE (spesso USA). In assenza di adeguate garanzie (Decisione di adeguatezza, Clausole Contrattuali Standard), il trasferimento di dati personali verso queste piattaforme viola il Capo V del GDPR. La difficoltà di tracciare dove fisicamente risiedono i dati rende la conformità quasi impossibile da dimostrare.

Impossibilità di garantire i diritti degli interessati. Se un dato personale è stato assorbito nei pesi di un LLM durante una sessione di fine-tuning, come garantisce l'azienda il diritto all'oblio (art. 17 GDPR) o alla rettifica (art. 16 GDPR)? La risposta tecnica è che, allo stato attuale, è quasi impossibile retrocedere l'apprendimento di una rete neurale. L'unica strategia legalmente difendibile è prevenire a monte l'inserimento del dato.

Perdita di proprietà intellettuale e segreti commerciali

Il 15% del codice sorgente aziendale finisce in LLM pubblici, tipicamente per debugging o code review. Il codice proprietario inserito in una sessione non protetta da DPA può essere trattenuto e potenzialmente riutilizzato. Oltre al rischio normativo, si apre un fronte di diritto industriale: la divulgazione non autorizzata di know-how brevettabile attraverso piattaforme di terzi può compromettere la novelty richiesta per il brevetto e vanificare anni di ricerca e sviluppo.

Responsabilità per i contenuti generati

L'azienda che utilizza output di LLM in comunicazioni commerciali, contratti o report interni si assume la piena responsabilità giuridica e reputazionale del contenuto generato. Le allucinazioni (output fattualmente errati ma esposti con sicurezza linguistica) non scaricano la responsabilità sul fornitore del modello: sono un rischio operativo che l'azienda deve governare tramite processi di Human-in-the-Loop. Per gli obblighi specifici di supervisione umana, si veda la guida alla supervisione umana AI Act.


Come rilevare la Shadow AI in azienda: l'audit tecnologico

Gli strumenti di rilevamento

Il primo passo per governare la Shadow AI è renderla visibile. Il dipartimento IT deve disporre di strumenti diagnostici specifici:

Network Traffic Analysis (NTA). Analisi del traffico di rete in uscita per identificare connessioni verso endpoint di API AI (api.openai.com, claude.ai, gemini.google.com, ecc.) non incluse nell'inventario ufficiale. Consente di quantificare il volume di dati trasmessi e la frequenza di accesso per singolo dipartimento.

Cloud Access Security Broker (CASB). Soluzioni specializzate che si interpongono tra l'utente e i servizi cloud, in grado di identificare le applicazioni AI in uso (sia via browser che via API), classificarne il profilo di rischio e applicare policy di blocco o registrazione selettiva. I CASB di nuova generazione includono dizionari aggiornati di oltre 200 servizi AI categorizzati per rischio di data leakage.

Endpoint Data Loss Prevention (DLP). Agenti installati sui dispositivi aziendali che rilevano pattern di dati sensibili (numeri di carte, codici fiscali, stringhe simili a codice sorgente) prima che vengano trasmessi a destinazioni esterne non autorizzate, bloccando il trasferimento in tempo reale.

La classificazione giuridica post-audit

Una volta mappati gli strumenti in uso, il DPO avvia la classificazione legale di ciascuno secondo la tassonomia dell'AI Act (Rischio Inaccettabile, Alto, Limitato, Minimo) e il GDPR (presenza o assenza di DPA, adeguatezza del trasferimento dati). I sistemi classificati come a Rischio Inaccettabile (es. strumenti che monitorano le emozioni dei lavoratori) vengono dismessi immediatamente, indipendentemente dalla loro utilità percepita. Gli strumenti ad Alto Rischio richiedono una DPIA preventiva prima del loro utilizzo. Per la metodologia di valutazione integrata, si veda la guida alla DPIA e FRIA integrate.


La governance minima per contenere la Shadow AI

Il sistema a semaforo per i dati

La causa principale del leakage non è la malafede dei dipendenti, ma la loro incapacità di valutare la classificazione di rischio dei dati che trattano. Una AI Policy efficace deve istituire un sistema visivo intuitivo:

Rosso: divieto assoluto. Dati sanitari, biometrici, performance individuali, dati finanziari regolamentati, codice sorgente proprietario, informazioni coperte da NDA. Vietato l'inserimento in qualsiasi LLM, anche enterprise, senza esplicita autorizzazione del DPO e verifica del DPA.

Giallo: uso condizionato su piattaforme Enterprise. Dati personali ordinari (nomi, email lavorative, ruoli), documenti interni non classificati. Consentito solo su piattaforme formalmente acquistate in versione Enterprise con DPA firmato che garantisce zero-data-retention. Per le clausole essenziali che un DPA con un fornitore AI deve contenere, si veda la guida ai DPA con fornitori AI.

Verde: libero uso per finalità lavorative. Informazioni di dominio pubblico, bozze di idee generali, codice open-source generico, ricerche su trend globali. Consentito anche su piattaforme consumer, purché per finalità professionali lecite.

Il vendor management: dalla Shadow AI alla Sanctioned AI

L'unica risposta sostenibile alla Shadow AI non è il divieto, ma la sostituzione con ambienti governati (sanctioned environments). L'azienda dismette gli abbonamenti consumer rimborsati in nota spese e migra la forza lavoro verso licenze Enterprise che garantiscono contrattualmente: confinamento dei dati nel tenant aziendale, zero-data-retention (i dati non vengono usati per l'addestramento), EU data residency ove disponibile, logging degli accessi e auditabilità.

La formazione come presidio legale

L'art. 4 dell'AI Act impone un livello sufficiente di AI literacy a tutto il personale che interagisce con sistemi IA, con obbligo formativo vigente dal 2 febbraio 2025. Un dipendente che causa un data breach usando un LLM non autorizzato espone l'azienda a una colpa in vigilando totale qualora non sia stato formato. I registri di frequenza ai corsi e i quiz di verifica diventano prove documentali essenziali durante le ispezioni. Per la struttura di un programma di formazione conforme, si veda la guida all'AI Literacy ex art. 4 AI Act.


Sanzioni applicabili in caso di data breach da Shadow AI

Una violazione GDPR derivante da Shadow AI può cumulare più profili sanzionatori:

InfrazioneBase normativaMassimale sanzione
Mancanza di DPA con il fornitore AIArt. 28 GDPR10 milioni di euro o 2% del fatturato globale
Violazione principi di liceità, minimizzazione, finalitàArt. 5 GDPR20 milioni di euro o 4% del fatturato globale
Trasferimento dati extra-UE senza garanzieArtt. 44-49 GDPR20 milioni di euro o 4% del fatturato globale
Mancata AI literacy del personale (post agosto 2026)Art. 4 AI Act + Legge 132/2025Fino a 15 milioni di euro (ACN)
Uso di sistema AI a Rischio InaccettabileArt. 5 AI ActFino a 35 milioni di euro o 7% del fatturato

Le sanzioni sono cumulative: un unico incidente può attivare contemporaneamente più profili normativi, con un effetto moltiplicatore che le PMI spesso sottovalutano fatalmente.


Conclusione: la Shadow AI si governa, non si vieta

La Shadow AI è il sintomo fisiologico di un'organizzazione che non ha ancora allineato la propria infrastruttura tecnologica ai bisogni di produttività del personale. La risposta non è proibitiva, ma architettonica: fornire strumenti governati, regole chiare e formazione certificata. L'assenza di una governance documentata trasforma ogni singolo prompt di un dipendente in un'esposizione legale per la quale l'azienda porta la piena responsabilità. Il punto di partenza è sempre la AI Policy aziendale: il documento che converte il rischio incontrollato in un vantaggio competitivo governato.

Mappa la Shadow AI nella tua organizzazione

Un AI e Data Governance Assessment identifica gli strumenti non autorizzati in uso, classifica i rischi e definisce le priorità di intervento normativo.

Prenota una consulenza strategica
Condividi:
Avv. Antonino Ingoglia

Autore

Avvocato iscritto all'Ordine di Sciacca (n. 747), specializzato in diritto delle tecnologie e privacy. Prima dell'attività forense ha sviluppato applicazioni web e architetture cloud, competenza che porta nell'analisi tecnico-giuridica di prodotti digitali, SaaS e sistemi AI. Assiste aziende e startup nell'adeguamento a GDPR, AI Act, NIS2 e DORA.

Profilo completo e competenze
Nota Informativa: I contenuti di questo articolo hanno finalità puramente divulgative e informative. Non costituiscono parere legale né instaurano un rapporto professionale. Ogni caso concreto richiede una valutazione specifica da parte di un professionista abilitato per delineare l'esatto perimetro legislativo e sanzionatorio.
SUPPORTO

Serve assistenza per il tuo caso?

Prenota un colloquio in videochiamata da tutta Italia. Analizzeremo la situazione assieme e definiremo i passi operativi in totale riservatezza strategica.