Agentic data analysis con controlli umani

Il problema concreto è questo: usare agenti AI sui dati senza trasformare il lavoro analitico in risposte che nessuno sa verificare. Non basta chiedere al modello di fare analisi. Serve un flusso in cui domanda, dati, controlli e decisione restano visibili e tracciabili, dal primo prompt al memo finale. La lezione riprende il disegno di tool, stato e guardrail e lo porta sul piano operativo: più velocità e copertura sul lavoro dati, senza cedere l’ownership su definizioni, soglie, segmenti e raccomandazioni. Appartiene al binario sistemi-llm.

Quando l’analista diventa il collo di bottiglia

Prendi una review settimanale qualunque: marketing, prodotto e data team devono decidere cosa correggere per primo tra funnel, tracking, campagna, modello o pipeline. Senza approccio agentico, l’analista brucia ore in passaggi ripetitivi, estrarre dati, incrociare tabelle, rifare gli stessi grafici con un filtro diverso. Con agentic AI usata male, il rischio opposto: una spiegazione convincente che cita numeri precisi e propone causa e soluzione, ma poggia su un join sbagliato o una definizione di metrica mai controllata.

La differenza sta nel disegno operativo. L’agente aiuta a formulare ipotesi, generare checklist di controlli, proporre segmenti alternativi, sintetizzare risultati e preparare output leggibili. Non decide da solo quale metrica conta, quale definizione usare o quale raccomandazione portare al business. Ogni passaggio lascia una traccia che un revisore può leggere, contestare e migliorare: query salvate, assunzioni dichiarate, controlli eseguiti con esito visibile.

Momento	Uso utile dell’agente	Controllo che resta umano
Prima dell’analisi	Chiarire domanda, vincoli e output atteso	Confermare owner, metrica e baseline
Durante l’analisi	Suggerire controlli, segmenti, spiegazioni alternative	Verificare dati, grain, filtri e casi limite
Dopo l’analisi	Preparare memo, trade-off, prossimi passi	Separare evidenza, ipotesi e raccomandazione

Il collo di bottiglia reale quasi mai è scrivere codice. È capire quale domanda merita risposta, quali dati sono affidabili, quale metrica sposta davvero la decisione e quale rischio resta in piedi dopo la raccomandazione. Un workflow agentico ben disegnato mette questi passaggi in primo piano invece di nasconderli dentro una chat che nessuno rileggerà.

Il confine tra delega e responsabilità

Il punto di partenza è distinguere i compiti delegabili dalle responsabilità che non si delegano. L’agente può generare ipotesi, bozze di query, documentazione, test di qualità, feature candidate per un modello e sintesi di risultati. La decisione resta umana quando tocca budget, roadmap, clienti, compliance, accessi ai dati o modelli in produzione. Sembra ovvio scritto così; in pratica il confine si sposta di nascosto, un’autonomia concessa per comodità alla volta, finché nessuno sa più chi ha deciso cosa.

Un modo concreto per fissarlo è scrivere tre righe prima di avviare qualsiasi workflow agentico. Decisione: quale scelta concreta vogliamo migliorare, espressa con un verbo operativo e un owner nominato. Evidenza: quale dato o controllo può sostenere quella scelta, con fonte e periodo dichiarati. Stop: quale rischio ci farebbe fermare tutto e chiedere una review, dati incoerenti, definizioni in conflitto, costi oltre soglia, segnali di leakage in un modello. Se manca una di queste tre righe, il workflow non è pronto: l’agente resta utile come supporto esplorativo, ma non entra nel processo decisionale stabile del team.

Disegnare il ciclo decisione-dato-controllo

Il framework operativo di riferimento ha cinque passaggi e l’ordine conta. Prima definisci la decisione da migliorare: non analizzare il funnel, ma decidere se investire due sprint nel rifacimento dell’onboarding o in una campagna di riattivazione, con owner e scadenza chiari. Poi descrivi il dato disponibile con i suoi limiti noti: sorgenti, grain, periodo coperto, buchi di tracking già conosciuti, più il contesto business che rende quei numeri interpretabili. Solo a quel punto chiedi all’agente di proporre ipotesi o passaggi, esplicitamente non conclusioni definitive. Le proposte diventano controlli eseguibili: query, confronti tra segmenti, baseline storiche. Infine consegni un output che separa con chiarezza cosa sai, cosa non sai e cosa intendi fare.

Passaggio	Domanda guida	Output minimo
Decisione	Quale scelta deve migliorare?	Verbo operativo e owner
Contesto	Che cosa sappiamo dei dati?	Fonti, grain, periodo, limiti
Supporto AI	Quale parte si può accelerare?	Prompt, tool o checklist
Verifica	Quale errore cambierebbe la conclusione?	Controllo, guardrail, baseline
Handoff	Chi decide e con quale criterio?	Memo, ticket, modello o dashboard

