Arriva la Shadow AI. Cosa succede quando vieti ChatGPT in azienda?

Bloccare l’AI in azienda non elimina il rischio ma lo sposta nello shadow AI. Serve governance, non veto: classificare i dati, scegliere strumenti enterprise, definire perimetro, monitorare e misurare per 30 giorni per adottare l’AI in modo sicuro e controllato.

Nelle ultime settimane ho avuto conversazioni molto simili con aziende diverse, in settori diversi e, indovina un po’, con dimensioni diverse. Il pattern che ho osservato è sempre lo stesso.

Il CEO, il team commerciale perfino i singoli operatori voglio usare l’AI. Anche giustamente direi, è uno strumento potentissimo, se utilizzato correttamente.

In tutto questo però il team di cybersecurity dice no, o quantomeno rallenta tutto finché non capiamo come gestirlo e di conseguenza nell’azienda si blocca l’aspetto di innovazione.

Voglio essere chiaro, il problema cyber è reale. Non sto dicendo che i team di sicurezza hanno torto nel sollevare le preoccupazioni, sto dicendo che trasformare una preoccupazione legittima in un veto permanente è una forma di rischio che nessuno sta considerando.

Il rischio del no non è neutro

Chi lavora in cybersecurity è abituato a ragionare sui rischi dell’adozione di uno strumento. È il suo mestiere ed è giusto che sia così, c’è però un bias strutturale in questo approccio in cui il rischio dell’adozione è visibile, misurabile, attribuibile; mentre il rischio della non adozione è diffuso, lento, e di solito ricade su qualcun altro.

Bloccando l’uso di strumenti AI aziendali non stai eliminando il rischio, lo stai semplicemente spostando.
I tuoi colleghi non smetteranno di usare l’AI perché il CISO ha mandato una policy da seguire, se ne fregano, aprono ChatGPT o Claude con l’account personale, incollano documenti aziendali, contratti, email sensibili, dati di clienti. Il tutto senza controllo, log e soprattutto senza governance. Tutto ciò ha un nome, shadow IT che applicato al mondo AI diventa shadow AI.

Così facendo il dipartimento cyber ha trasformato la sua incertezza in un problema operativo dell’intera azienda, e lo ha fatto senza contabilizzare il costo di questa scelta.

Il vero problema da affrontare.

Dirlo chiaramente mi costa qualcosa perché vengo da quel mondo, ma è necessario. Il punto è che non è che non sanno come bloccare l’AI, non sanno come strutturare il framework per governarla.

Il team cyber che dice “non siamo pronti” di solito non intende che l’AI è pericolosa, intende che non sa ancora come strutturare le policy di utilizzo, come classificare i dati che possono entrare in un modello LLM, come auditare gli output, come gestire la data residency, come integrare i controlli DLP con questi nuovi strumenti.
Queste sono domande legittime, ma la risposta a domande legittime non deve essere il blocco totale, piuttosto la sperimentazione controllata.

Se non sei mai entrato in contatto con uno strumento, non puoi costruire un framework per governarlo. È praticametne un circolo vizioso, non lo uso perché non so come gestirlo, non so come gestirlo perché non lo uso.

Come costruire un MVP di utilizzo AI in sicurezza

Un MVP in questo contesto deve avere un perimetro definito, con strumenti scelti, su un use case reale e con governance minima ma reale.
Ti condivido un framework che uso per costruire MVP di questo tipo.

Step 1. Classifica i dati.

Come sempre il primo passo è capire il perimetro in cui devi operare. In questo caso è importante definire una semplice matrice con quattro livelli:

• Pubblico Dati già accessibili fuori dall’azienda o che potresti rendere pubblici senza nessun problema. Alcuni esempi, testi del sito web, comunicati stampa, job posting, contenuti LinkedIn, brochure prodotto, FAQ di supporto, prezzi di listino pubblici.
  Questi per loro natura non devono avere restrizioni. Puoi usare qualsiasi strumento, idealmente anche con account free, perché il dato è già pubblico per definizione.
