AI Sprawl: dove porta l’adozione incontrollata dell’AI (e come governarla con un percorso a maturità crescente)

C’è un fenomeno che chi si occupa di architetture IT conosce bene, perché lo ha già vissuto una volta. Anni fa lo abbiamo chiamato API sprawl: la proliferazione incontrollata di API nate per rispondere a esigenze puntuali, senza standard condivisi, senza catalogo, senza governo — fino a quando l’ecosistema che avrebbe dovuto accelerare il business è diventato esso stesso un freno, fatto di duplicazioni, vulnerabilità e debito tecnico. Ne abbiamo scritto più volte su questo Journal, insieme al percorso per uscirne: visibilità, standard, governance.

Oggi quel copione si sta ripetendo con l’intelligenza artificiale, con due differenze importanti: la velocità, che è molto più alta, e la posta in gioco, che con l’arrivo dell’AI agentica — sistemi che non si limitano a rispondere ma agiscono sui processi — è destinata a crescere ancora. Lo chiamiamo AI sprawl, e i numeri dicono che è già realtà: secondo il Work Trend Index di Microsoft, il 78% di chi usa l’AI al lavoro porta con sé strumenti propri, fuori dall’approvazione IT. Secondo il report sulla Shadow AI di UpGuard l’81% dei dipendenti usa tool AI non autorizzati.

Adozione altissima, governo bassissimo: è la definizione stessa di sprawl. Vediamo, con tre scenari tratti dall’esperienza sul campo, dove porta — e poi come il mondo API ci abbia già insegnato la via d’uscita.

Tre scenari di adozione senza visione

Scenario 1: la compagnia con tre assistenti virtuali

Una compagnia assicurativa di medie dimensioni. Il marketing lancia un chatbot sul sito per la preventivazione, appoggiandosi a un vendor SaaS. Sei mesi dopo, l’area sinistri sviluppa internamente un assistente per gli operatori del contact center, integrando direttamente le API di un provider LLM. Nel frattempo l’IT sperimenta un terzo assistente per la intranet, con un altro modello ancora.

Dopo un anno la compagnia ha tre assistenti che rispondono in modo diverso alle stesse domande — con il rischio concreto che uno di essi dia al cliente un’informazione precontrattuale scorretta — tre contratti con tre fornitori, tre insiemi di API key disseminate nel codice, tre fatture a consumo che nessuno consolida e nessuna funzione aziendale in grado di dire quanto la compagnia stia spendendo in AI, né con quali risultati. Ogni progetto, preso da solo, era sensato. È l’assenza di una visione d’insieme che li ha trasformati in un problema.

Scenario 2: la shadow AI nella rete distributiva

Una banca con una rete di gestori e consulenti. Nessun progetto AI ufficiale è ancora partito — il comitato rischi sta valutando — ma nel frattempo i consulenti hanno scoperto da soli quanto gli strumenti generativi pubblici facciano risparmiare tempo: sintesi di documenti, bozze di e-mail ai clienti, preparazione degli incontri. Il problema è cosa incollano in quegli strumenti: estratti di posizioni patrimoniali, dati anagrafici, situazioni familiari.

Non è uno scenario teorico: secondo uno studio di Cisco del 2025, citato nel report sulla Shadow AI di Olakai, il 46% delle organizzazioni ha già riscontrato fughe di dati interni attraverso l’AI generativa, e il costo medio di una violazione legata alla shadow AI, secondo uno studio IBM citato nello stesso report Olakai, ha raggiunto cifre tra i 3,96 e 4,63 milioni di dollari. Il paradosso è che il divieto puro peggiora le cose: la shadow AI nasce proprio dove l’azienda non offre un’alternativa sanzionata. Come le shadow API di cui parlavamo a proposito di API Security, ciò che non è censito non è proteggibile — ma qui a essere invisibile non è un endpoint: sono i dati dei clienti che escono dal perimetro.

Scenario 3: il POC che diventa produzione

Un gruppo finanziario avvia un proof of concept: un modello LLM per classificare e smistare le richieste dei clienti corporate. Il POC funziona, il business lo adotta, i volumi crescono. Ma il POC non è mai stato promosso a sistema di produzione: il provider è cablato nel codice (cambiare modello significherebbe riscrivere), non esiste log delle interazioni (quando la compliance chiede “come ha deciso il sistema questa classificazione?” — domanda a cui AI Act e normative di vigilanza danno sempre più peso — non c’è risposta), e i costi a token, trascurabili nel pilota, a volumi reali sono decuplicati senza che nessuno se ne accorgesse fino alla fattura.

È forse lo scenario più insidioso, perché non nasce dall’indisciplina ma dal successo: è l’adozione che cresce più in fretta della sua infrastruttura di governo.

La lezione delle API: si esce dallo sprawl con un approccio strutturato

Questi tre scenari hanno una radice comune: l’adozione è avvenuta per accumulo di iniziative, non per stadi di maturità. Ed è esattamente l’errore da cui il mondo API è uscito adottando modelli di maturità espliciti: nessuna organizzazione è passata in un colpo solo dalle integrazioni punto-punto all’API-first, ma chi ha governato la traiettoria — prima visibilità, poi standard, poi piattaforma, poi cultura — è arrivato a destinazione con anni di vantaggio e molto meno debito tecnico.

