Agentic SQL and semantic layer with 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.

Real-world problem

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.

Conceptual model

Il modello poggia su quattro livelli.

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

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.

Rigorous formalization

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.

Element	Requested specification
Unit of analysis	proposed query, metric, semantic model, test, approval or change request
Primary signal	correct grain, passed tests, query cost, reused definitions, and approved changes
Baseline	Manual process, previous period, comparable group or current model
Decision	decidere se una query agentica può diventare modello riusabile o resta esplorazione
Guardrail	Privacy, costo, qualità dati, interpretabilità, ownership e rischio operativo
Main risk	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.

Operating Framework

Il workflow procede in cinque passaggi.

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 va trattato come evidenza finché non è legato a fonte, controllo e decisione.

Example or case study

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.

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 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à.

Typical mistake to avoid

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.

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 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.

Essential technical references

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

Operational Summary

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.