Data cleaning, data quality, and 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.

A starting scene

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.

Moment	Useful use	Necessary control
Before analysis	Clarify question, constraints, and expected output	Confirm owner, metric, and baseline
During analysis	Suggest controls, segments, and alternative explanations	Verify data, grain, filters, and edge cases
After the analysis	Prepare memos, trade-offs, and next steps	Separate evidence, hypothesis, and recommendation

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.

Operating Framework

Cinque passaggi chiave guidano il processo.

Step	Guiding question	Minimum Output
Decision	Which choice needs to improve?	Operating Verb and Owner
Context	What do we know about the data?	Sources, grain, period, limitations
AI Support	Quale parte può essere accelerata?	Prompt, tool or checklist
Verification	Which error could change the conclusion?	Control, guardrail, baseline
Handoff	Who decides and by what criteria?	Memo, ticket, model or dashboard

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

Real-world problem

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.

Conceptual model

Il modello si regge su quattro livelli.

Level	What to clarify	Example in data work
Task	Quale parte del lavoro accelera l’AI?	Query draft, data profile, AutoML checklist, memo
Context	Quali informazioni rendono utile l’output?	Schema, metric, period, segment, policy
Control	Come scoprire se l’output è sbagliato?	Test grain, baseline, leakage, review owner
Decision	What action follows if the control holds?	Fix pipeline, experiment, deploy, recommendation

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.

Rigorous formalization

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.

Element	Requested specification
Unit of analysis	field, cleaning rule, data test, feature or intermediate transformation
Primary signal	missing rate, duplicati, stabilità feature, leakage risk, drift, spiegabilità
Baseline	Manual process, previous period, comparable group or current model
Decision	quali trasformazioni automatizzare e quali richiedono owner di dominio
Guardrail	Privacy, costo, qualità dati, interpretabilità, ownership, rischio operativo
Main risk	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.

Example or case study

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.

Observed evidence	Cautious interpretation	Recommended action
Output più rapido	La velocità è utile solo se non abbassa qualità e controllo	Compare with manual baseline and independent review
Spiegazioni plausibili	La plausibilità linguistica non è prova empirica	Translate every explanation into data or process control
Migliora la metrica	Potrebbe esserci effetto composizione, leakage o stagionalità	Segment, verify guardrails and monitor over time

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à.

Typical mistake to avoid

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.

Line	Content
Decision	Quale scelta concreta migliorare
Evidence	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.

Essential technical references

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/

Operational Summary

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.