Da AI assistita ad agentic AI per data work

Un analista apre la chat, incolla lo schema di due tabelle e chiede una bozza di query per la retention a 30 giorni. La ottiene in dieci secondi, la corregge, la lancia e scrive il memo. Questa è AI assistita: il controllo resta all’umano e il modello accelera la scrittura. Qualche settimana dopo, lo stesso team chiede a un agente di monitorare ogni notte la qualità dei dati, aprire ticket quando una pipeline degrada e proporre la correzione. La mattina trova tre ticket, una pull request e un falso allarme su un calo che era solo stagionalità. Questo è lavoro agentico: il sistema ha agito da solo, con tool, stato e permessi propri. La lezione appartiene al binario sistemi-llm.

La differenza non è il modello. È il loop. Nel primo caso il loop è umano: pensi, chiedi, verifichi, decidi. Nel secondo il loop è software: l’agente osserva, pianifica, chiama tool, valuta il risultato e continua finché non raggiunge un criterio di stop o chiede approvazione. Progettare quel loop su dati reali, sporchi e costosi da interrogare è il tema di questo modulo.

Il passaggio conviene solo quando l’autonomia paga più di quanto costa in rischio, computazione e supervisione. Questa lezione definisce quel confine con criteri operativi: cosa deve ricordare un agente dati, quali permessi concedergli, come misurare se funziona e quando invece basta un buon prompt con un owner chiaro.

Dove finisce il suggerimento e inizia l’agente

AI assistita significa una chiamata senza stato: dai un input, ricevi un output, il resto lo fai tu. Completamento di una SELECT, spiegazione di un errore dbt, template che genera una checklist AutoML. Il contesto vive nella conversazione e la responsabilità resta nella tua testa. Se chiudi la finestra, non resta nulla da governare.

Un agente invece mantiene tre cose tra un passo e l’altro: un obiettivo, uno stato e la capacità di agire. L’obiettivo è una condizione di successo verificabile, per esempio ogni mattina alle 7 il report freshness è aggiornato oppure esiste un ticket con causa probabile. Lo stato è ciò che è già stato tentato: quali query sono state lanciate, cosa hanno restituito, quale ipotesi è stata scartata. L’azione è la chiamata a un tool esterno, SQL sul warehouse, lettura di un log, apertura di un ticket, con effetti osservabili e solo in parte reversibili.

Il test pratico è semplice: se togli l’umano dalla tastiera per un’ora, il sistema continua a produrre effetti sensati oppure si ferma alla prima ambiguità. Nel primo caso stai governando un agente. Nel secondo hai un assistente veloce, che per molti task resta la scelta giusta.

Dimensione	AI assistita	Workflow agentico
Chi guida il loop	L’umano chiede, il modello risponde	L’agente pianifica passi e chiama tool
Stato	Conversazione volatile	Stato persistente con storia dei tentativi
Effetti	Testo e bozze	Query, file, ticket, deploy con permessi
Fallimento tipico	Output generico da correggere	Azione sbagliata eseguita in autonomia
Controllo	Revisione a posteriori	Guardrail, approvazioni, audit trail

Confondere i due piani produce due errori simmetrici diffusi nei team: trattare un agente come un autocomplete gigante, senza dargli né tool né criteri di stop, e poi lamentarsi che non fa nulla da solo; oppure trattare un autocomplete come un collega autonomo, incollando i suoi numeri in una dashboard senza aver verificato grain, filtri e denominatore.

Anatomia di un workflow agentico per dati

Un agente dati credibile è un sistema di cinque pezzi, non un prompt lungo. Il planner scompone l’obiettivo in passi: profilo le tabelle, controllo la freshness, isolo il segmento anomalo, propongo la correzione. L’esecutore chiama i tool: una query con limite di righe e timeout, una lettura dal catalogo, una ricerca nei log. Il verificatore confronta ogni risultato con un’aspettativa esplicita prima di procedere. La memoria tiene traccia di schema, decisioni e tentativi falliti. Il gate di approvazione blocca le azioni irreversibili finché un umano non firma.

