Shadow AI: perché l’IA ombra è prima di tutto un problema di governance

In sintesi

• Shadow AI è l’uso di qualsiasi strumento, funzione o agente di intelligenza artificiale all’interno dell’organizzazione senza supervisione di governance, e oggi risulta coinvolto in circa una violazione di dati su cinque in ambito enterprise.
• La narrazione dominante è cybersecurity. La narrazione meno raccontata, e probabilmente più consequenziale, è di governance: non si può registrare, valutare o sottoporre ad audit ciò che non si vede.
• Shadow AI, AI sprawl e AI bill of materials sono tre concetti distinti che vengono spesso confusi. Tenerli separati è condizione necessaria per uno scaling credibile.
• Il regolamento UE sull'IA, la norma ISO/IEC 42001 e il NIST AI Risk Management Framework condividono un’assunzione implicita: l’organizzazione dispone di un inventario completo dei sistemi di IA in scope. Lo shadow AI invalida silenziosamente questa assunzione.
• La risposta non è il divieto (i divieti spingono l’uso ancora più in ombra) ma un programma di scoperta credibile che alimenta un unico registro dei sistemi di IA, il quale serve simultaneamente come sorgente per la registrazione Allegato VIII e come registro dei rischi ISO 42001.

Cosa significa davvero shadow AI

Shadow AI indica l’uso di uno strumento, di una capacità o di un agente di intelligenza artificiale all’interno di un’organizzazione senza la consapevolezza, l’approvazione o la supervisione di chi è responsabile della governance dell’IA: CISO, responsabile della protezione dei dati, AI Officer, responsabile compliance, o chiunque detenga questo mandato nella struttura organizzativa.

L’immagine comune è quella del dipendente che incolla un documento riservato in ChatGPT. È un caso, non l’intera categoria. Lo shadow AI si presenta in almeno tre forme, e trattarle come un problema unico produce controlli incompleti.

Strumenti GenAI consumer autonomi. Chatbot gratuiti, generatori di immagini, assistenti di codice, trascrittori di riunioni accessibili tramite browser o account personale. È la superficie classica, la più facile da rilevare con telemetria di rete.

Funzioni di IA integrate in SaaS già approvati. L’organizzazione ha autorizzato il SaaS, il fornitore ha attivato una nuova funzione di IA a contratto in corso. All’improvviso il CRM riassume le note cliente con un modello di fondazione, la suite collaborativa redige email automaticamente, lo strumento di project management suggerisce rischi. Nel verbale acquisti non risulta nessuna IA autorizzata. La realtà dice altro. IBM rileva che l’adozione enterprise di GenAI è passata dal 74 al 96 per cento tra il 2023 e il 2024, in gran parte per via di questo canale integrato (IBM Think).

Modelli, script e agenti interni. Un analista affina un modello open source sulla propria postazione. Un platform engineer collega un agente a un server Model Context Protocol con permessi estesi. Un team marketing addestra un GPT personalizzato su un corpus sensibile. Nessuno di questi traffici passa da un chatbot pubblico di terzi, quindi sfugge alla rilevazione shadow IT tradizionale, eppure produce la stessa falla di governance.

La distinzione utile rispetto allo shadow IT è di perimetro. Shadow IT copre qualsiasi asset tecnologico non sanzionato. Shadow AI è il sottoinsieme a forma di IA, e porta rischi specifici: output probabilistici, allucinazioni, dati di addestramento opachi, deriva del modello, contaminazione della catena del valore, e soprattutto un regime regolatorio dedicato (il regolamento UE sull’IA) che assegna esplicitamente responsabilità per queste caratteristiche.

È esattamente quest’ultimo elemento che sposta lo shadow AI dal registro della cybersecurity al registro della governance. La sicurezza informatica vanta due decenni di esperienza nello scovare SaaS non autorizzati. La disciplina nuova dei prossimi due decenni è governare l’IA di cui non si sapeva l’esistenza.

