Al Data + AI Summit 2026, andato in scena a San Francisco dal 15 al 18 giugno, Databricks ha annunciato una quantità di novità che meriterebbero più di un articolo: Unity AI Gateway, Lakebase, Iceberg v3, Lakehouse//RT. Ne parleremo in articoli separati. Qui mi concentro su una cosa sola, quella che secondo me conta di più per chi lavora con gli Agenti per l’analytics.
Cosa è successo a Genie?
La risposta breve è che Genie è diventata una famiglia: Genie One, Genie Agents, Genie Code, Genie ZeroOps, Genie App Builder. Cinque nomi con lo stesso prefisso, il tipo di elenco che fa subito pensare al rebranding… Ma dietro quei cinque c’è un sesto annuncio, meno appariscente e più importante degli altri, secondo me. Si chiama Genie Ontology, ed è lì che si gioca la partita.
Il collo di bottiglia è il contesto, non il modello
C’è una convinzione diffusa secondo cui la qualità di un assistente AI dipenda soprattutto dal modello, più grande vuol dire risposte migliori. Su dati aziendali, in pratica, non è così semplice. Il modello sa scrivere SQL corretto. Quello che non sa, di suo, è cosa significhi arr_netto nella tua azienda, se “cliente attivo” vuol dire uno che ha comprato negli ultimi 30 giorni o negli ultimi 12 mesi, quale delle tre tabelle chiamate orders sia quella buona.
Questo è contesto di business, e non vive nel modello. Vive sparso tra tabelle, dashboard, query salvate, thread Slack, canali Teams, un glossario scritto su Azure Boards tre anni fa. Un agente senza accesso a quel contesto indovina, e quando indovina su una definizione di metrica il risultato è peggio di un errore evidente… è una risposta plausibile e sbagliata, che spesso nessuno mette in discussione perché “l’ha detto l’AI”.
Genie Ontology è la risposta di Databricks a questo problema, non un modello più potente sopra i dati ma un layer di significato condiviso su cui gli agenti si appoggiano.
Cos’è Genie Ontology
Databricks la descrive come un knowledge graph automatico. Estrae il significato di business da tabelle, query, pipeline, dashboard e oltre 50 applicazioni connesse (Slack, Jira, Salesforce, SharePoint, ecc…), e lo tiene aggiornato mentre i dati cambiano. Quando un agente deve rispondere, Ontology gli inietta nel loop il contesto rilevante, già filtrato per i permessi di chi fa la domanda.

La parte tecnica interessante è OntoRank, l’algoritmo che sceglie quale definizione usare quando ce ne sono più di una in competizione. Al summit è stato paragonato a PageRank, come quello ordinava le pagine web per autorevolezza, OntoRank ordina le definizioni di business, pesando cinque fattori (origine, autorevolezza della fonte, frequenza d’uso, connessione ad asset certificati, recency) più il grafo organizzativo di chi accede a cosa. Una definizione usata ogni giorno dal team finance pesa più di una scritta una volta e mai più toccata.

Il diagramma riassume lo scenario. Da una parte Unity Catalog, con un Business knowledge definito manualmente (Glossary, Domains, Metrics) e la governance vera e propria (permessi, row filter, column mask); dall’altra le sorgenti di contesto grezzo, tabelle e app connesse. In mezzo Ontology, che raccoglie da entrambe, applica i permessi e alimenta i cinque agenti della famiglia.
I numeri mostrati sul palco
Al keynote Databricks ha portato anche dei numeri. Sul benchmark interno “28-question real-world data-analysis suite” (giugno 2026), Genie risponde correttamente al primo tentativo nell'84,5% dei casi, contro il 52,4% del miglior agente di coding generalista messo a confronto e il 25% del più debole. Sulla latenza, Genie è dichiarato due volte più veloce del concorrente più forte.