Per l’AI vale lo stesso approccio, e i framework di riferimento convergono: il modello di maturità AI di Gartner articola cinque livelli su pilastri che vanno dalla strategia alla governance, dall’engineering alle persone. La nostra esperienza sul campo — in particolare nei settori regolamentati, dove banche e assicurazioni guidano l’adozione di agenti in produzione (Statistiche sull’adozione degli agenti AI Enterprise 2026 di Paul Okhrem) ma la maturità di governo resta indietro — ci porta a declinarlo in quattro tappe operative, ognuna con un obiettivo chiaro e casi d’uso concreti.

Tappa 1 — Visibilità e prima risposta: dal divieto all’alternativa governata

Prima di costruire, occorre vedere. Il punto di partenza è un censimento onesto: quali strumenti AI sono già in uso — ufficiali e non — quali dati toccano, quali contratti e costi esistono. Segue la prima mossa concreta, che non è un divieto ma un’alternativa autorevole e autorizzata: uno strumento di produttività AI approvato, accessibile a tutti, con i dati personali mascherati e le interazioni tracciate.

Un esempio, nel mondo assicurativo: mettere a disposizione della rete agenziale un assistente interno per la sintesi di condizioni di polizza e normativa, che risponde solo su basi di conoscenza aziendali. I consulenti smettono di usare gli strumenti pubblici non perché è vietato, ma perché quello interno è migliore per il loro lavoro — e la shadow AI si svuota dal basso.

Tappa 2 — Il primo caso d’uso industrializzato: costruire il punto di controllo

La seconda tappa seleziona un solo caso d’uso ad alto valore e lo porta in produzione bene: non un POC promosso sul campo, ma un servizio con i requisiti di un sistema enterprise. È qui che entra l’AI Gateway di cui abbiamo parlato nel primo articolo di questa serie: il punto centralizzato da cui passano le chiamate ai modelli, con credenziali custodite, costi misurati per applicazione, log completo delle interazioni e indipendenza dal singolo provider.

Un esempio, nel mondo finance o assicurativo: la classificazione automatica della corrispondenza clienti, o l’estrazione dati dalle fatture di riparazione nei sinistri auto — casi d’uso a volumi alti, valore misurabile e rischio contenuto, perfetti per collaudare l’infrastruttura. Il criterio di successo non è solo il ROI del caso d’uso: è che il secondo caso d’uso costi la metà del primo, perché la piattaforma esiste già.

Tappa 3 — La piattaforma e il catalogo: scalare senza frammentare

Con il punto di controllo collaudato, l’adozione può allargarsi senza ricreare lo sprawl: ogni nuovo caso d’uso entra in un catalogo (chi lo usa, quali dati tocca, quale classe di rischio, quale modello lo serve), con policy differenziate — i dati sanitari delle polizze salute verso modelli on-premise, le richieste generiche verso modelli cloud economici — e una pratica di FinOps dell’AI: budget e quote di token per team, applicazione e canale.

Un esempio per il mondo assicurativo B2B: è la tappa in cui i servizi AI si estendono alla rete distributiva — broker, bancassurance, comparatori — trattati come prodotti a catalogo con quote e contrattualistica per partner, come descritto nel primo articolo.

Tappa 4 — Agentic readiness: l’autonomia come traguardo, non come scorciatoia

Solo a questo punto — con visibilità, piattaforma, catalogo e policy — l’organizzazione è pronta per il passo che tutti oggi vorrebbero fare per primo: gli agenti che operano sui processi con autonomia crescente. Le fondamenta delle tappe precedenti diventano prerequisiti: identità e permessi per ogni agente, strumenti in allowlist, checkpoint umani sulle azioni irreversibili, audit trail — i temi che approfondiamo nel terzo articolo di questa serie.

Sempre esemplificando, nel mondo assicurativo: l’agente che istruisce autonomamente un sinistro semplice — raccoglie i documenti, verifica la copertura, propone la liquidazione — con l’operatore umano (HITL – Human In The Loop) che rivede e modifica o approva l’atto finale. Un caso d’uso ad altissimo valore, che però solo un’organizzazione alla tappa 4 può permettersi di esercire in sicurezza. Chi prova a partire da qui, saltando le tappe, sta costruendo lo scenario 3 con carenze di governance che si presenteranno in forma amplificata.

Governare l’entusiasmo, non spegnerlo

La tentazione, di fronte allo sprawl, è sempre la stessa: bloccare tutto in attesa di regole perfette. Ma l’esperienza delle API insegna che lo sprawl non si ferma per decreto — si incanala. L’adozione incontrollata è, in fondo, un segnale positivo mal gestito: significa che le persone e il business hanno già capito il valore dell’AI. Il compito di chi governa l’IT è dare a quell’energia un percorso: una tappa alla volta, un caso d’uso alla volta, adottando un approccio strutturato come bussola.

In Intesys accompagniamo i clienti lungo questo percorso con un approccio graduale e sistemico, intercettando e applicando i trend di adozione più idonei in questo momento. Per farlo, facciamo forza sul modello di maturity che abbiamo già consolidato con successo nell’ambito delle API: si parte dalla costruzione del punto di controllo — l’AI Gateway — su un primo caso d’uso concreto, per poi definire una roadmap che porta progressivamente sotto governo strumenti, dati, costi e, quando l’organizzazione è pronta, agenti.