Databricks Genie non è l’ennesimo agente che traduce la tua domanda in una query SQL, fa molto di più! È un agente che lavora in sinergia con Unity Catalog, sa a chi può rispondere e a chi no, e soprattutto sa cosa può rispondere.

La differenza non è da poco. Mettere una chat sopra il lakehouse, oggi, lo sanno fare in tanti, ricevi la richiesta, generi la SQL, restituisci la risposta. Il problema arriva un attimo dopo. Quando un agente AI dialoga con i tuoi dati, chi decide cosa può vedere chi lo sta interrogando? La governance che hai costruito a fatica, fatta di row filter, column mask e policy sui dati personali, viene rispettata oppure l’agente l’ha appena bypassata?

Con Genie viene rispettata. E non perché aggiunga un suo strato di sicurezza, ma perché si appoggia interamente a Unity Catalog e ne eredita ogni controllo. Un agente che lavora sul tuo lakehouse rispettando le stesse regole che valgono per chiunque altro.

Cos’è Databricks Genie e come funziona

Genie è l’interfaccia conversazionale di Databricks per interrogare i dati strutturati del lakehouse. Un analista configura un Genie Space, lo collega ai dataset registrati in Unity Catalog e gli fornisce qualche query SQL di esempio insieme alle istruzioni che spiegano la semantica di business. Da quel momento l’utente fa le sue domande e si vede tornare indietro la query SQL generata, una tabella con i risultati e una visualizzazione. Sotto il cofano non c’è un solo modello che prova a indovinare la query. Genie legge i metadata di Unity Catalog, recupera gli esempi più pertinenti, tiene conto della conversazione fino a quel punto e, quando il contesto non basta, chiede un chiarimento invece di inventare.

Ci sono due vincoli da tenere a mente. Le query che genera sono sempre in sola lettura, quindi Genie non scrive, non aggiorna e non cancella nulla. E lavora soltanto su dati strutturati, perché per i documenti e i file non strutturati esiste una funzione separata. In sostanza è il volto conversazionale delle tue tabelle, niente di più.

Da Databricks One a Genie: cosa è cambiato

Per orientarsi servono due parole tenute distinte. Un Genie Space è il mattoncino: una singola chat curata da un analista e agganciata a un set preciso di tabelle, con le sue query di esempio e le sue istruzioni di business. Genie, senza “Space”, è invece l’esperienza che risiede ad al livello superiore: il posto unico dove un business user fa domande in linguaggio naturale, apre le dashboard AI/BI e lancia le Databricks Apps.

Quell’esperienza, fino a poco fa, si chiamava Databricks One. Databricks l’aveva annunciata a giugno 2025 come interfaccia unica per chi deve solo consultare i dati, senza abilitarlo all’ambiente tecnico e con la sicurezza affidata come sempre a Unity Catalog.

Ad aprile 2026 Databricks One è stato rinominato Genie. Non è un semplice cambio di nome, perché nel frattempo l’esperienza è cresciuta. Da un’unica chat, Genie attinge agli asset più rilevanti e certificati dell’organizzazione, più Genie Space, dashboard governate e Databricks Apps, così una singola domanda può combinare dati che prima vivevano in spazi separati, senza che l’utente debba sapere in quale cercare. Si collega anche a fonti di conoscenza esterne come Google Docs e SharePoint, con le connessioni gestite dall’Unity Catalog AI Gateway, e ha le app mobile native per iOS e Android. Se cerchi “Databricks One” nella documentazione, oggi ti ritrovi rimandato a Genie.

Un’ultima precisazione per non fare confusione, Genie, il volto per i business user, è una cosa diversa da Genie Code, l’assistente per chi scrive codice. Stessa famiglia, due strumenti distinti.

La governance va sul dato, non sull’interfaccia

Con una chat che genera SQL al posto tuo cambia una cosa fondamentale, la query non la scrivi più tu, la scrive il modello. Non puoi quindi filtrare cosa viene chiesto nel momento in cui la query nasce. E allora, se a fare la domanda è qualcuno che non dovrebbe vedere gli stipendi del team HR, quella richiesta va fermata da qualche parte. Tutto il punto sta nel capire dove.

La tentazione è metterci una pezza sulla chat, blocklist di parole, guardrail che intercettano le domande “sensibili”. È la strada sbagliata, per due motivi. Non scala, perché le domande possibili sono infinite e non le puoi prevedere tutte. E si aggira in pochi minuti, basta riformulare la frase in un altro modo. Il controllo va messo un livello più in basso, sul dato, se le regole vivono sulle tabelle, ogni interfaccia che le interroga le eredita in automatico, chat compresa.

Flusso di una domanda in linguaggio naturale governata da Unity Catalog

La domanda diventa un prompt, Genie genera una SQL read-only, e prima che qualunque riga torni indietro la query passa per Unity Catalog. Lì i permessi vengono applicati. Conta l’ordine, i filtri scattano prima che il result set arrivi al modello che compone la risposta in linguaggio naturale. Quello che l’LLM legge per scrivere la sua frase è già dato filtrato e mascherato, mai il dato in chiaro.

Come Unity Catalog protegge le risposte di Genie

Qui c’è una distinzione che vale la pena chiarire, perché è il cuore di tutto. Genie lavora con due identità diverse. Il compute è quello dell’autore dello spazio, è il suo SQL warehouse a far girare la query, e i consumer non devono gestirsi un cluster. L’autorizzazione sui dati, invece, resta quella di chi fa la domanda. Ogni utente deve avere almeno il privilegio SELECT sulle tabelle collegate allo spazio, e su quei dati Unity Catalog applica i permessi che competono a lui, non all’autore. È esattamente per questo che la demo qui sotto funziona: il row filter si valuta sul gruppo del consumer, non su quello di chi ha creato lo spazio.

Se qualcuno interroga dati a cui non ha accesso, la risposta che ottiene è vuota. Una nota di trasparenza, per l’utente finale un risultato vuoto per mancanza di permessi è indistinguibile da un «non ci sono dati», e l’LLM ci può costruire sopra una frase rassicurante ma fuorviante. È un limite da conoscere.

I row filter restringono quali righe escono dalla query, a tempo di esecuzione e riga per riga. Se un sales manager della Sicilia chiede il fatturato per regione, le righe della Lombardia non compaiono. Non vengono nascoste a video, semplicemente non escono dal lakehouse.

La stessa domanda, due risposte diverse.

Risposta Genie per utente grp_sales_sicilia: solo Sicilia nel result set
Utente grp_sales_sicilia: la risposta contiene solo la Sicilia
Risposta Genie per utente grp_sales_full: tutte le regioni nel result set
Utente grp_sales_full: la risposta mostra tutte le regioni

A sinistra l’utente fa parte di grp_sales_sicilia, Unity Catalog applica il row filter e la chat restituisce solo la Sicilia. A destra lo stesso utente, spostato in grp_sales_full, ripete identica la domanda e questa volta vede tutte le regioni. Genie non ha cambiato logica. È stato Unity Catalog a decidere cosa usciva, prima ancora che Genie componesse la risposta.

I column mask funzionano in modo analogo, ma sul valore di una singola colonna, e lo offuscano per chi non ha il privilegio giusto. Genie genera la query corretta, però il dato torna già mascherato.

Quando chiedo «mostrami la lista dei miei clienti con il loro contatto email», la colonna email mi torna nella forma usr***@sc.it. Il dato personale non è mai uscito dal lakehouse in chiaro.

Lista clienti con email mascherata nella risposta di Genie

E se chiedo «qual è il codice fiscale del cliente CLI-001?», il campo mi torna come FRR*************. La maschera vale a prescindere da come formulo la domanda diretta sulla colonna.

Risposta di Genie con codice fiscale mascherato

Un’avvertenza onesta, la maschera protegge il valore della colonna, non l’informazione che se ne può inferire. Un column mask su stipendio nasconde il singolo importo, ma non impedisce di chiedere a Genie un AVG(stipendio) per reparto se l’utente ha accesso alla tabella: l’aggregato passa, e su un reparto piccolo l’inferenza è quasi una lettura diretta. Contro questo servono contromisure diverse, non esporre quelle colonne nel Genie Space, oppure governare anche le aggregazioni. Row filter, column mask e le policy sono le fondazioni, non l’intero edificio.

Il punto che conta davvero è questo. Questi controlli non si configurano “per Genie”, si configurano sulle tabelle. Lo stesso row filter che protegge una query SQL scritta a mano in un notebook protegge anche la domanda in linguaggio naturale del direttore commerciale. La governance la definisci una volta sola e vale dappertutto.

Se vuoi vedere come si scrivono queste policy nel dettaglio, con i tag a livello di account e le UDF centralizzate, ne ho parlato in un articolo a parte sulla governance dati con le ABAC Policy di Unity Catalog .

Conclusioni: prima la governance, poi la chat

Genie stupisce, e con l’unificazione di Databricks One adesso è più chiaro. La parte da non dare per scontata resta sempre la stessa, la Governance. Aprire la chat agli utenti senza aver prima costruito Policy di Sicurezza su Unity Catalog è un rischio, perché Genie non aggiunge sicurezza, la eredita. E se sotto non c’è niente, non c’è proprio niente da ereditare.

Un’ultima precisazione, Unity Catalog ti mette al sicuro sul «chi accede a quale dato», non ti esonera dal ragionare su come quel dato può essere ricomposto.

Quindi l’ordine è uno solo. Prima i controlli su Unity Catalog, poi la chat. Mai il contrario.

Risorse

Nota sui dati di esempio: i dati utilizzati negli esempi di codice (nomi, indirizzi, numeri di telefono, codici fiscali e identificativi cliente) sono dati sintetici generati a puro scopo dimostrativo. Qualsiasi somiglianza con persone reali è puramente casuale. Non rappresentano dati reali di clienti o aziende.