--- title: "Data readiness: perché i progetti AI muoiono sui dati" url: https://zerofive.ai/blog/approfondimenti/data-readiness-progetti-ai canonical: https://zerofive.ai/blog/approfondimenti/data-readiness-progetti-ai language: it published: 2026-03-03 updated: 2026-09-18 author: "ZeroFive.AI" tags: data readiness, dati per AI, qualità dati progetti AI, AI-ready data, fallimento progetti AI dati abstract: "La causa più citata di fallimento dei progetti AI sono i dati. Cos'è la data readiness, come si verifica prima di investire e cosa fare quando manca." --- # 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?