"Chi pensa che per fare un salto di qualità serva il modello AI più costoso sul mercato?"
Quando ho fatto questa domanda durante l'ultima Masterclass "AI for business", quasi tutti hanno alzato la mano.
Risposta sbagliata.
Un modello da 10 milioni vale zero, se i dati sono sbagliati
Oggi si parla tanto di quanto è potente un modello: GPT-5, Claude Opus 4.7, Gemini 3 Ultra, parametri, benchmark, costi per token. Ma nei progetti reali la potenza è altrove.
La vera potenza è nel dato pulito, accessibile e tracciabile.
Il modello è l'ultimo pezzo della catena, non il primo. Se ogni reparto ha il suo database, dove vive l'AI? Da nessuna parte di utile.
Perché i progetti AI nel manifatturiero falliscono
Lo dicono i numeri: l'80% dei progetti AI nel manifatturiero non arriva in produzione. Non per limiti dell'algoritmo. Per i dati. Ecco le cause ricorrenti che vediamo nei nostri assessment.
1. Database a compartimenti stagni
Produzione, qualità, logistica, vendite, manutenzione: ognuno ha il suo gestionale, il suo Excel, il suo MES, il suo CRM. I dati esistono, ma non parlano tra loro. Il prodotto fisico attraversa l'intero stabilimento; il suo dato si ferma al primo confine reparto.
L'AI ha bisogno di vedere il processo end-to-end: dall'ordine cliente alla spedizione, passando per acquisti, produzione, qualità. Se i sistemi sono isolati, qualunque modello rimane cieco.
2. Nessun ownership chiaro
"Chi è responsabile della qualità dei dati di produzione?" — silenzio in sala. Tipicamente i dati sono di tutti e di nessuno: l'IT li ospita, il reparto li produce, nessuno li valida.
Senza un data owner per dominio, gli errori non vengono mai sistemati. Si accumulano in retroattività. Quando il modello AI legge il dato, eredita anni di sporcizia.
3. Schema disallineati
Lo stesso oggetto del business — un ordine, un articolo, un fornitore — ha 5 codici diversi in 5 sistemi diversi. La riconciliazione viene fatta a mano da Excel, una volta al mese, da un consulente esterno.
L'AI ha bisogno di un'ontologia unica: cosa è un cliente, cosa è un prodotto, cosa è un'anomalia. Senza questa standardizzazione, il training del modello è statisticamente rumoroso.
4. Compliance e silos forzati
In alcuni settori (sanità, finance, food) ci sono vincoli regolatori reali che frammentano l'accesso ai dati. Ma spesso il silo regolatorio diventa scusa per silos organizzativi che non hanno giustificazione legale.
Una governance ben fatta distingue tra ciò che la legge impone e ciò che è cattiva abitudine. Senza questa distinzione, l'AI non scala mai oltre il pilota.
5. Sistemi legacy che non rilasciano i dati
ERP installati 15 anni fa, MES customizzati che nessuno sa più toccare, gestionali "made in zia" senza API. Tirare fuori i dati richiede export CSV manuali, query SQL contro database non documentati, integrazioni custom costose.
Risultato: il progetto AI si trasforma per il 70% del budget in un progetto di data integration. Spesso si scopre solo dopo aver firmato il contratto col vendor AI.
6. Investimento in shiny AI invece che in plumbing
I CFO trovano facile firmare €200k per "l'AI". Trovano impossibile firmare €200k per "rifare lo schema del database materie prime". Eppure il secondo investimento sblocca 10 progetti AI; il primo, da solo, ne sblocca zero.
Questo è il bias del visibile: l'AI è marketabile, la governance no. Ma è la governance a generare il ROI.
Cosa fare prima del modello
La scaletta corretta per un progetto AI con impatto industriale è questa:
- Audit dei data domain. Mappare quali dati esistono, dove sono, in che stato. Quasi sempre la sorpresa è amara.
- Definire data owner per dominio. Una persona per ciascuna entità chiave (cliente, prodotto, ordine, anomalia, ecc.). Non è IT, è business.
- Standardizzare l'ontologia. Un codice unico per ogni entità, mappato a tutti i sistemi sorgente.
- Unificare le fonti. Data warehouse, data lake o data fabric — a seconda della maturità. L'obiettivo: un layer unico da cui l'AI legge.
- Quality gates automatici. Validazioni sul dato all'ingresso del layer unificato. Reject early, fix at source.
- Lineage e tracciabilità. Sapere da dove arriva ogni dato, quando è stato aggiornato, da chi. Critico per debug AI e compliance.
- Solo a questo punto: scegliere il modello. A questo punto la scelta del modello diventa quasi banale: si sceglie per costo/latenza/privacy. La qualità dell'output è già garantita dal dato a monte.
L'AI non risolve il caos. Lo amplifica.
Se applichi l'AI su dati disorganizzati, stai automatizzando l'inefficienza. Stai pagando €200k per produrre più velocemente errori che facevi già a mano.
Il C-level che ragiona su AI deve farsi una domanda prima di "quale modello":
"I miei dati sono pronti per essere letti da un algoritmo?"
Se la risposta è no — e in 8 casi su 10 è no — la priorità è la data governance. Non l'algoritmo.
L'algoritmo arriva dopo, e a quel punto può essere anche economico. È il dato pulito a fare la differenza.
Vuoi un assessment della data readiness della tua azienda prima di partire con un progetto AI? Parla con noi.