L'adozione indotta dell'AI
Nel 2026, il 68% delle organizzazioni che ospitano modelli AI su ambienti proprietari lo fa almeno in parte attraverso software acquistato per altre finalità: il modello è arrivato in azienda come componente di un'applicazione di terze parti, senza che nessun responsabile tecnico lo abbia mai valutato come applicazione AI. Wiz, la società di sicurezza cloud, ha misurato questo fenomeno direttamente dagli ambienti di produzione di centinaia di migliaia di organizzazioni clienti, non da survey autodichiarate. Va evidenziato che il campione è composto da aziende abbastanza mature da aver già adottato una piattaforma cloud security enterprise, il che significa che probabilmente sovrastima la diffusione del fenomeno all'effettiva situazione del mercato. Il dato descrive la frontiera, non la media. Tuttavia ciò che succede alla frontiera oggi tende ad arrivare al mercato generalista nel giro di qualche anno ed è per questo che vale la pena analizzare il fenomeno adesso.
La Shadow AI, cioè l'utilizzo non autorizzato di strumenti AI all'interno di un'organizzazione, è un tema dibattuto e piuttosto noto nel mondo AI. Io stesso ne ho parlato qui. È un problema comportamentale e si gestisce con formazione, policy d'uso e blocco selettivo degli accessi. L'"AI transitiva" è un'altra cosa. Arriva in azienda dopo la firma di un contratto enterprise. Nessun dipendente ha aggirato le policy aziendali, più semplicemente qualcuno ha rinnovato una licenza software, che ora — nella nuova versione — include modelli AI attivi.
Immaginiamo che Salesforce aggiorni la propria piattaforma e Einstein, il layer AI, diventi incluso di default nelle licenze enterprise esistenti, oppure che Microsoft 365 integri automaticamente Copilot in Word, Outlook e Teams. In questi casi l'azienda non ha preso una decisione esplicita di adottare l'AI; ha rinnovato abbonamenti e aggiornato software, così come ha sempre fatto.
Il problema non è solo che questi modelli girano e che nessuno sa esattamente cosa fanno. L'elemento più preoccupante è che i dati che passano attraverso Einstein o Copilot possono includere informazioni commerciali sensibili, pipeline di vendita, comunicazioni interne e codice proprietario. Il vendor ha clausole contrattuali che regolano questo, ma quelle clausole raramente emergono nel processo di rinnovo, e ancor più raramente qualcuno in azienda le ha lette nell'ottica dell'AI governance. L'azienda si trova davanti a una domanda senza risposta: quali modelli stanno girando sui nostri dati in questo momento, e chi può averci accesso? Non stiamo parlando di scenari meramente ipotetici: a gennaio 2026 è emerso che Microsoft 365 Copilot riassumeva email classificate come confidenziali, aggirando i filtri delle policy di protezione dei dati aziendali.
L'ottanta per cento delle organizzazioni analizzate da Wiz ha già adottato server MCP, il protocollo che permette agli agenti AI di connettersi a sistemi e dati esterni. Dà l'idea di quanto rapidamente si sta costruendo uno strato di connessione tra componenti AI. Ogni nuova integrazione MCP estende esponenzialmente la superficie transitiva: un agente che entra attraverso una licenza software può, se il protocollo lo consente, connettersi a sistemi che non erano nel perimetro della scelta originale. La superficie non è solo più ampia, è dinamica e difficile da tracciare in modo statico.
Secondo IBM (Cost of Data Breach Report 2025) il costo di un incidente legato alla Shadow AI è in media pari a 4,63 milioni di dollari, ovvero 670.000 dollari in più rispetto agli incidenti standard. Il differenziale dipende dai tempi di rilevamento più lunghi e dall'impossibilità di tracciare cosa è stato condiviso. Il problema non può essere risolto con l'adozione di policy di utilizzo degli strumenti, che per definizione arrivano dopo la decisione di adozione. Il rischio si genera a livello di procurement e nella fase di valutazione delle clausole contrattuali che regolano le conseguenze della condivisione di dati confidenziali attraverso flussi di lavoro basati su AI. È un aggiornamento del concetto di vendor due diligence, che richiede che la funzione legale e quella di sicurezza entrino nel ciclo di rinnovo dei contratti software con una checklist diversa da quella che hanno usato fino ad oggi.