Google Cloud sta impostando la propria strategia per l’intelligenza artificiale aziendale senza subordinare l’utilizzo della piattaforma all’adozione esclusiva dei modelli Gemini. L’obiettivo consiste nel diventare l’infrastruttura sulla quale le imprese sviluppano ed eseguono applicazioni AI, indipendentemente dal modello, dall’assistente di programmazione o dall’ambiente utilizzato durante la fase di sviluppo.
Questa impostazione risponde alla crescente volatilità del mercato dei modelli generativi. Le prestazioni delle diverse famiglie cambiano rapidamente, i prezzi dell’inferenza vengono aggiornati con frequenza e un modello particolarmente efficace in un determinato compito può risultare meno conveniente o meno preciso in un altro. Per Google Cloud, la selezione deve quindi avvenire in funzione del carico di lavoro, senza trasformarsi in una scelta permanente basata sulla fedeltà a un singolo fornitore.
Richard Seroter, Senior Director e Chief Evangelist di Google Cloud, ha descritto l’attuale livello di fedeltà degli sviluppatori agli strumenti AI come praticamente nullo. Chi programma può passare rapidamente da Gemini CLI a Claude Code, Cursor, GitHub Copilot o altri ambienti quando uno di questi offre risultati migliori, una latenza inferiore o un flusso operativo più efficace. Google non intende contrastare questa mobilità imponendo l’utilizzo dei propri strumenti, ma vuole rendere Google Cloud il luogo più efficiente nel quale eseguire il software generato attraverso qualsiasi assistente.
La strategia separa quindi il livello degli strumenti di sviluppo da quello dell’infrastruttura. Un programmatore può utilizzare Claude Code per analizzare un repository, scrivere funzioni o correggere errori e distribuire successivamente l’applicazione su Cloud Run, Google Kubernetes Engine o altri servizi della piattaforma. Allo stesso modo, un sistema aziendale può utilizzare modelli Anthropic attraverso Vertex AI senza dover trasferire dati, identità, controlli di sicurezza e processi di fatturazione verso un’infrastruttura separata.
Google sostiene che l’esecuzione dei modelli Claude attraverso Vertex AI possa offrire prestazioni di latenza superiori rispetto all’accesso tramite Azure, AWS o la stessa infrastruttura diretta di Anthropic. La presenza di Claude sulla piattaforma non viene quindi trattata come un’alternativa tollerata a Gemini, ma come una componente dell’offerta destinata a rendere Vertex AI competitivo anche quando il cliente preferisce un modello sviluppato da un’altra società.
Vertex AI assume in questo schema il ruolo di livello unificato per l’accesso ai modelli, la personalizzazione, la valutazione, il deployment e la gestione delle applicazioni generative. Il catalogo Model Garden comprende modelli proprietari di Google, soluzioni sviluppate da partner e modelli open-weight, permettendo alle organizzazioni di confrontare alternative differenti senza ricostruire da zero l’intera infrastruttura applicativa.
Il valore della piattaforma non viene fatto dipendere esclusivamente dalla qualità di Gemini. Google Cloud punta sulla capacità di offrire calcolo, acceleratori, gestione dei dati, identità, sicurezza, osservabilità e servizi di distribuzione all’interno dello stesso ambiente. Il cliente può sostituire il modello mantenendo invariati molti degli elementi che circondano l’applicazione, compresi i database, le pipeline, le autorizzazioni, i sistemi di monitoraggio e le procedure operative.
Questo approccio diventa particolarmente importante con l’aumento dei costi legati all’intelligenza artificiale. Nelle prime sperimentazioni le aziende potevano scegliere un modello principalmente in base alla qualità percepita delle risposte, perché il numero delle richieste rimaneva limitato. Il passaggio alla produzione introduce invece volumi elevati, catene agentiche composte da numerose chiamate e processi che possono consumare grandi quantità di token per completare una singola operazione.
Quando un agente utilizza un modello per pianificare un’attività, interrogare fonti, richiamare strumenti, controllare i risultati e correggere eventuali errori, il costo finale non coincide con quello di una sola risposta. La differenza di prezzo tra modelli apparentemente simili può quindi incidere in modo significativo sul costo complessivo del servizio. Le imprese devono scegliere di volta in volta tra modelli più potenti e costosi, versioni rapide ed economiche oppure sistemi specializzati per un determinato tipo di attività.
La maturazione dell’adozione aziendale sta portando anche a una maggiore attenzione verso la possibilità di sostituire rapidamente un modello. Le organizzazioni non vogliono costruire applicazioni rigidamente dipendenti da un’unica API, perché un cambiamento nei prezzi, nelle prestazioni, nei limiti di utilizzo o nelle condizioni commerciali potrebbe rendere necessario migrare verso una soluzione differente. Google Cloud cerca di intercettare questa esigenza attraverso un’infrastruttura nella quale il modello rappresenta una componente sostituibile del sistema.
L’apertura si estende agli agenti e ai protocolli attraverso i quali questi sistemi utilizzano servizi esterni. Google sta integrando server compatibili con Model Context Protocol, istruzioni, skill e strumenti che consentono agli assistenti di programmazione di interagire direttamente con le risorse cloud. Un agente può quindi ricevere informazioni sulle modalità corrette di configurazione di un servizio, generare il codice necessario al deployment, controllare lo stato dell’applicazione e intervenire sugli errori senza dipendere esclusivamente da Gemini.
La presenza di interfacce standardizzate permette a Google Cloud di essere utilizzato anche da agenti sviluppati da altre società. Un assistente esterno può accedere alle funzioni della piattaforma attraverso strumenti documentati e controllati, mentre l’organizzazione conserva i meccanismi di autenticazione, autorizzazione e governance già adottati. L’interoperabilità diventa in questo modo un elemento commerciale della piattaforma, oltre che una caratteristica tecnica.
Google continua comunque a investire nei propri strumenti per sviluppatori e intende competere direttamente nel settore della programmazione assistita. Gemini CLI, Gemini Code Assist, gli ambienti agentici e le integrazioni nei servizi cloud devono offrire un’esperienza capace di confrontarsi con Claude Code, Cursor e GitHub Copilot. L’apertura verso i prodotti concorrenti non corrisponde quindi a un ridimensionamento di Gemini, ma alla scelta di non far dipendere il successo di Google Cloud dalla vittoria di un singolo strumento.
La società considera Google Cloud una piattaforma unitaria piuttosto che un portafoglio composto da centinaia di prodotti indipendenti. Servizi come Compute Engine, Cloud Run, GKE, BigQuery, Vertex AI, i database gestiti e gli strumenti di sicurezza dovrebbero funzionare come parti coordinate dello stesso ambiente, evitando che il cliente debba assemblare manualmente una successione di componenti isolate.
Questa definizione distingue la strategia di Google da quella attribuita ad altri grandi fornitori cloud, nei quali il catalogo può apparire come una raccolta molto ampia di servizi acquistabili separatamente. Google vuole presentare la propria infrastruttura come un sistema integrato nel quale dati, modelli, agenti e applicazioni condividono identità, sicurezza e strumenti operativi.
La piattaforma deve inoltre mantenere un equilibrio tra rapidità di sviluppo e affidabilità. Le critiche rivolte a Google riguardano spesso una velocità di rilascio inferiore rispetto alle startup specializzate negli strumenti AI e le restrizioni applicate internamente all’utilizzo di alcuni prodotti esterni. Seroter ha collegato questa prudenza alla responsabilità di gestire servizi utilizzati su scala globale, sostenendo che Google non può operare come una società il cui unico prodotto è un chatbot.
Servizi come Search, Maps, Workspace, Android e l’infrastruttura cloud richiedono controlli di sicurezza, stabilità e compatibilità che rendono più complesso introdurre rapidamente nuove funzioni. Il ritmo di sviluppo deve quindi essere accompagnato da una direzione tecnica precisa, perché la velocità priva di un obiettivo e di adeguate verifiche non produce un’infrastruttura affidabile.
Per le imprese, la conseguenza pratica è la possibilità di costruire architetture multimodello. Gemini può essere utilizzato per un’attività di ragionamento o per l’elaborazione multimodale, Claude per la programmazione e l’analisi di documenti complessi, mentre un modello open-weight più piccolo può gestire richieste ripetitive a basso costo. L’orchestrazione può scegliere automaticamente il sistema più adatto in base al prezzo, alla latenza, alla sensibilità dei dati e alla qualità richiesta.
Questa configurazione riduce la dipendenza da un singolo produttore, ma non elimina completamente il rischio di lock-in. Anche quando i modelli sono intercambiabili, l’applicazione può rimanere legata ai servizi di gestione, ai database, alle procedure di autenticazione, agli strumenti di osservabilità e alle API specifiche della piattaforma cloud. La strategia di Google sposta quindi il punto di permanenza del cliente dal modello all’infrastruttura che lo circonda.
Il vantaggio per Google consiste nel poter acquisire carichi di lavoro anche quando Gemini non rappresenta la prima scelta del cliente. Un’impresa che preferisce Claude, un modello open source oppure una combinazione di sistemi può comunque utilizzare Vertex AI, le TPU e le GPU di Google, BigQuery, Cloud Run, GKE e gli altri servizi collegati. Il fatturato della piattaforma non dipende necessariamente dal modello che genera ogni singolo token.
Google Cloud punta quindi a vincere la competizione sull’intelligenza artificiale offrendo alle imprese libertà di scelta nel livello più visibile dell’applicazione, quello dei modelli e degli assistenti, e consolidando contemporaneamente il proprio ruolo nei livelli sottostanti. Calcolo, dati, sicurezza, deployment e gestione degli agenti diventano il nucleo della relazione con il cliente, mentre Gemini rimane una componente strategica ma non obbligatoria dell’architettura.