Cheat sheet: AI per data work

Anche qui siamo nel binario dei sistemi LLM, con un obiettivo molto pratico. Usare l’AI nel lavoro dati sembra facile finché il primo output plausibile si rivela sbagliato nel punto che conta: una metrica definita diversamente dal resto del team, una join che duplica le righe, un forecast che ha sbirciato il futuro. Questa pagina è una cheat sheet operativa per decidere in pochi minuti quanta automazione concedere a ciascun compito — bozza assistita, delega con verifica, pipeline autonoma governata — e quali controlli esigere prima di fidarti del risultato. Niente teoria astratta: criteri, soglie pratiche, codice di verifica e trappole documentate sul campo.

La regola in sintesi

Questa pagina assegna a ogni compito dati il suo livello di automazione, dalla bozza assistita alla pipeline autonoma governata, con i controlli che rendono l’output firmabile.

Il percorso in sei passi

Ecco come scegliere e proteggere, nell’ordine.

1. Stima il danno peggiore di un output sbagliato e la reversibilità della decisione che lo usa.
2. Scegli il livello: assistito se la verifica non è codificabile, delegato con controlli automatici se il compito si ripete, autonomo governato solo con guardrail, baseline e rollback.
3. Scrivi il contratto in quattro righe: artefatto con grain, contesto minimo, controllo con soglia, decisione con proprietario.
4. Passa al modello solo schema, definizioni, trappole note e un campione anonimizzato, mai intere tabelle con dati personali.
5. Esegui le tre maglie di verifica: test meccanici con tolleranze, confronto con baseline indipendente, revisione mirata sui punti dove i modelli sbagliano.
6. Promuovi un prototipo a workflow schedulato solo quando sai elencare tutti i modi in cui può rompersi e hai un controllo per ciascuno.

Quando l’AI accelera il lavoro dati e quando lo sabota

Il valore dell’AI cambia radicalmente a seconda del compito. Brilla dove il costo dell’errore è basso e la verifica è economica: generare la prima bozza di una query, documentare una pipeline esistente, esplorare un dataset sconosciuto, produrre varianti di una visualizzazione. In questi casi anche un output imperfetto fa risparmiare tempo, perché correggere è più veloce che partire da zero.

Diventa pericolosa dove l’errore è silenzioso e costoso: metriche business ambigue, join su chiavi non verificate, finestre temporali nei forecast, trasformazioni che alimentano decisioni o altri modelli. Qui un output “quasi giusto” è peggio di nessun output, perché passa i controlli superficiali e contamina tutto ciò che viene dopo.

Una regola pratica che regge bene: delega all’AI ciò che sai verificare in meno tempo di quanto impiegheresti a farlo da zero. Se la verifica costa più dell’esecuzione manuale — perché richiede di ricontrollare ogni riga, ricostruire la logica, o convincere uno stakeholder scettico — l’automazione è un prestito a tassi usurai.

Tipo di compito	Automazione consigliata	Perché
Bozza SQL esplorativa	Assistita, verifica leggera	Errori visibili subito nei risultati
Documentazione pipeline	Delegata con review	Il codice sorgente fa da verità
Definizione metrica business	Umana, AI solo come sparring	Ambiguità semantica, non sintattica
Feature per modello produttivo	Umana + test automatici	Leakage silenzioso, costo alto
Report ricorrente standardizzato	Autonoma governata	Schema stabile, controlli codificabili
Analisi ad hoc per decisione urgente	Assistita, verifica mirata	Contesto ricco, tempo poco

Il resto della pagina rende operativa questa tabella: come classificare il compito in trenta secondi, quali informazioni passare al modello perché non inventi, e come costruire la rete di controlli che rende l’output firmabile.

I tre livelli di automazione e come sceglierne uno in trenta secondi

Ogni compito dati cade in uno di tre livelli. La scelta dipende da due assi: quanto è reversibile l’errore e quanto è codificabile la verifica.

