Cheat sheet: agentic AI per data work

Usare un agente sui dati senza perdere il controllo è un problema di progettazione, non di prompt. Chi lavora con analytics, data engineering o AutoML lo scopre al primo incidente serio: una query generata in secondi che unisce le tabelle sul grain sbagliato, una spiegazione di un calo di conversione che suona perfetta e non regge a nessuna segmentazione, una pipeline auto-riparata che maschera un buco di tracking. Il danno non è la singola risposta errata. È che nessuno riesce a ricostruire da dove venga, con quali dati sia stata prodotta e chi l’abbia approvata. Questo articolo è una cheat sheet operativa: criteri compatti per decidere cosa delegare a un workflow agentico, come vincolarlo e quando fermarlo, con controlli che un collega può rieseguire. Appartiene al binario sistemi-llm.

Il lettore di riferimento ha già un warehouse, qualche dashboard che conta davvero e un backlog di richieste che cresce più in fretta delle ore disponibili. Sa scrivere SQL, conosce le metriche del suo dominio e ha già usato un modello linguistico per farsi aiutare. Quello che manca, di solito, non è un altro tool: è un modo condiviso per dire questo passo lo fa l’agente in autonomia, questo passo richiede un’approvazione umana, questo passo l’agente non lo tocca. Le sezioni seguenti costruiscono quel confine pezzo per pezzo, con esempi numerici, una regola per il costo atteso e codice di guardia che si può copiare nei propri run.

Quando un agente sui dati aiuta davvero e quando rovina tutto

L’agente rende quando il lavoro è scomponibile in passi verificabili e ogni passo lascia una traccia. Profilare un dataset nuovo, generare venti ipotesi di segmentazione e scartarne diciotto con test rapidi, scrivere la prima bozza di una query complessa, documentare una pipeline, preparare feature candidate per un modello di churn: qui la macchina macina varianti a una velocità che nessun analista eguaglia, e l’umano giudica. Il guadagno tipico, misurato su team analytics di medie dimensioni, sta nella fase esplorativa: da mezza giornata di lavoro ripetitivo a un’ora di revisione mirata, a parità di qualità finale, purché i controlli esistano davvero.

L’agente rovina tutto quando l’output sembra una risposta ma è in realtà una decisione travestita. Dire che il calo del 12 per cento della conversione è dovuto alla campagna X non è una frase da chat: è un’attribuzione causale che sposta budget. Se dietro non ci sono definizioni congelate, periodo di confronto, segmentazione e un test contro una baseline, quella frase è solo eloquenza statistica. Lo stesso vale per la scrittura diretta su tabelle di produzione, la modifica autonoma di una pipeline schedulata, il retraining silenzioso di un modello di scoring. Ogni volta che l’azione ha effetti irreversibili o costosi, l’autonomia va ridotta e l’approvazione va resa esplicita.

Una regola pratica per orientarsi: chiedersi cosa succede se l’output è sbagliato nel modo più plausibile possibile. Se la conseguenza è un’ora persa, l’autonomia può essere ampia. Se la conseguenza è una decisione di budget, un report al cliente o un modello in produzione, servono gate umani, log completi e piano di rollback. Il resto di questa cheat sheet serve a rendere quella domanda una procedura, non un’intuizione.

Il confine tra compiti delegabili e responsabilità non delegabili

Il modo più pulito per tracciare il confine è separare generazione e giudizio. All’agente va la generazione: bozze, varianti, controlli, documentazione, sintesi. Alle persone resta il giudizio: definizioni di business, soglie decisionali, approvazioni, assunzione di responsabilità verso stakeholder e autorità di fermare il workflow. Questa separazione va scritta, non presupposta, perché ogni incidente da automazione nasce da un’ambiguità su chi avesse l’ultima parola.

Area di lavoro	L’agente propone	La persona decide
Analisi esplorativa	Ipotesi, query, grafici, segmentazioni	Quale lettura regge e cosa comunicare
SQL e trasformazioni	Bozza di query, test di qualità, doc	Merge su ramo protetto e deploy
Data engineering	Diagnosi di failure, patch candidate	Approvazione del fix e rollback plan
AutoML e feature	Feature candidate, benchmark, report	Scelta del modello e soglia di produzione
Reporting	Sintesi, memo, tabelle	Firma sul numero comunicato all’esterno