Shadow AI, AI sprawl, AI bill of materials: tre concetti distinti

Tre nozioni vicine vengono usate come sinonimi nei blog e nelle note degli analisti. Non sono la stessa cosa, e confonderle produce un programma di governance sfocato.

Shadow AI riguarda l’autorizzazione. Un sistema è in ombra quando nessuno con responsabilità ne ha tracciato l’esistenza. Uno strumento perfettamente approvato ma usato da un team non abilitato resta shadow AI, perché manca la pista di audit.

AI sprawl riguarda la moltiplicazione, autorizzata o meno. Un’organizzazione con 80 strumenti di IA approvati sparsi in 40 team senza un catalogo centrale soffre di sprawl, non di shadow AI in senso stretto. Lo sprawl è ciò che si verifica quando la scoperta funziona ma la consolidazione no.

AI bill of materials (AI BOM) è l’artefatto documentale, modellato lascamente sul software BOM. Per un sistema dato, la distinta lista i componenti: modello di fondazione e versione, sorgenti di dati di addestramento e fine-tuning, basi vettoriali, API di terzi invocate all’inferenza, checkpoint umani. L’AI BOM non è un problema: è un deliverable, ed è ciò che rende auditabile la rimediazione dello shadow AI.

Un programma maturo affronta tutti e tre: far emergere lo shadow AI attraverso la scoperta, ridurre lo sprawl tramite consolidazione, e produrre un AI BOM per sistema affinché il registro abbia sostanza, non solo nome e proprietario.

Perché il fenomeno esplode adesso

In un preprint del 2026, Silic e colleghi propongono di leggere lo shadow AI come fallimento di governance socio-tecnico piuttosto che come incidente di sicurezza, argomentando che la natura generativa, opaca e autonoma dell’IA crea sfide che la governance IT esistente non riesce ad assorbire (Silic et al., Preprints.org). La loro cornice coincide con quello che si osserva sul campo. Quattro forze si rinforzano a vicenda.

La consumerizzazione della GenAI. Un account OpenAI gratuito o un abbonamento a quindici euro mensili offre una capacità che due anni fa richiedeva un ciclo acquisti e una bolletta cloud. L’attrito che frenava gli strumenti non autorizzati è evaporato.

L’IA integrata nei SaaS approvati. Quando un fornitore sotto contratto attiva una funzione di IA in modalità default, il contratto non cambia, ma il flusso di dati sì. Pochi CISO dispongono della strumentazione contrattuale per sapere quando il quinto fornitore SaaS più importante ha attivato in sordina la generazione potenziata da retrieval sui dati del tenant.

Gli agenti e lo strato MCP. Server Model Context Protocol e agenti autonomi rappresentano una superficie nuova che i tradizionali secure web gateway non sono stati progettati per ispezionare. Un agente che invoca un server MCP eredita i permessi di quel server, che possono superare quelli dell’utente chiamante. Senza visibilità dedicata, il raggio d’azione di un deployment di agente è ignoto.

Il divario di velocità tra IT e business. I dipendenti ricorrono allo shadow AI per la stessa ragione per cui ricorrevano allo shadow SaaS: è più veloce della via ufficiale. Come nota una guida Splunk, vietare gli strumenti GenAI consumer senza offrire un’alternativa interna spinge soltanto l’uso più in profondità nell’ombra (Splunk).

I numeri sono inequivocabili. Gartner prevede che oltre il 40 per cento delle imprese sperimenterà un incidente di sicurezza o compliance legato allo shadow AI entro il 2030 (comunicato Gartner, novembre 2025). Il rapporto IBM Cost of a Data Breach 2025 stima il premio di costo delle violazioni legate allo shadow AI in circa 4,63 milioni di dollari contro 3,96 milioni per le violazioni standard, e rileva che solo il 37 per cento delle organizzazioni dispone di una policy per gestire o rilevare lo shadow AI (IBM Cost of a Data Breach 2025). Una violazione su cinque oggi include lo shadow AI come fattore contributivo.

