Gli studi di settore concordano su un punto: la grande maggioranza dei progetti di intelligenza artificiale in azienda non arriva in produzione o, una volta rilasciata, non genera il valore atteso. Non si tratta di progetti nati male né di aziende incompetenti. Sono progetti con budget, con un team e con la reale volontà di trasformare il business.
Capire perché accade, nel dettaglio e non per generalità, è probabilmente più utile di qualsiasi elenco di consigli su «come avere successo con l’IA».
La causa più frequente: un problema di business mal definito
L’errore più comune non è tecnico, ma concettuale. Molte aziende avviano progetti di IA con un’idea vaga di ciò che vogliono ottenere: «migliorare l’efficienza operativa», «usare i dati che abbiamo», «essere all’avanguardia tecnologica».
Queste non sono definizioni di un problema, sono aspirazioni. E i progetti costruiti su aspirazioni non hanno un criterio di successo chiaro: non si sa mai se hanno funzionato e le risorse si disperdono senza un impatto concreto.
Un progetto di IA ben definito parte da una domanda precisa: «Perché perdiamo clienti nel terzo mese di contratto?», «Come possiamo prevedere quali macchine si guasteranno questa settimana?», «Quale combinazione di prodotti massimizza il margine per cliente?». La differenza tra un’aspirazione e un problema ben definito è che il secondo ha dati misurabili e un risultato specifico rispetto al quale validare il modello.
I dati: l’ostacolo che emerge a progetto avviato
Il secondo fattore di fallimento per frequenza riguarda la qualità e la disponibilità dei dati. Non la loro mancanza: quasi tutte le aziende hanno più dati di quanto pensino. Il problema è che quei dati si trovano in sistemi diversi, con formati incompatibili, errori storici accumulati e senza la struttura necessaria per addestrare un modello utile.
Ciò che rende questo fattore particolarmente insidioso è che si scopre tardi. Un’azienda può passare mesi nella fase di definizione e progettazione prima che il team tecnico si accorga che i dati dell’ERP e quelli del sistema di produzione usano chiavi diverse, che i record storici hanno il 30% di valori nulli nelle variabili più rilevanti o che il gestionale non registra il dato specifico di cui il modello ha bisogno.
L’audit dei dati prima di impegnare il budget di sviluppo non è un passaggio facoltativo. È la differenza tra scoprire i problemi quando costa ancora poco risolverli e scoprirli dopo mesi di lavoro già investiti.
Le aspettative gonfiate: il problema del pilota perfetto
C’è uno schema che si ripete spesso nei progetti di IA: il pilota funziona molto bene in condizioni controllate, suscita entusiasmo nella direzione e giustifica l’investimento; poi il modello in produzione dà risultati deludenti.
Perché accade? Perché i dati di addestramento del pilota sono i migliori disponibili, selezionati con cura e con casi rappresentativi. I dati di produzione sono il mondo reale: rumorosi, incompleti, con casi estremi che il modello non ha mai visto e variazioni stagionali che il pilota non ha intercettato.
Il passaggio dal pilota alla produzione richiede una progettazione specifica. I modelli vanno validati con dati che simulino le condizioni reali di produzione. Le procedure di monitoraggio in produzione devono essere progettate prima del lancio, non dopo. E le aspettative della direzione vanno calibrate sulle prestazioni in produzione, non su quelle del pilota.
Il fattore organizzativo: la tecnologia è pronta, l’organizzazione no
Un modello tecnicamente eccellente che nessuno usa genera esattamente lo stesso ritorno di un modello che non funziona. E i modelli di IA non adottati sono più frequenti di quanto sembri.
Le ragioni sono molteplici. Gli utenti finali non sono stati coinvolti nella progettazione e il sistema non si adatta ai loro flussi di lavoro reali. Il modello fornisce raccomandazioni che l’operatore non comprende e non può verificare, e così si affida al proprio giudizio. Il sistema richiede un cambiamento di processo che nessuno ha formalizzato e che la direzione non ha promosso.
La gestione del cambiamento organizzativo non è un compito secondario da aggiungere alla fine del progetto. È una dimensione del progetto fin dal primo giorno, importante quanto quella tecnica.
L’errore del fornitore generalista
Una categoria specifica di fallimenti merita una menzione a parte: i progetti affidati a fornitori che hanno aggiunto «IA» al proprio catalogo di servizi senza un’esperienza reale in progetti di questo tipo.
L’IA ha specificità che lo sviluppo software tradizionale non ha: la necessità di dati di qualità, la valutazione probabilistica delle prestazioni, la progettazione del monitoraggio in produzione, la gestione del model drift. Un fornitore senza esperienza specifica può costruire qualcosa che sembra funzionare nella demo ma che non regge il passaggio alla produzione.
Le domande per valutare un fornitore sono dirette: quanti progetti di IA ha portato in produzione? In quali settori? Come misura il successo dopo il rilascio? Che cosa è successo quando un modello non ha funzionato come previsto?
Che cosa distingue i progetti che arrivano in produzione
I progetti di IA che arrivano in produzione e generano valore hanno diversi elementi in comune: partono da un problema di business specifico e misurabile, fanno un audit onesto dei dati prima di impegnare il budget, coinvolgono gli utenti finali fin dalla progettazione, hanno uno sponsor interno con l’autorità per promuovere i cambiamenti organizzativi necessari e fissano metriche di successo di business, non solo tecniche, prima di iniziare.
Nessuno di questi elementi è sofisticato né richiede competenze tecniche avanzate. Sono pratiche di project management applicate al contesto specifico dell’IA.
Domande frequenti
Ci sono settori in cui i progetti di IA hanno più successo? I settori con il tasso di successo più alto sono quelli in cui i dati sono ben strutturati, il volume è sufficiente e il problema di business è ben definito. Manifattura, logistica e finanza sono avvantaggiate da questo punto di vista. I settori con dati più dispersi o processi meno standardizzati incontrano più difficoltà iniziali, anche se il valore potenziale, una volta risolte, è altrettanto elevato.
È possibile recuperare un progetto di IA fallito? Dipende da dove si trova il problema. Se è tecnico, cioè il modello ha prestazioni basse, di solito è recuperabile con più dati o un approccio diverso. Se è di adozione, cioè il sistema esiste ma nessuno lo usa, richiede un lavoro organizzativo. Se il caso d’uso non aveva abbastanza valore fin dall’inizio, la decisione più sensata può essere spostarsi su un problema diverso.
Quando si vedono i primi risultati? I progetti ben progettati danno priorità ad avere qualcosa in produzione che generi valore il prima possibile. Una prima versione limitata ma funzionante insegna più di un progetto perfetto che non viene mai rilasciato. I tempi dipendono dal perimetro del progetto e dalla qualità iniziale dei dati.