Data cleaning, data quality e feature engineering

Nel lavoro sui dati l’AI non deve trasformare l’analisi in una sequenza di risposte che nessuno può verificare. Il valore sta nel progettare un flusso operativo dove domanda, dati, controlli e decisioni rimangono trasparenti e tracciabili. L’approccio riprende la lezione precedente su SQL, notebook e data storytelling con AI e aggiunge un livello più operativo: mantenere ownership su definizioni, soglie, segmenti e raccomandazioni mentre cresce la velocità e la copertura del lavoro.

Una scena da cui partire

Immagina una review settimanale in cui marketing, prodotto e data team devono decidere cosa correggere per primo: funnel, tracking, campagna, modello o pipeline. Senza AI a supporto, l’analista perde ore in passaggi ripetitivi. Con l’AI usata male, ottiene spiegazioni convincenti ma fragili. La differenza la fa il disegno operativo: l’AI sostiene ipotesi, checklist, controlli, sintesi e output, ma non sostituisce la verifica del dato, la responsabilità della metrica o la scelta business. Ogni passaggio lascia una traccia leggibile e contestabile.

Momento	Uso utile	Controllo necessario
Prima dell’analisi	Chiarire domanda, vincoli e output atteso	Confermare owner, metrica e baseline
Durante l’analisi	Suggerire controlli, segmenti e spiegazioni alternative	Verificare dati, grain, filtri e casi limite
Dopo l’analisi	Preparare memo, trade-off e prossimi passi	Separare evidenza, ipotesi e raccomandazione

Perché conta nel lavoro sui dati

Il collo di bottiglia non è solo scrivere codice. È capire quale domanda merita una risposta, quali dati sono affidabili, quale metrica sposta la decisione e quale rischio resta dopo la raccomandazione. Il data cleaning, la data quality e il feature engineering rendono espliciti questi passaggi e alzano la disciplina dei controlli. Un buon workflow con AI parte da una decisione, dichiara input e output, produce artefatti revisionabili e prevede un criterio di stop per quando dati o modello non reggono.

Framework operativo

Cinque passaggi chiave guidano il processo.

Passaggio	Domanda guida	Output minimo
Decisione	Quale scelta deve migliorare?	Verbo operativo e owner
Contesto	Che cosa sappiamo dei dati?	Fonti, grain, periodo, limiti
Supporto AI	Quale parte può essere accelerata?	Prompt, tool o checklist
Verifica	Quale errore potrebbe cambiare la conclusione?	Controllo, guardrail, baseline
Handoff	Chi decide e con quale criterio?	Memo, ticket, modello o dashboard

Lo schema si applica ad analisi esplorativa, SQL, data engineering, AutoML e workflow agentici. Nessun output diventa evidenza senza fonte, controllo e decisione.

Problema reale

Nel dominio dell’AI per analisi dati, data engineering e AutoML, il problema è decidere quali trasformazioni automatizzare e quali richiedono un owner di dominio. Spesso si confondono i compiti delegabili con le responsabilità che non si possono cedere. L’AI aiuta a generare ipotesi, query, documentazione, test, feature candidate o sintesi, ma la decisione resta umana quando tocca budget, roadmap, clienti, compliance o modelli in produzione. L’obiettivo è produrre artefatti revisionabili che mettano nero su bianco la decisione, i dati osservati e gli errori da evitare.

Modello concettuale

Il modello si regge su quattro livelli.

Livello	Cosa chiarire	Esempio nel data work
Compito	Quale parte del lavoro accelera l’AI?	Bozza query, profilo dati, checklist AutoML, memo
Contesto	Quali informazioni rendono utile l’output?	Schema, metrica, periodo, segmento, policy
Controllo	Come scoprire se l’output è sbagliato?	Test grain, baseline, leakage, review owner
Decisione	Quale azione segue se il controllo regge?	Fix pipeline, esperimento, deploy, raccomandazione

Il modello tiene lontani due errori opposti: usare l’AI come semplice autocomplete, oppure darle autonomia su decisioni di business. La competenza sta nel disegnare il confine.

Formalizzazione rigorosa

Definisci l’unità di lavoro: un campo, una regola di pulizia, un test sui dati, una feature o una trasformazione intermedia. Collegala a segnali osservabili come missing rate, duplicati, stabilità della feature, rischio di leakage, drift e spiegabilità. Poi dichiara la decisione attesa, cioè quali trasformazioni automatizzare e quali richiedono un owner di dominio.

Elemento	Specifica richiesta
Unità di analisi	campo, regola di pulizia, test dati, feature o trasformazione intermedia
Segnale principale	missing rate, duplicati, stabilità feature, leakage risk, drift, spiegabilità
Baseline	Processo manuale, periodo precedente, gruppo comparabile o modello attuale
Decisione	quali trasformazioni automatizzare e quali richiedono owner di dominio
Guardrail	Privacy, costo, qualità dati, interpretabilità, ownership, rischio operativo
Rischio principale	creare feature potenti ma contaminate da informazioni future o definizioni instabili