La direzione è chiara. La domanda strategica è se l’organizzazione tratta la falla come un problema di sicurezza da tappare, o come una disciplina di governance da costruire.

Il rischio di governance: cosa rompe realmente lo shadow AI

Il racconto di sicurezza è intuitivo: dati sensibili escono dal perimetro, il regolatore sanziona, i clienti se ne vanno. È reale, e altri articoli lo raccontano bene. Il racconto di governance è meno raccontato e più consequenziale. Tre regimi regolatori e normativi convergono, e tutti e tre poggiano su un’unica assunzione che lo shadow AI invalida.

L’obbligo di registrazione del regolamento UE sull’IA

L’Articolo 49 del regolamento UE sull’IA esige che i fornitori di sistemi di IA ad alto rischio elencati nell’Allegato III si registrino, registrando il sistema nella banca dati pubblica dell’Unione prima dell’immissione sul mercato o della messa in servizio. I deployer che sono autorità pubbliche devono registrare anche l’uso. Il contenuto richiesto, definito nell’Allegato VIII, include identità del fornitore, denominazione e finalità del sistema, istruzioni per l’uso, certificato di valutazione di conformità, stato (sul mercato, ritirato, richiamato) e sintesi delle valutazioni di impatto (Articolo 49, Allegato VIII).

L’implicazione di enforcement per lo shadow AI è immediata. Se uno strumento usato in organizzazione, autorizzato o meno, rientra nelle categorie ad alto rischio dell’Allegato III (selezione personale, scoring creditizio, identificazione biometrica, infrastrutture critiche, istruzione, applicazione della legge, migrazione, amministrazione della giustizia), la registrazione è un obbligo di legge, non una best practice. Un sistema ombra che si rivela ad alto rischio è una registrazione mancata, esattamente il tipo di non conformità fattuale che le autorità nazionali di vigilanza del mercato perseguiranno.

Gli obblighi del deployer agli Articoli 26 e 27 aggravano l’esposizione. Il deployer deve seguire le istruzioni per l’uso del fornitore, mantenere i log, garantire la supervisione umana e, per i deployer pubblici o di settore in scope, condurre una valutazione d’impatto sui diritti fondamentali (FRIA). Il deployment ombra rompe silenziosamente tutti e quattro, perché il sistema non è mai stato nell’inventario che li avrebbe attivati.

Questa sezione è puramente descrittiva del testo giuridico. Il punto non è cosa fare al riguardo. Il punto è che lo shadow AI converte un obbligo documentale in un’inadempienza documentale, senza che nessuno se ne accorga fino all’audit.

La dichiarazione di applicabilità ISO/IEC 42001

La clausola 6 di ISO/IEC 42001 richiede che l’organizzazione identifichi i rischi e le opportunità legati all’IA, li tratti e documenti il trattamento in un registro dei rischi IA. L’Allegato A fornisce un catalogo di controlli raccomandati, e la dichiarazione di applicabilità (Statement of Applicability) dichiara quali controlli sono inclusi o esclusi, con giustificazione.

Lo shadow AI rompe questa struttura in due modi. Primo, il registro dei rischi è incompleto per costruzione: un sistema non noto non può avere un trattamento documentato. Secondo, la dichiarazione di applicabilità afferma che certi controlli si applicano a certi sistemi. Nel momento in cui un sistema ombra entra nel perimetro, queste affermazioni diventano inesatte, e le organizzazioni certificate rischiano una non conformità al riesame.

L’implicazione pratica è che una certificazione 42001 vale quanto il programma di scoperta che la sostiene. Le organizzazioni che si preparano alla certificazione scoprono spesso, dolorosamente, che il gap tra l’elenco IA autorizzate e l’impronta IA reale supera ciò che il calendario d’audit può assorbire.