Livello 1 — Assistita. L’AI propone, tu disponi. Prompt interattivi, bozze di query, spiegazioni di codice esistente, brainstorming su approcci. La verifica è la tua lettura critica. Adatto a esplorazione, prototipi, compiti mai fatti prima dove stai ancora capendo il problema. Costo di setup quasi zero, ma ogni output richiede attenzione umana completa.

Livello 2 — Delegata con verifica. L’AI esegue dentro un perimetro definito e una suite di controlli automatici giudica il risultato. Esempio: genera la query di data cleaning, ma prima del merge devono passare test di conteggio righe, null rate, distribuzione delle chiavi. Tu rivedi solo le eccezioni. Adatto a compiti ripetitivi con specifiche stabili, dove i controlli si scrivono una volta e si riusano.

Livello 3 — Autonoma governata. Il workflow gira senza intervento — schedulato, con agenti o AutoML — ma dentro guardrail rigidi: input validati, output confrontati con baseline, drift monitorato, rollback pronto, owner nominato. Adatto solo a pipeline mature dove il comportamento normale è ben caratterizzato e le anomalie sono rilevabili meccanicamente.

Per scegliere in fretta, poni tre domande in ordine. Prima: se l’output fosse sbagliato nel modo peggiore plausibile, qual è il danno — minuti persi, decisione errata, sanzione, modello produttivo corrotto? Danno alto significa mai oltre il livello 2 senza firma umana. Seconda: so scrivere un controllo automatico che cattura quel modo di sbagliare? Se no, resta al livello 1. Terza: il compito si ripete abbastanza da ammortizzare il costo di controlli e monitoraggio? Solo un sì giustifica il livello 3.

Un errore frequente è saltare dal livello 1 al livello 3 perché “il prototipo funzionava”. Il prototipo funzionava con te a bordo come controllo implicito. Industrializzarlo significa esplicitare tutto ciò che facevi con gli occhi — ed è un lavoro di ingegneria, non un cambio di flag.

Come incorniciare il compito prima di aprire il prompt

La maggior parte degli output deludenti nasce da prompt vaghi, non da modelli deboli. Prima di scrivere qualsiasi prompt, fissa per iscritto quattro elementi: il compito in una frase con verbo operativo, il contesto minimo, il controllo che giudicherà l’output e la decisione che l’output deve supportare. Chiamalo pure contratto del compito — sta in un paragrafo e cambia tutto.

Il compito deve nominare l’artefatto atteso con precisione meccanica. “Analizza le vendite” non è un compito, è un auspicio. “Query SQL che restituisce fatturato settimanale per canale, settimane ISO lunedì-domenica, resi esclusi, ultimi 12 mesi” è un compito: contiene grain, filtri, finestra e formato. Se non riesci a scriverlo così, il problema non è il prompt ma la specifica — e l’AI la erediterà tale e quale.

Il contesto minimo comprende tutto ciò che il modello non può indovinare: schema delle tabelle con tipi e chiavi, definizioni business delle metriche, periodo di riferimento, esclusioni note, vincoli come privacy o dialetto SQL. Il controllo dichiara in anticipo come capirai se l’output è sbagliato: confronto con una baseline, test di quadratura, review di un collega, soglia numerica. La decisione chiarisce cosa farai del risultato — esplorare, raccomandare, eseguire — e quindi quanta accuratezza serve davvero.

Un template compatto da incollare in testa a ogni sessione di lavoro:

