Google Cloud lancia l’era degli agenti AI pronti all’uso: analytics 200 volte più veloci con Spanner

Google Cloud ha concentrato a febbraio 2026 una serie di rilasci che, letti insieme, sembrano meno una somma di feature e più una scelta di architettura: portare governance e sicurezza al livello della piattaforma, spingere performance e resilienza su dati operativi, e rendere finalmente ingegnerizzabile ciò che negli ultimi mesi è spesso rimasto “vibe check”, cioè la valutazione soggettiva dei sistemi basati su AI agents. In parallelo, la piattaforma mostra due segnali che pesano in modo diverso ma convergente: da un lato la migrazione completata da PayPal di oltre 300 petabyte su BigQuery, dall’altro la disruption della campagna di spionaggio GRIDTIDE attribuita a un attore PRC-nexus e attiva dal 2017. Il messaggio operativo è che l’innovazione Gen AI non può vivere senza dati governati, pipeline affidabili e un modello di difesa che consideri l’abuso di API legittime come una superficie d’attacco primaria. Nel perimetro di febbraio entrano anche componenti che, fino a poco fa, sarebbero sembrati “di nicchia” ma che in realtà diventano fondamentali quando si prova a far funzionare sistemi distribuiti moderni: la sincronizzazione sub-10 nanosecondi di Firefly, e l’integrazione in Vertex AI di Nano Banana 2 con controlli enterprise di provenienza come SynthID e C2PA Content Credentials. L’impressione è che Google Cloud stia costruendo un’unica narrativa: modernizzare architetture event-driven, ridurre sprawl di API, mettere memoria e valutazione degli agenti su basi ripetibili, e chiudere i buchi che nascono non dalle vulnerabilità, ma dall’uso creativo dei servizi legittimi.

Eventarc Advanced: il bus eventi separa governance e logica applicativa

La novità più “infrastrutturale” è Eventarc Advanced, che diventa generally available e introduce un pattern architetturale capace di risolvere una tensione tipica del cloud moderno: gli sviluppatori vogliono autonomia sui microservizi, i team di sicurezza vogliono policy globali che non dipendano da accordi informali tra squadre. Eventarc Advanced separa esplicitamente il layer di governance dal layer di logica. Il Bus diventa il punto in cui applicare policy IAM centralizzate con content-based access control, mentre l’integrazione con VPC Service Controls è pensata per prevenire scenari di esfiltrazione che spesso emergono quando eventi e payload sensibili attraversano domini applicativi diversi. Le Pipeline gestiscono trasformazioni e routing con Common Expression Language, includendo conversioni di formato, retry e autenticazione indipendente. L’idea è fornire un controllo simile agli ESB legacy, ma con l’agilità e la granularità dei microservizi. Il fatto che gli eventi seguano lo standard aperto CloudEvents non è un dettaglio. È il tentativo di ridurre il lock-in “di fatto” che nasce quando la semantica degli eventi è proprietaria. In uno scenario tipo, un retailer globale può avere team separati per ordine, pagamento, settlement e fulfillment. Eventarc Advanced consente di farli muovere in parallelo senza un coordinamento continuo, perché il Bus verifica identità dei producer e classifica dati per sensibilità, mentre le Pipeline applicano filtri, conversioni e invocazioni downstream, inclusa l’integrazione con agenti AI attraverso protocolli come Agent2Agent e Model Context Protocol quando l’organizzazione decide di introdurre orchestrazione intelligente.

Apigee API Hub: la risposta allo sprawl diventa prerequisito per agenti che chiamano tool

Il secondo tema, meno appariscente ma cruciale, è lo sprawl di API. In molte aziende il problema non è avere poche API, ma averne troppe, spesso duplicate, con specifiche incomplete o assenti. Gli agenti AI, se devono scoprire e invocare API in modo affidabile, hanno bisogno di definizioni accurate, esempi, validazioni e versioning. Qui entra Apigee API Hub, che centralizza metadati e definizioni da gateway distribuiti. La nuova integrazione sincronizza specifiche OpenAPI da API Gateway in tempo reale, con un processo che avviene in background senza modifiche a API o client. In public preview arriva Specification Boost, che analizza le specifiche e produce versioni arricchite con esempi e validazioni, generando file draft paralleli che possono essere confrontati. Questo passaggio è un punto di contatto diretto con l’AI: se un agente deve fare function calling, una specifica povera è un invito all’errore, alle “shadow API” e alle invocazioni sbagliate. Un repository unico, invece, riduce il rischio che l’AI ignori API legacy solo perché non documentate, o che le interpreti in modo ambiguo.