La funzione MAP del NIST AI RMF

Il NIST AI Risk Management Framework 1.0 organizza le attività di IA affidabile in quattro funzioni: GOVERN, MAP, MEASURE, MANAGE. GOVERN fissa policy e responsabilità. MAP, la seconda funzione, richiede ciò che NIST chiama analisi contestuale: per ogni sistema di IA, conoscere finalità, proprietari, dati di addestramento, stato di deployment, punti di integrazione (NIST AI RMF).

Lo shadow AI mette in scacco MAP alla radice. Non si può caratterizzare il contesto di un sistema non identificato. Il NIST AI 600-1 (profilo GenAI) aggiunge un livello elencando dodici rischi specifici della GenAI (privacy dei dati, sicurezza delle informazioni, catena del valore, configurazione umano-IA, confabulazione, bias dannoso, ecc.) che richiedono tutti visibilità a livello di sistema per essere gestiti (NIST AI 600-1).

L’OWASP AI Exchange, progetto bandiera di OWASP da marzo 2025, formula lo stesso punto dal lato del catalogo di controlli: ogni minaccia e ogni controllo presuppone un asset noto. Dove l’asset è in ombra, il modello di minaccia tace per default (OWASP AI Exchange). I progetti di norme armonizzate CEN-CENELEC in corso (prEN 18228 e prEN 18282) seguono la stessa logica a livello europeo.

Tre riferimenti, una dipendenza non dichiarata: bisogna sapere quale IA si ha.

Scoprire lo shadow AI: cinque strati indispensabili

La scoperta deve essere stratificata, perché nessun segnale singolo cattura tutte le forme. I cinque strati seguenti, eseguiti in combinazione, producono una copertura difendibile.

Strato 1: telemetria di rete e SaaS. Log DNS, dati di secure web gateway, telemetria CASB ed estensioni browser rivelano traffico verso endpoint IA consumer noti. Cattura il caso classico ChatGPT-nel-browser. Non vede ciò che gira dentro un SaaS approvato o dietro un IP aziendale.

Strato 2: audit di identità. Storia delle concessioni OAuth, log SSO e schermate di consenso mostrano quali servizi IA di terze parti hanno ricevuto accesso all’identità aziendale. Cattura i servizi che si appoggiano all’identità Google Workspace o Microsoft 365. Non vede gli usi totalmente isolati.

Strato 3: audit di funzioni IA integrate nei SaaS approvati. Dialogo diretto con ciascuno dei primi venti fornitori SaaS: quali funzioni sono attive di default, quali sono opt-in, dove vanno i dati. Lavoro di pilotaggio acquisti poco glamour, ma è ciò che fa emergere la forma integrata che la telemetria non vede.

Strato 4: programmi di amnistia e indagine. Una finestra di amnistia comunicata chiaramente in cui i dipendenti dichiarano il loro uso di IA senza sanzioni. Combinata con un questionario breve e onesto, produce una scoperta qualitativa che nessuna telemetria pareggia. La condizione di successo è sicurezza psicologica, non strumento.

Strato 5: DLP consapevole di IA. Ispezione a livello di prompt nei canali approvati, alla ricerca di pattern di esfiltrazione di dati sensibili. È il focus di investimento attuale dell’industria di sicurezza e lo strato più presente nei blog dei fornitori. Necessario ma non sufficiente isolato.

Nessuna organizzazione raggiunge il cento per cento di copertura. L’obiettivo realistico è un setaccio abbastanza fine perché il residuo ignoto sia piccolo, documentato e in calo. L’errore è sovrainvestire in un solo strato e chiamarlo scoperta.

Dalla scoperta al registro dei sistemi di IA

La scoperta senza destinazione è un foglio elettronico una tantum che invecchia in un trimestre. La destinazione è un registro dei sistemi di IA centrale che ospita ogni sistema noto, in una struttura che soddisfa simultaneamente regolatori, organismi di normazione e funzione rischio interna.

