Tutti conoscono qualcuno il cui progetto di IA è partito con i fuochi d'artificio ed è finito in un cassetto. Non è sfortuna né mancanza di talento: è uno schema. E lo schema non è tecnico. I modelli di oggi bastano e avanzano per quasi ogni automazione di operazioni; ciò che fallisce sta prima e intorno. Ecco i cinque fallimenti che affondano la maggior parte dei progetti, ognuno con un nome, così da riconoscerli nel tuo prima che ti costino un anno.
Il fallimento non è quasi mai tecnico: i dati che lo dimostrano
I numeri sono scomodi e concordano tra le fonti. RAND stima che l'80,3% dei progetti di IA non generi valore di business misurabile. MIT ha osservato che il 95% dei pilot di IA generativa non arriva mai in produzione. E Gartner attribuisce l'85% dei fallimenti a dati di scarsa qualità o insufficienti, non all'algoritmo. In altre parole: la macchina fa il suo lavoro; il problema è cosa le diamo da mangiare e come la operiamo.
È una buona notizia, perché i fallimenti organizzativi si evitano una volta nominati. Un fallimento tecnico richiede ricerca; questi cinque richiedono solo onestà. Prendiamoli uno alla volta.
Fallimento 1 — Dato sporco: spazzatura dentro, spazzatura con sicumera
Il primo e il più letale. Un processo sembra un candidato perfetto finché non apri il dato che lo alimenta e scopri che vive nella testa di qualcuno, in una chat WhatsApp o in un PDF scansionato al contrario. L'IA non lo corregge: lo amplifica. Dagli un input a metà, contraddittorio tra sistemi o del tutto inesistente, e ti restituisce una risposta con la stessa sicurezza come fosse oro. Spazzatura dentro, spazzatura a testa alta.
Il segnale d'allarme: nessuno nella stanza sa dirti dove vive il dato né chi lo mantiene. Se l'input non è accessibile in un formato leggibile dalla macchina, non hai un progetto di automazione — hai un progetto di digitalizzazione che nessuno aveva messo a budget. Questo si collega direttamente a quali processi automatizzare con l'IA: il criterio « dato disponibile » è quello che scarta più candidati.
Fallimento 2 — Senza proprietario: il progetto di nessuno muore in sei mesi
Un progetto di IA senza una persona responsabile con nome non è un progetto: è un esperimento che aspetta che qualcuno smetta di guardarlo. E qualcuno smette sempre. I dati lo confermano: nel 56% dei casi falliti lo sponsor esecutivo perde interesse prima del sesto mese. Senza proprietario non c'è chi difenda il budget, iteri sui casi limite o decida cosa cambia quando il modello si aggiorna.
« Se ne occupa il team dati » non è un proprietario. Un proprietario è una persona con nome, con tempo assegnato e un incentivo legato al funzionamento del sistema. Se nessuno ha l'automazione nella propria descrizione di ruolo, l'automazione non ha nessuno.
Fallimento 3 — Senza misurazione: non puoi difendere ciò che non conti
Il terzo fallimento è silenzioso, perché il sistema può funzionare e morire lo stesso. Se non hai misurato il « prima » — quante ore costava il processo, quanti errori aveva, quanto durava —, non puoi provare il « dopo ». E ciò che non si può provare non si può difendere quando arriva il taglio di budget. Il tempo medio fino all'abbandono si aggira sui 13,7 mesi: giusto il tempo che la novità impiega a spegnersi se non c'è un numero che sale ogni settimana.
La regola è semplice: prima di automatizzare qualsiasi cosa, definisci la metrica che salirà o scenderà e cattura la sua baseline. Senza baseline, il tuo progetto vive di fede. E la fede non sopravvive a un comitato di direzione.
Fallimento 4 — Automatizzare un processo rotto: scali il caos, più in fretta
Automatizzare un processo cattivo non ti dà un processo buono più in fretta: ti dà un disastro su scala. Se il flusso aveva passaggi ridondanti, eccezioni non documentate e decisioni che dipendevano dal « chiedere a Marta », l'IA eredita tutto questo e lo esegue mille volte al giorno senza che Marta possa intervenire. Il risultato è peggiore del manuale, perché ora l'errore è sistematico.
Prima di automatizzare, aggiusta. A volte la migliore automazione è prima eliminare il 30% del processo che non aggiungeva nulla. Per questo conta chi lo monta: un buon team non automatizza ciò che chiedi, ridisegna prima e automatizza dopo ciò che resta. È anche ciò che separa il « quando NON automatizzare » (una decisione precedente) da questo fallimento, che è di esecuzione.
Fallimento 5 — Big-bang invece che per fasi: la prima che non diventa mai una stagione
L'ultimo fallimento è ambizione mal collocata. L'impulso naturale è partire dal processo più grande e vistoso — « automatizziamo tutto il reparto » — e lanciare tutto in una volta. È la corsia veloce verso il fallimento: massima superficie d'errore, zero apprendimento accumulato e nessun risultato da mostrare fino alla fine, che non arriva mai. La demo è la prima; la produzione è la stagione, e la stagione si vince episodio dopo episodio.
L'alternativa che funziona: parti dal processo che incrocia alto ritorno e basso sforzo, lascialo in produzione con il suo proprietario e la sua metrica, e usa quella prima vittoria per finanziare e sbloccare la successiva. Fase dopo fase, ognuna autosufficiente. Il progetto che arriva in produzione non è il più ambizioso: è quello che ha incatenato tre piccole vittorie prima di tentare la grande.
| Il fallimento | Come si presenta | L'antidoto |
|---|---|---|
| Dato sporco | Nessuno sa dove vive l'input | Verificare e pulire il dato prima di automatizzare |
| Senza proprietario | Interesse che si spegne al 6° mese | Una persona con nome, tempo e incentivo |
| Senza misurazione | Funziona ma indifendibile | Baseline prima di toccare qualsiasi cosa |
| Processo rotto | Scali il caos, più in fretta | Ridisegnare prima, automatizzare dopo |
| Big-bang | Tutto in una volta, risultato alla fine | Per fasi: una vittoria finanzia la successiva |
Come si presenta un progetto che arriva davvero in produzione
Un progetto che sopravvive ha un aspetto noioso e riconoscibile: dato pulito e accessibile, un proprietario con nome, una metrica con baseline, un processo già ridisegnato e un rilascio per fasi in cui il primo rende già prima di montare il secondo. Niente di glamour. Tutto questo è ciò che separa il 20% che funziona dall'80% che finisce nel cassetto.
Se preferisci non imparare questi cinque fallimenti a tue spese, l'automazione delle operazioni con l'IA fa esattamente questo: verifichiamo il dato, mettiamo proprietario e metrica, ridisegniamo il processo prima di toccarlo e rilasciamo per fasi. Non consegniamo un report con raccomandazioni — lasciamo il primo processo in funzione, con il suo numero che sale ogni settimana.