Il criterio economico aiuta a non delegare alla cieca. Il valore atteso di un passo agentico è il tempo risparmiato valorizzato al costo orario, meno il prodotto tra probabilità di errore e costo dell’errore, meno il costo di esecuzione. Quando il prodotto tra probabilità e costo dell’errore domina, come in reportistica esterna o scoring creditizio, il passo resta umano anche se l’agente è velocissimo. Quando domina il tempo risparmiato, come nella documentazione o nella profilazione iniziale, l’autonomia paga. Stimare i tre addendi a spanne, prima di automatizzare, evita le discussioni ideologiche sul fidarsi del modello.

Come disegnare contesto, tool e permessi prima di accendere l’agente

Un agente senza contesto inventa il contesto. La contromisura è un pacchetto minimo che accompagna ogni richiesta: definizione della metrica con formula e filtri, grain della tabella, periodo di osservazione, segmenti ammessi, fonti autorizzate e vincoli espliciti. Conversion rate non significa nulla finché non è scritto come ordini su sessioni con consenso tracking, bot esclusi, rimborsi entro 14 giorni trattati come non ordini. Congelare queste definizioni in un file versionato, puntato dal prompt di sistema, elimina la classe di errori più comune: l’agente che risponde alla domanda giusta con la metrica sbagliata.

Segue il disegno dei tool. Ogni funzione esposta all’agente va classificata per pericolosità: lettura soltanto, scrittura su area di staging, scrittura su produzione, esecuzione di codice arbitrario, accesso a dati personali. La configurazione sana prevede tre insiemi: tool sempre permessi come lettura del catalogo e profilazione su campioni, tool con approvazione come esecuzione di query sopra una soglia di costo o scrittura su schema di staging, tool vietati come comandi distruttivi, alter di pipeline schedulate e invio di comunicazioni esterne. Esporre all’agente l’intero warehouse con credenziali da amministratore non è semplificazione, è rinuncia alla governance.

I permessi si completano con limiti quantitativi: budget massimo di scansione per run, numero massimo di passi prima di chiedere conferma, timeout, finestra temporale dei dati interrogabili. Un esempio concreto: agente di supporto analytics con sola lettura sui mart, limite di 500 GB scansionati per run, massimo 15 passi, stop automatico se tocca tabelle con dati personali fuori dalla lista approvata. Questi numeri vanno nel file di configurazione, non nelle buone intenzioni, perché solo ciò che è configurato è verificabile in audit.

Gate di approvazione e controlli che rendono l’output revisionabile

Tra l’agente e il mondo servono cancelli. Il modello minimo ne prevede tre: un gate sintattico che blocca query distruttive e accessi fuori scope prima dell’esecuzione, un gate semantico dove un umano approva azioni con effetti esterni, e un gate di pubblicazione dove il numero che esce verso stakeholder viene firmato. Ogni gate registra chi ha approvato, cosa e su quali evidenze. Senza questo registro, la revisione a posteriori è archeologia.

Il controllo semantico più sottovalutato è il test sul grain di aggregazione. Gran parte degli errori SQL generati da agenti nasce da join che duplicano righe: ordini uniti a righe d’ordine senza pre-aggregazione, eventi uniti ad attributi utente many-to-many. La guardia è semplice e va automatizzata: conteggio righe prima e dopo il join, confronto con cardinalità attesa, blocco se il rapporto supera una soglia. Un secondo controllo obbligatorio è la baseline: nessun miglioramento dichiarato senza confronto con il processo manuale precedente, il periodo precedente o un modello banale. Dire che il nuovo clustering spiega meglio i resi vale solo contro una segmentazione ingenua come regione per fascia di prezzo.

Il terzo pilastro è l’output separato in tre strati: cosa sappiamo con evidenza, cosa non sappiamo per limiti dei dati, cosa proponiamo di fare. Questa struttura impedisce la fusione tra fatti e inferenze che rende i report generati così insidiosi. Un memo che dichiara che il calo è concentrato sul segmento mobile Android dal 12 marzo, che non si sa se dipenda da tracking o domanda reale perché manca il confronto con log grezzi, e che propone due controlli prima di spostare budget, è revisionabile. Un paragrafo che conclude che il calo è dovuto all’aggiornamento app non lo è, per quanto ben scritto.

