Guide pratiche

Un framework per la qualità dei dati nei progetti di IA

Una guida pratica per definire standard di qualità dei dati nei progetti di IA e machine learning. Tratta l’analisi dei dati, le regole di validazione, il monitoraggio e le buone pratiche di governance.

AI.info Team · 2026-08-10

Perché la «qualità dei dati» richiede un framework, non una lista di controllo

La maggior parte dei team di IA scopre i problemi di qualità dei dati nel modo più costoso: l’accuratezza di un modello cala in produzione, tre settimane dopo qualcuno risale a una modifica dello schema di una tabella sorgente a monte e, nel frattempo, le previsioni errate sono già state distribuite. Un framework per la qualità dei dati è semplicemente l’insieme delle dimensioni da verificare, degli strumenti che le verificano e dei punti della pipeline in cui i controlli vengono eseguiti automaticamente, invece di affidarsi al fatto che qualcuno si accorga del problema.

Per partire con un approccio adatto ai principianti, non servono tutti gli strumenti di questa guida fin dal primo giorno. Occorre conoscere le sei dimensioni che contano, scegliere uno strumento di validazione adatto al proprio stack e inserire controlli nei due o tre punti della pipeline in cui i dati errati entrano effettivamente: acquisizione, trasformazione e fase precedente all’addestramento.

Le sei dimensioni fondamentali

Questa guida usa sei dimensioni fondamentali; altri framework per la qualità dei dati ne adottano insiemi diversi. Prima di scegliere gli strumenti, definitele in modo concreto per i vostri dati.

• Completezza — i campi obbligatori sono compilati? Per esempio: quale percentuale dei valori customer_id o email è nulla in una tabella in cui quei campi non dovrebbero mai contenere valori nulli.
• Accuratezza — i dati rispecchiano la realtà? Per esempio: una birth_date nel 2087 o un price pari a -50 sono dati presenti, ma non accurati.
• Coerenza — gli stessi fatti concordano tra sistemi e nel tempo? Per esempio: il campo country di un cliente riporta «US» nel CRM e «United States» nel data warehouse.
• Tempestività — i dati sono abbastanza aggiornati da essere utili? Per esempio: una tabella del feature store che dovrebbe aggiornarsi ogni ora ma non viene aggiornata da due giorni.
• Validità — i dati rispettano i formati, i tipi e gli intervalli definiti? Per esempio: una colonna email con valori che non sono stringhe di indirizzi email validi, oppure una colonna categoriale status contenente un valore estraneo all’insieme di quelli ammessi.
• Unicità — ci sono record duplicati dove non dovrebbero essercene? Per esempio: lo stesso order_id compare due volte dopo un nuovo tentativo fallito in un processo ETL.

In pratica, la maggior parte dei team inizia predisponendo controlli di completezza, validità e unicità: sono i meno costosi da eseguire e intercettano la maggior parte degli errori delle pipeline. Aggiunge poi coerenza e tempestività quando dispone di dati provenienti da più sistemi o di dati in streaming, e infine l’accuratezza, che di solito richiede regole specifiche del settore di attività o dati di riferimento.

Dove inserire i controlli nella pipeline

Un modo utile per pensarci: la qualità dei dati non è un singolo strumento, ma un livello presente in tre fasi.

1. Durante l’acquisizione — convalidate i dati in arrivo rispetto a uno schema o a un contratto prima che vengano archiviati. È qui che potete intercettare a basso costo le modifiche agli schemi a monte e i record malformati, prima che si propaghino.
2. Nel livello di trasformazione o nel data warehouse — verificate le tabelle da cui le pipeline di analisi e di creazione delle feature leggono effettivamente i dati. È qui che si collocano i test dbt e i controlli basati su SQL.
3. Nelle pipeline di machine learning basate su Python — convalidate i dataframe destinati alla creazione delle feature o all’addestramento, e convalidate le etichette prima che vengano usate per addestrare i modelli. È qui che si collocano Great Expectations, Pandera e le metriche di controllo della qualità delle etichette.

Ogni fase trae vantaggio da uno strumento diverso e la maggior parte dei team con processi consolidati ne usa più di uno.