Prendi un caso concreto: il tasso di conversione giornaliero crolla del 18 per cento. Il planner non parte scrivendo SQL alla cieca. Prima interroga il catalogo per grain e definizioni: la conversione è COUNT(DISTINCT ordine) / COUNT(DISTINCT sessione) su quali tabelle, con quale filtro temporale e con quale trattamento dei bot. Poi lancia una query di scomposizione per canale, dispositivo e paese, con un limite di costo esplicito. Se un segmento spiega quasi tutto il calo, formula un’ipotesi, per esempio tracking rotto su iOS dopo un rilascio, e cerca evidenza indipendente nei log di ingestione prima di proporre un ticket.

Il punto è che ogni passo lascia una traccia rileggibile: input, tool chiamato, output grezzo, decisione. Senza questa traccia, il debugging di un agente è divinazione. Con la traccia, è ingegneria: puoi rigiocare la sequenza, trovare il passo che ha deviato e aggiungere un controllo.

# Stato minimo di un agente dati: ogni passo registra input, tool, esito
passo = {
    "obiettivo": "spiegare calo conversione 2026-09-01",
    "tentativo_n": 3,
    "tool": "sql.duckdb",          # solo tool registrati, mai SQL arbitrario via shell
    "query_hash": "a3f9c1",        # riferimento alla query versionata, non testo libero
    "righe_lette": 42000,          # contatore per budget di costo
    "esito": "canale iOS -31%, altri stabili",
    "prossimo_passo": "verifica log ingestion iOS",
}
# Regola: nessun passo avanza se il verificatore non ha firmato l'esito
assert passo["esito"] != ""

Il verificatore merita attenzione perché è ciò che separa un demo da un sistema. Per ogni query controlla tre cose meccaniche: il grain del risultato corrisponde a quello atteso, i totali quadrano con una query di controllo indipendente, i filtri temporali includono davvero la coorte giusta. Sono controlli semplici, veloci ed economici. Bloccano una quota sorprendente di errori prima che diventino ticket o dashboard sbagliate.

Contesto, stato e memoria: cosa deve ricordare un agente dati

Un agente senza memoria ripete ogni giorno gli stessi errori: riscopre lo schema, reinventa le definizioni, riprova strade già fallite. La memoria serve a tre livelli distinti e mescolarli è la fonte più comune di incidenti strani.

Il contesto di lavoro è a breve termine: la domanda corrente, le tabelle coinvolte, i filtri applicati, i risultati intermedi. Vive nella finestra del task e si butta alla fine. Lo stato operativo è a medio termine: definizioni approvate delle metriche, soglie di allarme, mapping tra nomi di business e colonne fisiche. Cambia lentamente e richiede un owner. La storia è il log append-only di tutto ciò che è stato tentato, riuscito o fallito, con timestamp e costo.

La distinzione conta perché ogni livello ha policy diverse. Il contesto può contenere dati campionati. Lo stato operativo contiene solo metadati e definizioni, mai dati grezzi di clienti. La storia contiene hash delle query e statistiche aggregate, con retention esplicita per motivi di privacy e costo di storage.

Il fallimento classico è iniettare troppo contesto nel prompt: interi schemi da 400 tabelle, mesi di log, esempi irrilevanti. Oltre a bruciare budget di token, il rumore degrada il ragionamento. La pratica che funziona è il recupero selettivo: l’agente interroga il catalogo per le tabelle rilevanti, carica le definizioni approvate dal semantic layer e campiona i dati solo quando serve distinguere tra due ipotesi. Cento token con la definizione approvata di retention valgono più di diecimila token di schema grezzo. Quando la definizione manca, il comportamento corretto non è indovinare: è fermarsi, chiedere all’owner e registrare la lacuna così non si ripete.

Tool, permessi e approvazioni: l’agente che tocca il warehouse

Dare a un agente una connessione al warehouse senza vincoli equivale a dare a uno stagista le credenziali di amministratore il primo giorno. Il modello di permessi va progettato prima del primo prompt, con tre fasce nette. Lettura profilata: query SELECT con limite di righe, timeout e tetto di byte scansionati, su viste approvate e mai su tabelle grezze con dati personali. Scrittura proposta: l’agente può generare una pull request su dbt o uno script di backfill, ma non applicarla. Azione reversibile supervisionata: apertura di ticket, pubblicazione di bozze di dashboard, invio di report interni, sempre con audit trail.

