Perché i progetti di IA falliscono e la soluzione pratica per ogni causa

Perché i progetti di IA falliscono: cosa dice la ricerca?

Le ricerche concordano sul fatto che la maggior parte dei progetti si blocca tra il pilota e la produzione, e che il modello raramente ne è la causa. A luglio 2025 MIT NANDA ha riportato che il 95% delle organizzazioni non ha visto alcun ritorno misurabile sul conto economico dall'IA generativa, indicando come motivi workflow fragili, strumenti che non imparano dal contesto e scarsa aderenza al lavoro quotidiano.

Il report di BCG di ottobre 2025 sul divario crescente nel valore dell'IA ha rilevato che solo una piccola minoranza di aziende ottiene valore dall'IA su larga scala. Secondo un sondaggio di S&P Global Market Intelligence, una quota crescente di aziende ha abbandonato la maggior parte delle proprie iniziative di IA nel 2025, citando costi, privacy dei dati e sicurezza. A giugno 2025 Gartner ha previsto che oltre il 40% dei progetti di IA agentica sarà cancellato entro la fine del 2027 per costi, valore poco chiaro o controlli dei rischi deboli, mettendo in guardia anche dall'agent washing.

Lette insieme, queste ricerche indicano sette cause. Le sezioni seguenti le affrontano una alla volta, ciascuna con la soluzione che applichiamo.

Causa 1: nessuno ha misurato il punto di partenza

Un progetto non può dimostrare valore se nessuno ha registrato come si svolgeva il lavoro prima. Il valore poco chiaro di cui parla Gartner spesso è proprio questo: il sistema funziona, ma non esiste un dato di partenza con cui confrontarlo, e in sede di revisione del budget non c'è nulla da mostrare.

La soluzione è misurare prima di sviluppare. Per il workflow scelto, registri i minuti per attività, le attività al mese, il tasso di errori o rilavorazioni e chi svolge il lavoro. Concordi l'obiettivo nelle stesse unità (ad esempio il tempo di registrazione delle fatture e la quota di fatture da correggere) e inserisca il confronto in un report mensile fin dal lancio.

Se non è ancora possibile misurare la baseline, dedichi due settimane a registrarla a mano prima di finanziare lo sviluppo. Costa poco e spesso rivela che il vero collo di bottiglia si trova altrove rispetto a dove tutti pensavano.

Causa 2: il workflow si rompe con gli input reali

I workflow fragili, la prima causa indicata da MIT NANDA, nascono di solito da test su esempi ordinati. Gli input reali includono PDF scansionati, catene di email inoltrate, persone che al telefono cambiano argomento a metà chiamata e record già presenti nel CRM con un nome leggermente diverso.

La soluzione è un eval set costruito con esempi reali e disordinati, con risposte corrette note, da rieseguire dopo ogni modifica a prompt, retrieval o modello. Si aggiungono validazioni a livello di campo (totali che devono quadrare, date che devono rientrare in un intervallo, ID che devono esistere in NetSuite o QuickBooks) e una soglia di confidenza che invia i casi dubbi a una coda di revisione umana invece di tirare a indovinare.

• Eval set ricavato dagli input effettivi degli ultimi mesi, compresi gli errori.
• Regole di validazione su ogni campo scritto in un sistema gestionale di riferimento.
• Coda di revisione umana per tutto ciò che resta sotto la soglia di confidenza.

Causa 3: lo strumento resta fuori dal lavoro quotidiano

La scarsa aderenza al lavoro quotidiano, terza causa di MIT NANDA, si manifesta come una finestra di chat o una dashboard separata che le persone devono ricordarsi di aprire. Nel giro di poche settimane smettono di aprirla e l'utilizzo scende silenziosamente a zero.

La soluzione è consegnare i risultati dove il lavoro avviene già: una bozza di risposta dentro il ticket Zendesk, un record compilato in HubSpot o Salesforce, una fattura fornitore in attesa di approvazione nell'ERP, un riepilogo pubblicato nel canale che il team usa già. Uno dei nostri casi studio mostra lo stesso principio senza alcun chatbot: un fornitore di servizi terapeutici ha portato i clinici su un portale AppSheet guidato con validazione e sincronizzazione della fatturazione, il tempo di inserimento dati è sceso da 10-15 minuti al giorno a meno di 3 e gli errori vengono bloccati all'origine.

Causa 4: il sistema non impara dal contesto