Come scegliere gli strumenti se si è agli inizi

Due di questi sei strumenti hanno cambiato responsabile nel 2026 senza che le loro API cambiassero. Fivetran e dbt Labs hanno completato la loro fusione il 1° giugno 2026 e Fivetran ha annunciato il 13 maggio 2026 che avrebbe assunto la gestione della comunità open source di Great Expectations e del progetto GX Core. Entrambi rimangono open source e nessuno dei due cambiamenti ha reso non valido il codice riportato di seguito.

Non servono tutti e sei. Un percorso comune per chi è agli inizi: dbt tests per le tabelle del data warehouse (perché probabilmente usate già dbt), Pandera o Great Expectations per la pipeline Python che costruisce il dataset di addestramento ed Evidently quando il modello è in produzione e occorre monitorare il drift.

Primi passi con i test di dbt

Se i tuoi dati passano già attraverso dbt, questo è il punto di partenza che richiede meno lavoro. I test di dbt sono query SQL che restituiscono le righe che non superano il controllo: se non ne restituiscono nessuna, il test è superato. dbt Core include quattro test generici pronti all’uso: not_null, unique, accepted_values e relationships.

Tutti e quattro sono rimasti invariati anche dopo il più grande cambiamento nella storia del progetto. Il 1 giugno 2026, giorno in cui si è conclusa la fusione con Fivetran, dbt Labs ha rilasciato la prima versione alpha di dbt Core v2.0: il nucleo di Fusion, il motore basato su Rust, è stato pubblicato nel repository dbt-core con licenza Apache 2.0 e ora costituisce il runtime condiviso dalle distribuzioni open source e commerciali. Il motore sottostante è cambiato; la sintassi dei test in schema.yml qui sotto no.

# models/schema.yml
models:
  - name: customers
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null
      - name: signup_country
        tests:
          - accepted_values:
              values: ['US', 'CA', 'GB', 'DE', 'FR']
      - name: plan_id
        tests:
          - relationships:
              to: ref('plans')
              field: plan_id

Esegui dbt test nella CI a ogni pull request e, secondo una pianificazione prestabilita, sulle tabelle di produzione. Quando i quattro test integrati non bastano più, aggiungi il pacchetto dbt-expectations per i controlli sull’aggiornamento dei dati, sulla loro distribuzione e per la logica che coinvolge più colonne.

Validare i dataframe con Pandera

Pandera permette di definire uno schema una volta sola e usarlo per validare i dataframe pandas, polars o PySpark ovunque compaiano nel codice. È particolarmente utile subito prima di una fase di feature engineering o di addestramento.

Importa dal modulo specifico per il backend, non da quello di primo livello. Dalla v0.24, definire uno schema pandas tramite import pandera as pa genera un FutureWarning che indica di usare import pandera.pandas as pa; i moduli equivalenti sono pandera.polars e pandera.pyspark. Nei vecchi tutorial compare ancora l’importazione dal modulo di primo livello: copiarne uno è il modo più rapido per riempire i log di avvisi di deprecazione.

import pandera.pandas as pa
from pandera.pandas import Column, Check, DataFrameSchema

training_data_schema = DataFrameSchema({
    "user_id": Column(int, Check.greater_than(0), nullable=False),
    "age": Column(int, Check.in_range(0, 120)),
    "signup_date": Column(pa.DateTime),
    "churned": Column(int, Check.isin([0, 1])),
    "email": Column(str, Check.str_matches(r"^[^@]+@[^@]+\.[^@]+$")),
}, strict=True)

# Raises pandera.errors.SchemaErrors with a readable diff if validation fails
validated_df = training_data_schema.validate(df, lazy=True)

Impostando lazy=True, tutte le violazioni vengono raccolte in un unico resoconto degli errori, anziché interrompere la validazione alla prima. È utile quando vuoi vedere l’intera portata di un problema di qualità dei dati in una sola esecuzione, invece di risolvere un problema alla volta.

Validazione dichiarativa con Great Expectations