La formalizzazione regge quando un reviewer può riprodurre la logica, criticare le assunzioni e arrivare alla stessa decisione con gli stessi dati. Se il risultato dipende da conversazioni che nessuno ha tracciato, il workflow non è maturo.

Esempio o caso studio

Un team costruisce un modello di churn. L’AI suggerisce feature ricavate da ticket e pagamenti, ma una di queste contiene eventi successivi alla data di previsione. Il controllo di leakage intercetta il problema ed evita una metrica falsa.

Il caso mostra che l’AI non è il centro del lavoro. Il centro è il ciclo decisionale: domanda, dato, controllo, raccomandazione, monitoraggio. L’AI riduce l’attrito tra questi passaggi, ma ognuno resta controllabile.

Evidenza osservata	Lettura prudente	Azione consigliata
Output più rapido	La velocità è utile solo se non abbassa qualità e controllo	Confrontare con baseline manuale e review indipendente
Spiegazioni plausibili	La plausibilità linguistica non è prova empirica	Tradurre ogni spiegazione in controllo su dati o processo
Migliora la metrica	Potrebbe esserci effetto composizione, leakage o stagionalità	Segmentare, verificare guardrail e monitorare nel tempo

Un buon caso studio si chiude con una decisione difendibile: cosa automatizzare, cosa tenere manuale, quale metrica monitorare e quale condizione fermerebbe il processo.

Esercizi per fissare il metodo

Parti da un esercizio semplice: scrivi una scheda di una pagina per il data cleaning, la data quality e il feature engineering, con la decisione da supportare, gli input richiesti, l’output atteso, il controllo minimo e il rischio principale. Va bene un caso piccolo, come una variazione di conversione, una pipeline in ritardo o un modello forecast da valutare.

Poi costruisci una tabella con tre scenari, il workflow manuale, quello AI-assisted e quello con automazione spinta, indicando per ciascuno tempo stimato, qualità attesa, rischio operativo, controllo necessario e owner finale.

Quando vuoi spingerti più a fondo, prepara un decision memo che si possa revisionare, con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio, e aggiungi una sezione su cosa farebbe cambiare idea al team. Come materiali usa profiling report, dizionario dati, log di qualità, esempi di feature e target definition. Se non hai dati reali, costruisci un dataset sintetico con almeno 200 righe, una dimensione temporale, un segmento, una metrica primaria e un campo con un possibile errore di qualità.

Errore tipico da evitare

Il primo errore è usare il data cleaning, la data quality e il feature engineering come etichetta invece che come processo, cioè mostrare output senza spiegare dati, controlli e decisione. Il secondo è confondere la produttività individuale con l’affidabilità organizzativa. Il terzo è non decidere in anticipo quali azioni sono permesse, quali richiedono approval e quali sono vietate.

La correzione pratica è scrivere tre righe prima di partire.

Riga	Contenuto
Decisione	Quale scelta concreta migliorare
Evidenza	Quale dato o controllo sostiene la scelta
Stop	Quale rischio fermerebbe o richiederebbe review

Se ne manca una, il workflow non è pronto. L’AI può essere un supporto esplorativo, ma non una parte stabile del processo decisionale.

Domande per verificare la padronanza

Prova a rispondere in modo specifico. Quale decisione concreta migliora con questa lezione? Quale parte del workflow puoi delegare all’AI e quale deve restare sotto un owner umano? Quale baseline useresti per misurare se il nuovo processo migliora davvero? Quale failure mode potrebbe rendere pericoloso un output che sembra corretto? E quale artefatto consegneresti a uno stakeholder, scegliendo tra memo, dashboard, query review, model card, runbook o checklist?

Se non rispondi con precisione, torna al problema reale. Le risposte generiche segnalano automazione prematura.

Riferimenti tecnici essenziali

I riferimenti qui sotto aiutano a orientare scelte tecniche che cambiano nel tempo e non sono ricette da copiare.

• OpenAI Agents SDK: https://developers.openai.com/api/docs/guides/agents
• Vertex AI AutoML forecasting: https://docs.cloud.google.com/gemini-enterprise-agent-platform/machine-learning/tabular-data/forecasting/overview
• Azure AutoML: https://learn.microsoft.com/en-us/azure/machine-learning/concept-automated-ml?view=azureml-api-2
• SageMaker Autopilot: https://docs.aws.amazon.com/sagemaker/latest/dg/autopilot-automate-model-development.html
• Databricks AutoML: https://docs.databricks.com/aws/en/machine-learning/automl/

Riepilogo operativo

Il data cleaning, la data quality e il feature engineering diventano utili quando producono decisioni chiare, non solo terminologia. Il ciclo di decisione, contesto, supporto AI, verifica e handoff è ciò che trasforma la lezione in pratica verificabile. Più il workflow usa prompt, controlli, metriche e review umana, più deve restare osservabile. Un output che non puoi ricostruire, revisionare o fermare non è automazione professionale, ma solo velocità che nessuno governa.