Prevenire leakage, drift e costi fuori controllo nei workflow agentici

Tre failure mode meritano un trattamento separato perché gli agenti li amplificano in silenzio. Il primo è il leakage temporale: feature che incorporano informazioni disponibili solo dopo l’evento da predire. Un agente lasciato libero di ingegnerizzare feature su uno storico ordini userà quasi certamente timestamp di spedizione o flag di rimborso per predire il reso, ottenendo un punteggio brillante in validazione e un modello inutile in produzione. La difesa è procedurale: cutoff temporale dichiarato per ogni experiment, feature costruite solo con dati antecedenti al cutoff, test che sposta il cutoff indietro di un mese e verifica che le performance non crollino.

Il secondo è il drift: il mondo cambia e il workflow continua a funzionare come se nulla fosse. Un agente di classificazione ticket addestrato su ticket pre-lancio degrada dopo il lancio di una nuova linea di prodotto; un forecast tarato su traffico organico si rompe quando il mix di acquisizione cambia. La metrica di guardia si esprime come distanza tra distribuzioni di input: per una feature, l’indice di stabilità confronta quota per classe nel periodo di riferimento contro quota nel periodo corrente. Valori alti impongono indagine; sopra soglie concordate con il dominio, il workflow si ferma e chiede revisione. Il calcolo conta meno della disciplina: finestra di riferimento congelata, ricalcolo schedulato, owner che risponde all’allarme.

Il terzo è il costo. Un agente che itera su query full-scan può bruciare in una notte il budget mensile di un piccolo team. La stima preventiva aiuta: il costo del run è il prodotto tra passi, righe medie e costo per riga, più il prodotto tra chiamate al modello e costo per chiamata. Con 40 passi e decine di gigabyte scansionati a passo, si arriva a cifre che nessun memo giustifica per una domanda esplorativa. Le contromisure sono campionamento obbligatorio nelle prime iterazioni, limiti e partizionamento imposti dal gate sintattico, dry-run prima dell’esecuzione reale. Il frammento seguente mostra una guardia minima da mettere davanti a ogni query generata, con commenti in italiano:

# Guardia minimale prima di eseguire query generate dall'agente
BLOCCATI = ["drop ", "delete ", "truncate ", "grant ", "revoke "]  # comandi mai ammessi
TABELLE_APPROVATE = {"marts.orders", "marts.sessions", "marts.refunds"}  # allowlist esplicita

def approva_query(sql: str, byte_stimati: int, budget_byte: int) -> tuple[bool, str]:
    # Normalizza per un controllo case-insensitive
    testo = sql.lower()
    # Rifiuta comandi distruttivi o amministrativi
    for vietato in BLOCCATI:
        if vietato in testo:
            return False, f"comando vietato trovato: {vietato.strip()}"
    # Accetta solo tabelle nella lista approvata (euristica: cerca i nomi nel testo)
    if not any(tab in testo for tab in TABELLE_APPROVATE):
        return False, "nessuna tabella approvata rilevata nella query"
    # Blocca esecuzioni sopra budget prima ancora di toccare il warehouse
    if byte_stimati > budget_byte:
        return False, f"stima {byte_stimati} byte sopra il budget {budget_byte}"
    return True, "ok"

Questo non è un sistema di sicurezza completo, ma sposta la protezione dal prompt alla pipeline, dove può essere testata.

Eval, trace e monitoraggio continuo per agenti che toccano i dati

Un workflow agentico senza eval set è un’opinione eseguibile. L’eval set è una raccolta di casi con risposta nota e criterio di giudizio automatico: dieci domande SQL con risultato atteso su snapshot congelato, cinque diagnosi di pipeline con causa radice nota, tre task di feature engineering con vincolo di cutoff temporale. Ogni modifica al prompt di sistema, ai tool o al modello fa rieseguire la suite, e il deploy avviene solo se il punteggio non regredisce. La costruzione richiede un pomeriggio; ripaga al primo aggiornamento di modello che avrebbe silenziosamente cambiato il comportamento su un edge case fiscale o su una definizione di metrica.