Memoria chatbot: storage polyglot come architettura, non come patch

Sul fronte agenti e chatbot, Google Cloud spinge un approccio che ha il pregio di essere meno “romantico” e più operativo: la memoria non è un’unica cosa, e non dovrebbe vivere in un unico storage. Il modello proposto è polyglot, con livelli diversi in base a latenza, retention e tipo di analisi. Memorystore for Redis gestisce la short-term memory con latenza sub-millisecondo, usando strutture come Redis Lists e pattern di scrittura tipo RPUSH per append rapidi. Cloud Bigtable diventa il system of record mid-term, con una chiave costruita per scalare su milioni di utenti e sessioni, ad esempio user_id e session_id con reverse timestamp, e garbage collection configurata a 60 giorni per mantenere il sistema pulito senza interventi manuali. BigQuery assorbe la long-term memory e la telemetria conversazionale per analytics, training e feedback loop, mentre Cloud Storage conserva artefatti multimediali con puntatori URI e signed URL per accesso sicuro. Il valore di questa architettura non sta nel singolo prodotto, ma nel flusso ibrido sync-async che sposta messaggi e risposte attraverso i layer senza far collassare l’esperienza utente. È anche un modo di rendere meno fragile il salto dal prototipo al reale: quando un agente deve gestire milioni di utenti, il problema non è “ricordare”, è ricordare senza introdurre latenza, costi fuori controllo o inconsistenza.

AI agents production-ready: dalla soggettività al processo ingegnerizzato

Il cuore del pacchetto di febbraio, per chi lavora davvero con agenti, è il tentativo di spostare lo sviluppo da test informali a un ciclo ingegneristico. Google Cloud descrive il passaggio dal “vibe check” a una continuous evaluation continua, automatizzata e misurabile. Qui entrano strumenti e pattern che parlano il linguaggio del software engineering. Il Vertex AI Gen AI Evaluation Service consente valutazioni con metriche pre-built come GROUNDING, SAFETY e TOOL_USE_QUALITY, usando rubriche statiche o adaptive che producono feedback spiegabile. L’Agent Development Kit punta su modularità, output strutturato con Pydantic e tracing con OpenTelemetry, cioè ciò che serve quando si deve osservare un agente in produzione e capire dove sta fallendo. Il protocollo Agent2Agent standardizza comunicazione tra agenti via HTTP e JSON, mentre Cloud Run porta logiche come shadow deployment per testare versioni senza esporle subito al traffico reale. La checklist che emerge è una grammatica di rollout: sandbox, canary, produzione. Dentro ci sono elementi che, nelle aziende, diventano “non negoziabili” appena un agente inizia a toccare processi reali: session management robusto, logging in tempo reale, CI/CD con Cloud Build, tool schema validati runtime e strategie per catturare regressioni dovute a drift di modello o cambiamenti nel prompt. L’idea che la valutazione si concentri su trajectory, con unit test e analisi di sequenza, è la parte più pragmatica, perché smette di giudicare una risposta finale e inizia a giudicare un percorso d’azione.

Spanner Columnar Engine: analytics fino a 200 volte più veloce senza sacrificare l’OLTP

Sul fronte dati operativi, Spanner Columnar Engine entra in preview e propone un’idea che molte aziende inseguono da anni: eliminare il trade-off tra transazionale e analitico quando i dati devono restare live. Il modello è un unico sistema con storage row e columnar, scalabile orizzontalmente, con esecuzione vettorizzata che accelera query analitiche fino a 200 volte senza impattare le transazioni OLTP. La piattaforma converte automaticamente i dati in formato columnar e offre opzioni come major compaction manuale. Il ponte con Iceberg lakehouse consente scenari di reverse ETL e integrazione con ecosistemi che ruotano attorno a BigQuery, Databricks o Snowflake, ma con una promessa specifica: servire dati lakehouse con consistenza globale e alta disponibilità. I casi d’uso che vengono evocati, come real-time dashboard, threat detection e AI agents, raccontano perché questa mossa interessa: quando un agente deve prendere decisioni basate su dati operativi, la distanza tra OLTP e analytics diventa latenza decisionale, cioè rischio.

