“Quanto abbiamo fatturato?”
Sembra una domanda semplice. Il database contiene ordini, fatture, spedizioni, clienti e importi. Un sistema di AI può leggere lo schema, individuare le tabelle, scrivere una query SQL e restituire un numero in pochi secondi.
Ma quale numero?
Durante una demo DataTalk è emerso un caso concreto: per quel cliente, “fatturato” non coincideva con le sole fatture emesse. Per la lettura che serviva in quel momento contava la merce partita. Anche un’espressione apparentemente ovvia come “Centro Italia” richiedeva una regola aziendale specifica.
Il problema, quindi, non era scrivere SQL. Era capire il significato che l’azienda attribuiva alla domanda.
È qui che cambia il modo di valutare l’AI applicata ai dati aziendali. Collegare un modello a un database gli dà accesso a una struttura. Non gli dà automaticamente accesso al contesto con cui quell’organizzazione interpreta quella struttura.
Una query può essere corretta e la risposta comunque sbagliata
Quando si parla di AI sui database, la qualità viene spesso misurata con una domanda tecnica: la query generata è valida?
È un controllo necessario, ma non sufficiente.
Una query può essere sintatticamente corretta, usare colonne esistenti e completare l’esecuzione senza errori. Eppure può scegliere la tabella sbagliata tra due fonti simili, utilizzare un join tecnicamente possibile ma non approvato, applicare una definizione di ricavo diversa da quella usata dal controllo di gestione oppure interpretare “cliente attivo” secondo una logica plausibile ma estranea all’azienda.
In tutti questi casi il database risponde. Il problema è che risponde a una domanda diversa da quella che l’utente pensava di aver fatto.
Per questo, con l’AI, è utile distinguere la correttezza tecnica dalla correttezza semantica. La prima verifica che la query possa funzionare. La seconda verifica che stia rappresentando davvero il concetto di business richiesto.
Il database descrive la struttura. Il business aggiunge il significato
Uno schema SQL può raccontare molto: nomi di tabelle e colonne, tipi di dato, chiavi, relazioni, viste. È una base indispensabile per orientarsi.
Ma molte informazioni decisive non sono contenute in modo esplicito nello schema.
Una colonna chiamata `revenue` non dice necessariamente se il valore include resi, note di credito o ordini non ancora evasi. Una tabella `customers` non garantisce che sia la fonte ufficiale usata dal finance. Un campo geografico non spiega da solo come l’azienda suddivide Nord, Centro e Sud. E una relazione tecnicamente possibile non dice necessariamente che quel join sia quello corretto per il KPI che stiamo calcolando.
Il significato nasce dall’incontro tra struttura tecnica e regole dell’organizzazione.
Ed è precisamente il problema che un semantic layer prova a risolvere.
Che cos’è un semantic layer, in pratica
Un semantic layer è un livello di astrazione che collega i dati tecnici ai concetti con cui il business li usa. Traduce tabelle, colonne e relazioni in entità, metriche, definizioni e regole condivise, in modo che persone, strumenti di Business Intelligence AI e sistemi di AI possano lavorare su una base più coerente.
Il termine non è nuovo. I livelli semantici esistono da anni nella Business Intelligence. La differenza è che l’arrivo degli agenti AI e delle interfacce in linguaggio naturale ne ha reso più evidente il valore: più diventa facile fare domande, più diventa importante stabilire che cosa quelle domande significano.
Google Cloud descrive il semantic layer di Looker come una base condivisa di metriche, dimensioni, definizioni e relazioni capace di fornire all’AI il contesto necessario per interpretare la logica di business, non soltanto i dati grezzi. IBM lo definisce come il livello che traduce strutture tecniche complesse in termini aziendali più significativi.
In concreto, un semantic layer utile all’AI può includere:
– La definizione approvata di metriche come fatturato, margine, cliente attivo o churn
– Quali tabelle e viste sono considerate canoniche e quali sono legacy o di supporto
– Le relazioni da utilizzare tra entità e la granularità corretta delle analisi
– Sinonimi, terminologia aziendale, eccezioni e regole che non si ricavano dai nomi dei campi
– Limiti di accesso e perimetri che influenzano ciò che un utente può chiedere e vedere
Non significa necessariamente creare un nuovo grande progetto dati. Significa rendere esplicita e utilizzabile quella conoscenza che altrimenti rimane sparsa tra dashboard, documentazione, codice e persone.
Perché l’AI rende il problema del contesto più importante, non meno
Con un report tradizionale, molte scelte vengono fatte prima: un analista decide quali fonti utilizzare, come calcolare un indicatore e come presentarlo. La dashboard incorpora quelle decisioni.
Con l’analisi dei dati in linguaggio naturale la sequenza cambia. È l’utente a formulare una domanda nuova, spesso senza conoscere lo schema e senza specificare tutte le regole implicite.
Questo è il grande vantaggio delle interfacce conversazionali: abbassano la barriera tecnica. Ma è anche il motivo per cui non basta affidarsi alla capacità del modello di “capire” la domanda.
Un modello linguistico è molto bravo a riconoscere intenzioni e generare codice plausibile. Non può però conoscere una definizione privata dell’azienda se nessuno gliel’ha fornita. Se “ordine acquisito” per il commerciale e “ricavo riconosciuto” per il finance seguono logiche diverse, il modello non può scegliere la definizione corretta semplicemente guardando il nome delle colonne.
La questione, quindi, non è scegliere tra AI e semantic layer. L’AI rende il semantic layer ancora più importante.
Schema, glossario, knowledge base e semantic layer non sono la stessa cosa
Questi concetti vengono spesso sovrapposti, ma risolvono problemi diversi. Lo schema descrive come il database è organizzato: tabelle, colonne, tipi, chiavi e relazioni tecniche.
Un business glossary chiarisce il significato dei termini: che cosa intendiamo per cliente attivo, fatturato netto, ordine chiuso, lead qualificato. Una knowledge base può raccogliere documentazione, eccezioni, procedure e informazioni utili a spiegare come funziona un dominio aziendale.
Il semantic layer rende operativa una parte di questa conoscenza, collegandola ai dati che devono essere interrogati e alle metriche che devono essere calcolate.
Nella pratica, le architetture possono essere diverse e i confini non sono sempre netti. Il punto non è imporre una terminologia unica. È assicurarsi che la conoscenza necessaria alla risposta non venga lasciata alla capacità del modello di indovinarla.
Il test più semplice: chiedi dove vive oggi la definizione di “fatturato”.
Prima di introdurre qualsiasi AI sui dati, si può fare un esercizio molto semplice. Chiedi a finance, commerciale e operations come viene calcolato un KPI importante. Poi chiedi dove quella definizione è documentata e come viene collegata alle tabelle che la producono.
Se la risposta è “lo sa quella persona”, “è dentro quella query”, “dipende dal report” oppure “abbiamo sempre fatto così”, il problema non è ancora l’AI. Il problema è che una parte importante del significato dei dati non è disponibile in una forma utilizzabile e governabile.
È proprio in questi scenari che collegare direttamente un modello generalista al database rischia di creare una falsa sensazione di autonomia: la domanda diventa facilissima da fare, mentre la logica necessaria per rispondere resta implicita.
Dove si inserisce DataTalk
DataTalk non nasce come una semplice interfaccia che prende una domanda e la trasforma in SQL.
Durante l’onboarding del database, DataTalk esplora e descrive la struttura, costruisce conoscenza utilizzabile dall’agente e usa un semantic layer per collegare schema tecnico, lessico aziendale, definizioni e regole utili all’interpretazione delle domande. La piattaforma dispone inoltre di una knowledge base e di meccanismi per adattarsi al linguaggio dell’organizzazione.
Questo non significa che l’AI possa dedurre da sola qualsiasi regola. Se una definizione è specifica dell’organizzazione, deve essere dichiarata, validata e mantenuta. Il valore del sistema sta nel poter usare quel contesto nel momento in cui la domanda viene interpretata, invece di costringere l’utente a riscriverlo ogni volta nel prompt.
Per i database complessi, la stessa logica è disponibile anche attraverso DataTalk API: il punto non è soltanto generare SQL, ma recuperare il contesto rilevante prima della query.
La domanda giusta non è “l’AI può interrogare il database?”
Oggi la risposta, in molti casi, è sì.
La domanda più utile è un’altra: che cosa sa l’AI del modo in cui la tua azienda interpreta quel database?
Sa quale fonte è autorevole? Sa che cosa intendete per fatturato? Conosce le eccezioni? Distingue una tabella operativa da una tabella legacy? È in grado di usare le stesse definizioni che usano le persone quando prendono una decisione?
Se queste risposte dipendono ancora dalla capacità del modello di intuire il contesto, la qualità dell’AI resta fragile anche quando il codice generato è impeccabile.
Il passaggio decisivo è quindi spostare l’attenzione dalla query alla comprensione.
Perché l’AI sa scrivere SQL. Ma il business non vive nel SQL.
Se vuoi verificare quanto contesto serve per interrogare in modo affidabile i dati della tua azienda, parti da una domanda reale.
Domande frequenti
No. Un Data Warehouse centralizza, storicizza e organizza i dati; un semantic layer aggiunge una rappresentazione orientata al business di metriche, entità, relazioni e regole. Possono lavorare insieme e spesso il semantic layer utilizza dati già organizzati nel DWH.
No. Il semantic layer non sostituisce necessariamente SQL o il motore di query. Serve soprattutto a stabilire quale significato, metrica, relazione o regola deve essere applicata quando i dati vengono interrogati. Un sistema può continuare a generare SQL, ma farlo usando un contesto più affidabile.
Può aiutare a descrivere uno schema, proporre relazioni, documentare tabelle e individuare pattern. Non può però conoscere con certezza una regola interna che non è presente nei dati o nella documentazione. Le definizioni di business specifiche devono essere validate da chi conosce il dominio.