• Interno Dati operativi che circolano dentro l’azienda ma non creano danno reale se escono. La maggior parte delle comunicazioni quotidiane rientra qui. Alcuni esempi, email interne su organizzazione e logistica, documentazione tecnica interni, organigrammi, bozze di comunicati non ancora pubblicati.
  Questi possono essere dati all’AI se approvati con DPA firmato, ovviamente NON vanno caricati su account personali o tool free. Attenzione, questo è il livello più sottovalutato perchè le persone tendono a classificare come Interno cose che sono già Confidenziali.
  Ogni volta che un documento contiene il nome di un cliente, un numero di contratto, o dati economici anche parziali, passa a livello confidenziale.
• Confidenziale Dati che, se uscissero, creerebbero un danno economico, reputazionale o competitivo concreto. Alcuni esempi, contratti attivi con clienti e fornitori, offerte commerciali e preventivi, dati finanziari interni, informazioni su clienti e loro esigenze, roadmap di prodotto, dati di accesso a sistemi (non credenziali, ma configurazioni e architetture).
  Possono essere forniti all’AI solamente su strumenti con DPA firmato, data residency verificata (EU se operi in ambito GDPR), e con la certezza che i dati non vengano usati per il training del modello.
• Ristretto Dati la cui fuoriuscita ha conseguenze legali dirette o danni irreversibili, va da se che questa categoria non è negoziabile. Alcuni esempi, dati personali sensibili ai sensi dell’art. 9 GDPR (salute, orientamento politico o religioso, dati biometrici), credenziali e segreti di autenticazione, dati coperti da NDA con clausole stringenti, informazioni su vulnerabilità non ancora patchate, dati coperti da segreto industriale con valore economico diretto.
  Questi dati non devono entrare in nessun LLM cloud, nemmeno enterprise con DPA firmato. L’unica eccezione tecnicamente, a mio avviso, praticabile è un modello open source in esecuzione su infrastruttura on-premise interamente controllata dall’azienda, dove nessun dato esce dal perimetro e nessun provider terzo interviene nel processing.
  Ma “on-prem” non significa automaticamente “sicuro”. Infatti il server di inferenza diventa un asset critico che richiede hardening dedicato, i log dell’inferenza contengono i dati in chiaro e vanno trattati con le stesse restrizioni dei dati sorgente, e l’integrità dei pesi del modello deve essere verificata.

Step 1. Classifica i dati.

Come sempre il primo passo è capire il perimetro in cui devi operare. In questo caso è importante definire una semplice matrice con quattro livelli:

• Pubblico Dati già accessibili fuori dall’azienda o che potresti rendere pubblici senza nessun problema. Alcuni esempi, testi del sito web, comunicati stampa, job posting, contenuti LinkedIn, brochure prodotto, FAQ di supporto, prezzi di listino pubblici.
  Questi per loro natura non devono avere restrizioni. Puoi usare qualsiasi strumento, idealmente anche con account free, perché il dato è già pubblico per definizione.
• Interno Dati operativi che circolano dentro l’azienda ma non creano danno reale se escono. La maggior parte delle comunicazioni quotidiane rientra qui. Alcuni esempi, email interne su organizzazione e logistica, documentazione tecnica interni, organigrammi, bozze di comunicati non ancora pubblicati.
  Questi possono essere dati all’AI se approvati con DPA firmato, ovviamente NON vanno caricati su account personali o tool free. Attenzione, questo è il livello più sottovalutato perchè le persone tendono a classificare come Interno cose che sono già Confidenziali.
  Ogni volta che un documento contiene il nome di un cliente, un numero di contratto, o dati economici anche parziali, passa a livello confidenziale.
• Confidenziale Dati che, se uscissero, creerebbero un danno economico, reputazionale o competitivo concreto. Alcuni esempi, contratti attivi con clienti e fornitori, offerte commerciali e preventivi, dati finanziari interni, informazioni su clienti e loro esigenze, roadmap di prodotto, dati di accesso a sistemi (non credenziali, ma configurazioni e architetture).
  Possono essere forniti all’AI solamente su strumenti con DPA firmato, data residency verificata (EU se operi in ambito GDPR), e con la certezza che i dati non vengano usati per il training del modello.
