Alcune note dal Databricks Data + AI Summit 2026: perché il livello dei dati conta di nuovo
Dopo il Databricks Data + AI Summit di quest’anno, mi sono ritrovato a pensare meno a un singolo annuncio e più a una domanda che mi accompagna da un po’:
Quando l’AI entra davvero in produzione, cosa diventa il livello dei dati?
La mia risposta attuale è semplice, anche se le implicazioni non lo sono: in questo ciclo, il livello dei dati è la parte dello stack AI che è stata rivalutata più lentamente. Questo sta iniziando a cambiare.
Dati: la parte dello stack AI che il mercato non ha ancora prezzato
Gli algoritmi sono stati rivalutati in pubblico. I modelli migliorano rapidamente e il settore può vedere i progressi quasi ogni settimana. Il compute è stato rivalutato da NVIDIA, dai cloud provider e dai mercati dei capitali. Tutti capiscono che le GPU contano.
I dati si sono mossi più lentamente. Non perché contino meno. È vero il contrario. I dati sono lenti da rivalutare perché è difficile parlarne e ancora più difficile sistemarli. I dati aziendali sono disordinati, sparsi, duplicati, obsoleti e pieni di permessi che nessuno comprende fino in fondo. Le semantiche di business non si allineano in modo pulito tra i sistemi. La cosa che le persone chiamano “real time” è spesso ancora un job pianificato che è stato eseguito a un certo punto la scorsa notte.
Quel lavoro è doloroso. Non è nemmeno molto affascinante. Ma una volta che l’AI passa dalle demo alla produzione, il dolore diventa impossibile da nascondere.
Nelle conversazioni con persone che costruiscono e addestrano modelli, incluse quelle di OpenAI e Anthropic, la discussione torna spesso allo stesso punto. I modelli stanno convergendo. Il compute si può comprare, almeno se hai abbastanza denaro. Il livello difendibile sta diventando sempre più quello dei dati: la loro qualità, la loro freschezza, i permessi che li circondano e la velocità con cui possono essere trasformati in contesto utile.
Questo non è solo un problema a livello applicativo. All’interno delle aziende di modelli, la qualità dei modelli dipende ancora fortemente dalla pipeline dei dati. Un training run può richiedere giorni di preparazione prima che inizi il primo esperimento serio. Se un campo a monte è sporco, un batch è etichettato male o una regola di filtraggio è sbagliata, giorni di compute e attesa possono sparire prima che qualcuno si accorga che la loss curve ha deviato.
Gli agenti AI rendono impossibile nascondere il problema dei dati
Gli agenti espongono lo stesso problema in una forma più operativa.
Quando gli agenti AI falliscono in produzione, la prima causa spesso non è che il modello sia incapace. È che il modello sta agendo sul contesto sbagliato: un record a cui non può accedere, un documento scaduto sei ore fa, una fonte dati che è cambiata silenziosamente durante la notte o un percorso di retrieval troppo costoso per essere usato abbastanza spesso. Di recente ho visto un team forte perdere quasi una settimana a causa di una pipeline di contesto obsoleta. L’agente rispondeva con sicurezza alla domanda di ieri. Il modello non era stupido. Il contesto era sbagliato e il sistema non aveva un modo pulito per dimostrare dove l’errore fosse entrato nel loop.
Questa è la modalità di fallimento che conta. Il prossimo collo di bottiglia infrastrutturale non è semplicemente un ragionamento migliore. È un contesto fresco, affidabile, economico e verificabile nel momento in cui un modello o un agente prende una decisione.
Ecco perché penso che il livello dei dati sia la prossima parte dello stack AI a essere rivalutata.
Databricks sta puntando al problema giusto
Sono scettico verso molti prodotti che si definiscono “AI data platforms.” Troppo spesso la narrazione arriva prima del sistema.
Databricks è abbastanza diversa da meritare, secondo me, seria attenzione. Due cose mi hanno colpito al Summit.
La prima è ancora la cultura ingegneristica. Alla scala di Databricks, sarebbe facile per l’azienda diventare puramente guidata dalle vendite. Eppure i fondatori sono ancora sul palco a parlare di execution engine, transazioni, analytics in tempo reale e dei tubi sotto il prodotto. Lo rispetto. Si percepisce quando un’azienda ha ancora intuizione di prodotto e ingegneristica al suo centro. Si vede nelle piccole decisioni architetturali molto prima di comparire in un keynote.
Il secondo è la base clienti. Gli utenti con cui ho parlato al Summit non parlavano dell’AI come di un livello dimostrativo. Stavano cercando di portare l’AI nei sistemi di produzione, e i problemi che descrivevano erano molto più concreti: gli agenti devono leggere e scrivere lo stato del business; le analytics in tempo reale non possono continuare a pagare il costo dello spostamento dei dati; le pipeline devono diventare più autonome; il comportamento degli agenti ha bisogno di governance a runtime, non solo a posteriori.
Ecco perché annunci come Lakebase, Lakehouse//RT, data agents e AI governance contano. I nomi sono meno importanti della direzione. Avvicinare le transazioni al lake. Riportare le analytics in tempo reale verso la stessa base dati. Automatizzare una parte maggiore della pipeline. Estendere la governance da “chi può vedere questo dataset” a “che cosa è autorizzato a fare questo agente in questo passaggio specifico?”
Non lo vedo come una svolta sbagliata. Lo vedo come la prova che molti di noi stanno guardando allo stesso futuro da angolazioni diverse.
Il database si sta espandendo. Non è più solo un luogo in cui archiviare ed eseguire query sui dati. Sta diventando la base per fatti, stato, semantica, governance e azione.
La mappa è buona. Ma non è finita.
Databricks è nella direzione giusta. Questo non significa che l’architettura abbia raggiunto la sua forma finale.
Foto: The Known Data Realm · Databricks Data + AI Summit 2026
Vedo tre aree in cui la mappa è ancora incompleta.
Il lakebase stesso.
Partire da Postgres è un punto di ingresso intelligente. Gli sviluppatori lo conoscono. L’ecosistema è enorme. La compatibilità riduce l’attrito nell’adozione. Questo conta.
Ma l’architettura che fa entrare le persone dalla porta non è sempre l’architettura che vince il carico di lavoro finale.
I sistemi operativi dell’era dell’AI hanno bisogno di transazioni, memoria, vettori, dati multimodali, tracce, branching, rollback e isolamento dei tenant molto granulare. Un core relazionale tradizionale può esporre alcune di queste capacità tramite estensioni e servizi circostanti, ma questo non le rende native. Il Postgres classico non è stato progettato per la scalabilità distribuita cloud-native, né per agenti che creano database di breve durata, fanno fork dello stato, scrivono in memoria, generano tracce e scompaiono.
Avvicinare Postgres all’object storage non elimina queste domande. L’object storage è economico e affidabile, ma non è a bassa latenza per impostazione predefinita. Per farlo sembrare veloce, serve un livello di cache che sia al tempo stesso aggressivo e corretto. Una cache che resta stabile sotto un reale carico transazionale è uno dei problemi di sistema più difficili nei database. Quindi la mia domanda sincera su Lakebase non è se la demo sia impressionante. È se il sistema possa sostenere carichi di lavoro OLTP reali su scala di produzione senza trasformare quella cache nella cosa che sveglia le persone alle 3 del mattino.
I dati multimodali.
Databricks ha tracciato una mappa solida tra OLTP, warehousing, analytics in tempo reale, data science e governance. Ma le applicazioni AI consumano sempre più testo, immagini, audio, video, embedding, log comportamentali e tracce degli agenti. Questi non sono solo oggetti accanto alle tabelle. Sono i dati che gli agenti recuperano, su cui ragionano, trasformano e riscrivono.
Se i dati multimodali restano fuori dalla mappa centrale, allora gli asset di dati AI più importanti vivono ancora ai margini.
L’utente predefinito.
Gran parte della superficie del prodotto presuppone ancora un utente umano: dashboard, BI in linguaggio naturale, workflow in stile Excel ed esperienze rivolte agli analisti. Sono elementi preziosi. Ma gli agenti usano i database in modo diverso.
Un agente non apre una dashboard una volta al giorno. Funziona in un ciclo. Recupera contesto, prende una decisione, chiama uno strumento, scrive lo stato, controlla una policy e ripete. Ogni passaggio può dover essere sottoposto ad audit. Ogni recupero può influenzare l’azione successiva. Ogni scrittura può richiedere rollback. Ogni controllo dei permessi può dover avvenire a runtime.
Questo è un carico di lavoro di database diverso.
Foto: Unity AI Gateway · Governance —— Databricks Data + AI Summit 2026
Quando l’utente del database è un agente
Per decenni, un database ha potuto concentrarsi per lo più su una domanda: come eseguire questa query correttamente e rapidamente.
Nell’era degli agenti, la domanda diventa più ampia:
Come fa un agente a ottenere il contesto più aggiornato, più affidabile, a costo più basso e più verificabile nel momento in cui prende una decisione?
Questo non è solo un problema di ottimizzazione delle query. È un problema di sistemi che attraversa storage, indicizzazione, governance, lineage, replay, controllo dei costi ed enforcement delle policy a runtime.
È qui che la categoria inizia a cambiare. Un sistema di dati non può più essere soltanto un sistema di intelligence: fai una domanda, restituisce una risposta. Deve diventare qualcosa di più vicino a un sistema operativo per l’AI: il luogo in cui gli agenti leggono il contesto, prendono decisioni, chiamano strumenti, scrivono stato e lasciano una traccia che esseri umani e altri sistemi possono ispezionare.
L’auditability non può essere aggiunta a posteriori. Se un agente dà la risposta sbagliata, compie l’azione sbagliata o spende troppo denaro, la prima domanda sarà: che cosa ha visto esattamente in quel momento?
Per rispondere, il sistema deve sapere quali documenti sono stati recuperati, quali vettori sono stati abbinati, quali filtri di metadati sono stati applicati, quale reranker ha cambiato l’ordine, quale strumento è stato chiamato, quale policy è stata applicata e quale stato è stato riscritto. Debugging e governance diventano lo stesso workflow.
Questa è l’architettura che non penso nessuno abbia ancora risolto completamente.
Che cosa dovrebbe significare davvero “AI-native”
“AI-native” sta diventando una di quelle espressioni che possono significare quasi qualsiasi cosa. Non penso esista ancora una definizione pulita. Ma se partiamo a ritroso dai workload reali degli agenti, un sistema di dati AI-native deve fare bene almeno alcune cose.
I dati multimodali devono essere first-class
Testo, immagini, audio, video, embedding, log e trace non dovrebbero essere dispersi tra una tabella relazionale, una colonna vettoriale, un object bucket e diversi indici laterali. Devono vivere in un unico sistema logico in cui retrieval, filtraggio, ranking e governance possano avvenire insieme.
La parte difficile non è archiviare questi asset. La parte difficile è renderli interrogabili insieme senza trasformare l’architettura in un altro problema di pipeline.
L’elasticità deve partire dal workload
Il traffico degli agenti è a raffiche. Un sistema può rimanere silenzioso per un’ora e poi ricevere un’ondata di richieste di retrieval, memoria e uso di strumenti. Il data lake o object store dovrebbe diventare la base durevole: economica, affidabile e disaccoppiata dal compute.
Ma il compute non dovrebbe restare costoso solo perché il corpus esiste. Se nessuno sta cercando, il sistema dovrebbe spendere pochissimo. Se un workload si risveglia, il compute dovrebbe arrivare rapidamente. In quel mondo, l’unità naturale di pricing non è sempre un cluster permanente. Può essere la query, la sessione o il minuto di compute attivo.
La multi-tenancy deve spostarsi al livello dell’agente
I sistemi multi-tenant tradizionali spesso presuppongono un numero gestibile di grandi tenant. I sistemi agentici possono creare milioni o miliardi di stati minuscoli, di breve durata e isolati. Ogni agente può portare con sé la propria memoria, i propri permessi, trace, branch temporanei e percorsi di scrittura.
Un design costruito per migliaia di grandi tenant farà fatica quando il tenant diventa l’esecuzione stessa dell’agente.
Branching e rollback diventano funzionalità centrali del database
Gli agenti scriveranno la cosa sbagliata. Non è un caso limite. Fa parte del workload.
Un data layer AI utile ha bisogno di branching simile a Git e rollback rapido per lo stato dei dati. Un’esecuzione dell’agente dovrebbe poter creare un fork di un branch di lavoro, testare un’azione, scrivere stato temporaneo e scartarlo o promuoverlo. Se arriva un aggiornamento errato, il sistema dovrebbe poter tornare rapidamente a un punto noto come valido.
Il versioning non è più soltanto una comodità per l’analytics. Diventa un meccanismo di sicurezza operativa.
Trace e replay deterministico sono obbligatori
Quando un agente fallisce, la domanda non è solo “qual è stata la risposta finale?” È “che cosa ha visto, recuperato, classificato, deciso, chiamato e scritto l’agente?”
Questo richiede una traccia di ogni passaggio significativo. Ancora più importante, richiede il replay. Il sistema dovrebbe essere in grado di ricostruire il contesto decisionale così com’era in quel momento, non come appare dopo che un documento è stato modificato o un indice è stato ricostruito.
Per gli agenti, verificabilità e debug convergono nello stesso requisito.
Le autorizzazioni devono governare le azioni, non solo le righe
L’autorizzazione tradizionale chiede chi può leggere una tabella, una colonna o una riga. I sistemi agentici hanno bisogno di una domanda più dinamica: che cosa è autorizzato a recuperare, chiamare, modificare, divulgare e spendere questo agente in questo specifico passaggio?
La parte difficile si sposta dal percorso di lettura al percorso di azione. L’applicazione delle policy deve avvenire mentre l’agente è in esecuzione, non solo quando un essere umano apre una dashboard.
Le operazioni devono diventare autonome
La scala a livello di agente rompe l’infrastruttura gestita dagli esseri umani. Nessun team può gestire manualmente indici, compattazione, riscaldamento della cache, posizionamento dei tenant, ripristino e schedulazione delle risorse su milioni di workload piccoli e in rapido movimento.
Il sistema deve operare da solo. Altrimenti, l’architettura può funzionare in un diagramma ma fallire nell’unico posto che conta: la produzione.
SQL non basta come interfaccia finale
C’è un’altra questione a cui penso sempre di più: l’interfaccia stessa.
SQL era l’interfaccia giusta per l’era degli analisti. È ancora essenziale. Ma per le aziende costruite intorno a database e analytics, SQL può anche diventare una forma di dipendenza dal percorso. La superficie del prodotto, il modello utente e persino l’organizzazione spesso presuppongono che l’utente principale sia qualcuno che sa scrivere una query.
L’interfaccia finale per i dati nell’era dell’AI non sarà un editor SQL leggermente migliore. E non sarà nemmeno un chatbot incollato davanti al database.
Il punto di arrivo più interessante è un sistema dati headless, nativo per il linguaggio naturale: uno in cui una persona o un agente può dichiarare direttamente l’intento e il sistema può rispondere, agire o preparare il giusto piano di esecuzione senza esporre ogni passaggio interno come un esercizio di scrittura di query.
Ma questo deve essere nativo del database, non un agente separato posizionato davanti a esso.
Se il linguaggio naturale è solo un livello applicativo, il sistema reintroduce proprio le giunture che sta cercando di rimuovere: un passaggio di traduzione in più, una finestra di contesto obsoleta in più, una lacuna di governance in più. Il database stesso deve comprendere la domanda, i dati, le policy e il percorso di esecuzione.
Questo è molto più difficile che costruire un’interfaccia amichevole. Significa che il database deve possedere la semantica.
Il fossato che conta ancora
Non ho una conclusione perfettamente pulita. Forse è appropriato così. Il mercato si sta muovendo troppo rapidamente, e troppe vecchie supposizioni vengono prosciugate più velocemente del previsto.
Un dialetto di query proprietario non è più il fossato che era un tempo. Il costo di migrazione è più debole quando gli agenti possono riscrivere il codice di integrazione. Un’interfaccia utente familiare conta meno quando il prossimo utente potrebbe non essere umano. Persino il vantaggio silenzioso di possedere semplicemente i dati è più debole quando formati di tabella aperti, interfacce in linguaggio naturale e agenti che usano strumenti rendono il movimento più facile.
Il fossato in cui credo ancora è meno affascinante: la capacità di creare valore reale per gli utenti per un lungo periodo di tempo, con pazienza e ripetizione.
È per questo che sono uscito dal Summit prendendo Databricks sul serio. Penso che Databricks abbia una reale possibilità di diventare la prossima azienda da mille miliardi di dollari nei dati. Non perché ogni annuncio di prodotto sia la risposta definitiva. Alcuni cambieranno. Alcuni probabilmente saranno sbagliati. È normale. Ciò che conta è che l’azienda continui a tornare verso il problema giusto.
E il problema giusto non è più solo analytics, warehousing o storage transazionale. È la fondazione dati per sistemi AI che agiscono.
Dal punto di vista di Zilliz, siamo arrivati a una conclusione simile partendo da un’altra direzione. I database vettoriali non stanno scomparendo. Stanno diventando il motore di serving all’interno di un’architettura più ampia per dati non strutturati e multimodali. Per questo pensiamo in termini di Vector Lakebase: non un sostituto dei database vettoriali, ma la prossima architettura costruita attorno a essi man mano che i carichi di lavoro AI diventano più continui, elastici e agentici.
La mappa non è finita. Questa è la parte migliore.
Economico batte costoso. Affidabile batte inaffidabile. Attento batte distratto. Paziente batte impaziente.
Il database AI-native è ancora in fase di disegno. Per tutti coloro che stanno costruendo in questo spazio, questa è un’ottima notizia.
Un’ultima cosa: Zilliz Vector Lakebase è disponibile in anteprima pubblica
Abbiamo lanciato l’anteprima pubblica di Zilliz Vector Lakebase — una grande evoluzione di Zilliz Cloud da puro database vettoriale a fondamento dati lake-native per l’AI, che combina il serving vettoriale a bassa latenza con l’apertura, la scalabilità e l’economicità di un data lake.
Funzionalità principali di Zilliz Vector Lakebase:
- Serving a livelli ottimizzato per diversi compromessi tra prestazioni in tempo reale e costi
- Ricerca on-demand per carichi di lavoro su larga scala o esplorativi senza compute sempre attivo
- Ricerca su data lake esterni — indicizza e cerca direttamente sui dati del tuo lake esistente
- Ricerca full-spectrum su vettori, testo, JSON e dati geospaziali con recupero ibrido e reranking
- Storage unificato lake-native basato su Vortex, un formato aperto con letture casuali più rapide ed economiche rispetto a Lance o Parquet
Se il tuo stack attuale separa serving e discovery in sistemi distinti, potrebbe valere la pena dare un’occhiata a Vector Lakebase. Provalo su Zilliz Cloud — le nuove registrazioni con email di lavoro ricevono $100 di crediti gratuiti — oppure parla con noi del tuo caso d’uso.
Continua a leggere
VDBBench Adds Cost-Aware Benchmarking for Vector Databases
Compare Zilliz Cloud, Pinecone, and turbopuffer with VDBBench cost-aware vector database benchmarks across latency, freshness, multitenancy, and cold starts.
AI Agents Are Quietly Transforming E-Commerce — Here’s How
Discover how AI agents transform e-commerce with autonomous decision-making, enhanced product discovery, and vector search capabilities for today's retailers.
Introducing DeepSearcher: A Local Open Source Deep Research
In contrast to OpenAI’s Deep Research, this example ran locally, using only open-source models and tools like Milvus and LangChain.