Accanto alle eval servono trace complete. Ogni run registra input, contesto fornito, sequenza di chiamate ai tool con argomenti e risultati, output intermedi e approvazioni. La traccia è l’equivalente del log di una pipeline: senza, il debugging è interrogare la memoria di una conversazione. Con, è rieseguire il passo sospetto con gli stessi input. La pratica che distingue i team maturi è campionare regolarmente le trace per revisione umana indipendente, con una griglia fissa: la query usa le definizioni congelate, i controlli sul grain sono passati, le inferenze sono marcate come tali, le azioni vietate non sono state tentate. Bastano cinque run a settimana per intercettare derive prima che diventino incidenti.

Il monitoraggio in produzione chiude il cerchio su tre assi: qualità dei dati in ingresso con test di freschezza e completezza, qualità delle decisioni con confronto periodico contro giudizio umano su campioni, e salute operativa con latenza, costo per run e tasso di rifiuti dei gate. Quando due assi degradano insieme, ad esempio freschezza dati e accuratezza delle diagnosi, la causa è quasi sempre a monte dell’agente. Fermare il workflow in quel caso non è ammettere un fallimento: è il comportamento progettato. Lo stop automatico va definito in anticipo con soglie numeriche, non deciso a caldo durante l’incidente.

# Mini-harness di eval per un agente SQL: riesegue i casi noti su snapshot congelato
import sqlite3  # database locale per l'eval, nessun warehouse toccato

def esegui_eval(casi: list[dict], db_path: str) -> dict:
    # Apre lo snapshot congelato in sola lettura
    conn = sqlite3.connect(f"file:{db_path}?mode=ro", uri=True)
    esiti = []  # raccoglie pass/fail per ogni caso
    for caso in casi:
        # Esegue la query generata dall'agente sul caso corrente
        righe = conn.execute(caso["sql_generata"]).fetchall()
        # Confronta con il risultato atteso registrato nell'eval set
        ok = (righe == caso["atteso"])
        esiti.append({"id": caso["id"], "ok": ok})
    conn.close()
    # Sintetizza il tasso di successo per decidere il deploy
    tasso = sum(1 for e in esiti if e["ok"]) / max(len(esiti), 1)
    return {"tasso_successo": tasso, "dettagli": esiti}

Dal memo alla produzione: far atterrare il lavoro agentico in team

Il punto di caduta più frequente non è tecnico ma organizzativo: l’agente produce, nessuno adotta. La contromisura è standardizzare l’handoff. Ogni output agentico che conta arriva come memo breve con intestazione fissa: decisione da prendere, evidenze con link a query e snapshot, limiti noti, alternative scartate con motivo, raccomandazione e condizione che farebbe cambiare idea. Chi riceve il memo deve poter rispondere approvo, rifiuto o chiedo questi due controlli senza aprire una chat di trenta messaggi. I team che adottano il template vedono crollare i fraintendimenti perché il formato obbliga a separare fatti e giudizi.

La seconda metà dell’atterraggio è la proprietà. Ogni workflow agentico ha un owner nominativo che risponde di definizioni, soglie, eval set e piano di rollback, e una cadenza di revisione proporzionata al rischio: settimanale per scoring e report esterni, mensile per supporto esplorativo interno. L’owner non è chi ha scritto il prompt: è chi ha l’autorità di spegnere il workflow un venerdì pomeriggio senza chiedere permesso. Senza questo ruolo, alla prima anomalia tutti indicano il tool e nessuno interviene sui dati.

Serve infine una politica di rollout a stadi. Stadio uno: l’agente lavora su snapshot storici, nessun dato fresco, nessuna azione. Stadio due: dati freschi in lettura, azioni solo su staging con approvazione. Stadio tre: autonomia limitata su casi a basso rischio con monitoraggio stretto. Il passaggio di stadio richiede eval superate, trace revisionate e firma dell’owner. Saltare gli stadi per entusiasmo è il modo più rapido per trasformare un esperimento promettente in un incidente citato nelle retrospettive per mesi.

Checklist operativa per approvare, limitare o fermare un workflow

Tutto il ragionamento precedente si condensa in una griglia da usare prima di ogni attivazione e a ogni revisione periodica. Non è un modulo burocratico: ogni riga corrisponde a un incidente reale osservato in team dati che hanno automatizzato troppo in fretta. Se una riga non ha risposta, il workflow resta allo stadio precedente.

Domanda	Risposta minima accettabile	Se manca
Quale decisione migliora?	Verbo operativo, owner, scadenza	Si resta su snapshot storici
Quali dati tocca?	Allowlist di tabelle, grain, periodo	Solo lettura su staging
Cosa non può fare mai?	Lista di azioni vietate configurate	Nessuna esecuzione autonoma
Quanto può spendere per run?	Budget byte e chiamate, stop automatico	Dry-run obbligatorio
Come si accorge di sbagliare?	Test grain, baseline, guard su PII	Revisione umana su ogni output
Come si valuta?	Eval set versionato, soglia di deploy	Nessun passaggio di stadio
Chi lo ferma?	Owner nominativo, soglie di stop	Spento fino a nomina

Tre righe meritano attenzione quotidiana. La prima è la condizione di stop: fermiamo il workflow se la freschezza supera sei ore, se l’indice di stabilità supera la soglia per due finestre consecutive, se il tasso di rifiuti dei gate raddoppia in una settimana. La seconda è la regola sui dati personali: minimizzazione, pseudonimizzazione dove possibile, esclusione di default con inclusione solo su approvazione documentata. La terza è il divieto di auto-modifica: l’agente non aggiorna il proprio prompt di sistema, non allarga i propri permessi, non disabilita i propri gate. Sembra ovvio finché un’ottimizzazione ben intenzionata non propone esattamente questo.

Per chi progetta l’orchestrazione, due riferimenti tecnici restano utili come mappe dei concetti, non come ricette: la documentazione sugli agenti di OpenAI per i pattern di tool-use e handoff, e la panoramica di LangGraph per i workflow a grafo con stato, checkpoint e approvazioni intermedie. Entrambi cambiano in fretta; ciò che resta stabile sono i principi: stato esplicito, transizioni osservabili, punti di intervento umano versionati. Un’implementazione concreta dei gate di approvazione dentro un grafo a stati rende visibile ciò che in una catena di prompt resta implicito, e la visibilità è metà della governance.

L’uso maturo di questa cheat sheet si riconosce da un dettaglio: il team la usa anche per dire di no. Dire no a un’automazione prematura su dati non ancora profilati, no a un retraining agentico senza cutoff dichiarato, no a un report generato senza baseline. Ogni no motivato con una riga della griglia aumenta la fiducia nell’automazione restante, perché dimostra che i sì sono meritati. La velocità promessa dagli agenti arriva davvero, ma arriva per ultima, dopo che definizioni, permessi, eval e proprietà hanno reso ogni passo ricostruibile da un collega che non c’era quando il run è partito.

Verdetto: approva solo il workflow che risponde a ogni riga della griglia, limita a staging ed eval ciò che non passa una riga, e fermi tutto dove mancano owner, budget o stop automatico.

La griglia in una frase

La checklist decide se un workflow agentico sui dati si approva, si limita a staging o si ferma per mancanza di controlli.

La sequenza operativa in cinque passi

1. Verifica decisione, dati toccati e azioni vietate prima di ogni attivazione.
2. Imponi budget per run con dry-run obbligatorio e stop automatico.
3. Esegui eval set versionato e trace revisionate prima di ogni passaggio di stadio.
4. Assegna owner nominativo con soglie di stop e piano di rollback.
5. Ripeti la griglia a ogni revisione e declassa alla prima riga senza risposta.

Un caso reale: il costo di un rollout senza gate

Nel luglio 2024 il blackout CrowdStrike ha costretto Delta Air Lines a cancellare circa 7.000 voli in cinque giorni. L’amministratore delegato Ed Bastian ha quantificato l’impatto in circa 500 milioni di dollari tra rimborsi e costi operativi. La causa era un aggiornamento distribuito senza gate graduali né arresto automatico, lo stesso failure mode di un agente senza rollout a stadi. Il caso mostra perché la checklist vale più del prompt: nessuna autonomia scala senza owner, budget e stop.

Domande per chiudere la lezione

1. Quale riga della griglia blocca un workflow senza owner nominato?
2. Quando un passo resta umano anche se l’agente è velocissimo?
3. Come impedisci leakage temporale e drift silenzioso nei run?
4. Cosa serve per passare da snapshot storici a dati freschi in lettura?