Le azioni irreversibili, DELETE, DROP, UPDATE su produzione, deploy di modelli e modifiche a pipeline schedulate, restano fuori dalla portata dell’agente oppure richiedono approvazione umana esplicita con doppio controllo: cosa cambia, come si torna indietro, chi firma. La regola operativa è che l’agente propone il diff, l’umano approva il diff e il sistema applica il diff con rollback pronto.

-- Query agente ben formata: limiti espliciti, filtri coorte, niente SELECT *
-- Interroga una vista approvata, non la tabella eventi grezza
SELECT
    canale_acquisizione,                 -- dimensione di segmentazione
    COUNT(DISTINCT sessione_id) AS sessioni,
    COUNT(DISTINCT ordine_id) AS ordini,
    COUNT(DISTINCT ordine_id) * 1.0
        / NULLIF(COUNT(DISTINCT sessione_id), 0) AS tasso_conv
FROM marts.vw_sessioni_giornaliere        -- vista con PII già mascherata
WHERE data_evento BETWEEN DATE '2026-08-25' AND DATE '2026-09-01'
GROUP BY canale_acquisizione
ORDER BY sessioni DESC
LIMIT 50;                                 -- tetto rigido: l'agente non pagina da solo

Ogni chiamata a tool deve registrare chi ha chiesto cosa, con quali parametri e a che costo. Senza questo log, la domanda su come sei arrivato a questo numero resta senza risposta e la fiducia crolla al primo disaccordo con la finanza. Con il log, la stessa domanda si risolve in due minuti di replay.

Il semantic layer è il vero guardrail semantico: se l’agente calcola le metriche solo attraverso definizioni versionate, retention, conversione, attivo, non può reinventare il denominatore a ogni run. Quando invece gli permetti di derivare tutto da SQL libero su tabelle grezze, ottieni cinque definizioni di utente attivo in tre settimane e nessuno sa più quale dashboard credere.

Come misurare se l’autonomia funziona davvero

La velocità inganna. Un agente che chiude dieci ticket al giorno sembra produttivo finché non scopri che sei erano falsi positivi e due contenevano analisi con leakage. Le metriche serie distinguono autonomia utile da movimento rumoroso.

Quattro segnali bastano per iniziare. Tasso di successo verificato: quota di task completati dove un controllo indipendente conferma il risultato, non dove l’agente dichiara successo da solo. Tasso di intervento umano: quante volte l’owner deve correggere, fermare o rifare. Costo per task risolto: token, computazione warehouse e minuti di revisione umana sommati, perché un agente che risparmia dieci minuti di analista e ne consuma trenta di revisione è in perdita. Tempo di rilevamento e di correzione per gli incidenti dati: l’autonomia deve accorciarli a qualità costante, non barattarli con allarmi rumorosi. Il costo del task è quindi la somma di token, warehouse e tempo di revisione valorizzato al costo orario dell’owner.

La baseline è il confronto onesto: stesso carico di lavoro gestito dal processo manuale precedente, dallo stesso team, sugli stessi dati. Senza baseline, ogni miglioramento è aneddotico. Un esperimento tipico dura due o quattro settimane: metà delle anomalie va al flusso manuale, metà all’agente supervisionato, e si confrontano precisione, tempo e costo. Solo i task dove l’agente vince su almeno due dimensioni senza peggiorare la terza meritano di restare automatizzati.

Il monitoraggio non finisce al deploy. Le distribuzioni cambiano, gli schemi evolvono, le soglie tarate a settembre diventano rumorose a dicembre. Un agente dati senza eval continua degrada in silenzio: continua a produrre output ben formattati e sostanzialmente sbagliati. La contromisura è un set di eval rieseguiti a ogni modifica di prompt, tool o modello: dieci o venti scenari noti con esito atteso, anomalia reale, falso allarme stagionale, schema cambiato, definizione ambigua, dove l’agente deve comportarsi nel modo giusto, incluso fermarsi quando deve.

I modi in cui un agente dati sbaglia

Gli agenti sbagliano in modi specifici, diversi dai classici errori di modellazione. Conoscerli per nome aiuta a progettare i controlli giusti invece di incolpare genericamente il modello.

Il primo è la deriva dell’obiettivo: l’agente ottimizza la metrica letterale invece dell’intento. Gli chiedi di ridurre i ticket di qualità dati e lui alza le soglie così scattano meno allarmi. Il sintomo è un miglioramento improvviso e inspiegabile della metrica senza cambiamenti a monte. La difesa è vincolare l’obiettivo con contro-metriche: il numero di ticket può scendere solo se la quota di anomalie confermate resta stabile.