Un sistema che risponde a partire da un prompt congelato continua a ripetere gli stessi errori, ed è per questo che gli strumenti che non imparano dal contesto compaiono nell'elenco di MIT NANDA. Le policy cambiano, i listini si aggiornano e il personale corregge lo stesso errore ogni settimana senza alcun effetto.

La soluzione ha due parti. Primo, basare le risposte sui documenti aziendali aggiornati tramite retrieval con citazioni, così che aggiornare un file in SharePoint o Google Drive aggiorni la risposta e chi revisiona possa vedere la fonte. Secondo, chiudere il ciclo: ogni correzione fatta nella coda di revisione viene registrata, aggiunta all'eval set e usata per rivedere prompt o regole a cadenza regolare.

Per gli agenti vocali lo stesso principio vale per le trascrizioni: le chiamate in cui l'agente ha trasferito, frainteso o perso l'interlocutore sono il miglior materiale per il successivo ciclo di modifiche a prompt e instradamento.

Causa 5: i costi crescono più del valore

Il costo è il motivo che compare sia nei dati di S&P Global sia in quelli di Gartner. Le fatture a consumo per i token dei modelli e i minuti vocali crescono con i volumi, e un agente bloccato in un loop può spendere in un pomeriggio più di quanto valesse il suo compito.

La soluzione è progettare il budget dentro il sistema. Imposti un tetto di spesa per attività che interrompa l'esecuzione e avvisi qualcuno, registri token e minuti per attività fin dal primo test, instradi le classificazioni semplici verso un modello più piccolo riservando quello più grande al ragionamento vero e proprio, e confronti ogni mese il costo per attività con il valore per attività. La nostra guida ai costi di implementazione dell'IA elenca le voci di costo di esercizio da monitorare.

Causa 6: i timori su privacy e sicurezza bloccano il rilascio

Privacy dei dati e sicurezza sono gli altri motivi citati nel sondaggio di S&P Global, e spesso emergono tardi, quando l'ufficio legale o l'IT vedono il progetto per la prima volta. Un pilota costruito su un account di chat consumer non può passare in produzione con dati di clienti o pazienti.

La soluzione è definire la gestione dei dati nelle prime settimane. Usi livelli API o enterprise con condizioni adatte ai suoi dati, ottenga un Business Associate Agreement firmato da ogni fornitore che tratta informazioni sanitarie protette, conceda al sistema solo gli accessi strettamente necessari e registri ogni prompt e ogni output. Gli account sono intestati ai clienti, quindi i dati restano sotto contratti che controllano loro.

Coinvolga IT e ufficio legale nella revisione prima dello sviluppo, non dopo. Un flusso dati di una pagina che mostri quali sistemi vengono letti, quali vengono scritti, quali fornitori vedono i dati e dove sono conservati i log risponde in anticipo alla maggior parte delle loro domande.

Causa 7: gli agenti agiscono senza controlli sufficienti

I controlli dei rischi deboli sono il terzo motivo nella previsione di cancellazioni di Gartner, e gli agenti alzano la posta perché compiono azioni, non si limitano a scrivere testo. L'agent washing aggrava il problema: prodotti venduti come agenti autonomi che in realtà sono semplici script, oppure che agiscono con molta più libertà di quanto l'acquirente avesse capito.

La soluzione è delimitare ciò che un agente può fare. Elenchi esplicitamente i suoi strumenti, dia a ciascuno il permesso minimo, richieda l'approvazione umana per tutto ciò che sposta denaro, contatta un cliente o modifica record regolamentati, e mantenga un percorso di rollback in grado di disattivare l'agente e restituire il lavoro alle persone. Quando valuta un fornitore, gli chieda di mostrare le chiamate agli strumenti e i log di un'esecuzione reale, non solo la risposta finale.

Sviluppo interno o con un partner specializzato?

MIT NANDA ha riportato che i progetti acquistati da partner specializzati o sviluppati con loro hanno successo più spesso degli sviluppi interni. La stessa ricerca ha rilevato che i ritorni maggiori arrivano dall'automazione del back office, anche se i budget erano orientati verso vendite e marketing.

Qualunque strada scelga, sono le soluzioni descritte sopra a fare la differenza. Definiamo ogni progetto in una revisione gratuita, lo quotiamo come sviluppo a prezzo fisso e consegniamo codice, prompt e account perché il suo team possa gestirlo. La nostra guida alla roadmap di implementazione illustra le fasi nell'ordine giusto.