Agentic SQL e semantic layer con approval

Quando l’analisi dati si intreccia con decisioni complesse, la sfida è integrare un agente senza perdere controllo e tracciabilità del lavoro. Non si tratta di lasciare all’AI il compito di “fare analisi” in autonomia, ma di costruire un flusso in cui domanda, dati, controlli e decisioni restano chiari e verificabili. Questa lezione riprende il tema del lavoro tra AI e persone affrontato in precedenza e aggiunge un livello operativo più specifico, centrato sul semantic layer. L’obiettivo resta concreto: aumentare velocità e copertura del lavoro sui dati senza cedere la responsabilità su definizioni, soglie, segmenti e raccomandazioni.

Problema reale

Una riunione settimanale mette intorno allo stesso tavolo marketing, prodotto e data team. Devono decidere cosa correggere prima: funnel, tracking, campagna, modello o pipeline. Senza un approccio agentico l’analista perde ore in passaggi ripetitivi; con un uso superficiale dell’AI consegna spiegazioni convincenti ma fragili.

Il nodo operativo è decidere se una query agentica può diventare un modello riusabile o deve restare esplorazione. Non è teoria isolata: serve a migliorare una scelta concreta con dati, assunzioni dichiarate e controlli minimi. Quando un team vuole accelerare il lavoro sui dati, deve distinguere i compiti delegabili all’AI dalle responsabilità che restano umane, soprattutto quando in gioco ci sono budget, roadmap, clienti o compliance.

Modello concettuale

Il modello poggia su quattro livelli.

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

I quattro livelli evitano due errori opposti: usare l’AI come semplice autocomplete testuale oppure affidarle decisioni che richiedono giudizio di business. La competenza professionale sta nel disegnare con chiarezza quel confine.

Formalizzazione rigorosa

Per rendere il processo analizzabile conviene definire l’unità di lavoro: una query proposta, una metrica, un semantic model, un test, un approval o una change request. A quell’unità si collegano segnali osservabili come grain corretto, test passati, costo della query, definizioni riusate e modifiche approvate. La decisione attesa è se la query agentica può diventare modello riusabile o resta esplorazione.

Elemento	Specifica richiesta
Unità di analisi	query proposta, metrica, semantic model, test, approval o change request
Segnale principale	grain corretto, test passati, costo query, definizioni riusate e modifiche approvate
Baseline	Processo manuale, periodo precedente, gruppo comparabile o modello attuale
Decisione	decidere se una query agentica può diventare modello riusabile o resta esplorazione
Guardrail	Privacy, costo, qualità dati, interpretabilità, ownership e rischio operativo
Rischio principale	permettere all’agente di inventare definizioni metriche fuori dal semantic layer

La formalizzazione regge quando un reviewer riproduce la logica, critica le assunzioni e ottiene la stessa decisione partendo dagli stessi dati. Se il risultato dipende da conversazioni mai tracciate, il workflow non è maturo.

Framework operativo

Il workflow procede in cinque passaggi.

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 può essere accelerata?	Prompt, tool o checklist
Verifica	Quale errore potrebbe cambiare la conclusione?	Controllo, guardrail, baseline
Handoff	Chi decide e con quale criterio?	Memo, ticket, modello o dashboard

Lo schema vale per analisi esplorativa, SQL, data engineering, AutoML e workflow agentici. Cambiano gli strumenti, non il principio: nessun output va trattato come evidenza finché non è legato a fonte, controllo e decisione.

Esempio o caso studio

Un agente propone una metrica di revenue netta. Il semantic owner blocca la pull request perché mancano il timing dei refund e la valuta. Dopo la correzione, la metrica diventa riusabile.

Il caso mostra che al centro non c’è l’AI ma il ciclo decisionale: domanda, dato, controllo, raccomandazione, monitoraggio. L’agente riduce l’attrito tra questi passaggi, e ogni passaggio resta controllabile.

Evidenza osservata	Lettura prudente	Azione consigliata
Il workflow produce output più rapidamente	La velocità è utile solo se non abbassa qualità e controllo	Confrontare con baseline manuale e review indipendente
Il modello propone spiegazioni plausibili	La plausibilità linguistica non è prova empirica	Tradurre ogni spiegazione in controllo su dati o processo
Il risultato migliora una metrica	Potrebbe esserci effetto composizione, leakage o stagionalità	Segmentare, verificare guardrail e monitorare nel tempo

Un caso studio fatto bene non si chiude con “l’AI ha funzionato” ma con una decisione difendibile: cosa automatizzare, cosa tenere manuale, quale metrica monitorare e quale condizione fermerebbe il processo.

Esercizio guidato

Comincia da una scheda sintetica su agentic SQL e semantic layer con approval: decisione da supportare, input richiesti, output atteso, controllo minimo e rischio principale. Usa un caso semplice come una variazione di conversione, una pipeline in ritardo o un modello forecast da valutare.

Quando la scheda regge, costruisci una tabella con tre scenari, cioè workflow manuale, workflow assistito dall’AI e workflow con automazione più spinta, annotando per ciascuno tempo stimato, qualità attesa, rischio operativo, controllo necessario e owner finale. Poi prepara un decision memo revisionabile che includa ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo la decisione, con una sezione su cosa farebbe cambiare idea al team.

Per i materiali, appoggiati a semantic layer, dbt docs, query log, glossary delle metriche, test di modello e review checklist. Se non hai dati reali, costruisci un dataset sintetico di almeno 200 righe con una dimensione temporale, una dimensione segmento, una metrica primaria e un campo che rappresenti un possibile errore di qualità.

Errore tipico da evitare

Il primo errore è usare agentic SQL e semantic layer con approval come etichetta invece che come processo. Capita quando si mostra 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 approval e quali restano vietate.

La correzione pratica è scrivere tre righe prima di iniziare.

Riga	Contenuto
Decisione	Quale scelta concreta vogliamo migliorare
Evidenza	Quale dato o controllo può sostenere la scelta
Stop	Quale rischio ci farebbe fermare o chiedere review

Se ne manca una, il workflow non è pronto. L’agente può servire come supporto esplorativo, non come parte stabile del processo decisionale.

Domande di verifica

Prima di proseguire, rispondi in modo specifico a cinque domande. Quale decisione concreta dovrebbe migliorare questa lezione. Quale parte del workflow puoi delegare all’AI e quale deve restare sotto owner umano. Quale baseline useresti per capire se il nuovo processo migliora davvero. Quale failure mode renderebbe pericoloso un output apparentemente corretto. 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 prima di andare avanti. Una risposta vaga di solito significa che hai automatizzato troppo presto.

Riferimenti tecnici essenziali

Questi riferimenti aiutano a orientare scelte tecniche destinate a cambiare nel tempo. Non sono ricette da copiare ma strumenti 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

Riepilogo operativo

Agentic SQL e semantic layer con approval diventa utile solo quando produce una decisione chiara e verificabile, non quando aggiunge terminologia. Il ciclo decisione, contesto, supporto AI, verifica e handoff trasforma la lezione in pratica applicabile.

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, ma solo velocità non governata.