COMPITO: [artefatto + grain + formato]
CONTESTO: [tabelle, metriche, periodo, vincoli]
CONTROLLO: [come verifico + soglia di accettazione]
DECISIONE: [cosa faccio con l'output + owner]

Compilato su un caso reale, diventa qualcosa del genere: compito “classificazione binaria churn a 30 giorni, output probabilità per user_id”; contesto “tabella eventi con event_date, esclusi utenti con meno di 7 giorni di anzianità”; controllo “holdout temporale sopra soglia con calibrazione entro banda”; decisione “se supera la soglia, test A/B su retention, owner il PM crescita”. Con queste quattro righe, sia un collega sia un modello sanno cosa produrre e come saranno giudicati.

La verifica empirica: se cancelli il prompt elaborato e lasci solo queste quattro righe, un analista competente dovrebbe produrre qualcosa di riconoscibilmente simile. Se non ci riesce, il contratto è incompleto e va completato prima di coinvolgere l’AI, non dopo.

Dati in ingresso: schema, grain e definizioni che il modello non può inventare

L’AI è un eccellente manipolatore di strutture e un pessimo indovino di significati. Tutto ciò che è convenzione locale — cosa conta come “cliente attivo”, se il fatturato è IVA inclusa, quando una settimana inizia — deve arrivare esplicitamente nel prompt, perché il modello riempirà ogni vuoto con la convenzione più comune nel suo training set, che quasi mai è la tua.

Il kit minimo di contesto per compiti SQL e analytics ha cinque pezzi. Primo, lo schema essenziale: solo le tabelle e colonne coinvolte, con tipi, chiavi primarie ed esterne, non l’intero catalogo. Secondo, il grain dichiarato: una riga uguale cosa — un ordine, un evento, un utente-mese? Terzo, le definizioni business delle metriche coinvolte, copiate dal glossario ufficiale se esiste, scritte ex novo se non esiste. Quarto, le trappole note: duplicati attesi, timezone miste, storicizzazione assente, soft delete. Quinto, un campione di righe reali o realistiche, poche ma vere nel formato.

Il grain merita enfasi perché è la fonte più comune di errori silenziosi. Una join molti-a-uno applicata al contrario duplica le righe e gonfia ogni somma. Il risultato sembra perfettamente ragionevole finché non lo si confronta con un totale noto. Per questo ogni prompt che produce aggregazioni dovrebbe nominare il grain atteso dell’output e includere un controllo di quadratura: il totale deve riconciliarsi con una fonte indipendente entro una tolleranza dichiarata.

Sul piano quantitativo, la domanda giusta è quanta storia passare al modello. Troppo poco contesto e inventa; troppo e diluisce il segnale, alza i costi e rischia di esporre dati sensibili. Una buona euristica: schema completo delle tabelle coinvolte più un campione di 5-20 righe rappresentative, inclusi i casi limite — valori nulli, stringhe vuote, date future, importi negativi. Se il dataset ha una dimensione temporale, il campione deve coprire più periodi, altrimenti il modello non vedrà mai la stagionalità o i cambi di schema.

Un’ultima precauzione riguarda dati sensibili e costi. Mai incollare in un servizio esterno dati personali non anonimizzati, credenziali, o intere tabelle quando bastano schema e campione. E tieni d’occhio la dimensione: inviare ogni volta centinaia di migliaia di token di contesto per un compito che ne richiede poche migliaia è il modo più rapido per trasformare un assistente utile in una voce di costo che qualcuno taglierà.

Verificare l’output: test, baseline e revisione che reggono davvero

Ogni output AI su dati va trattato come codice non testato: potenzialmente utile, certamente non pronto. La rete di controlli ha tre maglie con granularità diversa, e la robustezza sta nell’usarle tutte, non nel perfezionarne una sola.

La prima maglia sono i test meccanici, economici e automatizzabili. Conteggio righe prima e dopo ogni trasformazione, con soglia di variazione attesa — se una join raddoppia le righe senza motivo, qualcosa si è rotto. Tasso di nulli e duplicati sulle chiavi, confrontato con il profilo storico della tabella. Quadratura dei totali: la somma per segmento deve ricostruire il totale entro una tolleranza, diciamo ±1% per arrotondamenti e timing. Freschezza e copertura temporale: il minimo e il massimo delle date devono coprire la finestra dichiarata senza buchi imprevisti. Questi test si scrivono una volta in SQL o Python e girano su ogni output, umano o artificiale che sia.

-- Controlli di quadratura dopo una query generata dall'AI: confronto con totali noti
-- Ogni SELECT restituisce una riga: scostamento oltre soglia = output da scartare
WITH dettaglio AS (
  SELECT canale, SUM(importo) AS fatturato_canale, COUNT(*) AS righe_canale
  FROM vendite
  WHERE data_ordine >= DATE '2026-01-01'  -- finestra dichiarata nel contratto
    AND reso_flag = FALSE                  -- esclusione business concordata
  GROUP BY canale
),
totale AS (
  SELECT SUM(importo) AS fatturato_totale, COUNT(*) AS righe_totali
  FROM vendite
  WHERE data_ordine >= DATE '2026-01-01'
    AND reso_flag = FALSE
)
-- 1) quadratura: somma dei canali contro totale indipendente
SELECT 'quadratura_fatturato' AS test,
  ABS(SUM(d.fatturato_canale) - (SELECT fatturato_totale FROM totale))
    / (SELECT fatturato_totale FROM totale) AS scostamento_relativo
