ThinkPink Studio Logo
ThinkPink Studio
BlogShopAcademy🐛 Bug Party
DATAQUALITY
LLM
DIAGNOSIAUTOMATICA
ROOTCAUSEANALYSIS
DATAENGINEERING
COSTINASCOSTI
THINKPINKSTUDIO
DATAOBSERVABILITY
TECHDEBT
PMI
INNOVAZIONEREALE

Dati Marci, Tool Inutili e Notti in Bianco: Cronaca di un Disastro Annunciato

TP

ThinkPink Studio

13 maggio 2026

Dati Marci, Tool Inutili e Notti in Bianco: Cronaca di un Disastro Annunciato

Quel Martedì Notte Che Conosciamo Tutti

Sono le due del mattino. Il caffè sa di bruciato e la dashboard che hai davanti pure. È arrivato un alert: errore di chiave esterna sulla tabella `orders`. Tre righe. Il tool di data quality, quello che ti hanno venduto come la soluzione a ogni male, ti ha detto cosa è andato storto. Grazie tante. Peccato che non ti dica il perché. E così parte la solita via crucis. Apri tre notebook, scrivi query che sembrano bestemmie in SQL, spulci log di pipeline che neanche un monaco amanuense avrebbe la pazienza di decifrare. Ti perdi nel labirinto delle dipendenze. Tre ore della tua vita, andate. E alla fine, scopri l'inghippo: un account di test cancellato di fretta, lasciando orfani i suoi ordini. Per sistemare ci metti dieci minuti. Per trovare la causa, tre ore di sonno perse. Questa non è sfortuna. È la normalità. È il fallimento sistemico di un'intera categoria di software che promette di risolvere problemi ma, in realtà, si limita a segnalarteli.

Il Costo Reale di un "FAILED" Gridato nel Vuoto

Ammettiamolo, la maggior parte degli strumenti di data quality sul mercato sono bravissimi a fare una cosa: creare rumore. Ti inondano di notifiche, ma quando si tratta di trovare la causa del problema, sei solo. E quel "Costo Nascosto", come lo chiamiamo noi in ThinkPink Studio, non è una riga in un bilancio. È il tempo dei tuoi ingegneri migliori, buttato a fare un lavoro da detective che una macchina dovrebbe fare in automatico. I numeri sono un pugno nello stomaco. Si parla di una media di 12,9 milioni di dollari all'anno bruciati dalle aziende per colpa di dati di scarsa qualità. Per le nostre PMI a Rosignano, che lottano su ogni centesimo, una cifra del genere è fantascienza, ma il concetto è lo stesso: una perdita secca che può arrivare al 25% del fatturato. Negli USA, il disastro ha raggiunto i 617 miliardi di dollari nel 2026. Una cifra che fa girare la testa.

Ma il denaro è solo una parte del problema. C'è il costo umano. Gli ingegneri passano fino al 60% del loro tempo a "pulire" e a fare debug, invece di costruire cose che funzionano e che portano soldi. In media, ci vogliono 15 ore per chiudere un incidente legato ai dati. Quindici ore. Pensa a cosa significa per le decisioni che contano, per una campagna di marketing che va a gambe all'aria, per un modello di AI che impara spazzatura. A proposito, più dell'80% dei progetti di AI/ML fallisce proprio per questo. Una catastrofe. Con il cloud, l'IoT e pipeline di dati che sono diventate più complesse di un albero genealogico dei Medici, la visibilità sullo stato di salute dei dati non è un lusso. È una questione di sopravvivenza. Non a caso, il mercato della data observability sta esplodendo, con una stima di 8,32 miliardi di dollari entro il 2034. Chi non si adegua, è fuori.

Smettere di Mettere Pezze, Iniziare a Curare la Malattia

Certo, tool open-source come Great Expectations, Soda Core o i test di dbt hanno il loro perché. Li abbiamo usati anche noi. Ma sono un semaforo che sa dirti solo "rosso" o "verde". Quando è rosso, tanti saluti. Ti lasciano a piedi. In ThinkPink, il nostro DNA un po' toscano e un po' ugandese ci ha insegnato due cose: non ci accontentiamo di risposte a metà e sappiamo come risolvere problemi complessi con quello che abbiamo. Senza fare il giro del fumo.

Per questo abbiamo iniziato a sporcarci le mani con un'idea diversa: usare un LLM (Large Language Model) non per sostituire i tool di validazione, ma per potenziarli. Il concetto è brutale nella sua semplicità: il motore di regole, veloce e stupido, fa il suo lavoro. Ma quando qualcosa fallisce, entra in gioco l'LLM. Non per fare chiacchiere, ma per fare una diagnosi. Gli diamo in pasto la regola fallita, le righe incriminate, lo schema della tabella e uno storico di problemi simili. E lui ti spiega cosa è successo, perché, e come rimediare. Esattamente come farebbe quell'ingegnere senior che hai svegliato alle due di notte.

Torniamo all'esempio della chiave esterna. Invece di un inutile "FAILED", il sistema ti darebbe un output così:

Rule: orders_customer_fk (critical)
Table: orders
Failed: 3 rows

Explanation:
  3 ordini fanno riferimento al customer_id=99 che non esiste più
  nella tabella dei clienti. Qualsiasi report basato su JOIN, tipo
  quello sul fatturato, ignorerà questi ordini.
  # Qui è dove il reparto vendite inizia a urlare, di solito.

Likely cause:
  Il customer_id=99 sembra un account di test che è stato cancellato
  senza prima eliminare gli ordini collegati. Un classico.

Recommended action:
  1. SELECT * FROM orders WHERE customer_id = 99
  2. Controlla la tabella customers: l'id=99 è stato cancellato di recente?
  3. Se sono dati di test: DELETE FROM orders WHERE customer_id = 99
  4. Aggiungi un constraint di chiave esterna per evitare che risucceda.
     # Fatelo, per l'amor del cielo.

Proposed SQL:
  DELETE FROM orders WHERE customer_id NOT IN (SELECT id FROM customers);

Questa non è una notifica. È una consulenza. Un processo che va dritto al punto: valida → classifica → diagnostica → trova la causa → scrivi l'SQL → chiudi il ticket. E il costo? Ridicolo. Con Claude Haiku, per diagnosticare 11 fallimenti, abbiamo speso mezzo centesimo. Se lo fai girare in locale con Ollama, ti costa zero. Niente.

Il vero colpo di genio, però, è usare l'AI per *generare* le regole. Invece di farti scrivere a mano centinaia di test, un comando analizza lo schema del database e le policy aziendali (tipo "il campo status può essere solo A, B o C") e ti prepara una bozza dei controlli da implementare. È come avere un junior che ti prepara il lavoro sporco, ma lo fa bene.

Non stiamo parlando del futuro. Il mercato globale della data quality basata su LLM raggiungerà i 5,4 miliardi di dollari entro il 2030. Un sistema del genere macina log in secondi, trova correlazioni che a un umano sfuggirebbero e ti avvisa *prima* che il disastro accada. Trasforma la caccia alla causa da un'attività reattiva e costosa a una capacità strategica.

Come Sopravvivere nell'Economia dei Dati (Senza Essere Google)

Per una PMI italiana, gestire la qualità dei dati sembra una montagna da scalare. Ma è proprio qui che il nostro approccio da "insider con le mani in pasta" fa la differenza. Avere un sistema di diagnosi automatica significa che anche un team piccolo può operare con la stessa efficacia di una squadra di veterani. I nostri ragazzi a Kampala, che sono maestri nel risolvere casini complessi con due spiccioli, ce lo dimostrano ogni giorno. Quando sai che puoi fidarti dei tuoi dati, in tempo reale, puoi permetterti di essere audace. Puoi aggredire un nuovo mercato, lanciare un prodotto, ottimizzare i processi. Non devi essere una multinazionale per avere dati di qualità élite. Devi solo essere più furbo.

Noi Non Vendiamo Tool, Risolviamo Rogne

Se i dati sono il nuovo petrolio, noi siamo quelli che capiscono perché la trivella si è bloccata a 200 metri di profondità e sanno come tirare su un accrocchio per farla ripartire prima dell'alba. Non siamo qui per venderti l'ennesima dashboard scintillante. Siamo qui per darti un metodo, un modo di pensare che trasforma un costo nascosto in un vantaggio competitivo. È ora di finirla con la favoletta che la diagnosi dei dati debba essere un lavoro manuale per gente con troppo caffè in corpo. L'AI non è un trend, è l'unica via per non ritrovarsi tra un anno con un software che non serve a niente e un business che va al rallentatore. Quella di oggi non è una scelta tecnica, è una scelta di sopravvivenza.

Se hai capito che stai buttando tempo e soldi, forse è il caso di parlarne.

Torna al blog

Ultimo aggiornamento: