Se il Pilota AI non Funziona: Cosa Fare (Diagnosi e Recupero per PMI)

Il 60% dei "fallimenti AI" che vediamo in audit sono problemi di misurazione o adozione, non di tecnologia. Diagnosi in 3 livelli in ordine: misurazione, adozione, tecnico. Matrice 2x2 per decidere tra recuperare e ripartire, prima di un audit indipendente.

La trappola del 'fallimento' AI

Il primo errore quando un pilota AI sembra non funzionare è dare per scontato che stia fallendo davvero. Nella maggioranza dei casi che incontriamo in audit indipendente, il sistema sta funzionando — solo che nessuno se ne accorge perché viene misurato male.

Scenari ricorrenti. Il management aveva aspettative non realistiche: "l'AI dovrebbe gestire il 100% dei ticket" quando l'80% è già un risultato eccellente. La baseline pre-AI era stata definita male o non era stata definita affatto, quindi non si riesce a quantificare il miglioramento effettivo. I benefici reali (es. capacità sbloccata, qualità più costante) non vengono tracciati mentre vengono cercati benefici visibili (es. riduzione headcount) che non sono mai stati l'obiettivo del progetto.

Prima di dichiarare un fallimento, va fatta una verifica: il sistema sta producendo i risultati che era stato progettato per produrre? Se la risposta è sì ma "non sembra abbastanza", il problema non è il sistema — è l'allineamento delle aspettative o la metodologia di misurazione. Per il framework di misurazione ROI corretto, vedi come misurare il ROI di un progetto AI a 6 mesi.

Se la verifica conferma che il sistema sotto-performa rispetto agli obiettivi originali (non a quelli rivisti a posteriori), è il momento di fare diagnosi strutturata.

Diagnosi in 3 livelli

L'ordine dei livelli è critico: saltare il livello 1 o 2 e andare direttamente al tecnico è l'errore più costoso. Si finisce a modificare prompt o cambiare modello quando il vero problema era organizzativo.

Livello 1: Misurazione

La prima domanda non è "perché non funziona?". È "siamo sicuri che non stia funzionando?". Verifica:

• Le metriche pre-AI erano state documentate? Se no, il confronto attuale è opinione, non dato.
• Le metriche post-AI vengono raccolte sistematicamente o solo aneddoticamente? Una percezione di "non funziona" basata su 2-3 lamentele degli utenti non è un dato.
• Gli obiettivi originali del progetto erano realistici? Se l'obiettivo era "ridurre del 50% il tempo di customer service" e il sistema lo riduce del 30%, è un fallimento o un successo parziale? Dipende da come è scritto il contratto.
• La finestra di misurazione è corretta? Misurare a 60 giorni significa misurare la curva di apprendimento, non la performance a regime.

Se a questo livello emerge che il "fallimento" è in realtà un problema di misurazione o di aspettative, si fixa la misurazione — non il sistema. Risparmio tipico: settimane di lavoro tecnico inutile.

Livello 2: Adozione

Se la misurazione conferma che il sistema sotto-performa, la seconda domanda è "il team lo sta davvero usando come previsto?".

