Agentic data analysis with human controls

Il problema concreto è questo: come usare agentic AI sui dati senza trasformare il lavoro analitico in una sequenza di risposte che nessuno riesce a verificare. Non basta chiedere al modello di “fare analisi”. Bisogna progettare un flusso in cui domanda, dati, controlli e decisione restano sempre visibili e tracciabili.

La lezione riprende e approfondisce quanto visto in tool-state-memory-handoff-e-guardrail, aggiungendo un livello operativo. L’obiettivo è guadagnare velocità e copertura sul lavoro sui dati senza cedere l’ownership su definizioni, soglie, segmenti e raccomandazioni.

A starting scene

Immagina una review settimanale in cui marketing, prodotto e data team devono decidere cosa correggere per primo, tra funnel, tracking, campagna, modello o pipeline. Senza un approccio agentico l’analista rischia di bruciare ore in passaggi ripetitivi. Con agentic AI usata male, rischia di consegnare una spiegazione che suona convincente ma è fragile.

La differenza sta nel disegno operativo. L’AI dovrebbe aiutare a formulare ipotesi, creare checklist, proporre controlli, sintetizzare risultati e preparare gli output. Non dovrebbe sostituire la verifica del dato, la responsabilità sulla metrica o la scelta di business. Ogni passaggio deve lasciare una traccia che un reviewer possa leggere, contestare e migliorare.

Moment	Useful use	Necessary control
Before analysis	Clarify question, constraints, and expected output	Confirm owner, metric, and baseline
During analysis	Suggest controls, segments, and alternative explanations	Verify data, grain, filters, and edge cases
After the analysis	Prepare memos, trade-offs, and next steps	Separate evidence, hypothesis, and recommendation

Perché conta nel lavoro sui dati

Nel lavoro reale il collo di bottiglia non è quasi mai scrivere codice. Di solito è capire quale domanda merita una risposta, quali dati sono affidabili, quale metrica sposta davvero la decisione e quale rischio resta in piedi dopo la raccomandazione. Un workflow agentico con controlli umani mette questi passaggi in primo piano invece di nasconderli dentro una chat.

Un buon workflow con AI parte da una decisione concreta e non da uno strumento. Dichiara input, vincoli e output atteso. Produce artefatti che si possono revisionare, non solo un blocco di testo finale. E prevede un criterio di stop per quando il dato o il modello non reggono. Quando una di queste proprietà manca, il lavoro può sembrare moderno ma resta fragile. L’AI aumenta la produttività solo se alza anche la qualità della domanda e la disciplina dei controlli.

Operating Framework

Il framework ha cinque passaggi. Prima definisci la decisione da migliorare. Poi descrivi il dato disponibile, i limiti noti e il contesto business. A quel punto chiedi all’AI di proporre ipotesi o passaggi, non conclusioni definitive. Trasformi le proposte in controlli eseguibili. Infine consegni un output che separa con chiarezza cosa sai, cosa non sai e cosa intendi fare.

Step	Guiding question	Minimum Output
Decision	Which choice needs to improve?	Operating Verb and Owner
Context	What do we know about the data?	Sources, grain, period, limitations
AI Support	Quale parte può essere accelerata?	Prompt, tool or checklist
Verification	Which error could change the conclusion?	Control, guardrail, baseline
Handoff	Who decides and by what criteria?	Memo, ticket, model or dashboard

Lo schema vale 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.

Quando serve davvero

In un contesto di analisi dati, data engineering e AutoML, questo approccio serve a stabilire dove l’agente può procedere da solo e dove deve fermarsi e chiedere approvazione. Non è teoria astratta. È un modo per migliorare una scelta concreta con dati, assunzioni esplicite e qualche controllo minimo.

Il problema nasce quando un team vuole velocizzare il lavoro ma non sa distinguere i compiti delegabili dalle responsabilità che non si delegano. L’AI può generare ipotesi, query, documentazione, test, feature candidate o sintesi. La decisione resta umana quando tocca budget, roadmap, clienti, compliance, accessi o modelli in produzione.

L’obiettivo è produrre un artefatto che un altro professionista possa revisionare. Se alla fine non sai dire quale decisione cambia, quale dato osservi e quale errore vuoi evitare, la lezione non è ancora diventata competenza applicata.

Conceptual model

Il modello ha quattro livelli: compito, contesto, controllo e decisione. Il compito dice cosa può fare l’AI. Il contesto fornisce dati, definizioni, strumenti e vincoli. Il controllo verifica che l’output non sia solo plausibile sulla carta. La decisione chiarisce cosa cambia concretamente nel lavoro del team.

Level	What to clarify	Example in data work
Task	Which part of the work is accelerated?	Query draft, data profile, AutoML checklist, memo
Context	What information makes the output useful?	Schema, metric, period, segment, policy
Control	Come scopri se l’output è sbagliato?	Test grain, baseline, leakage, review owner
Decision	What action follows if the control holds?	Fix pipeline, experiment, deploy, recommendation

Il modello evita due errori opposti: ridurre l’AI a un autocomplete testuale, oppure darle autonomia su decisioni che richiedono giudizio di business. La competenza sta nel tracciare quel confine.

Formalizzare il problema

