Quasi tutti i pilot di AI enterprise superano la stessa asticella bassa: colleghi un LLM ai tuoi dati, aggiungi un vector database, fai la demo al management. Il difficile arriva dopo, quando la security segnala i buchi di governance, la latenza degli agenti multi-step rovina l’esperienza e il conto del provider continua a salire. In un post argomentativo, Databricks fa risalire questi problemi a una sola decisione: estrarre i dati da sistemi governati per portarli in uno stack AI che non e’ mai stato costruito per far rispettare le tue policy. La proposta e’ invertire la direzione: spostare modelli e agenti verso i dati, non i dati verso l’AI.
La tassa nascosta degli agenti esterni
I dati hanno gravita’: il compute e’ economico da spostare, i dati no. Estrarli introduce penalita’ note: la governance si indebolisce perche’ access control, lineage e residency vanno reimplementati in ogni integrazione; la latenza si somma a ogni hop verso vector store e LLM esterni; i costi si frammentano tra egress, storage duplicato e pricing per-token di piu’ fornitori; l’osservabilita’ si spezza, perche’ tracciare una singola richiesta significa ricucire log da tre o quattro strumenti; e il contesto di business resta indietro, con l’agente esterno costretto a ricostruire le definizioni delle metriche dai nomi delle colonne.
Perche’ la governance a posteriori fallisce
L’argomento piu’ netto riguarda la governance, l’unica penalita’ che non si puo’ rattoppare dopo. Molti approcci trattano la governance come un filtro applicato dopo che l’agente ha gia’ avuto accesso ai dati: redazione dei campi sensibili, blocco di certi topic in output, audit dei log. Funziona per demo di Q&A, ma si rompe appena gli agenti iniziano a calcolare sui dati. Un agente che produce un riassunto finanziario su righe soggette a row-level security genera un valore derivato la cui forma dipende da quali righe sono incluse: se la policy non e’ applicata prima della query, nessuna redazione a valle puo’ annullare quel calcolo. La decisione di policy deve avvenire al momento della pianificazione della query, non del rendering della risposta. C’e’ anche un costo economico: quando la governance viene risolta a posteriori, l’agente finisce per fare da solo la riconciliazione, attraversando log e unendo frammenti tra sistemi, trasformando una richiesta in migliaia di token fatturati.
Stato, memoria e la proposta Databricks
Gli agenti in produzione non solo leggono ma scrivono: cronologia, progressi dei task, preferenze utente, cache. Anche questo stato ha bisogno di governance e di storage transazionale, con letture e scritture veloci per riga che le tabelle Delta, pensate per scansioni analitiche, non offrono. La soluzione classica, un Postgres o Redis esterno, riporta al problema di partenza. Databricks propone di eseguire gli agenti dentro la Data Intelligence Platform: traffico instradato tramite Unity AI Gateway con guardrail deterministici ALLOW/DENY/ASK, ogni primitiva AI trattata come asset di Unity Catalog, tracing completo via MLflow 3, inferenza dentro il perimetro su Model Serving, retrieval con AI Search che rispetta le ACL, e stato e memoria su Lakebase, PostgreSQL gestito sotto lo stesso piano di governance. Come nota il post, la maggior parte dei pezzi esiste gia’ sulla piattaforma: cio’ che manca e’ la decisione di trattarli come la casa dell’agente anziche’ come sorgenti dati per uno stack parallelo.
- La governance non si applica a posteriori: quando gli agenti calcolano sui dati, la policy va imposta al planning della query.
- Lo stato e la memoria dell’agente sono a loro volta dati sensibili e vanno tenuti dentro il perimetro governato.
- Portare gli agenti vicino ai dati riduce latenza, costi di egress e frammentazione dell’osservabilita’.
Fonte: Data-Native AI Agents: Why Agents Must Move to Your Data — https://www.databricks.com/blog/data-native-ai-agents-why-agents-must-move-your-data
Hai qualcosa da aggiungere? Unisciti alla discussione.