Agenti IA nativi dei dati: perché gli agenti devono spostarsi verso i tuoi dati

La maggior parte dei progetti pilota di AI aziendali supera lo stesso ostacolo minimo: collegare un LLM ai dati, inserire un database vettoriale e presentare una demo alla dirigenza. La parte difficile arriva dopo. Il team della sicurezza segnala le falle nella governance. La latenza negli agenti multi-step rovina l'esperienza utente. La fattura del fornitore del modello continua a salire. Questi problemi di solito risalgono a un'unica decisione: estrarre i dati dai sistemi controllati per inserirli in uno stack di AI che non è mai stato progettato per applicare le policy aziendali.

Questo post propone una direzione architetturale diversa: spostare i modelli e gli agenti verso i dati, e non viceversa. Invece di creare un'infrastruttura di AI parallela per poi collegarla al lakehouse, gli agenti vengono trattati come workload nativi che vengono eseguiti all'interno della piattaforma dati, sotto gli stessi controlli di governance, sicurezza e osservabilità di cui già ci si fida per i dati.

Il lakehouse ha fornito un unico punto per governare i dati. La domanda successiva è se gli agenti debbano risiedere all'interno o all'esterno di questo perimetro. Stanno emergendo due paradigmi.

Agenti esterni

Gli agenti e gli LLM vengono eseguiti in uno stack di AI separato. I dati vengono esportati o interrogati tramite rete in database vettoriali esterni, LLM SaaS o layer di serving personalizzati. La governance, la sicurezza e l'osservabilità vengono reimplementate separatamente per l'AI.

Agenti data-native

Agenti, modelli, strumenti, retrieval e memoria degli agenti vengono eseguiti all'interno della stessa piattaforma in cui risiedono i dati, sotto un layer unificato di governance e sicurezza. L'AI diventa un altro workload sul tuo stack di dati esistente.

Il costo nascosto degli agenti esterni

I dati hanno gravità. Spostare il compute è economico; spostare i dati no, specialmente quando i volumi crescono e le modalità si moltiplicano. Estrarli introduce una serie di svantaggi ben noti:

• La governance si indebolisce. Reimplementare il controllo degli accessi, la lineage e la residenza dei dati in ogni integrazione lascia lacune che i controlli di audit finiscono per rilevare.
• La latenza si accumula. Ogni passaggio verso un vector store esterno, un LLM e viceversa si somma negli agenti multi-tool.
• I costi si frammentano. I costi di egress, la duplicazione dello storage e le tariffe per token dei vari vendor colpiscono il budget da tre direzioni diverse.
• La gestione del ciclo di vita si trasforma in un lavoro di coordinamento tra vendor. Schemi, indici e modelli subiscono un drift tra sistemi che non condividono una pipeline di deployment.
• L'osservabilità si frammenta. Tracciare una singola richiesta end-to-end significa dover unire i log di tre o quattro strumenti diversi.
• Il contesto aziendale viene tralasciato. Le definizioni delle metriche, il glossario aziendale e i raggruppamenti di dominio risiedono nel layer di governance; un agente esterno deve ricostruirli a partire dai nomi delle colonne, o semplicemente indovinarli.

Perché la governance post-hoc non funziona per gli agenti

Tra tutti questi svantaggi, la governance merita un'attenzione particolare perché è l'unico aspetto che non può essere corretto a posteriori. La maggior parte degli approcci alla governance dell'AI la tratta come un filtro applicato dopo che l'agente ha già effettuato l'accesso ai dati, ad esempio oscurando i campi sensibili nella risposta, bloccando determinati argomenti a livello di output e controllando i log a posteriori. Questo funziona per semplici demo di domande e risposte (Q&A), ma fallisce nel momento in cui gli agenti iniziano a elaborare i dati.

Consideriamo un agente che calcola un riepilogo finanziario su righe soggette a sicurezza a livello di riga (row-level security). L'aggregazione stessa (la somma, la media, il trend) è un valore derivato che dipende da quali righe vengono incluse. Se la governance non viene applicata prima dell'esecuzione della query, il risultato conterrà già informazioni derivanti da dati a cui l'utente non avrebbe dovuto avere accesso. Nessun intervento di oscuramento a valle può annullare quel calcolo. La decisione sulla policy doveva avvenire al momento della pianificazione della query, non durante il rendering della risposta.

Questo è il limite fondamentale della governance basata sul perimetro o post-hoc: presuppone che i dati possano essere censurati in modo sicuro dopo aver raggiunto l'agente. In pratica, una volta avvenuta un'aggregazione o una trasformazione, l'intento della governance è già andato perduto. I controlli retroattivi sono intrinsecamente incompleti.

C'è un secondo costo legato a questo errore, e si vede direttamente in fattura. Il problema non è solo ciò che l'agente è autorizzato a toccare, anche se questo fa parte del problema. Quando la governance viene gestita a posteriori invece che alla fonte, l'agente finisce per doversi occupare autonomamente della riconciliazione: analizzare i log di audit, unire frammenti provenienti da sistemi esterni, recuperare lo stesso record da più posizioni per capire se può utilizzarlo e ripetere il ragionamento su ogni risultato parziale. Niente di tutto questo fa parte del suo vero compito. È l'agente che compensa la mancanza di una risposta già verificata a monte. Gli output bloccati o oscurati non fanno altro che alimentare questa spirale, poiché l'agente li interpreta come errori e riprova. Le sessioni si allungano, ogni passaggio carica più contesto nel modello e una singola richiesta si trasforma silenziosamente in migliaia di token fatturati. Questo è il loop di consumo dei token, e la governance post-hoc è ciò che lo innesca.

Gli agenti data-native affrontano queste sfide integrando l'applicazione delle policy direttamente nella pianificazione della query e nel calcolo. Ogni risultato intermedio riflette gli stessi vincoli di governance. La governance deve essere valutata prima e durante l'esecuzione, un aspetto che non ci si può permettere di applicare come ripensamento una volta completato il calcolo. I Custom Guardrails in Unity AI Gateway sono la forma concreta di questo approccio: policy componibili e deterministiche che il gateway applica a ogni richiesta e risposta, non filtri che si chiede al modello di rispettare a posteriori. Definire la policy al momento della pianificazione, su dati che risiedono già in un unico ambiente controllato, significa anche che l'agente ottiene una risposta pulita in un unico passaggio, invece di dover esplorare diversi sistemi per assemblarne o giustificarne una.

Lo stato e la memoria degli agenti hanno bisogno di governance

Finora ci siamo concentrati su come gli agenti leggono i dati. Ma gli agenti in produzione scrivono anche: cronologia delle conversazioni, avanzamento delle attività, preferenze dell'utente, risultati memorizzati nella cache e output degli strumenti per audit futuri. Man mano che gli agenti assumono più compiti, il layer di stato diventa importante tanto quanto il layer di dati. Lasciarlo fuori dal perimetro di governance significa compromettere qualsiasi promessa di verificabilità end-to-end.

Lo stato è l'area di lavoro a breve termine dell'agente: la conversazione in corso, l'attività in esecuzione, la cache appena riempita. La memoria è ciò che sopravvive alla sessione: con quali clienti l'agente ha interagito, cosa preferisce un utente, quali output passati vale la pena riutilizzare. Entrambi richiedono uno storage transazionale ed entrambi espongono a falle di governance nel momento in cui lasciano la piattaforma. Un'informazione in memoria come "l'utente X è un cliente UE ad alto valore" è essa stessa un dato sensibile, soggetto alle stesse regole di accesso e residenza del record che riassume. Ed è un workload transazionale: le tabelle Delta sono progettate per grandi scansioni analitiche, ma lo stato dell'agente richiede letture e scritture rapide per riga, ricerche per chiave e aggiornamenti atomici.

La soluzione temporanea abituale è un database Postgres o Redis esterno. Ma questo riporta al problema descritto in questo post: lo stato dell'agente esce dal perimetro controllato per entrare in un sistema invisibile al layer di governance, con la propria sicurezza e il proprio ciclo di vita da gestire. In questo modo si finisce per creare un agente data-native con una dipendenza non controllata.

E il problema si complica nel momento in cui un singolo agente diventa un gruppo di agenti. Uno sciame che lavora per un obiettivo comune (un pianificatore che delega a specialisti, un supervisore che riconcilia i loro risultati) ha bisogno di una memoria condivisa, ed è proprio nel mantenere l'allineamento su di essa che questi sistemi falliscono. Quando ogni agente mantiene uno stato privato e trasmette il contesto peer-to-peer, non esiste un'unica fonte di verità. Gli agenti divergono, si verificano collisioni di scrittura e ogni passaggio di consegne diventa un altro canale non controllato che si moltiplica con la crescita dello sciame. Lo scambio di memoria si rivela essere la parte più difficile.

Lakebase colma queste lacune. Si tratta di uno storage PostgreSQL completamente gestito all'interno della piattaforma Databricks, sotto lo stesso piano di governance di tutto il resto. Lo stato dell'agente diventa un asset controllato: eredita i controlli di accesso della piattaforma, risiede accanto ai dati e agli strumenti dell'agente e non richiede un team di infrastruttura dedicato. E poiché ogni agente legge e scrive su quello stesso layer transazionale, questo funge anche da unica fonte di verità dello sciame. Lo stato rimane coerente, gli aggiornamenti atomici impediscono a due agenti di corrompere la stessa attività, una policy sulla vista di un agente si applica a tutto ciò che scrive per il successivo e qualsiasi memoria può essere tracciata a ritroso attraverso lo sciame: quale agente l'ha scritta, quale l'ha letta e come una conclusione complessa ha raggiunto la sua origine.

I vantaggi degli agenti data-native

La questione della governance è la più evidente, ma i vantaggi vanno ben oltre. Quando gli agenti vengono eseguiti all'interno dello stack di dati, i benefici si sommano in ogni dimensione operativa: sicurezza, qualità, osservabilità, deployment, latenza e costi. Gli strumenti e le dipendenze dei dati vengono configurati e registrati nei log insieme al modello, in modo che l'intero sistema sia sottoposto a controllo di versione, verificabile e riproducibile per impostazione predefinita.

Il seguente confronto riassume le differenze tra questi due paradigmi rispetto alle dimensioni più importanti per i sistemi in produzione:

Come si presentano effettivamente gli agenti data-native su Databricks

La Data Intelligence Platform mette in pratica tutto questo. Invece di creare uno "stack IA" separato e collegarlo ai tuoi dati, crei agenti IA direttamente all'interno dello stack di dati. Un agente data-native su Databricks è un agente che:

• Instrada tutto il traffico di modelli e agenti attraverso Unity AI Gateway, dove ogni richiesta viene controllata prima dell'esecuzione e ogni risposta viene ispezionata successivamente, con criteri deterministici di CONSENTI / NEGA / CHIEDI (ALLOW / DENY / ASK) che sostituiscono il filtraggio best-effort a posteriori. Il controllo degli accessi, la limitazione della frequenza (rate limiting), la registrazione dei payload e il monitoraggio dei costi risiedono tutti nello stesso piano di controllo, incluse le chiamate a provider LLM esterni e agenti di codifica.
• Tratta ogni primitiva IA (modelli, agenti, MCP, competenze e gli strumenti che chiamano) come un asset di Unity Catalog insieme a tabelle e funzioni, in modo che l'identità, la lineage e i controlli di accesso si applichino in modo uniforme su tutta la superficie dell'IA.
• Acquisisce tracce complete delle richieste tramite MLflow 3: ogni chiamata LLM, invocazione di strumenti, punteggi, valutazioni, documenti recuperati e ciclo di monitoraggio end-to-end diventano verificabili per la conformità e osservabili per il debug.
• Esegue l'inferenza all'interno del perimetro di sicurezza di Databricks su Model Serving, senza spostamenti di dati non governati verso stack IA di terze parti.
• Recupera il contesto da indici basati su Delta che rispettano le ACL di Unity Catalog e tracciano automaticamente la lineage, con la tecnologia di AI Search.
• Mantiene la memoria tra le sessioni tramite stato e memoria basati su Lakebase: il contesto della conversazione a breve termine, l'avanzamento delle attività in più passaggi, le preferenze dell'utente a lungo termine e il richiamo episodico delle chiamate passate agli strumenti risiedono insieme ai dati su cui l'agente ragiona.
• Fonda il ragionamento in un contesto aziendale tramite Unity Catalog Semantics (Metriche, Glossario aziendale, Domini) e Genie Ontology, un knowledge graph gestito automaticamente ed estratto da tabelle, query, dashboard e app già utilizzate dal team.
• Delega il ragionamento specializzato ad altri agenti, tra cui Genie per domande su dati strutturati, con coordinamento multi-step e cross-dominio all'interno del confine della piattaforma.
• Estende la stessa governance agli agenti di codifica tramite Omnigent, un meta-harness che instrada Claude Code, Codex e Cursor attraverso Unity AI Gateway con sessioni condivise e un audit trail comune.

Da dove iniziare

Alcune aziende stanno già sviluppando in questo modo. I loro agenti vengono eseguiti all'interno dello stesso confine dei loro dati, con criteri di Unity Catalog che coprono entrambi, lo stato in Lakebase e il traffico attraverso Unity AI Gateway. Nessuna di esse ci è arrivata con un singolo progetto di migrazione della piattaforma. Hanno colmato il divario tra il lakehouse e lo stack IA un progetto pilota alla volta, per poi smettere di aprirne di nuovi.

Per i team che si trovano all'inizio del percorso, il lavoro non è così drastico. La maggior parte dei componenti esiste già sul lato piattaforma: Model Serving, Unity Catalog, Lakebase, MLflow. Ciò che manca è la decisione di considerarli come la sede dell'agente anziché come fonti di dati per uno stack parallelo. Questa decisione tende a essere la parte più difficile.

Il punto di partenza più utile è un inventario di ciò che è già in esecuzione al di fuori del perimetro. È da lì che deriverà il prossimo incidente di governance, ed è questo il lavoro che rende possibile tutto il resto.

Se desideri approfondire come rendere operativi gli agenti data-native con i giusti guardrail e pattern, queste risorse rappresentano un ottimo passo successivo:

• Per tradurre la strategia in controlli concreti, leggi Un framework pratico di governance dell'IA per le aziende, che mostra come trasformare gli obiettivi di alto livello in ruoli, criteri e flussi di lavoro sulla Databricks Data Intelligence Platform.
• Per una visione più ampia dell'IA responsabile nella pratica, Best practice per la governance dell'IA: come creare programmi di IA responsabili ed efficaci illustra i principi e i modelli operativi che puoi adottare in tutti i team.

Per esplorare le funzionalità della piattaforma discusse in questo post:

• Unity AI Gateway: novità del Data + AI Summit 2026 — un unico piano di controllo per tutto il traffico di modelli e agenti, con Custom Guardrail deterministici di tipo CONSENTI/NEGA/CHIEDI (ALLOW/DENY/ASK).
• Agent Bricks: Data + AI Summit 2026 — agenti ottimizzati automaticamente e distribuiti come carichi di lavoro governati di prima classe sulla piattaforma.
• Omnigent: un meta-harness per combinare, controllare e condividere i tuoi agenti — instrada gli agenti di codifica (Claude Code, Codex, Cursor) attraverso Unity AI Gateway con un audit trail condiviso.
• Presentazione di Genie One, Genie Agents e Genie Ontology — il knowledge graph gestito automaticamente che fonda gli agenti nel tuo contesto aziendale.
• Scalabilità della memoria per gli agenti IA — come lo stato e la memoria degli agenti scalano su Lakebase, con la governance di Unity Catalog all'interno della piattaforma.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale