Data readiness: perché i progetti AI muoiono sui dati

Nelle autopsie dei progetti AI falliti la tecnologia compare di rado tra le cause, i dati quasi sempre. RAND Corporation (2024) mette le fondamenta dati inadeguate tra le ragioni primarie di quel oltre 80% di progetti che manca il valore atteso, il MIT Project NANDA (The GenAI Divide, luglio 2025) individua nella scarsa prontezza dei dati e nella mancata integrazione nei flussi la radice del 95% di pilot GenAI senza impatto sul conto economico, e Gartner (2025) ha formulato la previsione più netta: entro il 2026 le organizzazioni abbandoneranno il 60% dei progetti AI non supportati da dati AI-ready.

Il paradosso è che i dati sono anche la causa di fallimento più prevedibile in assoluto, perché a differenza dello sponsor che cambia ruolo o del mercato che si muove, la loro condizione si può verificare per intero prima di spendere il primo euro. Basta volerlo fare, e sapere cosa guardare.

L'illusione del dataset da demo

Il meccanismo con cui i dati uccidono i progetti ha una dinamica ricorrente che abbiamo descritto parlando di pilot bloccati, e che merita di essere vista dal lato dei dati. Il pilot gira su un estratto curato: qualcuno che conosce bene un sistema ha esportato una tabella, l'ha pulita a mano, ha risolto i duplicati e riempito i buchi. Su quel materiale il modello funziona, la demo convince, il progetto accelera verso la produzione.

In produzione, però, il modello deve bere dalla fonte vera, e la fonte vera è un'altra cosa: anagrafiche clienti duplicate tra CRM e gestionale con chiavi che non si parlano, campi liberi compilati in dieci modi diversi in dieci anni, storici interrotti da migrazioni, dati freschi che arrivano con giorni di ritardo rispetto a quando servirebbero. Il lavoro manuale che aveva reso possibile la demo non è ripetibile ogni notte, e il progetto entra nella fase che consuma budget e pazienza, quella in cui si scopre che il vero cantiere non era il modello, era tutto ciò che sta prima.

Le domande che misurano la prontezza

La data readiness si lascia interrogare con domande concrete, e conviene farle per il caso d'uso specifico, perché dati ottimi per un'applicazione possono essere inservibili per un'altra. La prima riguarda l'accesso: i dati necessari sono raggiungibili in modo programmatico e ricorrente, o vivono dietro estrazioni manuali, fogli di calcolo personali, fornitori da pregare? La seconda riguarda la qualità misurata, che è cosa diversa dalla qualità percepita: esistono metriche di completezza, accuratezza e coerenza su quelle tabelle, o il giudizio si basa sul fatto che "il gestionale funziona"?

La terza domanda riguarda la ownership: per ogni fonte, c'è una persona che risponde della sua qualità e che può autorizzarne l'uso, o l'unico esperto è un collega che "quel sistema lo conosce"? La quarta riguarda il tempo, nelle sue due forme, la profondità storica sufficiente ad addestrare e la freschezza sufficiente a servire il processo. La quinta, spesso dimenticata, riguarda la legittimità: quei dati possono essere usati per quello scopo, con quella base giuridica, o il progetto sta costruendo su un trattamento mai valutato?

Un caso d'uso che risponde bene a tutte e cinque è raro, e va benissimo così: la readiness non chiede perfezione, chiede di conoscere i gap prima di partire e di metterli nel budget e nel piano, invece di scoprirli al momento peggiore.

Sistemare i dati senza l'alibi del progetto infinito

Davanti a un quadro dati mediocre, le organizzazioni oscillano tra due errori speculari. Il primo è partire lo stesso, confidando che "i dati li sistemiamo strada facendo", che è il copione esatto dei fallimenti censiti dalle ricerche citate. Il secondo è il rinvio a tempo indeterminato, il grande programma di data quality triennale che deve completarsi prima di qualunque AI, e che di solito muore di inedia perché nessun business case lo tiene in vita.

La via che vediamo funzionare è chirurgica: si sistemano i dati che servono al caso d'uso scelto, in profondità e con criteri di riuso, lasciando che sia la sequenza dei casi d'uso a estendere progressivamente il perimetro dei dati in ordine. Ogni progetto AI diventa così anche un investimento incrementale in fondamenta, con un ritorno visibile che finanzia il successivo, e la data readiness smette di essere un prerequisito astratto per diventare un sottoprodotto misurabile della roadmap.

La misura prima della scommessa

Nel nostro AI Rating la condizione dei dati attraversa la valutazione da parte a parte: pesa sulla Readiness (qualità, accessibilità e ownership delle fonti), condiziona la Delivery (pipeline e integrazione) e tocca il Risk, dove il presidio sui dati è uno dei gate critici non compensabili, in coerenza con quanto l'EU AI Act chiede sui dati dei sistemi ad alto rischio e con gli standard di qualità come ISO 8000. Il punteggio dice, prima dell'investimento, se il prossimo pilot poggia su roccia o su sabbia, e quanto costa consolidare.

Se avete un progetto AI in partenza nel 2026, l'esercizio più redditizio della settimana costa un'ora: prendete il caso d'uso e fategli le cinque domande di sopra, per iscritto, con i nomi delle fonti accanto. Se preferite farlo con metodo e con un punteggio confrontabile, ci trovate su calendly.com/fabiolalli/zerofive o a hello@zerofive.ai. La versione scomoda della domanda, quella che vale il budget intero, resta comunque una: il vostro prossimo modello, da dove berrà ogni notte?