FROM dettaglio d
UNION ALL
-- 2) completezza righe: nessuna riga persa o duplicata dalla GROUP BY
SELECT 'completezza_righe',
  ABS(SUM(d.righe_canale) - (SELECT righe_totali FROM totale)) * 1.0
    / (SELECT righe_totali FROM totale)
FROM dettaglio d;
-- Lettura: scostamento_relativo > 0.01 in un test qualsiasi -> indaga prima di usare i dati

La seconda maglia è il confronto con una baseline. Per una query, la baseline è il calcolo manuale su un campione o la query precedente di cui ti fidi: i due risultati devono coincidere entro la tolleranza su un periodo di sovrapposizione. Per un modello, la baseline è la regola stupida — media storica, maggioranza, ultimo valore noto — e il nuovo modello deve batterla di un margine che giustifichi la complessità. La regola economica è semplice: il guadagno atteso dal miglioramento deve superare il costo di esercizio del modello complesso, altrimenti la “vittoria” statistica è una sconfitta economica.

La terza maglia è la revisione umana mirata, non la rilettura integrale. Chi revisiona non ricontrolla tutto — altrimenti tanto valeva farlo da sé — ma ispeziona i punti dove i modelli sbagliano di più: definizioni di metriche contro glossario, direzione delle join contro grain dichiarato, finestre temporali contro leakage, segmenti piccoli dove la varianza esplode. Una checklist di revisione da cinque voci, stampata e usata davvero, batte ore di rilettura ansiosa.

Il principio di fondo: la verifica deve costare meno del lavoro risparmiato ma essere indipendente dal processo che ha generato l’output. Un controllo che riusa la stessa logica della query sotto esame — o peggio, che chiede allo stesso modello “è corretto?” — è teatro, non controllo.

Rischi tipici: leakage, allucinazioni silenziose, costi e privacy

Quattro famiglie di rischi coprono quasi tutti i fallimenti dei workflow AI su dati. Conoscerle a memoria è metà della cheat sheet.

Leakage temporale. Il modello vede informazioni che al momento della previsione non sarebbero disponibili: la data di chiusura dentro le feature di churn, gli ordini futuri nella media mobile, il target travestito da variabile esplicativa. I sintomi sono metriche sospettosamente buone in validazione e crollo in produzione. La difesa è procedurale: split temporale rigoroso — mai shuffle casuale su dati con dipendenza temporale — e audit delle feature con la domanda “questo campo esisteva davvero alla data di scoring?”. Uno script di controllo che elenca la massima data di aggiornamento di ogni feature contro la data di cutoff vale più di qualsiasi metrica.

Allucinazioni silenziose. L’AI produce valori plausibili ma falsi: codici prodotto che non esistono, date fuori range, join su colonne omonime ma semanticamente diverse. Sono pericolose proprio perché sembrano giuste a colpo d’occhio. Le difese sono vincoli di dominio codificati — chiavi esterne, enum ammessi, range validi — verificati automaticamente su ogni output. Il controllo Python sotto mostra il pattern: validare un dataframe generato o trasformato con l’AI contro regole dichiarate, e fallire rumorosamente alla prima violazione.

# Validazione di dominio su output AI: fallisce rumorosamente invece di propagare errori
import pandas as pd

def valida_output_ai(df: pd.DataFrame, catalogo_prodotti: set, tolleranza: float = 0.01) -> list[str]:
    # Raccoglie tutte le violazioni invece di fermarsi alla prima: una sola passata, quadro completo
    violazioni = []
    # 1) chiavi referenziate devono esistere nel catalogo (niente codici inventati)
    codici_ignoti = set(df["codice_prodotto"].dropna()) - catalogo_prodotti
    if codici_ignoti:
        violazioni.append(f"codici non a catalogo: {sorted(codici_ignoti)[:10]}")
    # 2) vincoli di range: importi negativi e date future sono quasi sempre errori
    if (df["importo"] < 0).any():
        violazioni.append(f"importi negativi: {(df['importo'] < 0).sum()} righe")
    # 3) completezza: grain dichiarato una riga per utente-mese, niente duplicati
    if df.duplicated(subset=["user_id", "mese"]).any():
        violazioni.append("duplicati su chiave (user_id, mese): grain violato")
    return violazioni  # lista vuota = output accettabile, altrimenti scarta e indaga

Costi fuori controllo. Chiamate ridondanti, contesti gonfiati, agenti in loop, AutoML che esplora spazi enormi per guadagni marginali. La difesa è un budget esplicito per workflow — costo per esecuzione, per riga processata, per esperimento — con alert prima del tetto, non dopo. La stima preventiva confronta il costo atteso (volume per token medi per prezzo) con il valore della decisione supportata prima di schedulare alcunché.

Privacy e compliance. Schema e campioni inviati a servizi esterni, log che trattengono dati sensibili, output che memorizzano informazioni da cancellare. La difesa è minimizzazione — anonimizza o sintetizza prima di inviare — più una mappa di dove i dati transitano e quanto restano. Se il contratto dati vieta l’esportazione, il workflow AI deve girare dentro il perimetro, punto: nessun prompt “solo questa volta” regge un audit.

Un rischio trasversale merita una riga a sé: l’automazione non governata, dove un agente ottiene permessi di scrittura su tabelle produttive o invio diretto a stakeholder. La regola è semplice e non negoziabile: permessi di lettura di default, ogni scrittura o invio richiede approvazione esplicita o una suite di controlli che la sostituisce formalmente, con log immutabile di chi — umano o agente — ha fatto cosa.

Dal prototipo al workflow affidabile: template e quality gate

Il salto tra “l’AI mi ha aiutato una volta” e “abbiamo un workflow AI affidabile” è fatto di artefatti noiosi: template, gate, log. Tre bastano per partire.

Il primo è il template di richiesta, versione archiviata del contratto del compito più il contesto stabile — schema, definizioni, trappole note. Vive nel repository accanto al codice, versionato, non nella cronologia di una chat. Quando lo schema cambia, il template cambia con review esplicita, e tutti i workflow che lo usano ereditano la correzione invece di continuare a lavorare su assunzioni fossilizzate.

Il secondo è il quality gate, la porta che ogni output attraversa prima di procedere: test meccanici verdi, quadratura entro tolleranza, confronto baseline superato, revisione umana dove prevista. Il gate è binario — passa o non passa — e il suo esito va registrato con l’output, così mesi dopo puoi ricostruire perché una certa cifra finì in un report. Per i workflow schedulati il gate deve anche sapere cosa fare quando fallisce: bloccare e avvisare, mai far passare dati dubbi “per non rompere la pipeline”.

Il terzo è il log decisionale: per ogni esecuzione, input usati, versione del prompt o modello, controlli eseguiti con esiti, decisione presa e owner. Sembra burocrazia finché non devi rispondere a “perché a marzo il forecast diceva il contrario” — e in quel momento è l’unica cosa che ti separa da una ricostruzione fantasiosa.

La maturità del workflow si misura su tre assi indipendenti. Riproducibilità: rieseguendo oggi con gli stessi input ottengo lo stesso output, o so spiegare la differenza? Osservabilità: vedo cosa è successo dentro — token usati, chiamate, tempi, controlli — o solo il risultato finale? Reversibilità: se scopro un errore tra una settimana, so quali output ne sono contaminati e posso ricalcolarli? Un workflow che segna basso su uno qualsiasi dei tre non è pronto per il livello 3, indipendentemente da quanto bene funzioni nelle demo.

Mettere la cheat sheet al lavoro su casi concreti

Tutto questo diventa memoria muscolare solo applicandolo. Tre scenari coprono la maggior parte del lavoro reale e mostrano come gli stessi principi si adattino a contesti diversi.

Scenario uno: esplorazione di un dataset nuovo. Livello assistito, verifica leggera. Chiedi all’AI un profilo esplorativo — tipi, distribuzioni, nulli, duplicati, anomalie evidenti — passando schema e campione. Poi verifica con i tuoi occhi su tre punti: le distribuzioni descritte corrispondono a quelle che vedi con una GROUP BY indipendente? I nulli dichiarati corrispondono al conteggio reale? Le “anomalie” segnalate sono anomalie dei dati o del ragionamento del modello? Il guadagno è reale ma modesto — ed è giusto così: l’esplorazione è il compito dove la tua comprensione si forma, e delegarla interamente significa non capire i dati che analizzerai.

Scenario due: report ricorrente standardizzato. Livello autonomo governato, ma solo dopo un periodo di rodaggio delegato. Le prime 3-5 esecuzioni girano con revisione umana completa: confronti ogni cifra con il calcolo precedente, annoti ogni discrepanza e la sua causa. Quando le discrepanze scendono a zero per cause strutturali — restano solo variazioni legittime dei dati — codifichi i controlli che facevi a mano nel quality gate e passi all’esecuzione schedulata con revisione per eccezione. Il criterio di promozione non è “ha funzionato tre volte” ma “so elencare tutti i modi in cui può rompersi e ho un controllo per ciascuno”.

Scenario tre: feature engineering per AutoML. Livello delegato con verifica pesante, perché il leakage si nasconde qui. L’AI propone trasformazioni — encoding, aggregazioni temporali, interazioni — e tu le filtri con due domande per ciascuna: questa informazione esisteva alla data di cutoff per ogni riga? La trasformazione è stabile tra training e serving, o dipende da statistiche globali che in produzione non avrò? Le aggregazioni con finestra mobile sono il caso classico: media degli ultimi 7 giorni calcolata correttamente è una feature legittima, calcolata includendo il giorno corrente o con normalizzazione sull’intero dataset è leakage. Nessuna metrica di validazione ti salverà se la procedura è sbagliata — la metrica gonfiata dal leakage è la bugia più costosa del machine learning applicato.

Tieni questa pagina a portata di mano non come mappa da seguire passo passo ma come griglia di domande da porre ogni volta che l’entusiasmo per un output veloce supera la voglia di verificarlo. Il data work assistito dall’AI premia chi è metodico due volte: una quando scrive il prompt, una quando non si fida della risposta.

Verdetto: delega ciò che verifichi in meno tempo di quanto faresti a mano; tutto il resto resta assistito o non parte affatto.

Il caso Zillow

Nel 2021 Zillow chiuse il programma di acquisto automatico di case dopo svalutazioni per centinaia di milioni di dollari e tagliò un quarto della forza lavoro, circa 2.000 persone. L’algoritmo di pricing aveva continuato a comprare mentre il mercato cambiava, senza un gate umano capace di fermarlo. È il prezzo del salto dal prototipo all’autonomia senza controlli: la pipeline funzionava, il governo della pipeline no.

Domande per chiudere la lezione

1. Quali tre domande assegnano un compito al livello giusto di automazione in trenta secondi?
2. Cosa contiene il contratto del compito e perché senza di esso il prompt eredita specifiche vaghe?
3. Quale controllo distingue una quadratura vera da un controllo di facciata?
4. Quando un prototipo che funziona merita la promozione a pipeline schedulata?