Un chatbot AI meticolosamente addestrato fornisce risposte precise per settimane. Il team festeggia il lancio. Tre mesi dopo, il sistema è sicuro ma errato su un terzo delle domande. Nessuno ha modificato il modello o i prompt. Il mondo è cambiato: i prezzi si sono aggiornati, una policy aziendale è stata rivista, un prodotto ha rilasciato una nuova versione. Il knowledge store sottostante è rimasto fermo. Questo non è un caso isolato: è uno dei fallimenti produttivi più comuni nell'AI enterprise odierna, e la maggior parte dei team di data engineering non ha gli strumenti per intercettarlo.
Un fallimento invisibile
Un'applicazione AI non distingue se recupera dati da un vector store, un indice documentale o una chiamata API. In nessuna pipeline standard si verifica se ciò che viene servito è ancora corretto. Un documento sui prezzi obsoleto viene recuperato con la stessa sicurezza di uno aggiornato, perché il sistema valuta la rilevanza, non la correttezza. Un record con un campo mancante passa inosservato. L'errore è invisibile per progettazione: dati vecchi o incompleti ottengono punteggi alti di rilevanza e superano tutti i controlli. Il modello risponde con piena sicurezza perché il contesto appare autorevole. I cruscotti restano verdi. Il sistema sembra funzionare, ma è semplicemente sbagliato.
Sponsored Protocol
Un caso analogo è accaduto in una pipeline fintech: un sistema a monte ha modificato un campo senza avvisare i consumatori a valle. La pipeline non è fallita; ha propagato valori errati nei dashboard. L'unica verifica era sul completamento del job, non sulla correttezza dei dati. Il problema è emerso solo quando un cliente ha notato un'incoerenza. Che si tratti di un documento scaduto o di un campo mancante, la dinamica è la stessa: l'assenza di errore non equivale a correttezza, e senza un layer di validazione adeguato nulla individua il problema.
Perché è un problema di ingegneria dei dati
I team che incontrano questo fallimento tendono a sbagliare diagnosi, e lo fanno due volte. Prima incolpano il modello, provano un LLM diverso, aggiustano il prompt. Poi, escluso il modello, danno la colpa al retrieval layer e acquistano una soluzione migliore. Ma il vero problema è più a monte, nel layer di data engineering. AWS è entrata nella corsa al "context layer" con un knowledge graph che apprende dall'uso degli agenti. Snowflake ha lanciato Horizon Context e Cortex Sense per affrontare proprio il sintomo descritto: agenti che danno risposte errate con sicurezza perché nessuna logica di business governa i dati. Entrambe sono risposte reali, ma si collocano un livello sopra: un knowledge graph dipende da ciò che lo alimenta. Il vero problema è nel data engineering: i team controllano se un job è stato eseguito, non se i dati che ha spostato sono ancora veri. Il monitoraggio è costruito per la pipeline, non per i dati.
Sponsored Protocol
Ciò che manca: l'osservabilità dei dati
L'osservabilità dei dati è un concetto noto ma raramente implementato correttamente. La metrica rilevante non è una percentuale, ma la copertura: quanti dataset critici hanno una lineage interrogabile, contro quanti vivono solo nella mente di qualcuno. Uber ha costruito una piattaforma di qualità e osservabilità dei dati molto prima dell'esistenza del retrieval augmented generation. La sua Unified Data Quality platform supporta oltre 2.000 dataset critici e rileva circa il 90% degli incidenti di qualità prima che raggiungano i consumatori downstream. Netflix ha risolto un pezzo diverso dello stesso problema, creando un sistema di lineage aziendale che permette a chiunque di tracciare l'origine di un dataset e le trasformazioni subite, mappando le dipendenze tra topic Kafka, modelli ML e sperimentazione.
Sponsored Protocol
In pratica, possiamo pensare a quattro dimensioni misurabili. Correttezza: ogni record rispetta la forma e le regole previste, con tipi corretti, assenza di null inattesi, valori in range. Strumenti come Great Expectations e Soda gestiscono bene la validazione automatica a livello di riga e colonna. Freshness: i dati sono ancora aggiornati rispetto alla fonte, non solo rispetto all'ultimo controllo. Si traccia il tempo dall'ultimo aggiornamento per fonte, con SLA per dataset. Consistenza: lo stesso fatto viene letto allo stesso modo ovunque sia archiviato. Un controllo incrociato periodico tra destinazioni downstream, con soglia per il tasso di mismatch, è sufficiente. Lineage: si può tracciare ogni output fino alla sua fonte e a ogni trasformazione. Netflix ha costruito il suo sistema per rispondere proprio a questa domanda.
Sponsored Protocol
Niente di tutto ciò richiede infrastrutture che la maggior parte dei team dati non possiede già. In Socure, i dati dei clienti arrivavano in forme arbitrarie, a volte errati silenziosamente. La sfida era costruire un sistema che identificasse i dati scorretti prima che si propagassero a valle. Great Expectations è diventato parte della fondazione: validazione dello schema e dei range all'ingestione, SLA per freshness, controlli incrociati per consistenza e lineage a livello di file. Il tutto basato su un pattern write-audit-publish: i dati arrivavano in staging, venivano validati, e solo se superavano i controlli venivano spostati a valle. Il risultato è stata una migliore accuratezza in reporting, modelli ML e recupero AI.
Cosa fare lunedì mattina
Se gestisci sistemi AI basati su retrieval in produzione, la domanda diagnostica non è quale modello provare o quale architettura di retrieval adottare. Sono quattro domande più mirate: i dati di base sono validati secondo gli standard richiesti dai consumatori? Qual è il contenuto più vecchio attualmente servito con alta sicurezza? Due blocchi della stessa fonte potrebbero contraddirsi nello stesso risultato di retrieval? Saresti in grado di tracciarne l'origine se risultasse errato? Se non sai rispondere, il divario è nella pipeline tra i sistemi sorgente e ciò che il tuo agente legge. È una correzione di data engineering, non un cambio di modello o un vendor migration. Che tu stia costruendo pipeline di reporting, sistemi ML o agenti AI, correttezza, freshness, consistenza e lineage sono ciò che rende i dati affidabili. L'AI si limita a esporre debolezze che esistono da sempre nell'ingegneria dei dati.
Sponsored Protocol