Lo schema regge per analisi esplorativa, SQL, data engineering, AutoML e workflow agentici: cambiano gli strumenti, non il principio. Nessun output diventa evidenza finché non è collegato a una fonte, a un controllo e a una decisione. Vale anche per i passaggi intermedi che sembrano innocui: una tabella aggregata che l’agente prepara solo per esplorare finisce citata in una slide, e da lì diventa premessa di una decisione. Tracciare anche quelli costa poco e salva molto.

La parte che i team sottovalutano è il criterio di stop. Va dichiarato prima, non quando i numeri iniziano a puzzare: se il dato o il modello non reggono, il workflow si ferma e scala a un umano. Esempi tipici di stop sono una discrepanza tra sorgenti oltre soglia, una definizione di metrica contestata tra due team, un costo di esecuzione anomalo, un controllo di qualità fallito su una pipeline. Senza stop dichiarati, l’agente fa quello per cui è ottimizzato, produrre un output plausibile, anche quando l’input non lo meriterebbe.

Compito, contesto, controllo, decisione: il modello a quattro livelli

Sotto il ciclo c’è un modello ancora più semplice, quattro livelli che chiariscono cosa chiedere all’agente e cosa tenere in mano. Il compito dice quale parte del lavoro viene accelerata: bozza di query, profilo dati, checklist AutoML, memo di sintesi. Il contesto fornisce ciò che rende l’output utilizzabile invece che generico: schema delle tabelle, definizione della metrica, periodo, segmento, policy di accesso. Il controllo verifica che l’output non sia solo plausibile sulla carta: test sul grain, confronto con baseline, ricerca di leakage, review dell’owner. La decisione chiarisce cosa cambia concretamente: fix a una pipeline, esperimento da lanciare, modello da promuovere, raccomandazione da portare in review.

Livello	Cosa chiarire	Esempio nel data work
Compito	Quale parte del lavoro viene accelerata?	Bozza query, profilo dati, checklist AutoML, memo
Contesto	Quali informazioni rendono l’output utile?	Schema, metrica, periodo, segmento, policy
Controllo	Come scopri se l’output è sbagliato?	Test grain, baseline, leakage, review owner
Decisione	Quale azione segue se il controllo regge?	Fix pipeline, esperimento, deploy, raccomandazione

Il modello evita due errori opposti e simmetrici. Il primo è ridurre l’agente a un autocomplete testuale, con prompt vaghi, output generici e zero connessione con dati e tool reali. Il secondo è concedergli autonomia su decisioni che richiedono giudizio di business, come ridefinire un segmento di clientela o promuovere un modello con metriche appena sufficienti. La competenza sta nel tracciare quel confine caso per caso e riscriverlo quando il workflow evolve. Un confine scritto in un documento condiviso, con esempi di cosa l’agente può fare da solo e cosa no, vale più di dieci discussioni astratte su quanta autonomia dare al modello.

Fermarsi al momento giusto: i gate di approvazione

Il comportamento che distingue un agente affidabile da uno pericoloso è saper chiedere aiuto. Pensa a un agente che analizza una caduta di activation: incrocia eventi prodotto e tabelle BI, trova definizioni incoerenti di utente attivo tra i due team e si ferma invece di scegliere da solo. Il revisore indica la definizione corretta e l’agente riprende da lì. Tutto qui, ma è esattamente il comportamento che vuoi industrializzare, non lasciare al caso.

Per farlo serve una policy esplicita dei permessi, scritta prima che l’agente tocchi dati reali. Tre fasce bastano nella maggior parte dei casi. Azioni libere: leggere schemi e metadati, proporre ipotesi, generare bozze di query, produrre controlli read-only su campioni. Azioni con approvazione: eseguire query su tabelle di produzione, modificare una pipeline, riaddestrare o promuovere un modello, inviare output a stakeholder. Azioni vietate: accedere a dati personali non necessari, scrivere su tabelle gold senza review, decidere soglie di business, silenziare o saltare un controllo fallito.

Fascia	Esempi	Chi approva
Libera	Profilo dati, bozze query, checklist, sintesi	Nessuno, con trace automatica
Con approvazione	Query su produzione, fix pipeline, deploy modello	Owner nominato, con criterio scritto
Vietata	Accessi PII non necessari, scritture gold, soglie business	Mai delegabile, solo processo umano

Ogni gate deve registrare tre cose: chi ha approvato, sulla base di quale evidenza, con quale criterio reversibile. Approvato su Slack senza contesto non è un gate, è un ricordo. Un gate vero dice: la product manager ha approvato il deploy perché precision e recall sul periodo di holdout superano le soglie scritte nel model card, e il rollback scatta se la metrica live scende sotto soglia per due giorni. Quando l’approvazione diventa un rituale formale, click senza lettura, il controllo umano è morto anche se la casella risulta spuntata. La difesa è rendere ogni approvazione contestabile: evidenza allegata, criterio verificabile, possibilità reale di dire no senza bloccare il team per una settimana.

Formalizzare il problema prima di automatizzarlo

Per rendere il problema analizzabile, definisci prima l’unità di lavoro: un’ipotesi, un controllo, una query proposta, un grafico, un memo, un singolo intervento umano. Poi collega quell’unità a segnali osservabili: qualità delle ipotesi generate, correzioni del revisore, falsi insight intercettati prima della presentazione, copertura dei segmenti rilevanti, chiarezza dell’output finale. Infine dichiara la decisione attesa: stabilire dove l’agente può procedere da solo e dove deve fermarsi per approvazione.

Elemento	Specifica richiesta
Unità di analisi	Ipotesi, controllo, query proposta, grafico, memo, intervento umano
Segnale principale	Qualità ipotesi, correzioni reviewer, falsi insight evitati, copertura segmenti
Baseline	Processo manuale, periodo precedente, gruppo comparabile, modello attuale
Decisione	Dove l’agente procede e dove chiede approvazione
Guardrail	Privacy, costo, qualità dati, interpretabilità, ownership, rischio operativo
Rischio principale	Human-in-the-loop ridotto a rituale formale senza capacità di correzione

L’impostazione regge quando un revisore esterno può riprodurre la logica, criticare le assunzioni e arrivare alla stessa decisione partendo dagli stessi dati. Se il risultato dipende da una conversazione non tracciata, il workflow non è maturo, per quanto sembri funzionare. La baseline merita attenzione esplicita: confronta sempre il workflow agentico con il processo manuale precedente o con un periodo comparabile, su tempo, qualità e rischi. Velocità senza baseline è marketing interno.

La query che smaschera le metriche pigre

Fin qui il discorso è di processo. Ora serve la prova su dati veri, perché è lì che i workflow agentici falliscono più spesso: non nel ragionamento, ma in un dettaglio SQL che nessuno controlla. Il caso classico è la retention a 30 giorni calcolata come COUNT(DISTINCT user_id) su tutta la tabella eventi, senza filtrare per data di attivazione. Il risultato include utenti attivati da dieci giorni che non hanno ancora avuto il tempo di arrivare a trenta, e deforma la metrica a seconda del mix di coorti. Un agente a cui chiedi di calcolare la retention produce spesso proprio questa versione, sintatticamente perfetta e concettualmente sbagliata.

La versione corretta ancora prima la coorte all’attivazione e poi misura solo dentro la finestra valida:

-- Cohort di attivazione: un utente esiste per l'analisi
-- solo dal giorno del suo primo evento
WITH cohort AS (
    SELECT
        user_id,
        MIN(event_date) AS activation_date -- inizio finestra dei 30 giorni
    FROM events
    GROUP BY user_id
),
-- Per ogni data di attivazione, conta quanti utenti
-- hanno almeno un evento dentro la finestra valida
retention AS (
    SELECT
        c.activation_date,
        -- denominatore corretto: solo utenti con finestra completa
        COUNT(DISTINCT c.user_id) AS cohort_size,
        COUNT(DISTINCT CASE
            WHEN e.event_date > c.activation_date -- ritorni successivi
             AND e.event_date <= c.activation_date + INTERVAL '30 days'
            THEN e.user_id
        END) AS retained_users
    FROM cohort c
    LEFT JOIN events e
        ON c.user_id = e.user_id -- join sull'utente, mai su date grezze
    -- solo cohort con finestra già chiusa alla data di analisi
    WHERE c.activation_date <= CURRENT_DATE - INTERVAL '30 days'
    GROUP BY c.activation_date
)
SELECT
    activation_date,
    cohort_size,
    retained_users,
    -- percentuale arrotondata: il controllo umano legge questa colonna
    ROUND(100.0 * retained_users / NULLIF(cohort_size, 0), 2) AS retention_pct
FROM retention
ORDER BY activation_date;

Tre dettagli meritano review umana ogni volta: il filtro che esclude le coorti con finestra incompleta, il LEFT JOIN che preserva gli utenti senza ritorni invece di farli sparire, il NULLIF contro la divisione per zero. Il principio guida resta uno solo, da verificare prima di fidarti di qualsiasi numero: la somma delle parti deve tornare con il totale. Se la retention per segmento non riconcilia con quella globale, c’è un filtro o un join che mente, e nessun memo ben scritto lo può compensare.

Gli errori che vedo più spesso nei team