Great Expectations, distribuito come GX Core e ancora nella serie 1.x, è un’opzione più complessa ma più facile da sottoporre a verifica: definisci le «Expectations» (singole asserzioni), le raggruppi in una Expectation Suite, associ la suite a un Batch di dati tramite una Validation Definition e la esegui attraverso un Checkpoint. Quest’ultimo può essere configurato con UpdateDataDocsAction per produrre i Data Docs: un report HTML generato automaticamente che mostra quali controlli sono stati superati e quali no. Funziona con pandas, Spark, i data warehouse accessibili tramite SQLAlchemy e le fonti di dati più comuni.

import great_expectations as gx

context = gx.get_context()

data_source = context.data_sources.add_pandas("pandas_datasource")
data_asset = data_source.add_dataframe_asset(name="training_data")
batch_definition = data_asset.add_batch_definition_whole_dataframe("training_data_batch")

suite = context.suites.add(
    gx.core.expectation_suite.ExpectationSuite(name="training_data_suite")
)
suite.add_expectation(gx.expectations.ExpectColumnValuesToNotBeNull(column="user_id"))
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeBetween(column="age", min_value=0, max_value=120)
)
suite.add_expectation(gx.expectations.ExpectColumnValuesToBeUnique(column="user_id"))

validation_definition = context.validation_definitions.add(
    gx.core.validation_definition.ValidationDefinition(
        name="training_data_validation", data=batch_definition, suite=suite
    )
)
checkpoint = context.checkpoints.add(
    gx.checkpoint.checkpoint.Checkpoint(
        name="training_data_checkpoint", validation_definitions=[validation_definition]
    )
)

result = checkpoint.run(batch_parameters={"dataframe": df})
if not result.success:
    raise ValueError("Data quality validation failed — see the validation result for details")

Il vantaggio rispetto alle asserzioni scritte caso per caso è il risultato prodotto: i Data Docs offrono anche a chi non è ingegnere, come un responsabile della gestione dei dati o un product manager, un report leggibile senza dover toccare il codice. La Suite diventa inoltre una definizione versionata e verificabile di «come devono essere i dati di buona qualità» per quel dataset.

Contratti sui dati: individuare i problemi prima che diventino un problema per voi

Tutto quanto descritto finora convalida i dati dopo il loro arrivo. Un contratto sui dati sposta il controllo a monte: è un accordo esplicito e soggetto a versionamento tra il team che produce un dataset e i team che lo utilizzano. Specifica lo schema, le regole di qualità e la frequenza degli aggiornamenti a cui il produttore si impegna. L’Open Data Contract Standard (ODCS), mantenuto dal progetto Bitol nell’ambito della Linux Foundation, è una specifica basata su YAML pensata proprio per questo: schema, regole di qualità dei dati, SLA e responsabilità in un unico documento che entrambe le parti possono confrontare con un diff e sottoporre a versionamento in git. Fissate la versione rispetto alla quale scrivete il contratto: la v3.2.0, rilasciata a settembre 2026, è quella attuale.

Per i dati in streaming, il meccanismo equivalente è uno schema registry (Confluent Schema Registry è la scelta più comune per Kafka), che applica le regole di compatibilità dello schema al momento della scrittura e respinge i produttori che comprometterebbero il funzionamento dei sistemi che consumano i dati. Il principio, in entrambi i casi, è questo: invece di scoprire una modifica incompatibile dello schema quando la suite di convalida fallisce a valle, il contratto impedisce al produttore di apportarla — o quantomeno gli impone di attribuirle una nuova versione — prima che venga distribuita.

Monitoraggio delle variazioni dello schema e dei dati in produzione

I contratti sui dati e le suite di convalida individuano i problemi al momento della scrittura. Una volta che un modello è operativo, occorre anche tenere d’occhio i cambiamenti graduali che nessun singolo controllo rileverebbe da solo:

