--- title: "Pulizia e organizzazione dei dati: da dove iniziare, in pratica" url: https://zerofive.ai/blog/approfondimenti/pulizia-organizzazione-dati canonical: https://zerofive.ai/blog/approfondimenti/pulizia-organizzazione-dati language: it published: 2026-03-17 updated: 2026-09-18 author: "ZeroFive.AI" tags: pulizia dati, data cleaning, organizzazione dati aziendali, qualità dati AI, deduplica anagrafiche abstract: "Come pulire e organizzare i dati aziendali in vista di progetti AI: priorità, problemi ricorrenti, pipeline ripetibili e gli errori che sprecano mesi." --- # Pulizia e organizzazione dei dati: da dove iniziare, in pratica Il momento in cui un'azienda decide di "mettere a posto i dati" è quasi sempre un buon momento arrivato nel modo sbagliato: un progetto AI si è incagliato, qualcuno ha aperto le tabelle vere, e la scoperta di anagrafiche triplicate e campi compilati a fantasia ha generato la richiesta più pericolosa del repertorio, puliamo tutto. Pericolosa perché "tutto" non è un perimetro, e i programmi di pulizia senza perimetro condividono il destino delle diete da lunedì: partenza solenne, tre settimane di rigore, abbandono silenzioso. Il lavoro sui dati si può invece impostare in modo che produca valore visibile in settimane e fondamenta riusabili negli anni, e la differenza sta quasi tutta nelle prime decisioni. ## Il perimetro lo detta il caso d'uso La prima decisione è cosa non pulire. I dati aziendali sono un continente, e la parte che serve ai primi casi d'uso AI è tipicamente una provincia: le entità che alimentano quel processo, le tabelle da cui il modello berrà, gli storici che servono ad addestrare. Partire da lì ha due vantaggi che il programma universale non avrà mai, un committente che aspetta il risultato (il progetto AI stesso, che finanzia e giustifica lo sforzo) e un criterio di completamento verificabile, perché "dati pronti per il caso d'uso X" è una condizione che si misura, "dati a posto" no. Dentro il perimetro, la seconda decisione è l'ordine dei lavori, e conviene seguire la gerarchia del danno. Prima le entità chiave, clienti, prodotti, fornitori, perché ogni difetto lì si propaga ovunque: deduplicare un'anagrafica clienti e stabilire una chiave univoca condivisa tra CRM e gestionale vale, da solo, più di mesi di ritocchi sui campi secondari. Poi le relazioni tra sistemi, cioè le riconciliazioni che oggi qualcuno fa a mano in un foglio di calcolo. Solo alla fine la cosmesi dei campi descrittivi, che è la parte visivamente gratificante e economicamente meno urgente. ## I quattro difetti che si incontrano sempre Le patologie dei dati aziendali sono sorprendentemente ripetitive, e riconoscerle accelera la diagnosi. I duplicati sono la prima: la stessa entità registrata più volte con varianti minime, "Rossi S.p.A.", "ROSSI SPA", "Rossi Spa (nuova)", che per un modello sono tre clienti diversi. Il rimedio ha una parte tecnica (matching e merge) e una parte organizzativa che la sopravvive, la regola su chi può creare nuove anagrafiche e con quali controlli, perché deduplicare senza chiudere il rubinetto è svuotare il mare con il secchio. Il secondo difetto sono i campi liberi usati come discarica: note che contengono informazioni strutturali (scadenze, importi e stati) perché il campo giusto non esisteva o nessuno lo compilava. Qui l'AI moderna offre paradossalmente un aiuto, perché l'estrazione di struttura da testo libero è uno dei suoi mestieri migliori, purché l'output torni in campi governati e non in altre note. Il terzo difetto sono i valori mancanti non casuali, i buchi che si concentrano in certi periodi o certe filiali e che, dati in pasto a un modello, diventano bias appresi. Il quarto sono le convenzioni divergenti, date in tre formati, unità di misura implicite, codifiche che ogni reparto ha piegato ai suoi usi: il rimedio si chiama standard dichiarato, e vale solo se qualcuno ne risponde. ## La pulizia che resta pulita L'errore tecnico più costoso dell'intero cantiere è pulire i dati invece di costruire la pulizia, cioè produrre un dataset sistemato una tantum che ricomincia a sporcarsi il giorno dopo. La forma giusta del lavoro è la pipeline: regole di validazione, deduplica e standardizzazione scritte come codice, versionate, eseguite a ogni aggiornamento, con metriche di qualità che escono a ogni esecuzione e un punto dove le eccezioni finiscono davanti a un occhio umano. La pipeline cambia anche l'economia del progetto, perché trasforma un costo ricorrente e invisibile (le ore che analisti e team spendono ogni mese a sistemare a mano) in un investimento una tantum con manutenzione, e quel risparmio ricorrente è spesso il business case più solido dell'intero programma dati, più solido persino del progetto AI che l'ha innescato. Resta la parte organizzativa, che decide la tenuta nel tempo: ogni regola di pulizia incorpora una scelta di business (quale dei due indirizzi è quello buono? sotto quale soglia un record si scarta?), e quelle scelte spettano agli owner dei dati, non a chi scrive la pipeline. Dove la data governance di cui abbiamo scritto esiste, questo passaggio è un flusso; dove non esiste, la pulizia la fa nascere per necessità, un dominio alla volta. Se state per aprire un cantiere dati in vista di progetti AI, il modo per non sprecare il primo mese è sapere in anticipo quali dati contano, in quale ordine e con quali soglie, che è esattamente la fotografia che l'AI Rating produce sulla dimensione Readiness: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. E se il cantiere è già aperto, una domanda di controllo vale l'intera retrospettiva: quello che state pulendo oggi, tra sei mesi sarà ancora pulito da solo?