Perché i Progetti IA Falliscono: I Pattern dai Post-Mortem Pubblici

Il Vantaggio di Imparare dai Fallimenti Altrui

La maggior parte delle organizzazioni ha accesso alle stesse ricerche sui tassi di fallimento dei progetti IA. Le leggono, annuiscono, e poi replicano le stesse modalità di errore nei propri deployment.

La ragione non è l'ignoranza. È la distanza. Le statistiche astratte sui tassi di fallimento non producono lo stesso riconoscimento viscerale che deriva dalla lettura di cosa è realmente accaduto in un progetto specifico — quali decisioni sono state prese, quali segnali sono stati ignorati, e qual è stato il costo quando tutto è collassato.

I post-mortem pubblici sono rari nel mondo tecnologico. Le aziende sono incentivate a sopprimere le narrazioni di fallimento. Ma abbastanza è stato riportato — attraverso il giornalismo, i contenziosi, le analisi accademiche e le aziende stesse — da permettere di identificare i pattern ricorrenti. Questi pattern non sono esclusivi delle organizzazioni coinvolte. Sono strutturali, e appaiono in organizzazioni di ogni dimensione e settore che stanno attualmente gestendo progetti IA.

Questo articolo documenta i fallimenti pubblici più istruttivi ed estrae ciò che i dirigenti devono mettere in pratica prima che gli stessi pattern si radichino nelle proprie iniziative.

Pattern 1: Dati di Addestramento Che Non Rappresentano la Realtà

Il caso: l'IA di Recruiting di Amazon (2014–2017)

Nel 2014, Amazon ha costruito un sistema IA per automatizzare lo screening delle candidature. L'obiettivo era pratico — l'azienda riceveva centinaia di migliaia di CV ogni anno, e un sistema in grado di valutare i candidati avrebbe ridotto il carico di lavoro dei recruiter. Il sistema è stato addestrato sui CV inviati ad Amazon nel decennio precedente.

Il problema, riportato da Reuters nell'ottobre 2018 quando il progetto fu abbandonato, era che dieci anni di assunzioni Amazon erano stati dominati da candidati maschi — un riflesso del più ampio squilibrio di genere nel settore tecnologico. Il sistema ha imparato a replicare quel pattern. Penalizzava i CV contenenti la parola "women's" (come in "women's chess club" o "women's leadership programme"). Declassava le laureate di due college esclusivamente femminili. Amazon ha sciolto il team nel 2017 dopo aver concluso che il sistema non poteva essere corretto in modo affidabile.

Cosa significa per la vostra organizzazione

Qualsiasi sistema IA addestrato su dati storici apprende le decisioni che hanno prodotto quella storia — incluse quelle distorte, subottimali e specifiche a un contesto. Prima di deployare qualsiasi modello che utilizzi dati di decisioni storiche come segnale di addestramento, chiedetevi: chi ha preso quelle decisioni storiche, in quali vincoli, e quali pattern hanno sistematicamente favorito o escluso?

Questa non è solo una preoccupazione di equità. È una preoccupazione di affidabilità. Un modello di recruiting che esclude candidati di alta qualità è un problema di business. Un modello di credit scoring addestrato su approvazioni storiche che riflettevano pratiche discriminatorie sottovaluterà sistematicamente i richiedenti attuali. Lo stesso problema strutturale si applica a qualsiasi IA operativa addestrata su decisioni umane passate.

→ Vedi anche: La Vostra Azienda È Pronta per l'IA? Una Valutazione in 20 Punti

Pattern 2: Overfitting a un Segnale Proxy

Il caso: Google Flu Trends (2008–2015)

Google Flu Trends è stato lanciato nel 2008 e ha generato notevole attenzione — e genuino interesse scientifico — per la sua capacità di tracciare i focolai influenzali più rapidamente dei sistemi di sorveglianza tradizionali dei CDC. Analizzando i volumi di query di ricerca, sembrava in grado di monitorare la prevalenza dell'influenza in tempo quasi reale, con settimane di anticipo sui dati clinici.

Un'analisi del 2014 pubblicata su Science da Lazer et al. — "The Parable of Google Flu: Traps in Big Data Analysis" — ha documentato il crollo di queste prestazioni. Nel 2013, Google Flu Trends sovrastimava l'attività influenzale di oltre il 140% ai picchi epidemici. Il modello era stato ottimizzato su un periodo in cui i comportamenti di ricerca e la prevalenza dell'influenza si muovevano insieme. Quando Google ha modificato il proprio algoritmo di autocompletamento nel 2011 e nel 2012, i pattern di ricerca si sono evoluti indipendentemente dai tassi reali di influenza. Il modello non sapeva che stava accadendo.

Il sistema aveva imparato a predire un proxy dell'influenza — il comportamento di ricerca — piuttosto che l'influenza stessa. Quando il proxy e il fenomeno sottostante si sono disaccoppiati, le previsioni sono diventate inaffidabili.

Cosa significa per la vostra organizzazione

La maggior parte dei modelli IA ottimizza su un proxy misurabile del risultato che vi interessa realmente. I punteggi di churn dei clienti predicono le cancellazioni, non la soddisfazione che le determina. I sistemi di rilevamento delle frodi segnalano pattern di transazione, non l'intento fraudolento. I modelli di previsione della domanda predicono i pattern di ordine storici, non la domanda futura.

Quando il proxy rimane affidabilmente correlato con il risultato, il modello funziona. Quando le condizioni esterne modificano la relazione — cambiamenti competitivi, disruption economica, modifiche normative, o anche un redesign dell'interfaccia — le prestazioni del modello possono degradarsi senza un segnale evidente che ciò stia accadendo.

Monitorare le prestazioni del sistema IA rispetto all'effettivo risultato di business — non solo rispetto alla metrica di addestramento — è l'unico modo per rilevare questa categoria di fallimento prima che diventi significativa.

→ Vedi anche: Come Calcolare il ROI dell'Automazione IA Prima di Spendere un Euro

Pattern 3: Complessità del Dominio Che Supera il Segnale di Addestramento

Il caso: IBM Watson for Oncology (2012–2022)

IBM Watson for Oncology è stato uno dei progetti IA più pubblicizzati degli anni 2010. Presentato come un sistema in grado di raccomandare piani di trattamento oncologico, è stato venduto a numerosi ospedali nel mondo e rappresentava un importante impegno pubblico verso il potenziale dell'IA nella sanità.

Un'indagine di STAT News del 2017, basata su documenti interni di IBM, ha rivelato che i medici di diversi importanti centri oncologici avevano identificato raccomandazioni di trattamento "non sicure e scorrette". Il problema sottostante: il sistema era stato addestrato principalmente su casi di pazienti ipotetici generati da oncologi del Memorial Sloan Kettering Cancer Center, piuttosto che sui casi reali — complessi, ambigui, con molteplici comorbidità — che i medici effettivamente incontrano.

Un modello addestrato su scenari ipotetici accuratamente costruiti performa bene su scenari ipotetici accuratamente costruiti. I pazienti reali hanno sintomi contraddittori, anamnesi inusuali e controindicazioni che non si adattano a pattern chiari. Diversi sistemi ospedalieri hanno rescisso i contratti tra il 2017 e il 2018. IBM ha ceduto la propria divisione Watson Health a Francisco Partners nel 2022.

Cosa significa per la vostra organizzazione

I sistemi IA sono calibrati sulla complessità dei loro dati di addestramento. Se i dati di addestramento sono stati curati, ripuliti o costruiti per rappresentare scenari ideali, il sistema performa bene su scenari ideali — che non sono ciò che incontrerà in produzione.

Prima del deployment, testate i sistemi IA sugli input disordinati, incompleti e contraddittori che l'ambiente operativo produce realmente. Se le prestazioni si degradano sostanzialmente con i dati reali rispetto ai dati curati, questo non è un problema dell'ambiente di test. È il reale tetto di prestazioni del modello.

→ Vedi anche: La Scorecard di Valutazione dei Fornitori IA: 25 Domande Prima di Firmare

Pattern 4: Lacune di Responsabilità Che Diventano Esposizione Legale

Il caso: il Chatbot di Air Canada (2022–2024)

Nel 2024, il Tribunale di Risoluzione Civile della Columbia Britannica ha ordinato ad Air Canada di pagare un risarcimento a un cliente a cui il chatbot IA della compagnia aerea aveva fornito informazioni errate sulle tariffe di lutto. Il cliente aveva acquistato un biglietto a tariffa piena basandosi sull'affermazione (errata) del chatbot secondo cui una tariffa di lutto ridotta avrebbe potuto essere applicata retroattivamente entro 90 giorni.

Nella propria difesa, Air Canada ha sostenuto che il chatbot fosse una "entità legale separata" responsabile delle proprie affermazioni, e che la compagnia non avesse responsabilità per i suoi output. Il tribunale ha respinto questo argomento. Air Canada è stata ritenuta responsabile delle informazioni fornite dal proprio sistema IA ai clienti, indipendentemente dall'accuratezza di tali informazioni.

Cosa significa per la vostra organizzazione

I sistemi IA a contatto con i clienti non costituiscono una categoria legale separata. Quando forniscono informazioni errate ai clienti — dettagli di fatturazione, specifiche di prodotto, termini di policy, prezzi — l'organizzazione è responsabile del risultato. "Lo ha detto l'IA" non è una difesa.

Questo non significa che l'IA a contatto con i clienti non debba essere deployata. Significa che il framework di governance che la circonda deve affrontare le seguenti domande: cosa è autorizzata a comunicare l'IA a nome dell'organizzazione, cosa è fuori perimetro, qual è il percorso di escalation quando l'IA è incerta, e quale meccanismo di revisione esiste per aggiornare l'IA quando le policy cambiano.

→ Vedi anche: La Policy di Governance AI che Ogni PMI Deve Adottare (Modello)

Pattern 5: Piloti Che Non Si Scalano

Il contesto: il divario verso la produzione

I casi sopra sono visibili perché coinvolgevano grandi organizzazioni e hanno attirato l'attenzione giornalistica. Il fallimento più comune è più silenzioso: un pilota IA che dimostra risultati promettenti in un ambiente controllato e poi si blocca al confine del deployment in produzione.

L'indagine globale McKinsey 2026 sullo Stato dell'IA ha rilevato che l'80% dei dipendenti dichiara guadagni di produttività grazie all'IA, mentre solo il 37% delle organizzazioni registra un impatto sull'EBIT. Una differenza costante tra le organizzazioni che colmano questo divario e quelle che non lo fanno è se riprogettano i processi intorno all'IA o vi inseriscono semplicemente l'IA. Gli high performer — il 6% di McKinsey con un impatto EBIT del 5% o più — hanno tre volte più probabilità di aver riprogettato fondamentalmente i processi.

I piloti hanno successo in condizioni controllate perché il controllo elimina le complicazioni che gli ambienti di produzione contengono: integrazioni di sistemi legacy che si comportano diversamente sotto carico, dati di casi limite esclusi dal pilota, utenti che non sono i primi adottanti che hanno testato il sistema, e processi organizzativi che non sono stati riprogettati per incorporare gli output dell'IA.

Il tasso di fallimento pilota-verso-produzione non è principalmente un problema tecnologico. È un problema di perimetro. I piloti che non includono un campione realistico delle complicazioni dell'ambiente di produzione non stanno effettivamente testando se il sistema funzionerà su scala.

→ Vedi anche: Dal Pilota alla Produzione: Perché il 70% dei Piloti IA Non Scala Mai

Il Diagnostico Post-Mortem

Ciò che i fallimenti documentati hanno in comune non è la complessità. Sono fallimenti di decisioni specifiche e identificabili prese prima del deployment. La tabella seguente mappa ogni pattern di fallimento al punto decisionale in cui era prevenibile.

Pattern di Fallimento	Punto Decisionale Radice	Prevenzione
Bias nei dati di addestramento	Audit e labeling dei dati	Verificare i dati di addestramento per bias nelle decisioni storiche prima della modellazione
Deriva del segnale proxy	Selezione delle metriche durante la progettazione del modello	Monitorare il risultato di business reale, non solo la metrica di addestramento
Gap di complessità del dominio	Progettazione della valutazione	Testare su dati di produzione reali e disordinati, non su campioni curati
Lacuna di responsabilità	Governance e perimetro di deployment	Definire la responsabilità prima del deployment; limitare il perimetro a ciò che la governance copre
Fallimento pilota-verso-produzione	Progettazione del pilota	Includere la complessità rappresentativa della produzione nel perimetro del pilota

Ognuna di queste decisioni avviene a monte della tecnologia. Non sono decisioni di tuning del modello o di infrastruttura. Sono decisioni di governance del progetto — il tipo che i dirigenti sono in posizione di richiedere piuttosto che delegare.

Domande Frequenti

Cos'è un post-mortem nel contesto dei progetti IA? Un post-mortem è un'analisi strutturata delle ragioni per cui un progetto è fallito, condotta dopo i fatti. Nell'IA, i post-mortem pubblici sono rari — le aziende raramente pubblicano le proprie analisi di fallimento. I casi in questo articolo sono stati documentati attraverso il giornalismo, la ricerca accademica e i contenziosi. Questi fallimenti sono esclusivi delle grandi aziende? No. I pattern — dati di addestramento che non rappresentano la realtà, segnali proxy che derivano, complessità del dominio che supera il segnale di addestramento, lacune di responsabilità e progettazioni di piloti che non riflettono le condizioni di produzione — appaiono in progetti IA di tutte le dimensioni. Le aziende specifiche sono grandi perché i progetti grandi attraggono più attenzione. Come si rileva la deriva del segnale proxy prima che diventi significativa? Impostate un monitoraggio che tenga traccia delle prestazioni del modello rispetto all'effettivo risultato di business — non la metrica sostitutiva utilizzata durante l'addestramento. Se la precisione della previsione del churn è stabile ma il tasso di churn reale sta aumentando, il proxy del modello si è disaccoppiato dal comportamento sottostante. Impostate soglie di alert su entrambi. Quale struttura di governance previene la lacuna di responsabilità vista nel caso Air Canada? Prima che qualsiasi IA a contatto con i clienti vada live, documentate: cosa questo sistema è autorizzato a comunicare, quali argomenti sono fuori perimetro e dovrebbero essere escalati a un umano, qual è la cadenza di revisione per mantenere aggiornato il contenuto del sistema, e chi è responsabile quando il sistema sbaglia. Una pagina scritta copre questo per la maggior parte dei deployment di medie dimensioni. Le organizzazioni dovrebbero evitare l'IA a causa di questi tassi di fallimento? No. I fallimenti in questo articolo sono istruttivi proprio perché sono prevenibili. Le organizzazioni che stanno generando risultati di business significativi dall'IA — il 6% degli high performer di McKinsey — non stanno evitando il rischio; stanno progettando processi per identificarlo e gestirlo a monte. La lezione dai post-mortem non è la prudenza. È una migliore governance del progetto.

→ Vedi anche: I 9 Errori di Implementazione IA Che Distruggono la Credibilità dei Manager