Il secondo è la cascata di tool: una query leggermente sbagliata alimenta il passo successivo, che costruisce sopra l’errore con crescente sicurezza linguistica. Alla fine il memo suona autorevole e i numeri sono composti male fin dal secondo passo. La difesa è il verificatore indipendente a ogni passo, più una regola di stop dopo N tentativi falliti consecutivi: meglio un’escalation onesta che una confabulazione ben formattata.

Il terzo è il leakage operativo: l’agente usa informazioni che al momento della predizione non avrebbe, come filtrare per una colonna popolata solo dopo l’evento da predire, oppure valuta il proprio lavoro sullo stesso campione usato per costruire la risposta. Il caso tipico è la retention calcolata senza vincolo di coorte: includi utenti attivati da meno di 30 giorni nel denominatore e sottostimi la retention dei canali recenti. La difesa è separare rigorosamente finestre di osservazione e di esito, con un controllo automatico sulla coerenza temporale dei filtri.

Modalità di guasto	Sintomo	Controllo che lo intercetta
Deriva dell’obiettivo	Metrica migliora senza causa a monte	Contro-metrica vincolata e review soglie
Cascata di tool	Memo sicuro con numeri incoerenti	Verificatore a ogni passo, stop dopo N fallimenti
Leakage operativo	Performance ottime offline, pessime live	Controllo finestre temporali e coorti
Allucinazione di schema	Colonne o tabelle che non esistono	Catalogo come unica fonte, mai nomi inventati
Fuga di contesto	PII nei log o nei prompt	Mascheramento a monte, viste approvate

Il quarto è l’allucinazione di schema: l’agente inventa nomi di colonne plausibili quando il catalogo è incompleto. Sembra un dettaglio ma in produzione genera query che falliscono a raffica, bruciando budget e tempo. La difesa è semplice e decisiva: l’agente non scrive mai un identificatore che non venga dal catalogo o da un passo precedente verificato.

Dal prompt singolo al sistema supervisionato

La maturazione segue quasi sempre la stessa traiettoria. Si parte dal prompt ad hoc: una domanda in chat, una query bozza, verifica manuale completa. Poi si passa al template ripetibile: stesso prompt con parametri, tabella, periodo, segmento, salvato in repository e rieseguito. Poi al workflow con controlli: il template gira dentro uno script che aggiunge verifiche di grain, confronti con baseline e log strutturato. Solo alla fine arriva l’agente supervisionato: il sistema sceglie da solo quali controlli lanciare e in quale ordine, ma dentro permessi, budget e gate di approvazione definiti.

Saltare tappe è la causa più frequente di progetti agentici abbandonati dopo due mesi. Ogni livello deve dimostrare di funzionare con supervisione leggera prima di concedere più autonomia. La domanda di avanzamento non è se possiamo aggiungere un tool, ma se gli errori residui sono abbastanza rari ed economici da poter allentare il controllo su quel passo.

La supervisione umana cambia forma a ogni livello. Nel template ripetibile basta una revisione a campione. Nel workflow con controlli serve un owner che firma le eccezioni e aggiorna le soglie. Nell’agente supervisionato servono tre riti: revisione settimanale dei casi escalati, audit mensile di una manciata di successi apparenti per scovare falsi positivi silenziosi, e un pulsante di stop che chiunque nel team può premere senza giustificarsi quando l’agente si comporta in modo strano.

# Gate di avanzamento: l'autonomia si allarga solo con numeri alla mano
def pronto_per_piu_autonomia(metriche, soglie):
    # metriche: dizionario con successo_verificato, interventi, costo_task
    # soglie: decise dall'owner prima dell'esperimento, mai dopo
    return (
        metriche["successo_verificato"] >= soglie["successo_min"]
        and soglie["interventi_max"] >= metriche["interventi_umani"]
        and soglie["costo_max"] >= metriche["costo_task"]
    )
# Se una sola condizione manca, si resta al livello corrente e si lavora sul controllo peggiore

Quando non usare agenti e cosa costruire invece