Per rendere il problema analizzabile, definisci prima l’unità di lavoro, che può essere un’ipotesi, un controllo, una query proposta, un grafico, un memo o un intervento umano. Poi collega quell’unità a segnali osservabili come la qualità delle ipotesi, le correzioni del reviewer, i falsi insight evitati, la copertura dei segmenti e la chiarezza finale. Infine dichiari la decisione attesa, cioè stabilire dove l’agente può procedere e dove deve fermarsi per l’approvazione.

Element	Requested specification
Unit of analysis	hypothesis, control, proposed query, chart, memo or human intervention
Primary signal	qualità ipotesi, correzioni reviewer, falsi insight evitati, copertura segmenti e chiarezza finale
Baseline	Manual process, previous period, comparable group or current model
Decision	stabilire dove l’agente può procedere e dove deve fermarsi per approvazione
Guardrail	Privacy, costo, qualità dati, interpretabilità, ownership e rischio operativo
Main risk	trasformare human-in-the-loop in rituale formale senza vera capacità di correggere il sistema

L’impostazione regge quando un reviewer può riprodurre la logica, criticare le assunzioni e arrivare alla stessa decisione partendo dagli stessi dati. Se il risultato dipende da una conversazione che non è rimasta tracciata, il workflow non è ancora maturo.

Un caso concreto

Pensa a un agente che analizza una caduta di activation. A un certo punto trova definizioni incoerenti tra prodotto e BI e si ferma. Il reviewer sceglie la definizione corretta, poi l’agente riprende. Tutto qui, ma è esattamente il comportamento che vogliamo.

Il caso mostra che l’AI non è il centro del lavoro. Il centro è il ciclo decisionale: domanda, dato, controllo, raccomandazione, monitoraggio. L’AI riduce l’attrito tra questi passaggi, ma ogni passaggio resta sotto controllo umano.

Observed evidence	Cautious interpretation	Recommended action
Il workflow produce output più rapidamente	La velocità è utile solo se non abbassa qualità e controllo	Compare with manual baseline and independent review
The model proposes plausible explanations	La plausibilità linguistica non è prova empirica	Translate every explanation into data or process control
The result improves a metric	Potrebbe esserci effetto composizione, leakage o stagionalità	Segment, verify guardrails and monitor over time

Un buon caso non si chiude con “l’AI ha funzionato”. Si chiude con una decisione difendibile: cosa automatizzare, cosa tenere manuale, quale metrica monitorare e quale condizione farebbe fermare il processo.

Esercitarsi

Puoi lavorare su questi concetti a profondità crescente. Per cominciare, scrivi una scheda di una pagina con decisione da supportare, input richiesti, output atteso, controllo minimo e rischio principale. Vai su un caso semplice, come una variazione di conversione, una pipeline in ritardo o un modello forecast da valutare.

A un livello intermedio, costruisci una tabella con tre scenari: workflow manuale, workflow assistito dall’AI e workflow con automazione più spinta. Per ognuno indica tempo stimato, qualità attesa, rischio operativo, controllo necessario e owner finale.

Per la versione più impegnativa, prepara un decision memo revisionabile con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo la decisione. Aggiungi una sezione su cosa farebbe cambiare idea al team. Come materiale usa eventi prodotto, metriche di activation, prompt di review, rubriche di approvazione e memo finali. Se non hai dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento, una metrica primaria e un campo che rappresenti un possibile errore di qualità.

Gli errori tipici

Il primo errore è usare questo approccio come etichetta invece che come processo, cioè mostrare un output generato senza spiegare dati, controlli e decisione. Il secondo è confondere la produttività del singolo con l’affidabilità dell’organizzazione. Il terzo è non aver deciso in anticipo quali azioni sono permesse, quali richiedono approvazione e quali sono vietate.

La correzione pratica è scrivere tre righe prima di iniziare:

Line	Content
Decision	Which concrete choice do we want to improve
Evidence	Quale dato o controllo può sostenere la scelta
Stop	Which risk would make us stop or ask for review

Se manca una di queste tre righe, il workflow non è pronto. L’AI resta utile come supporto esplorativo, ma non come parte stabile del processo decisionale.

Prima di andare avanti, prova a rispondere a qualche domanda. Quale decisione concreta dovrebbe migliorare questa lezione, quale parte del workflow puoi delegare all’AI e quale deve restare sotto un owner umano, quale baseline useresti per capire se il nuovo processo migliora davvero, quale failure mode potrebbe rendere pericoloso un output apparentemente corretto e quale artefatto consegneresti a uno stakeholder, scegliendo tra memo, dashboard, query review, model card, runbook o checklist. Se le risposte restano generiche, torna al problema reale: spesso è il segnale che hai automatizzato troppo presto.

Essential technical references

I riferimenti sotto orientano scelte tecniche che cambiano nel tempo. Non vanno copiati come ricette, ma usati per verificare concetti, limiti e terminologia prima di progettare workflow reali.

• 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

Operational Summary

Questo approccio diventa utile quando produce una decisione più chiara, non quando aggiunge terminologia. Il ciclo decisione, contesto, supporto AI, verifica e handoff trasforma la lezione in pratica verificabile.

La regola finale è semplice: 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.