Sono numeri interessanti, e coerenti con la tesi di questo articolo. Se il contesto pesa quanto ho argomentato, un salto del genere, non un +5% marginale, è quello che ci si aspetterebbe di vedere. Vanno però presi come una buona base di partenza più che come un verdetto, perché il benchmark è interno, i competitor sono anonimizzati e non conosciamo le 28 domande né quanto rappresentino il caos di un catalog aziendale vero. Mi piacerebbe verificarli in prima persona, testarlo con qualche metrica volutamente ambigua.
Contesto vs Governance
Ho già raccontato come Unity Catalog protegge le risposte di Genie. Le query in linguaggio naturale ereditano row filter e column mask perché la sicurezza vive sul dato, non sull’interfaccia (ne parlo nel pezzo sulla governance di Databricks Genie , che qui do per presupposto).
Governance e contesto rispondono però a due domande diverse. Unity Catalog risponde a “chi può leggere cosa”; sapere che un utente può leggere la colonna revenue non dice all’agente cosa revenue significhi, se è al lordo o al netto, in quale valuta. Ontology prova a colmare questo spazio, e il modo in cui Databricks la posiziona è significativo: si appoggia agli asset di “Enterprise Semantics” di Unity Catalog (Glossary, Domains, Metrics) e ne eredita i permessi, come se il significato di business fosse materia di governance quanto gli accessi.
C’è però una differenza tra Ontology e le fonti curate a cui attinge. Glossary, Domains e Metrics li cura qualcuno, un owner di dominio risponde di quella definizione. Ontology impara da sola, in background, dai dati e dalle app connesse. È un pregio, perché nessuno potrebbe compilare a mano un knowledge graph aziendale su larga scala, ma è anche un dubbio legittimo da verificare nel tempo… OntoRank ordina le definizioni per autorevolezza, e l’autorevolezza non coincide sempre con la correttezza. Una metrica popolare, agganciata a una dashboard certificata, potrebbe essere premiata anche se il calcolo sottostante è sbagliato (per esempio somme di conteggi distinti giornalieri che gonfiano gli utenti attivi). Non è detto che succeda spesso, ma è un caso limite che vale la pena osservare quando Ontology girerà su cataloghi reali. È lo stesso tipo di questione che avevo notato nell’articolo di giugno a proposito dell’inferenza sui dati (una column mask non impedisce un AVG per reparto), solo spostata di un livello, dal dato al significato del dato.
La famiglia Genie è più forte con Ontology
Negli ultimi mesi Databricks ha cambiato più volte forma a Genie, dai Genie Spaces (chat NL2SQL su dataset curati) al rename di Databricks One in Genie (ne ho scritto a giugno), fino alla famiglia attuale di cinque agenti. Visto come sequenza di rebranding potrebbe sembrare indecisione; visto attraverso Ontology sembra piuttosto la ricerca di un collante che prima mancava.
Senza Ontology, quei cinque agenti sarebbero prodotti separati con lo stesso prefisso di marketing. Con Ontology, condividono lo stesso layer di contesto, anche se non tutti ne dipendono allo stesso modo. Genie ZeroOps, che monitora pipeline e propone fix, ha bisogno di sapere non solo cosa si è rotto ma perché conta, cioè chi usa quella pipeline a valle; Genie Agents ha bisogno che “fatturato” significhi la stessa cosa per chi crea un agente e per chi lo eredita, altrimenti la riusabilità promessa si affievolisce. Genie One, Genie Code e Genie App Builder ne beneficiano, ma dipendono meno strutturalmente dal layer.
Cosa è davvero pronto
General availability vera ce l’hanno Genie One, Genie Agents e Genie Code. Genie ZeroOps e Genie App Builder sono in private preview, quindi per la maggior parte delle aziende restano demo per ora. Sul fronte Enterprise Semantics, Metrics è GA (materializzazione in public preview, import da terze parti in beta), Domains in public preview, Glossary “preview imminente”, Governance Hub in private preview. Genie Ontology stessa, all’annuncio, era in preview.
Il giudizio positivo che do in questo articolo riguarda quindi la direzione architetturale, non un risultato già dimostrato su larga scala. Databricks ha inquadrato bene il problema e proposto un’architettura coerente per affrontarlo. Che OntoRank regga su un catalog reale, con migliaia di tabelle e definizioni contraddittorie, è qualcosa che il summit da solo non può dimostrare.
Il banco di prova vero arriva dopo
Il problema che Genie Ontology prova a risolvere è quello giusto. Negli Agenti per il tuo lakehouse aziendale vince chi controlla il contesto, non chi ha il modello più grande. L’idea di trattare il significato di business come materia di governance, accanto ai permessi, mi convince. Resta aperta una domanda che solo l’uso reale potrà chiudere, chi si prende la responsabilità di ciò che un layer auto-appreso impara come vero, e quanto bene OntoRank distingue l’autorevolezza dalla correttezza su un catalog vero, con reparti che si contraddicono. Ne riparleremo, in futuro.
Risorse
- What’s new in Unity Catalog at Data + AI Summit 2026 (Databricks Blog)
- Introducing Genie One, Genie Ontology and Genie Agents (Databricks Blog)
- What’s new in Genie Code at Data + AI Summit 2026 (Databricks Blog)
- Articolo correlato sul blog: Databricks Genie: dialogare con i dati del lakehouse senza perdere la governance