Il registro deve catturare per sistema:

• Identità: nome, proprietario, sponsor di business, sponsor tecnico
• Finalità: uso previsto, usi vietati, popolazioni di utenti in scope
• Dati: classificazioni di input e output, sorgenti di addestramento e fine-tuning, basi di retrieval
• Catena fornitori: modello di fondazione e versione, fornitore di fine-tuning, ambiente di hosting, API di terzi invocate all’inferenza
• Stato del ciclo di vita: pilota, produzione, ritirato; data di messa in servizio
• Livello regolatorio: classificazione di rischio del regolamento UE, applicabilità Allegato A ISO 42001, profilo NIST AI RMF
• Rischio residuo: dopo i controlli, con il responsabile dell’accettazione nominato
• Evidenze: link a FRIA, valutazioni di conformità, model card, datasheet

La sezione AI BOM di ciascuna voce è ciò che rende il sistema auditabile. Lineage del modello, composizione dei dati di addestramento, indici di retrieval e dipendenze API a valle formano un grafo che un auditor esterno può verificare rispetto ai deployment reali.

Fatto bene, il registro è la sorgente unica che alimenta tre artefatti a valle: il pacchetto di registrazione Allegato VIII quando un sistema rientra nel regolamento UE, il registro dei rischi ISO 42001 e gli allegati della dichiarazione di applicabilità, e gli output MAP del NIST AI RMF. Costruiti in tre fogli separati, derivano l’uno dall’altro nel giro di settimane. Costruiti una volta, con lo schema giusto, danno leva di governance.

Far emergere lo shadow AI in 60 giorni

La sequenza conta, perché scoperta senza abilitazione genera risentimento e spinge lo shadow AI ancora più sottoterra.

Settimane 1-2. Annuncio della finestra di amnistia. Comunicazione centrata sull’obiettivo: abilitare l’IA, non vietarla. Costruzione dello scheletro del registro con uno schema minimo. Cattura della telemetria di baseline sui cinque strati.

Settimane 3-4. Sweep di scoperta. Combinazione di telemetria, audit identità, conversazione con fornitori SaaS e indagine d’amnistia. Sorprese attese nella categoria IA integrata.

Settimane 5-6. Triage. Esposizione regolatoria prima, criticità di business poi. Identificare i sistemi che corrispondono all’Allegato III del regolamento UE: portano obblighi di registrazione indipendentemente dalla maturità del resto del programma.

Settimane 7-8. Migrazione del triage nel registro. Per ogni sistema Tier 1, allegare l’AI BOM, la FRIA dove applicabile, la model card, la classificazione dei dati. Per i Tier inferiori, catturare identità e finalità, e rinviare la documentazione profonda allo sprint successivo.

Oltre il giorno 60, il programma diventa operativo: l’ingaggio di nuovi sistemi sostituisce la scoperta, il registro alimenta le pipeline regolatorie e di audit, e lo sprint successivo affronta lo sprawl (consolidazione, dismissione, ritiro).

La modalità di fallimento da evitare è l’over-engineering. Un registro perfetto che nessuno aggiorna vale meno di un registro grezzo che cattura l’ottanta per cento dei sistemi e viene rinfrescato trimestralmente. Partire leggero, far scorrere gli input, e lasciare che la pressione regolatoria modelli la precisione nel tempo.

Domande frequenti

Cos’è lo shadow AI in parole semplici? Lo shadow AI è l’uso di uno strumento, di una funzione o di un agente di IA nell’organizzazione di cui i responsabili della governance IA non sono al corrente. Può essere un dipendente che usa un chatbot gratuito, una funzione di IA attivata dentro un SaaS approvato, o un modello costruito internamente che gira su una postazione. Il denominatore comune è l’assenza dall’inventario, quindi l’assenza di gestione.

