SQL, notebook e data storytelling con AI

Quando lavori con SQL, notebook e narrazione dei dati, il punto non è la definizione astratta ma la scelta che devi prendere: dove l’AI ti accelera e dove invece serve una revisione umana che metta in dubbio l’output. Questa lezione tiene insieme domanda, dato, controllo e azione, in modo che il lavoro tecnico resti ancorato a una decisione che qualcuno può verificare anche quando l’incertezza è alta.

Il problema da cui partire

Lavorando ogni giorno con dati e AI, è facile trasformare un’analisi in una catena di risposte che nessuno può davvero controllare. Il nodo concreto è capire quando l’AI può proporre una query o un insight e quando invece quella proposta va passata sotto una revisione analitica fatta da una persona. Senza un disegno operativo chiaro, l’analista perde tempo oppure consegna spiegazioni che sembrano solide e poi crollano alla prima domanda di un revisore.

Come ragionare sul workflow

Conviene pensare il lavoro su quattro piani: compito, contesto, controllo e decisione. L’AI accelera compiti come scrivere una bozza di query o una checklist, ma è il contesto a fissare dati, metriche e vincoli. Il controllo serve a far emergere errori e incongruenze, mentre la decisione stabilisce l’azione che segue. Tenere distinti questi piani evita i due errori opposti: usare l’AI come semplice autocomplete oppure delegarle scelte di business senza nessuna supervisione.

Livello	Cosa chiarire	Esempio nel data work
Compito	Quale parte del lavoro viene accelerata?	Bozza query, profilo dati, checklist AutoML
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

Rendere il processo analizzabile

Per poter analizzare il processo conviene fissare l’unità di lavoro, che può essere una query, una cella di notebook, un grafico, un memo o una metrica derivata, e legarla a segnali osservabili come la correttezza logica, la leggibilità, la performance, il test di grain e la chiarezza della narrazione. La decisione attesa resta una sola: capire quando l’AI può proporre codice e quando serve una revisione analitica. I guardrail riguardano privacy, costi, qualità dei dati, interpretabilità, ownership e rischio operativo.

Elemento	Specifica richiesta
Unità di analisi	Query, cella notebook, grafico, memo o metrica derivata
Segnale principale	Correttezza logica, leggibilità, performance, test di grain, chiarezza narrativa
Baseline	Processo manuale, periodo precedente, gruppo comparabile o modello attuale
Decisione	Stabilire quando l’AI può proporre codice e quando serve code review analitica
Guardrail	Privacy, costo, qualità dati, interpretabilità, ownership e rischio operativo
Rischio principale	Accettare SQL plausibile che duplica righe, cambia grain o ignora filtri critici

Un caso pratico di revisione

Un analista chiede all’AI una query per calcolare la retention mensile. La prima versione gira senza errori di sintassi, ma la revisione scopre che conta gli utenti riattivati come nuovi, e questo altera il grain. Sistemata quella logica, l’output torna affidabile. Il caso mostra bene cosa significa tenere l’AI dentro un ciclo decisionale fatto di domanda, dati, controllo, raccomandazione e monitoraggio: ogni passaggio deve restare controllabile.

Evidenza osservata	Lettura prudente	Azione consigliata
Output più rapido	Velocità utile solo se non compromette qualità	Confrontare con baseline manuale e review
Spiegazioni plausibili	Plausibilità linguistica non è prova empirica	Tradurre spiegazioni in controlli dati
Miglioramento metrica	Possibile effetto composizione o leakage	Segmentare, verificare guardrail, monitorare

Esercitarsi sul caso

Si parte da una scheda sintetica per un caso semplice, per esempio una variazione di conversione o una pipeline in ritardo: ci scrivi la decisione da supportare, gli input, l’output atteso, il controllo minimo e il rischio principale. Da lì si passa a una tabella con tre scenari, il workflow manuale, quello assistito dall’AI e l’automazione avanzata, indicando per ciascuno tempo stimato, qualità attesa, rischio operativo, controllo necessario e owner finale.

Il livello più ambizioso è un memo decisionale revisionabile con ipotesi, dati, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio, chiuso da una sezione che dice cosa farebbe cambiare idea al team. Come materiale conviene usare schemi di data warehouse, query esistenti, notebook, definizioni di metriche e test SQL; se non sono disponibili, basta un dataset sintetico di almeno 200 righe con una dimensione temporale, un segmento, una metrica primaria e un campo per gli errori di qualità.

L’errore tipico da evitare

L’errore più comune è usare SQL, notebook e data storytelling con AI come un’etichetta invece che come un processo, cosa che succede ogni volta che si mostra un output senza spiegare dati, controlli e decisione. Il secondo è confondere la produttività del singolo con l’affidabilità dell’organizzazione. Il terzo è non avere deciso prima quali azioni sono permesse, quali richiedono approvazione e quali sono vietate.

Una correzione pratica è scrivere tre righe prima di iniziare:

Riga	Contenuto
Decisione	Quale scelta concreta vogliamo migliorare
Evidenza	Quale dato o controllo sostiene la scelta
Stop	Quale rischio ci farebbe fermare o chiedere review

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

Domande per mettersi alla prova

Vale la pena rispondere a poche domande prima di andare avanti. Quale decisione concreta dovrebbe migliorare questa lezione? Quale parte del workflow puoi delegare all’AI e quale deve restare sotto controllo umano? Quale baseline useresti per capire se il nuovo processo migliora davvero? Quale failure mode potrebbe rendere pericoloso un output che sembra corretto? E quale artefatto consegneresti a uno stakeholder, tra memo, dashboard, query review, model card, runbook o checklist?

Se non riesci a rispondere in modo specifico, torna al problema iniziale prima di proseguire. Una risposta generica di solito segnala un’automazione partita troppo presto.

Riepilogo operativo

Il valore di questo lavoro emerge quando produce decisioni più chiare, non solo terminologia nuova. Il ciclo che lega decisione, contesto, supporto dell’AI, verifica e handoff trasforma la lezione in una pratica verificabile. Più il workflow si appoggia a prompt, controlli, metriche e revisione umana, più deve restare osservabile. Un output che non puoi ricostruire, revisionare o fermare non è automazione professionale: è solo velocità senza controllo.