• Ristretto Dati la cui fuoriuscita ha conseguenze legali dirette o danni irreversibili, va da se che questa categoria non è negoziabile. Alcuni esempi, dati personali sensibili ai sensi dell’art. 9 GDPR (salute, orientamento politico o religioso, dati biometrici), credenziali e segreti di autenticazione, dati coperti da NDA con clausole stringenti, informazioni su vulnerabilità non ancora patchate, dati coperti da segreto industriale con valore economico diretto.
  Questi dati non devono entrare in nessun LLM cloud, nemmeno enterprise con DPA firmato. L’unica eccezione tecnicamente, a mio avviso, praticabile è un modello open source in esecuzione su infrastruttura on-premise interamente controllata dall’azienda, dove nessun dato esce dal perimetro e nessun provider terzo interviene nel processing.
  Ma “on-prem” non significa automaticamente “sicuro”. Infatti il server di inferenza diventa un asset critico che richiede hardening dedicato, i log dell’inferenza contengono i dati in chiaro e vanno trattati con le stesse restrizioni dei dati sorgente, e l’integrità dei pesi del modello deve essere verificata.

Step 2. Scegli tu lo strumento.

La scelta dello strumento non è solo una decisione tecnica, ma anche una decisione contrattuale e di perimetro. Due strumenti con funzionalità identiche possono avere profili di rischio completamente diversi in base a come trattano i tuoi dati.

La prime cosa da verificare, ancora prima delle funzionalità, sono:

• Il provider mette a disposizione un Data Processing Agreement?
• I tuoi dati vengono usati per il training del modello?
• Dove vengono processati fisicamente? Se operi in Europa con dati GDPR, la risposta deve essere EU, senza eccezioni.

Se un vendor non risponde chiaramente a tutte e tre, la soluzione è cambiare strumento.
Quelli che passano questo filtro e hanno un profilo enterprise verificabile oggi sono:

• Microsoft 365 Copilot. Se hai già un tenant M365 attivo, è il punto di partenza più naturale. L’elaborazione rimane dentro il tuo perimetro Azure, i dati non escono per il training, hai log di audit nativi in Purview e il controllo degli accessi si gestisce con gli stessi strumenti che usi già.
  Il limite reale per le PMI è il costo dato che la licenza Copilot si aggiunge alle licenze M365 esistenti e il prezzo per utente è significativo. Ha senso valutarlo se disponi già M365 Business Premium o E3/E5, non come primo acquisto standalone.
• Claude for Teams o Enterprise. Anthropic ha un DPA disponibile, nessun uso dei dati per il training e supporta l’SSO. È lo strumento con il miglior rapporto qualità/flessibilità per chi non è dentro l’ecosistema Microsoft, o per chi vuole uno strumento AI dedicato senza legarlo all’infrastruttura di produttività esistente.
• ChatGPT Team o Enterprise, Garanzie equivalenti a quelle di Anthropic sulla carta. Hanno un DPA firmabile, ti permettono di fare opt-out dal training, data residency US o EU a seconda del piano scelto.
• Gemini for Google Workspace. Se sei già su Google Workspace, il profilo di rischio è comparabile a Copilot su M365, con la stessa logica di perimetro. La governance si gestisce dalla Google Admin Console che già conosci.

Cosa escludere per default nella fase MVP, indipendentemente dalla qualità dello strumento:

• account free su qualsiasi piattaforma,
• tool che nelle condizioni di utilizzo prevedono l’uso dei dati per il training del modello,
• qualsiasi strumento che non ha un DPA firmabile o che non specifica esplicitamente la data residency.

La scelta di questo strumento non è una decisione delegata solo al team IT o di security, richiede il coinvolgimento del DPO o del responsabile della compliance perché la firma del DPA ha implicazioni legali che vanno oltre la configurazione tecnica.

Step 3. Definisci il perimetro.

Il perimetro deve rappresentare la risposta a tre domande concrete a cui devi poter rispondere in maniera precisa e semplice.

• Chi. Non scegliere il gruppo pilota per entusiasmo, sceglilo per utilità.
  Il team più entusiasta dell’AI non è necessariamente quello in cui il ROI è più alto o dove il rischio è più controllabile. Il gruppo pilota ideale è quello che ha un use case specifico e ripetuto, dove puoi misurare il prima e il dopo, e dove le persone sono abbastanza responsabili da segnalare se qualcosa non funziona come previsto. Dalle 5 alle 10 persone sono più che sufficienti, se il gruppo fosse più numeroso rischia di diventare solamente più rumore nella fase di misurazione.
  Un approccio che funziona bene è iniziare con il team che già usa l’AI in modo non governato. Hai meno resistenza, più motivazione, e un ROI più immediato.