Indicatori da verificare: tasso di utilizzo settimanale (% degli utenti target che usa il sistema almeno una volta), tasso di override manuale (% di volte che gli utenti scavalcano l'output AI), tasso di completamento del flusso (% di sessioni che arrivano al risultato vs abbandono).

Cause comuni di problemi di adozione:

• Resistenza al cambiamento: il team teme di essere sostituito o non si fida del sistema. Fix: comunicazione esplicita dal management su come l'AI integra (non sostituisce) il ruolo umano.
• UX/UI scadente: il sistema funziona ma è scomodo da usare nel flusso quotidiano. Fix: integrazione più stretta con gli strumenti esistenti, riduzione dei click necessari.
• Formazione mancata o superficiale: il team non sa come usare il sistema al meglio. Fix: sessioni hands-on, manuale operativo, supporto Q&A nei primi 60 giorni.
• Mancanza di accountability: nessuno ha l'obbligo formale di usare il sistema. Fix: KPI di utilizzo nel performance review.

Se il tasso di utilizzo è sotto il 40%, il problema è quasi certamente di adozione — non tecnologico. Modificare i prompt non aumenta l'adozione di una percentuale apprezzabile.

Livello 3: Tecnico

Si arriva al livello tecnico solo dopo aver escluso problemi di misurazione e di adozione. Le cause tipiche:

• Prompt drift: modifiche ad hoc accumulate ai prompt che hanno peggiorato la performance. Fix: rollback a un prompt baseline funzionante + versioning sistematico.
• Cambio di pattern degli input: i dati che arrivano al sistema sono cambiati nel tempo (es. nuovo formato documenti, nuovo linguaggio degli utenti). Fix: ricalibrazione su dati recenti.
• Edge case non coperti: il sistema gira bene sul 90% dei casi ma cade sul 10% restante. Fix: identificare pattern degli edge case e gestirli esplicitamente.
• Qualità dati degradata: i dati a monte sono peggiorati (es. l'ERP è stato aggiornato e produce output diversi). Fix: validazione e pulizia dei dati di input.
• Modello obsoleto: il modello AI usato è stato superato e i nuovi avrebbero performance significativamente migliori. Fix: upgrade del modello dopo test A/B.

Il livello tecnico è il più visibile ma il meno frequente come root cause del "fallimento". È la conseguenza tipica del salto del livello 1-2 — si arriva qui senza aver risolto le vere cause organizzative.

I 5 fallimenti più comuni nei progetti AI delle PMI italiane

1. Misurazione assente (40% dei casi). Causa: nessuna baseline pre-AI, nessun KPI condiviso, metriche raccolte aneddoticamente. Fix: prima di toccare il sistema, definire e implementare un sistema di tracking strutturato. Tempo tipico: 2-3 settimane.
2. Adozione bassa (25% dei casi). Causa: change management saltato, formazione inadeguata, resistenza non gestita. Fix: workshop con il team utente, ridisegno dell'esperienza d'uso, KPI di utilizzo nei review. Tempo tipico: 4-8 settimane.
3. Scope inadeguato (15% dei casi). Causa: il caso d'uso scelto non genera abbastanza valore neanche se eseguito perfettamente. Fix: ripensare lo scope. A volte significa chiudere il progetto e ripartire su un altro caso d'uso. Per evitarlo in futuro, vedi perché falliscono i progetti AI nelle PMI.
4. Dati di scarsa qualità (10% dei casi). Causa: i dati a monte del sistema AI sono incompleti, inconsistenti o non strutturati. Fix: data cleaning e validazione prima di re-toccare il sistema AI. Tempo tipico: 3-6 settimane.
5. Problema tecnico isolato (10% dei casi). Causa: bug nel sistema, prompt drift, edge case non gestito. Fix: intervento tecnico mirato dopo audit. Tempo tipico: 2-4 settimane.

La distribuzione è coerente con l'osservazione di Gartner e dell'Osservatorio AI PoliMi: la maggioranza dei "fallimenti AI" non è di natura tecnologica. Saltare la diagnosi e attaccare direttamente il livello tecnico spreca tempo e budget.

Quando recuperare e quando ripartire

Una volta completata la diagnosi, la domanda è: vale la pena recuperare il progetto o conviene chiuderlo e ripartire? La matrice decisionale 2x2:

• Alta probabilità di successo + basso costo di recupero: recuperare. È lo scenario tipico dei problemi di misurazione e adozione — il sistema funziona, basta sistemare l'organizzazione attorno. Tempo: 4-8 settimane.
• Alta probabilità di successo + alto costo di recupero: valutare caso per caso. Tipicamente significa che serve un re-build parziale del sistema con dati migliori o un cambio di modello AI. Se il costo del recupero è inferiore al 50% del costo di un re-start da zero, recuperare. Tempo: 8-16 settimane.
• Bassa probabilità di successo + basso costo di recupero: provare il fix economico (es. un re-training rapido del modello), ma con una deadline di 4-6 settimane. Se non funziona, chiudere senza accumulare investimenti.
• Bassa probabilità di successo + alto costo di recupero: chiudere il progetto. Documentare quanto imparato. Riconoscere onestamente che il caso d'uso o lo scope erano sbagliati. Ripartire su un caso d'uso diverso, applicando le lezioni. Risparmio tipico: 6-12 mesi rispetto al continuare a investire.

L'errore più costoso è il sunk cost fallacy: continuare a investire in un progetto perché "abbiamo già speso tanto". I soldi già spesi sono persi indipendentemente dalla decisione futura. La domanda corretta è solo: "il prossimo euro investito qui vale più che investito altrove?".

Il rescue audit indipendente

Quando la diagnosi interna non è chiara o quando il team è troppo coinvolto emotivamente, conviene un rescue audit indipendente — fatto da un consulente esterno, idealmente diverso da chi ha implementato il sistema originale. Cosa fa in 2-3 settimane:

• Settimana 1 — Discovery: review della documentazione tecnica esistente, interviste a Sponsor, AI Champion (se esiste), Process Owner, e 3-5 utenti finali. Raccolta delle metriche disponibili.
• Settimana 2 — Analisi: applicazione della diagnosi a 3 livelli, identificazione delle cause radici, valutazione delle opzioni (recuperare vs ripartire vs chiudere).
• Settimana 3 — Raccomandazioni: report scritto con diagnosi formale, opzioni con costi e tempi, piano di azione raccomandato. Presentazione allo Sponsor con Q&A.

Costo tipico di un rescue audit per PMI italiana: 5-15K€ a seconda della complessità del sistema. Vale praticamente sempre la pena: il costo dell'audit è 5-10% del costo di un progetto AI tipico, ma può evitare di buttare via il restante 90% in interventi sbagliati.

Importante: il rescue audit dovrebbe essere fatto da un consulente diverso da quello che ha implementato il sistema originale. Il consulente originale ha incentivi a difendere il proprio lavoro; un consulente terzo può fare una valutazione più onesta delle cause.

Cosa NON fare quando il pilota non funziona

• Cambiare modello AI a caso. "Proviamo Claude invece di GPT-4" o viceversa, senza A/B test né diagnosi. Nove volte su dieci non risolve nulla — il problema non era il modello.
• Raddoppiare il budget senza diagnosi. "Spendiamo di più, magari così funziona". Senza capire la causa, l'investimento aggiuntivo amplifica gli stessi errori invece di risolverli.
• Licenziare il consulente attuale prima dell'audit. La reazione emotiva è "se non funziona è colpa loro". Spesso il consulente non è il problema (o è solo una parte del problema). Licenziarlo prima dell'audit fa perdere contesto storico utile alla diagnosi.
• Chiudere il progetto senza documentare cosa imparare. Anche un fallimento ha valore se viene documentato: cause, decisioni sbagliate, segnali ignorati. Senza retro strutturata, il prossimo progetto AI ripeterà gli stessi errori.
• Annunciare il fallimento internamente prima di avere il piano di recupero. Distrugge la fiducia del team nell'AI in generale, anche per progetti futuri che potrebbero funzionare. La comunicazione interna sui problemi va fatta insieme alla comunicazione del piano di recupero.

Il prossimo passo

Hai un progetto AI in produzione e i risultati sono sotto le attese. Il prossimo passo non è cambiare la tecnologia — è fare diagnosi strutturata.

Se vuoi un rescue audit indipendente del tuo progetto AI (anche se implementato da altri consulenti), parla con IL DOGE DI VENEZIA. Lo facciamo in 2-3 settimane, con costo prevedibile, e ti diamo una valutazione onesta — anche quando la risposta è "il sistema funziona, dovete cambiare come lo misurate". La prima call diagnostica è gratuita.