Shadow AI e shadow IT sono la stessa cosa? No. Shadow IT è la categoria più ampia di asset tecnologici non autorizzati. Shadow AI è il sottoinsieme a forma di IA, e porta rischi propri: output probabilistici, allucinazioni, dati di addestramento opachi, deriva del modello, e un regime regolatorio dedicato in UE. I controlli shadow IT catturano una parte dello shadow AI, ma mancano completamente le forme integrate e interne.

Quanto è grande il fenomeno nel 2026? Gartner stima che oltre il 40 per cento delle aziende sperimenterà un incidente di sicurezza o compliance legato allo shadow AI entro il 2030. Il rapporto IBM 2025 indica che circa una violazione su cinque coinvolge oggi lo shadow AI come fattore, e che queste violazioni costano in media 0,67 milioni di dollari in più di quelle standard. Solo il 37 per cento delle organizzazioni dichiara di disporre di una policy di gestione o rilevamento.

Il regolamento UE mi obbliga a inventariare lo shadow AI? Il regolamento UE non usa la parola “inventario” ma l’effetto è lo stesso. L’Articolo 49 impone la registrazione dei sistemi ad alto rischio dell’Allegato III prima dell’immissione sul mercato. Gli Articoli 26 e 27 impongono al deployer obblighi (log, supervisione, istruzioni d’uso, FRIA per i deployer in scope) che non possono essere soddisfatti senza sapere quali sistemi sono in perimetro. Un sistema ombra che risulta ad alto rischio è, in pratica, una falla di compliance in attesa di enforcement.

Come tratta ISO 42001 lo shadow AI? La clausola 6 di ISO/IEC 42001 richiede un registro dei rischi IA. L’Allegato A fornisce un catalogo di controlli, e la dichiarazione di applicabilità specifica quali si applicano a quali sistemi. Lo shadow AI rompe entrambi: il registro dei rischi è incompleto per costruzione, e la dichiarazione di applicabilità diventa inesatta nel momento in cui un sistema ombra entra in perimetro. È per questo che gli audit di certificazione iniziano spesso con un esercizio di scoperta piuttosto che con una revisione dei controlli.

Differenza tra shadow AI e AI sprawl? Shadow AI riguarda l’autorizzazione: un sistema è in ombra quando la governance non lo vede. AI sprawl riguarda la moltiplicazione: molti sistemi di IA, autorizzati o meno, che si diffondono senza catalogo centrale. Si può avere sprawl senza ombra (tutto è tracciato, ma sono ottanta) e ombra senza sprawl (due strumenti non autorizzati, ampiamente usati). Un programma maturo affronta entrambi, e l’AI BOM per sistema è il deliverable che fa da ponte.

Cosa deve contenere un registro IA, al minimo? Al minimo: identità del sistema e proprietario, finalità e utenti in scope, classificazioni dei dati, modello di fondazione e versione, API di terzi all’inferenza, stato del ciclo di vita, livello regolatorio, rischio residuo dopo controlli, e link alle evidenze (model card, datasheet, valutazione di conformità, FRIA). Ogni voce funge simultaneamente da sorgente per la registrazione Allegato VIII UE, il registro dei rischi ISO 42001 e l’output MAP del NIST AI RMF.

Conclusione

Lo shadow AI non cederà ai divieti, né alla sola strumentazione di cybersecurity. È un problema di scoperta di governance travestito da problema di sicurezza, e le organizzazioni che lo trattano come tale passeranno i prossimi due anni a costruire registri, AI BOM e trattamenti del rischio che sopravvivono a un audit. Quelle che lo trattano come un problema di perimetro passeranno gli stessi due anni a inseguire incidenti. Il deliverable è identico nei due casi: un inventario unico, attuale, credibile di ogni sistema di IA che l’organizzazione fa girare. La domanda è se lo si costruisce al proprio ritmo o sotto pressione del regolatore.