• Variazione dello schema — una colonna viene rinominata, un tipo passa da intero a stringa oppure un campo, senza che nessuno se ne accorga, comincia più spesso ad arrivare come null. Il modo migliore per rilevarla è ripetere la stessa convalida dello schema (test Pandera, GX o dbt) su ogni batch, non soltanto una volta durante la creazione.
• Variazione dei dati — la distribuzione statistica delle feature in arrivo cambia anche se lo schema resta invariato (per esempio, la distribuzione dell’età dei clienti cambia dopo una campagna di marketing rivolta a un nuovo segmento). Evidently, una libreria Python open source, è pensata per questo: confronta un dataset di riferimento con i dati attuali di produzione mediante test statistici (Kolmogorov-Smirnov per le feature numeriche, chi quadrato per quelle categoriali nei dataset più piccoli e metriche di distanza come la distanza di Wasserstein in quelli più grandi). Può produrre report HTML, inviare metriche a Grafana o essere eseguita come fase di un DAG di Airflow.

Una configurazione pratica: eseguite i controlli di schema e validità (test dbt, Pandera o GX) a ogni esecuzione della pipeline, come requisito vincolante in grado di bloccare un deploy, ed eseguite il rilevamento delle variazioni (Evidently) a intervalli programmati, come segnale meno vincolante che attivi un avviso da sottoporre a una persona. Una variazione, infatti, non significa sempre che qualcosa si sia rotto: può anche significare che è cambiato il mondo.

Qualità dell’etichettatura: la dimensione che sfugge agli strumenti per i dati tabellari

Se il vostro progetto comprende dati di addestramento etichettati da persone — immagini annotate, testi etichettati, feedback umano — le sei dimensioni precedenti restano valide, ma il principale indicatore di qualità è diverso: l’accordo tra annotatori (IAA). Quando più persone etichettano gli stessi esempi, l’accordo misura quanto sia coerente la loro interpretazione del compito di etichettatura. Le misure più comuni sono il Kappa di Cohen (due annotatori) e l’Alpha di Krippendorff (più di due annotatori, oppure etichette mancanti).

Per chi è agli inizi, ci sono due cose da sapere:

• Un accordo basso di solito significa che le linee guida per l’etichettatura sono ambigue, non che gli annotatori siano poco attenti. Correggete le linee guida e misurate di nuovo l’accordo prima di concludere che servano annotatori migliori.
• Un accordo alto è necessario, ma non sufficiente: se tutti gli annotatori applicano con coerenza la stessa regola sbagliata, l’accordo risulterà ottimo anche se le etichette resteranno errate. Affiancate all’IAA una revisione periodica, da parte di esperti, di un campione casuale; non affidatevi soltanto all’IAA.

In pratica, calcolate l’IAA su un campione di sovrapposizione del 5-10% di ogni batch di etichettatura e trattate un calo persistente dell’accordo come un test dello schema fallito: impedite che il batch entri nei dati di addestramento finché non ne avrete accertato la causa.

Un piano di adozione per chi è agli inizi

Se introducete queste pratiche in un’organizzazione che non dispone ancora di strumenti per la qualità dei dati, una sequenza realistica è questa:

1. Scegliete 3-5 tabelle o dataset che alimentano il vostro modello più importante e scrivete test not_null, unique e accepted_values per le colonne critiche (test dbt se usate dbt; altrimenti Pandera o GX).
2. Integrate i test nella CI, così che una pull request che li farebbe fallire venga respinta prima del merge, e nelle esecuzioni programmate della pipeline, così che i dati di produzione vengano controllati continuamente, non soltanto durante la creazione.
3. Aggiungete un contratto sui dati (anche un semplice file YAML scritto a mano secondo la struttura ODCS) per la dipendenza a monte più fragile: quella che in passato ha già causato il malfunzionamento della vostra pipeline.
4. Quando il modello è in produzione, aggiungete il monitoraggio delle variazioni con Evidently per le feature più importanti e impostate una soglia di avviso, invece di cercare di esaminare manualmente ogni report.
5. Se l’etichettatura fa parte della vostra pipeline, iniziate a misurare l’IAA sui nuovi batch di etichettatura prima di usarli per l’addestramento, non dopo aver constatato che un modello addestrato su quei dati rende meno del previsto.

Non occorre realizzare tutto questo in una volta. I team che ottengono risultati con i framework per la qualità dei dati sono quelli che iniziano controllando automaticamente una o due dimensioni e poi ampliano i controlli, non quelli che cercano di predisporre il monitoraggio di tutte e sei le dimensioni per ogni tabella prima di distribuire alcunché.