Google ha ridisegnato la propria architettura dei dati per far smettere all'IA di fallire nelle aziende
Per anni, i team dei dati e i team dell'IA nelle grandi aziende hanno operato come dipartimenti di paesi diversi. I primi costruivano data warehouse, cataloghi e pipeline. I secondi distribuivano modelli, API e agenti. I due mondi comunicavano attraverso esportazioni manuali, processi discontinui e una fede cieca nel fatto che "l'altro team avrebbe risolto". Il risultato era prevedibile: gli agenti di IA arrivavano nell'ambiente di produzione e collassavano di fronte a dati che nessuno aveva preparato affinché una macchina autonoma potesse leggerli, interpretarli e agire su di essi.
Al Google Cloud Next 2026, Google ha nominato quel collasso con precisione: la separazione tra piattaforma dei dati e piattaforma dell'IA è il principale freno al dispiegamento aziendale di agenti autonomi. La risposta è stata il Cloud di Dati Agentico, una profonda riconfigurazione della propria architettura dei dati che non aggiunge uno strato di IA sopra ciò che esiste, ma ridisegna le fondamenta affinché gli agenti diventino utenti di prima classe del dato aziendale.
La differenza di ambizione non è trascurabile. Non stiamo parlando di nuovi connettori né di dashboard arricchite con linguaggio naturale. Stiamo parlando di una riprogettazione strutturale che obbliga a ripensare il modo in cui qualsiasi azienda Fortune 500 — con dati distribuiti tra AWS, Azure e Google Cloud — governerà, servirà e monetizzerà le informazioni che già possiede.
La diagnosi che i dirigenti preferiscono ignorare
C'è un dato che mette a disagio: secondo la ricerca che accompagna il lancio, circa il 70% delle aziende scopre i problemi della propria infrastruttura di dati dopo aver distribuito gli agenti, non prima. Questo non è un problema tecnico. È un problema di leadership travestito da problema tecnico.
I dati frammentati, privi di governance, intrappolati in silos di cloud diverse, non sono comparsi dall'oggi al domani. Si sono accumulati nel corso di anni di decisioni affrettate, acquisizioni aziendali mal integrate e una tendenza organizzativa molto umana: rimandare la conversazione difficile sulla reale architettura del dato perché "il business continua a funzionare". Fino a quando smette di funzionare.
L'architettura che Google ha presentato è composta da sei componenti che non sono indipendenti tra loro, ma formano un sistema con una logica sequenziale. Alla base, il Data Lakehouse Multinube, costruito sul formato aperto Apache Iceberg, consente a BigQuery di interrogare dati ospitati su AWS S3 e Azure ADLS senza necessità di spostarli né replicarli, eliminando i costi di egress e il rischio di incoerenza tra copie. Su questa base opera il Motore Lightning per Apache Spark, uno strato di esecuzione vettorializzato in C++ che offre fino a 4,9 volte le prestazioni dello Spark convenzionale. Il dato non è soltanto accessibile; è elaborabile a una velocità tale da rendere praticabile che un agente generi, esegua e corregga codice Spark in cicli continui senza che i costi esplodano.
Sopra quella infrastruttura di esecuzione si inserisce lo strato di intelligenza contestuale: il Catalogo della Conoscenza, l'evoluzione di Dataplex Universal Catalog presentata il 10 aprile 2026. Questo componente è quello che dovrebbe catturare maggiormente l'attenzione degli architetti aziendali. Il catalogo non richiede che i team dei dati cataloghino manualmente gli asset. Esamina i log delle query, profila le tabelle, analizza modelli semantici di strumenti come Looker ed estrae relazioni tra entità da file non strutturati. Il risultato è un grafo della conoscenza dinamico, mantenuto automaticamente, che risponde alla domanda che qualsiasi agente deve risolvere prima di agire: quali dati esistono, cosa significano con precisione e se sono attendibili.
Quando lo storage smette di essere passivo
Il componente che più radicalmente cambia la geometria operativa del dato è lo Storage Intelligente, attualmente in anteprima. Fino ad ora, un file che entrava in un bucket di Google Cloud Storage era inerte fino a quando qualcuno decideva di elaborarlo. Con questa funzionalità, nel momento in cui un file arriva nel bucket, il sistema lo etichetta automaticamente, genera embedding, estrae entità rilevanti e lo collega al Catalogo della Conoscenza. PDF, contratti, ticket di supporto, registrazioni audio: tutto diventa un asset ricercabile senza che nessun ingegnere debba intervenire.
Per i dirigenti che hanno rimandato progetti di preparazione dei dati non strutturati — quelli che "richiederanno sei mesi" di estrazione, OCR, indicizzazione e catalogazione — questo riconfigura l'equazione di tempo e costo in un modo che non ammette rinvii comodi. Ciò che prima era un progetto con uno sponsor esecutivo, un budget proprio e una data di consegna incerta, diventa ora una conseguenza automatica della politica di archiviazione.
L'Agente di Ricerca Approfondita, basato su Gemini 3.1 Pro, illustra il caso d'uso terminale dell'intera infrastruttura. Opera combinando fonti interne del Catalogo della Conoscenza e del Lakehouse con fonti aperte su internet, genera piani di ricerca strutturati e consegna report con citazioni verificabili in pochi minuti. Attività che in aree come l'intelligence competitiva, le scienze della vita o i servizi finanziari richiedevano tra una e tre settimane di lavoro analitico diventano il punto di partenza, non il punto di arrivo.
Il Kit di Agenti per i Dati completa il quadro dal lato dello sviluppatore. Offre strumenti MCP preconfigurati e tre agenti specializzati: uno che converte istruzioni in linguaggio naturale in pipeline gestite scegliendo tra BigQuery, dbt, Spark o Airflow; un altro che automatizza il ciclo completo dei modelli di data science; e un terzo dedicato all'osservabilità dell'infrastruttura. Il Model Context Protocol funge da strato di interoperabilità che consente ad agenti di qualsiasi fornitore — Gemini, Claude, modelli proprietari — di accedere agli asset di dati senza connettori su misura.
Il multicloud smette di essere una lamentela e diventa una decisione architetturale
Nessuna azienda tra le Fortune 500 opera esclusivamente su Google Cloud. I sistemi SAP, Salesforce, Workday e Oracle sono distribuiti tra AWS e Azure per ragioni storiche, contrattuali e operative che nessun mandato del CTO può risolvere con una circolare interna. Per anni, il multicloud è stato l'argomento ricorrente per non avanzare con alcuna iniziativa di IA su scala: "prima dobbiamo consolidare i dati".
Il Data Lakehouse Multinube smonta quell'argomento con specificità tecnica. Utilizzando il Catalogo REST di Iceberg, l'interconnessione multinube e uno strato di cache intelligente, BigQuery può interrogare dati su AWS S3 e Azure ADLS con latenza e costo comparabili a quelli dei dati nativi su Google Cloud. Un agente degli acquisti può combinare in un'unica query dati di contratti archiviati su S3, inventario su Azure e registrazioni transazionali su BigQuery, tutto sotto un catalogo Iceberg unificato, senza che nessun team di ingegneria debba gestire un processo ETL tra cloud.
L'implicazione per gli architetti dell'integrazione è di ordine strategico. La conversazione smette di essere "come migriamo tutto su un unico cloud" e diventa "come governiamo un catalogo unico sulla distribuzione dei dati che già abbiamo". Non è la stessa conversazione. La prima ha un costo politico e finanziario proibitivo nella maggior parte delle organizzazioni mature. La seconda è eseguibile senza stravolgere i contratti esistenti con altri fornitori.
Ciò che Google sta proponendo, nel suo insieme, è un cambiamento di paradigma con conseguenze organizzative che vanno ben oltre l'architettura tecnica. L'MCP come strato di governance degli agenti richiede di essere gestito con la stessa disciplina che oggi si applica a un gateway API: versionamento, autenticazione, monitoraggio, limiti di utilizzo. Il Catalogo della Conoscenza smette di essere un progetto di documentazione e diventa una dipendenza operativa in tempo reale, il che implica accordi sul livello di servizio, manutenzione continua e un modello operativo che i team dei dati non hanno ancora progettato.
La cultura di un'organizzazione non è il cartello incorniciato nella sala riunioni né il discorso del CEO alla convention annuale. È la somma accumulata di tutte le decisioni che i leader hanno preso quando era più comodo rimandare che decidere, più sicuro delegare che assumersi la responsabilità, più facile incolpare il debito tecnico che riconoscere che l'architettura del dato riflette con precisione chirurgica l'architettura del potere, della paura e delle conversazioni che la direzione non ha mai avuto il coraggio di affrontare.