PayPal e BigQuery: 300 petabyte come segnale di industrializzazione dell’AI su dati governati

La migrazione di PayPal è il tipo di notizia che, in un mondo pieno di annunci, funziona come prova. Oltre 300 petabyte migrati da Teradata, Hadoop, Redshift e Snowflake a BigQuery, con riduzione dei vendor da quattro a uno e decommission del 25% dei workload senza downtime o impatto clienti. Il dato operativo che spicca è la freschezza dei dati, dichiarata 16 volte superiore per training di modelli Gen AI, e l’accelerazione delle query da 2,5 a 10 volte su workload complessi. In prospettiva, PayPal usa questa base unificata per insight personalizzati, rilevamento frodi predittivo e esperienze merchant più intelligenti, oltre a consolidare dati frammentati da acquisizioni come Venmo e Braintree. È un caso che collega tre concetti: unificazione dei dati, governance e possibilità di costruire sistemi agentici su una base consistente.

GRIDTIDE: la disruption di una campagna che abusa API legittime

Nel pacchetto di febbraio c’è anche il segnale “difensivo”: Google Threat Intelligence Group e Mandiant disattivano GRIDTIDE, campagna di spionaggio attribuita a UNC2814 e sospettata PRC-nexus, attiva dal 2017. Il backdoor abusa le Google Sheets API come command and control stealth, cioè un pattern sempre più frequente: non serve un exploit di vulnerabilità se puoi vivere dentro l’uso legittimo dei servizi. Google dichiara di aver terminato progetti Cloud controllati dall’attore, sinkhole domini e revocato accessi API, proteggendo 53 vittime confermate in 42 paesi più 20 sospetti, soprattutto in telecom e governi. È un promemoria per le imprese: la sicurezza del cloud non è solo patching e WAF, è anche governance e osservabilità sull’uso delle API, perché l’abuso “pulito” è spesso più difficile da distinguere dal traffico normale.

Firefly: sincronizzazione sub-10 ns come infrastruttura invisibile per log, RPC e ML deterministico

Un altro tassello che sembra tecnico ma ha conseguenze di sistema è Firefly, protocollo che raggiunge sincronizzazione sub-10 nanosecondi NIC-to-NIC su hardware commodity. In un data center, la capacità di sincronizzare clock con jitter e asimmetrie gestite da un modello a layered consensus permette timestamping preciso per pacchetti, log e RPC, e abilita workload ML più deterministici. Firefly supera requisiti regolatori come i 100 microsecondi per mercati finanziari, ma il valore va oltre l’high-frequency trading: telemetria fine-grained, debugging distribuito, auditing di eventi e ricostruzione causale di incidenti diventano più affidabili quando il tempo non è più una variabile rumorosa.

Nano Banana 2 in Vertex AI: immagini enterprise con provenienza e credenziali

Nel perimetro Vertex AI arriva Nano Banana 2 in preview, con la promessa di qualità Pro a velocità Flash e funzioni come rendering testo preciso, upscaling 4K, aspect ratio multipli e consistenza narrativa fino a cinque personaggi e 14 oggetti. Il dettaglio rilevante per l’enterprise non è la creatività, è la trasparenza: SynthID e C2PA Content Credentials come meccanismi per rendere la provenienza tracciabile in contesti dove la generazione immagini deve convivere con policy legali, brand safety e auditing. Insieme, questi rilasci raccontano un febbraio 2026 in cui Google Cloud spinge su due fronti contemporaneamente. Da un lato rende più solide le fondamenta di architetture moderne, separando governance e logica con Eventarc Advanced, centralizzando e “curando” le API con Apigee API Hub, e riducendo i trade-off tra transazionale e analitico con Spanner Columnar. Dall’altro, costruisce un percorso di maturità per gli AI agents, con memoria ingegnerizzata, valutazione continua, osservabilità e rollout controllati, mentre la sicurezza viene trattata come disciplina che parte dai fundamentals e arriva a modelli e agenti senza perdere il controllo del perimetro dati.