Shadow AI è la versione generativa dello shadow IT: dipendenti o team che usano strumenti, modelli o plugin AI mai approvati dalla sicurezza, senza che l'azienda abbia visibilità su cosa passa attraverso di loro. Ogni report sul tema descrive la stessa direzione: qualcosa di sensibile che esce dall'azienda attraverso uno strumento non controllato. Per una software house quel rischio è reale. Non è quello che costa di più fra sei mesi.
Cosa intendono i vendor di sicurezza per shadow AI?
Cerca il termine oggi e l'impostazione è quasi sempre la stessa: IBM, Palo Alto Networks, Zscaler, Check Point, Orca Security, Vanta e la Cloud Security Alliance descrivono tutti lo stesso scenario, un dipendente che incolla una lista clienti, un contratto o del codice sorgente dentro un chatbot pubblico che l'azienda non ha mai approvato, senza nessun log di cosa sia uscito e dove sia finito. Il PagerDuty Shadow AI Survey, pubblicato l'11 giugno 2026 da Wakefield Research, ci mette un numero: due terzi dei professionisti d'ufficio in aziende con almeno 500 milioni di dollari di fatturato dichiara di aver usato uno strumento AI al lavoro che credeva non fosse approvato, e l'88% ha condiviso informazioni di lavoro con uno strumento AI pubblico. Il sondaggio ha coperto ruoli di marketing, finanza e operations. Ha escluso esplicitamente IT e ruoli tecnici, quindi non ha misurato nulla di quello che fa uno sviluppatore con un agente di coding.
L'altra direzione: il codice che entra invece dei dati che escono
Rovescia la direzione e il vuoto di quel sondaggio diventa il punto centrale: gli sviluppatori non sono stati esclusi per caso, sono stati esclusi perché non sono mai stati "shadow" in primo luogo. Usano strumenti AI di coding apertamente, spesso con il via libera dell'azienda. Il report Checkmarx Future of AppSec in the Era of AI, pubblicato il 14 agosto 2025 su oltre 1.500 fra CISO, responsabili AppSec e sviluppatori in Nord America, Europa e Asia-Pacifico, ha trovato che il 34% delle organizzazioni dichiara che oltre il 60% del proprio codice è ormai generato da AI, mentre solo il 18% ha una policy che governa come questo avviene, e il 20% vieta ufficialmente gli assistenti AI di coding comunque. Autorizzato o no, il codice continua ad arrivare. Una policy costruita per fermare informazioni che escono attraverso un canale non approvato non ha niente da dire su una modifica che è entrata nel prodotto attraverso un canale approvato, senza nessuna traccia di quale sessione l'abbia prodotta o chi l'abbia firmata.
| Dati che escono (quello che si misura) | Codice che entra (quello che non si misura) | |
|---|---|---|
| Cosa attraversa il confine | Dati aziendali incollati in uno strumento esterno | Codice scritto da AI che finisce nel prodotto |
| Chi se ne accorge per primo | La sicurezza, di solito dopo un incidente | Nessuno, finché qualcuno non chiede perché una modifica è fatta così |
| Cosa esiste già per intercettarlo | DLP, isolamento del browser, liste di modelli consentiti | Strumenti di review che controllano il diff, non la sua origine |
| Costo se ignorato | Violazione di dati, proprietà intellettuale persa | Logica non revisionata in produzione, nessuna traccia di chi l'ha approvata |
Perché vietare gli strumenti non funziona in un'organizzazione di delivery?
Vietare gli strumenti AI di coding è la soluzione che il 20% delle organizzazioni nel sondaggio Checkmarx ha già provato, senza nessun segnale che cambi cosa finisce nel codebase. Un divieto funziona solo se è applicabile, e un assistente che gira dentro un editor, un terminale o una CLI lascia molte meno tracce di una scheda del browser che un proxy web può bloccare. La maggior parte di questi strumenti gira anche in locale o tramite una CLI che non tocca mai il percorso di rete aziendale che uno strumento DLP è costruito per sorvegliare, quindi il controllo che intercetta una lista clienti incollata non ha niente da ispezionare quando lo stesso rischio si presenta come una funzione generata.
Il risultato pratico somiglia al vibe coding sotto una scadenza cliente: il codice arriva in fretta perché arrivare in fretta è il lavoro, e se una persona l'ha rivisto, o quale agente l'ha scritto con quale autorizzazione, smette di essere qualcosa a cui chiunque può rispondere dopo il fatto. Una regola che nessuno può verificare non è un controllo. È una riga in un documento che peggiora un audit invece di migliorarlo, perché ora c'è una policy a verbale che l'organizzazione non sta davvero rispettando, sopra il vuoto originale che avrebbe dovuto chiudere.
Cosa puoi davvero imporre al posto di un divieto?
Tre cose sono applicabili dove un divieto non lo è, perché nessuna delle tre dipende dal notare una scheda del browser prima che il codice esista già:
- Dichiarazione: ogni modifica unita allo stato principale dichiara quale agente o assistente l'ha toccata, anche quando la risposta è "nessuno".
- Verifica: qualcosa di diverso dallo stesso modello che corregge i propri compiti, una suite di test, una build, uno strumento che controlla il diff, conferma che il codice fa quello che dichiara prima che parta.
- Registrazione: la dichiarazione e il risultato della verifica vengono conservati da qualche parte che sopravvive alla persona, o alla sessione, che li ha prodotti.
Niente di tutto questo richiede di conoscere ogni strumento che un dipendente potrebbe aprire in un pomeriggio qualunque. Richiede di sapere cosa è cambiato, nell'unico punto per cui ogni modifica deve comunque passare: il merge.
Una policy breve che non rallenta il team
Niente di quanto sopra richiede a un team di sicurezza di riscrivere come lavorano gli sviluppatori. Richiede di agganciare i tre passaggi appena visti al punto della pipeline per cui ogni modifica passa già, invece di una lista di strumenti vietati che nessuno può far rispettare fino in fondo. Lo stesso vuoto si ripresenta su cosa viene dichiarato dentro una build generata da AI: il meccanismo per mostrare cosa c'è in una release e chi l'ha approvata esiste già, è solo raramente puntato sulla domanda che una policy di shadow AI non è mai stata costruita per rispondere. Detent, l'impianto di delivery end-to-end (detent-ai.com), lega quella dichiarazione, verifica e firma registrata a ogni modifica sulla linea, dalla richiesta alla produzione, così "ha scritto questo un agente non autorizzato" ha una risposta che non dipende dal chiedere in giro.