Chiedi all’agente: “Quali utenti si sono attivati questa settimana?”. Lui risponde. Poi scopri che “attivato” vuol dire tre cose diverse in tre tabelle: in una è chi ha completato l’onboarding, in un’altra chi ha creato un progetto, in un’altra ancora chi ha invitato un collega.
Il problema non è la domanda. È il modello dati.
Un agente ha bisogno di entità chiare
Per analizzare bene il dominio, devi sapere prima di tutto cosa contiene: utenti, account, eventi, sessioni, feature, esperimenti, fonti, task, output, decisioni. E ogni entità deve avere relazioni precise. Un evento appartiene a un utente? A un account? A entrambi? Un output a quale task è collegato? Chi ha approvato una certa decisione?
Sembrano domande tecniche, ma sono loro a stabilire cosa l’organizzazione riuscirà davvero a capire.
Modellare per le domande
Un buon modello dati nasce dalle domande operative che il team deve porsi. Vuoi sapere se un agente migliora l’onboarding? Allora devi collegare esposizione, interazione, completamento del setup e ritorno nei giorni successivi. Vuoi capire se alleggerisce il supporto? Devi collegare ticket, bozze, modifiche fatte dalle persone, riaperture e soddisfazione. Per valutare gli insight di marketing servono il collegamento tra proposta, esperimento, risultato e decisione.
Il modello dati deve rispecchiare le decisioni, non solo i sistemi da cui i dati arrivano.
Evitare duplicazioni e ambiguità
ID incoerenti, eventi duplicati, timestamp che non tornano e definizioni che ognuno interpreta a modo suo: bastano questi a rovinare un’analisi. Un agente AI può nascondere il problema dietro risposte fluide, ma la fluidità non è affidabilità.
Serve un glossario dei dati con nome della metrica, definizione, fonte, proprietario, frequenza di aggiornamento e limiti.
Come applicare il data modeling senza complicare il lavoro
Non partire dallo strumento più nuovo. Parti dal punto in cui il team perde tempo, discute senza dati o decide con informazioni incomplete. È lì che si capisce se il tema ha valore operativo o resta una bella idea da slide.
Un agente non è una chat brillante: ha bisogno di input chiari, strumenti limitati, memoria controllata e una regola esplicita che gli dica quando passare la decisione a una persona, cioè quando il rischio cresce.
Una sequenza che funziona:
- Definisci quali dati l’agente può leggere e quali no.
- Scrivi il risultato atteso in forma verificabile, non come intenzione generica.
- Decidi quando serve revisione umana prima di inviare o salvare l’output.
- Misura tempo risparmiato, errori evitati e casi in cui l’agente si ferma.
Cosa misurare per capire se funziona
La domanda non è “abbiamo usato l’AI?” o “abbiamo aggiunto una dashboard?”. La domanda è: quale decisione è diventata più veloce, più chiara o più sicura? Se non cambia nessuna decisione, il progetto rischia di restare decorazione tecnica.
Misura almeno tre livelli: tempo operativo risparmiato, qualità del risultato e fiducia del team nel processo. Il tempo da solo inganna, perché un flusso più rapido ma meno controllabile non è un miglioramento. Anche la qualità da sola inganna, perché un sistema perfetto ma troppo lento non entra mai nel lavoro di tutti i giorni.
Collegamento con il percorso ginnytech
Per trasformare questo ragionamento in competenza pratica, collega questo articolo al percorso Agentic AI Data Workflows. L’obiettivo è costruire un modo di lavorare in cui dati, modelli e persone collaborano senza perdere il controllo.
La riflessione
Il data modeling è soprattutto un atto di realismo. Decide come il prodotto vede se stesso.
Gli agenti AI aiutano a interrogare meglio i dati, ma non possono inventare una coerenza che non c’è.
Prima di chiedere insight intelligenti, costruisci fondamenta leggibili.