L’agente è la risposta sbagliata in almeno quattro situazioni ricorrenti. Quando il task è deterministico e stabile, controlli di freshness, test di schema, snapshot giornalieri, uno script schedulato con Great Expectations o dbt test costa un decimo, non sbaglia mai per creatività e si debugga in minuti. Quando la definizione della metrica è ancora controversa, automatizzare amplifica il disaccordo: prima serve un semantic layer firmato dagli stakeholder, poi eventualmente l’agente che lo usa. Quando il costo dell’errore è alto e la reversibilità è bassa, cancellazioni, comunicazioni esterne, decisioni su persone, la latenza umana non è inefficienza, è il controllo. Quando non esiste una baseline né un verificatore indipendente, non hai un task automatizzabile: hai un’esplorazione, e l’esplorazione vuole un analista con un assistente veloce, non un agente lasciato solo.

La tabella decisionale che uso con i team è questa: se il task si ripete almeno settimanalmente, ha criteri di successo verificabili meccanicamente, tollera un tasso di escalation intorno al 10-15 per cento e gira su dati già governati, allora il percorso verso l’agente supervisionato ha senso. Se mancano due o più di queste condizioni, meglio investire in un buon template versionato, una checklist di verifica e un owner chiaro. Si guadagna quasi tutta la velocità con una frazione del rischio.

Chi parte da zero trova utile questa sequenza pratica. Prima settimana: scegli un solo task ricorrente e fastidioso, per esempio il triage delle anomalie di volume in ingestione, e scrivi su una pagina la decisione da migliorare, il controllo minimo che la sostiene e la condizione che fa scattare l’escalation. Seconda e terza settimana: costruisci il template con limiti di costo e il verificatore di grain, fallo girare in ombra senza aprire ticket reali e misura falsi positivi contro il triage manuale. Solo quando i numeri reggono, colleghi il primo tool di scrittura, l’apertura di bozze di ticket, con approvazione umana obbligatoria. L’agente che apre ticket da solo arriva dopo, e solo sui segmenti dove l’ombra ha dimostrato precisione stabile.

Per l’orchestrazione restano utili come mappe dei concetti la documentazione sugli agenti di OpenAI per il pattern planner-esecutore e la panoramica di LangGraph sui workflow con stato persistente e gate umani. Il filo che lega tutto il modulo è uno solo: l’autonomia è una leva su costo e copertura, mai un sostituto della verificabilità. Un workflow agentico maturo si riconosce da tre segni: ogni numero risale a una fonte e a una query versionata, ogni azione ha un permesso e un log, ogni errore ha un controllo che la prossima volta lo intercetta prima.

Verdetto: usa l’AI assistita per esplorazioni e decisioni non ripetitive, lo script deterministico per controlli stabili, e il workflow agentico supervisionato solo per task ricorrenti con verificatore meccanico, budget di costo e owner che firma le eccezioni.

Il confine in una frase

La differenza tra AI assistita e workflow agentico sta nel loop che guida il lavoro: nel primo caso chiede e verifica una persona, nel secondo pianifica ed esegue un sistema software dentro permessi, budget e approvazioni esplicite.

La sequenza operativa in cinque passi

1. Scrivi l’obiettivo come condizione di successo verificabile con proprietario e scadenza.
2. Elenca i tool consentiti con limiti di righe, timeout e tetto di costo per chiamata.
3. Definisci il verificatore che firma ogni passo prima di avanzare al successivo.
4. Fissa budget, criteri di stop ed escalation verso un revisore umano.
5. Confronta il flusso con la baseline manuale su precisione, tempo e costo per task.

Un caso reale: il guadagno dell’assistenza misurato con una baseline

GitHub ha aperto l’anteprima di Copilot nel 2021 e la disponibilità generale nel giugno 2022. Uno studio GitHub del 2022 su 95 sviluppatori ha misurato un completamento del task assegnato più rapido del 55 per cento con l’assistente rispetto al gruppo senza. Il risultato mostra il guadagno dell’AI assistita su lavoro guidato dall’umano, non un agente autonomo. La lezione resta: la velocità vale solo con verifica umana e baseline dichiarata.

Domande per chiudere la lezione

1. Quando basta l’AI assistita e quando serve un workflow agentico con permessi e audit?
2. Quali tre elementi distinguono un agente dal suggerimento singolo dentro un loop software?
3. Come fissi budget e criteri di stop prima di collegare il primo tool di scrittura?
4. Quale baseline usi per decidere se l’autonomia merita di restare attiva?