• Su cosa. Potrei darlo per scontato ma meglio specificarlo, fai questo test su device aziendali gestiti, con EDR attivo e policy di DLP già configurata. Tutta la governance che hai costruito negli step precedenti funziona solo se hai visibilità su cosa succede sui device. Se parte del team lavora su device personali, risolvilo prima di partire
• Con quali dati. Nelle prime quattro settimane permetti l’utilizzo solamente di dati di livello Pubblico e Interno. Questa limitazione ha due funzioni:
  • la prima è contenere il rischio mentre il team impara a usare lo strumento e tu impari a monitorarlo.
  • la seconda è darti dati puliti, se nella fase uno non hai nessun alert rilevante, hai una baseline da cui partire quando allarghi ai dati Confidenziali nella fase due.
    Se hai alert già nella fase uno, hai un problema da risolvere prima di salire di livello.

Step 4. Configura regole di monitoring che ti danno visibilità reale.

Questo non richiede assolutamente una nuova infrastruttura, richiede che tu usi quello che probabilmente hai già configurato per rispondere a queste tre domande:

Chi accede a cosa.
Ogni piattaforma enterprise ha un activity log, quello che ti serve è sapere chi ha usato lo strumento AI approvato, quando, e su quali contenuti.
Su M365 è Purview Activity Explorer, su Google Workspace è l’Admin Audit Log, su qualsiasi altro stack è il log nativo della piattaforma o del tuo SIEM se ne hai uno. Non devi guardare questi log in real time, ma deve aiutarti a capise se qualcuno ha usato lo strumento su contenuti fuori dal perimetro dati definito, se ci sono picchi anomali di attività, se qualcuno ha ripetutamente ignorato un avviso.
Una volta che hai verificato che questi casi non si sono presentati per quattro settimane consecutive, puoi essere abbastanza sicuro che il perimetro regge ed estendere l’utilizzo anche a dati confidenziali.

Cosa esce dal perimetro.
Le DLP policy ti avvisano o bloccano quando un contenuto classificato viene spostato fuori dall’applicazione approvata, copiato negli appunti, caricato su un sito esterno.
Configurale prima in modalità avviso, non in modalità blocco, perchè nella prima fase è difficile che tu sappia sai qual è il volume reale degli eventi, un blocco aggressivo su falsi positivi crea attrito inutile nel gruppo pilota e ti porta a smontare le policy invece di affinarle.
Dopo un periodo di 30 giorni puoi direi di avere i dati per decidere cosa bloccare davvero.

Chi usa strumenti non approvati.
Se il tuo firewall o il tuo EDR ha l’URL filtering attivo, usalo per vedere quali domini AI vengono raggiunti dai device aziendali. Nella maggior parte dei casi, quando le aziende guardano questi dati per la prima volta, scoprondo che il problema dello shadow AI è già presente e diffuso. Quel numero non è un problema da punire, è il punto di partenza reale del tuo MVP.
Ti dice dove c’è domanda reale e chi la sta soddisfacendo da solo.

Step 5. Misura i risultati dopo 30 giorni.

Dopo 30 giorni dovresti avere dati sufficienti per capire se il perimetro regge e se l’adozione controllata sta producendo valore reale. Idealmente ti bastano quattro metriche per trarre delle conclusioni sensate.

Ore risparmiate dal gruppo pilota sulle attività target.
Prima di partire con l’MVP, chiedi al gruppo pilota di stimare in linea di massima quanto tempo dedicano ogni settimana alle attività specifiche su cui useranno l’AI. Dopo 30 giorni, fai la stessa domanda e valuta il delta di differenza tra le due stime, questo è il tuo indicatore principale di valore. Non è di certo un dato scientifico, ma è sufficiente per decidere se allargare il perimetro o ricalibrare.

Alert DLP scattati e motivazione.
Ogni alert che sorge è una domanda alla quale dare una risposta. La domanda che mi fatto spesso è l’utente stava cercando di fare qualcosa di inappropriato, o la policy è troppo restrittiva e sta generando falsi positivi? entrambe le risposte sono utili per affinare il sistema.