Il primo errore è usare l’approccio agentico come etichetta invece che come processo: mostrare un output generato senza spiegare dati, controlli e decisione che ci stanno dietro. Il secondo è confondere la produttività del singolo, per esempio l’analista fa tutto in un pomeriggio, con l’affidabilità dell’organizzazione, che dipende da review, ownership e monitoraggio, non dalla velocità di una persona assistita. Il terzo, il più costoso, è non aver deciso in anticipo quali azioni sono permesse, quali richiedono approvazione e quali sono vietate: il confine si negozia caso per caso, sotto pressione, e perde sempre il controllo.

L’errore tecnico gemello riguarda il denominatore. Calcolare un tasso di conversione medio su tutta la popolazione senza segmentare per canale di acquisizione produce decisioni sbagliate appena il mix di canali cambia nel tempo, ed è esattamente il tipo di errore che un agente non nota, perché la query gira e il numero sembra ragionevole. La difesa è una domanda da porre sempre prima di fidarti del numeratore: rispetto a cosa sto misurando questo. Verifica che il denominatore sia corretto, confronta la metrica globale con la somma dei segmenti, usa un gruppo di controllo quando possibile. Ogni spiegazione plausibile che l’agente propone va tradotta in un controllo su dati o processo prima di entrare in un memo: la plausibilità linguistica non è prova empirica, e un risultato che migliora una metrica potrebbe nascondere effetto composizione, leakage o semplice stagionalità.

Rendere il lavoro revisionabile da chiunque

Tutto il percorso converge su un artefatto finale che un altro professionista possa revisionare senza doverti intervistare: ipotesi dichiarate, dati richiesti con fonti e periodo, criteri di esclusione, controlli di qualità con esito, soglia decisionale, rischio residuo, piano di monitoraggio dopo la decisione. Aggiungi una sezione che pochi scrivono e tutti rimpiangono: cosa farebbe cambiare idea al team. Definirla prima protegge dall’ancoraggio: se sai già quale segnale ti farebbe invertire la rotta, lo riconoscerai quando arriva invece di razionalizzarlo.

Per i riferimenti tecnici che evolvono in fretta, SDK per agenti, framework di orchestrazione come LangGraph, pattern di tool e memoria, verifica sempre concetti, limiti e terminologia sulla documentazione ufficiale prima di progettare workflow reali, senza copiarli come ricette:

• OpenAI Agents SDK: https://developers.openai.com/api/docs/guides/agents
• LangGraph overview: https://docs.langchain.com/oss/python/langgraph/overview
• LangGraph workflows and agents: https://docs.langchain.com/oss/python/langgraph/workflows-agents

La regola finale è semplice e conviene tenerla appesa sopra la scrivania: più il workflow usa tool, stato, approvazioni e trace, più deve essere osservabile. Un output che non puoi ricostruire, revisionare o fermare non è automazione professionale, è solo velocità che nessuno governa. Il ciclo decisione, contesto, supporto AI, verifica e handoff trasforma la lezione in pratica verificabile, e ogni volta che un revisore riesce a rifare i tuoi passi e arrivare alla stessa decisione, il sistema ha funzionato.

Verdetto: delega all’agente ipotesi, bozze e controlli meccanici, e tieni agli umani definizioni, soglie, approvazioni e firma sul numero comunicato.

Il principio in una frase

L’analisi agentica con controlli umani decide in anticipo dove l’agente procede da solo e dove si ferma per approvazione con evidenza tracciabile.

La sequenza operativa in cinque passi

1. Scrivi decisione, evidenza e condizione di stop con owner nominato prima di partire.
2. Fai proporre all’agente ipotesi e controlli, mai conclusioni definitive.
3. Esegui verifiche meccaniche su grain, filtri, finestre e riconciliazione dei segmenti.
4. Blocca il flusso su definizioni contestate, dati incoerenti o costi fuori soglia.
5. Consegna un memo che separa evidenza, ipotesi e raccomandazione con piano di monitoraggio.

Un caso reale: il punteggio che nessuno aveva approvato

Nel 2012 il New York Times ha raccontato come Target assegnasse un punteggio di gravidanza a partire da circa 25 prodotti indicatori. Il modello funzionava e proprio per questo fece scandalo: un padre scoprì la gravidanza della figlia adolescente dai coupon mirati prima di saperlo in famiglia. Il caso mostra perché segmentazione e dati sensibili vogliono gate umani: un punteggio accurato senza policy di approvazione produce danno reale. Da allora è il riferimento standard per chi progetta controlli su PII e output verso clienti.

Domande per chiudere la lezione

1. Dove l’agente procede da solo e dove deve fermarsi per approvazione?
2. Quali tre righe scrivi prima di avviare un workflow agentico?
3. Come verifichi grain, denominatore e finestre prima di fidarti di un tasso?
4. Cosa deve contenere un gate di approvazione per essere contestabile?