Quando un pilota AI viene archiviato come fallimento, il verbale quasi sempre punta al modello. Nella maggior parte dei casi il modello ha fatto esattamente il suo lavoro: ha restituito, con precisione, il disordine che gli è stato dato in pasto.
Le survey di McKinsey sull’adozione AI lo ripetono da anni: la frizione che impedisce ai progetti di scalare non è la qualità del modello, ma la governance dei dati. Sistemi scollegati, dataset con proprietari diversi in reparti diversi, standard di qualità incoerenti, protocolli di accesso mai definiti. Un modello che legge questo produce output inaffidabili, e l’inaffidabilità erode la fiducia di chi firma i budget molto più in fretta di quanto qualsiasi demo la costruisca.
Il punto che di solito si salta è questo: l’accuratezza non è una proprietà del modello preso da solo, è una proprietà del modello più i dati che tocca. Metti lo stesso identico modello sopra un data layer governato e sopra un archivio frammentato: ottieni due sistemi con affidabilità opposte. Misurare l’accuratezza senza governare gli input significa misurare rumore.
Da qui la conseguenza scomoda: il modello non è più il vantaggio competitivo, è la stessa API per tutti. Il fossato sta sotto, nei dati puliti, tracciabili, con accessi chiari, su cui un sistema può lavorare lasciando una traccia verificabile di cosa ha letto e perché. Le aziende che hanno scalato hanno costruito quel fondamento prima del deployment, non dopo il primo pilota andato male.