Utenti fuori dal perimetro che usavano AI non approvata.
Questo dato viene dagli stessi log URL filtering che hai configurato in Step 4, non da sondaggi o dichiarazioni. Se dopo 30 giorni di MVP il numero di utenti che accedono a tool AI non approvati è calato, il perimetro funziona. Al contrario, se è rimasto uguale o addirittura è cresciuto, hai un problema di comunicazione o di adozione che va risolto prima di allargare il perimetro.

Zero incidenti di sicurezza legati all’AI nel perimetro definito.
Non è un risultato scontato, ma è la baseline minima per procedere. Se in 30 giorni non hai avuto nessun dato sensibile fuori dal perimetro, nessun account compromesso, nessun alert critico non gestito, hai dimostrato che il perimetro è sostenibile.

Con questi quattro numeri hai i dati per decidere cosa fare dopo, allargare il perimetro, aggiungere use case, correggere qualcosa, o fermarti. Senza di questi, non hai ancora fatto niente di diverso da chi blocca tutto perché non sa come misurarlo.

Il tuo prossimo passo

Come hai potuto leggere l’approccio di per sé non è complicato, richiede solo un po’ di consapevolezza e volontà di agire.

In questo articolo ti ho condiviso il framework che attualmente uso quando lavoro con aziende che vogliono adottare l’AI senza perdere il controllo sul rischio. Sia chiaro, non è l’unico approccio possibile, e probabilmente non è perfetto per il tuo contesto specifico, per questo l’importante non è che tu lo segua alla lettera, ma che che inizi a interagire con la tecnologia invece di aspettare che il contesto sia pronto.
Nella maggior parte dei casi il problema non è tanto la complessità tecnica, è proprio il punto di partenza. Non complicare troppo le cose dentro la tua testa, inizia e da lì poi vai ad affinare il tutto, meglio governare questo rischio in modo imperfetto che non governarlo affatto.

Michele Franceschet

Appassionato di cybersecurity fin da adolescente, ho trasformato l’interesse per l’offensiva in una specializzazione nella difesa. Ho fondato Centurio per offrire servizi MDR e NOC vendor-agnostic alle PMI, opero come CTO per startup e svolgo ricerca, formazione e divulgazione su sicurezza informatica e AI.

Aree di competenza: Ho iniziato ad entrare nel mondo della cybersecurity già a 15 anni, capendo come funzionavano i sistemi per poi bucarli, come ci si potrebbe aspettare da un ragazzo di quell'etá e con molto tempo libero. Ad un certo punto ho realizzato che si poteva fare il contrario, e che questo mi interessava di più. Non mi concentravo più sull'exploit, ma sul capire perché esiste e come togliergli spazio. La parte difensiva, lo studio delle architetture, l'implementazione è quello che mi piace davvero di questo settore. Centurio nasce da una rottura precisa. Ho visto troppo spesso aziende vendere soluzioni cybersecurity calibrate sul proprio catalogo e sul proprio margine, non sul rischio reale del cliente. L'ignoranza tecnica del mercato PMI viene usata come leva commerciale, non come problema da risolvere. Ho fondato Centurio per stare dall'altra parte: tecnologia come mezzo, servizio come obiettivo. Oggi eroga servizi MDR e NOC a PMI prevalentemente manifatturiere, con un modello vendor-agnostic in cui siamo noi a prenderci la responsabilità di scegliere la soluzione giusta, e a cambiarla se non performa. Parallelamente opero come CTO in alcune startup in fase di lancio o scale-up. Il mio ruolo è mantenere alta la qualità tecnica nelle fasi in cui la pressione sulla velocità tende a erodere gli standard. È un lavoro diverso da Centurio ma complementare, perché mi costringe a ragionare su architetture e decisioni tecniche in contesti con vincoli diversi. Sul fronte della ricerca, mi occupo di email security applicata, in particolare sull'adozione reale di DMARC, SPF e DKIM nel tessuto imprenditoriale italiano. I numeri che emergono raccontano un livello di esposizione sottovalutato, e credo valga la pena parlarne con più chiarezza di quanto si faccia normalmente. Faccio anche formazione su cybersecurity e AI per aziende, con l'obiettivo di trasformare la consapevolezza sul rischio in scelte tecniche concrete. Il problema della cybersecurity nelle PMI non è tecnologico, è di incentivi. Chi vende sicurezza ha spesso interesse a vendere prodotti, non a ridurre il rischio. Scrivo e comunico per contribuire alla cultura tecnica del settore con contenuti che partono da casi reali.