Yury Pukhov, YuSMP Group
Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group · Consulenza a team americani ed europei su strategia prodotto e build-vs-buy
Illustrazione isometrica di una grande griglia di rack server blu luminosi a piena capacità con intensi flussi di luce che entrano da sinistra e un indicatore circolare quasi pieno che brilla a destra, su uno sfondo blu notte

La risposta breve

Il 22 luglio 2026 Google Cloud ha registrato una crescita dell'82% a 24,8 miliardi di dollari e un backlog contrattuale da 514 miliardi di dollari — e ha comunicato agli investitori di non riuscire a costruire capacità abbastanza velocemente per soddisfare la domanda. Il CEO Thomas Kurian ha dichiarato che i clienti spendono circa il 50% in più rispetto a quanto impegnato, e che Google affitterà capacità da fornitori terzi per qualche trimestre per supportarli finché i propri data center non raggiungono la domanda. Alphabet ha alzato le spese in conto capitale 2026 fino a 205 miliardi di dollari, e le sue azioni sono comunque scese di circa il 7% per i timori che il conto continui a salire.

Per i team che acquistano cloud, il segnale è che il vincolo determinante si è spostato dal budget alla capacità fisica. L'effetto a breve termine è tempi di attesa più lunghi e meno margine negoziale sugli acceleratori più recenti; la risposta duratura è trattare la pianificazione della capacità e la portabilità come lavoro di ingegneria di primo livello, non come burocrazia di approvvigionamento.

Cosa ha effettivamente comunicato Alphabet?

Un business cloud che cresce molto più rapidamente del previsto, con una domanda che non riesce apertamente a soddisfare completamente. Nei risultati Q2 2026, Alphabet ha dichiarato che i ricavi di Google Cloud sono aumentati dell'82% su base annua a 24,8 miliardi di dollari, rispetto ai 13,6 miliardi dell'anno precedente e comodamente al di sopra delle stime degli analisti vicine ai 22,4 miliardi. Questo pone il segmento su un tasso di run-rate annualizzato di circa 99 miliardi. I ricavi totali di Alphabet sono stati 119,8 miliardi di dollari, in aumento del 24% per il trimestre concluso il 30 giugno 2026.

Il numero che ridefinisce la storia è il backlog. I ricavi contrattualmente impegnati ma non ancora riconosciuti di Google Cloud — contratti firmati ancora da consegnare — hanno raggiunto 514 miliardi di dollari, rispetto ai circa 460 miliardi del trimestre precedente. Ciò corrisponde a diverse volte il run-rate annuale attuale, il che significa che una grande quota della spesa cloud aziendale e IA per gli anni a venire è già impegnata nello stack Google. Per i team che pianificano la propria capacità cloud e DevOps, un backlog di quella dimensione non è solo un argomento per gli investitori: descrive chi sta in coda davanti a voi per le stesse GPU scarse.

Gli investitori non hanno festeggiato. Alphabet ha alzato la sua guidance sulle spese in conto capitale 2026 a 195-205 miliardi di dollari, rispetto ai 180-190 miliardi del trimestre precedente, e le azioni sono scese di circa il 7% poiché il mercato si interrogava sulla sostenibilità dell'investimento nell'IA. Il sottotesto di quella reazione conta per chi acquista: il fornitore sta investendo denaro in capacità proprio perché ne è a corto.

Perché un backlog da 514 Mrd. $ è una storia di capacità, non solo di crescita?

Perché il collo di bottiglia si è spostato dalla domanda all'offerta. Per la maggior parte dell'era cloud il compito del provider era vincere il contratto; servirlo era dato per scontato. Ciò che Kurian ha descritto nella call sui risultati è il problema opposto: i clienti si sono iscritti per una cosa, hanno scoperto di aver bisogno di molta più infrastruttura IA di quanto pianificato, e stanno ora spendendo circa il 50% in più rispetto agli importi impegnati. Quando l'utilizzo supera gli impegni su un portafoglio da 500 miliardi di dollari, il vincolo non è più la vendita — sono i data center, l'energia e gli acceleratori.

La prova più evidente è ciò che Google ha deciso di fare al riguardo. Invece di lasciare che la carenza limitasse la crescita, l'azienda ha dichiarato che noleggerà capacità da fornitori terzi per qualche trimestre per onboardare i clienti e supportarli finché la propria capacità sarà disponibile. Un hyperscaler che noleggia la capacità di qualcun altro è un'ammissione insolita: significa che la fornitura interna è genuinamente indietro rispetto alla domanda contrattuale, non semplicemente tesa. L'aumento della guidance sul capex è la soluzione pluriennale; i noleggi da terze parti sono il rimedio temporaneo mentre il cemento fa presa.

Nulla di tutto ciò è esclusivo di Google. Lo stesso schema — backlog record, capex in accelerazione e la fornitura di acceleratori come fattore limitante — è visibile tra i più grandi vendor cloud e IA in questo ciclo. Ecco perché questo è un segnale di mercato piuttosto che una peculiarità aziendale: la risorsa scarsa per l'intero settore in questo momento è la capacità, e chi pianifica per la scarsità supererà chi presume abbondanza.

Cosa significa la crisi per i team che acquistano cloud?

Principalmente leva persa e tempi di attesa aumentati — nella direzione sbagliata. Quando la domanda contrattuale supera l'offerta, i provider allocano le risorse scarse, in particolare le GPU e la capacità degli acceleratori più recenti in regioni specifiche, prima ai clienti più grandi con impegni maggiori. Per un team di medie dimensioni ciò può tradursi in tempi di attesa più lunghi sulle istanze riservate, limiti di quota sugli acceleratori più recenti e notevolmente meno margine per negoziare sconti rispetto a un anno fa. I prezzi a listino on-demand raramente salgono dall'oggi al domani, ma la disponibilità pratica dietro quei prezzi si restringe.

Il cambiamento strategico è che la pianificazione della capacità protegge ora la roadmap più della ricerca del miglior prezzo. Una tariffa oraria più bassa vale poco se la capacità di cui avete bisogno non è disponibile nella regione che vi serve, quando vi serve. Questo riordina le domande che un team dovrebbe porre a un fornitore: non solo "quanto costa?" ma "potete impegnarvi su questa capacità in questa regione in questa data, e cosa succede ai nostri workload se non potete?" Ottenere quelle risposte per iscritto è ora parte della due diligence, non un caso limite.

Aumenta anche il valore della portabilità. Se la vostra piattaforma IA, ML e dati può girare solo sui servizi proprietari di un provider, ereditate i vincoli di capacità di quel provider senza alternative. I team che mantengono i workload debolmente accoppiati — formati di dati portabili, infrastruttura-as-code, runtime di inferenza che possono puntare a più di un backend — possono aggirare una carenza regionale o usare un secondo provider come leva. Quella flessibilità vale la pena costruirla prima che la crisi forzi la decisione, non durante.

Cosa significa per i team italiani ed europei

Per i team statunitensi il titolo è la disciplina di pianificazione. L'era in cui la capacità cloud veniva trattata come un'utilità infinita e sempre disponibile si mette in pausa per i workload che richiedono acceleratori scarsi. Ciò non significa accaparrare prenotazioni che non userete — l'eccessivo impegno in un mercato in rapida evoluzione è di per sé una trappola — ma significa prevedere la domanda di acceleratori con qualche trimestre di anticipo, assicurarsi capacità riservata per i workload certi e mantenere un fallback documentato per quelli incerti. I team che vincono qui sono quelli che fanno della capacità un input della roadmap, non un'affannosa ricerca dell'ultimo momento.

I team europei affrontano la crisi su due assi contemporaneamente: capacità e compliance. La scarsa capacità degli acceleratori non è distribuita uniformemente tra le regioni, quindi la regione europea che soddisfa i vostri requisiti di residenza dei dati potrebbe essere esattamente quella con vincoli di capacità — e un provider che colma la domanda con capacità di terze parti noleggiate può cambiare dove i workload vengono fisicamente eseguiti. Ciò rende essenziale trattare la residenza dei dati e il logging come vincoli rigidi in ogni decisione di capacità, e verificare dove viene effettivamente eseguito il calcolo rispetto al GDPR e all'AI Act dell'UE piuttosto che presumere che venga gestito. In particolare nel lavoro regolamentato di FinTech e sanitario, una soluzione alternativa di capacità che sposta silenziosamente l'elaborazione verso una giurisdizione errata è un incidente di compliance, non una convenienza.

Prospettiva mercato Italia: In Italia, la carenza di capacità cloud si inserisce in un contesto di forte accelerazione digitale guidata dal Piano Nazionale di Ripresa e Resilienza (PNRR), che ha stanziato oltre 6 miliardi di euro per la migrazione cloud della Pubblica Amministrazione verso il Polo Strategico Nazionale (PSN) e i cloud qualificati da ACN (Agenzia per la Cybersicurezza Nazionale). Le organizzazioni italiane che operano con dati della PA o in settori regolamentati (bancario, assicurativo, sanità) sono tenute a verificare che i fornitori cloud rispettino le Misure minime di sicurezza ICT di AgID e le indicazioni del Garante della Privacy. Se Google Cloud ricorre a capacità di terze parti per colmare il divario, è essenziale verificare contrattualmente che il trattamento rimanga nella regione europe-west8 (Milano) e che non si producano trasferimenti extra-UE non conformi al GDPR. Le aziende italiane farebbero bene a richiedere impegni scritti sulla residenza dei dati e a testare scenari di fallback prima che l'eventuale vincolo di capacità le costringa a farlo in emergenza.

La lezione duratura si colloca al di sopra di qualsiasi singolo comunicato trimestrale. I prezzi cloud, la capacità e la disponibilità regionale continueranno a cambiare mentre l'investimento nell'IA fa il suo corso; i team che restano resilienti sono quelli la cui architettura tratta la capacità come un input pianificato e sostituibile piuttosto che come un presupposto. Costruire questa disciplina è poco entusiasmante — previsioni, prenotazioni, portabilità, un fallback testato — e ripaga ogni volta che il mercato si irrigidisce come ha appena fatto.

Come pianificare in un contesto di capacità limitata

Trattate questo come uno spunto per pianificare deliberatamente la capacità, non per acquistare prenotazioni in preda al panico. Ecco la versione operativa.

  1. Prevedete la domanda di acceleratori. Proiettate le esigenze di GPU e acceleratori con qualche trimestre di anticipo per workload, e separate la domanda certa da quella speculativa.
  2. Prenotate per ciò che è certo. Assicuratevi capacità riservata o impegnata nelle regioni specifiche di cui avete bisogno per i workload certi; lasciate flessibilità on-demand per gli altri.
  3. Ottenete impegni di capacità per iscritto. Chiedete ai provider capacità specifica per regione e tempi di consegna, non solo il prezzo, e documentate cosa succede se la capacità slitta.
  4. Mantenete i workload portabili. Usate infrastruttura-as-code, formati di dati portabili e runtime che possano puntare a più di un provider, in modo che una carenza sia un reroutamento, non una ricostruzione.
  5. Fissate la residenza come vincolo rigido. Rendete la residenza dei dati e il logging input non negoziabili in ogni decisione di capacità, e verificate dove viene eseguito il calcolo rispetto al GDPR e all'AI Act dell'UE.
  6. Testate il fallback. Avete un'opzione documentata di secondo livello per i workload critici e esercitata realmente, in modo che "possiamo spostarci" sia una capacità provata, non una speranza.

Usato bene, un mercato con capacità limitata premia i disciplinati: prevedete, prenotate, restate portabili e trattate la residenza come un vincolo piuttosto che come un ripensamento. Usato con superficialità, trasforma un titolo sul backlog di qualcun altro nel vostro lancio bloccato. La differenza sta nella pianificazione che fate prima che la capacità di cui avete bisogno sia la capacità che vuole chiunque altro.

Domande frequenti

Cosa ha comunicato Alphabet su Google Cloud il 22 luglio 2026?

I ricavi di Google Cloud sono aumentati dell'82% su base annua a 24,8 miliardi di dollari, rispetto ai 13,6 miliardi, superando le stime vicine ai 22,4 miliardi, e il backlog contrattuale ha raggiunto 514 miliardi di dollari, rispetto ai circa 460 miliardi del trimestre precedente. I ricavi totali di Alphabet sono stati 119,8 miliardi di dollari, in aumento del 24%. L'azienda ha alzato la guidance sul capex 2026 a 195-205 miliardi di dollari, e le sue azioni sono scese di circa il 7% per i timori sulle spese per l'IA.

Cosa intendeva Thomas Kurian con "la domanda supera la capacità"?

Kurian ha affermato che i clienti spendono circa il 50% in più rispetto a quanto impegnato, perché avevano bisogno di molta più infrastruttura IA di quanto pianificato. La domanda è così forte che Google affitterà capacità da fornitori terzi per qualche trimestre per onboardare i clienti e supportarli finché la propria capacità raggiunge la domanda. La domanda contrattuale sta superando la capacità fisica disponibile per soddisfarla.

Come influisce la crisi su prezzi e disponibilità del cloud?

La scarsa capacità GPU e degli acceleratori in regioni specifiche viene assegnata prima ai clienti più grandi con impegni maggiori, quindi i team più piccoli possono riscontrare tempi di attesa più lunghi, limiti di quota sugli acceleratori più recenti e meno margine negoziale. I prezzi a listino on-demand raramente salgono dall'oggi al domani, ma la disponibilità si restringe — rendendo la pianificazione della capacità, non la ricerca del miglior prezzo, ciò che protegge davvero la roadmap.

I team dovrebbero passare al multi-cloud per questo motivo?

Non in modo riflesso. Il multi-cloud aggiunge costi e complessità, quindi vale la pena quando porta qualcosa di specifico: accesso a capacità scarsa in una regione, resilienza o leva negoziale. L'approccio predefinito migliore è la portabilità — mantenere workload, formati di dati e infrastruttura-as-code debolmente accoppiati — in modo che aggiungere o cambiare provider sia un progetto pianificato, non una ricostruzione d'emergenza.

Cosa significa la crisi specificamente per i team europei?

I team europei affrontano capacità e compliance insieme. La scarsa capacità degli acceleratori è disomogenea tra le regioni, quindi la regione che soddisfa GDPR e residenza dei dati potrebbe essere quella con vincoli di capacità, e il noleggio di capacità di terze parti può cambiare dove vengono eseguiti i workload. Fissate residenza dei dati e logging come vincoli rigidi in ogni decisione di capacità, e verificate dove viene eseguito il calcolo rispetto al GDPR e all'AI Act dell'UE.

Fonti

CNBC — Google Cloud CEO Kurian says customers are spending 50% more as segment blows away expectations, 23 luglio 2026
CNBC — Alphabet earnings: Q2 revenue beats, GOOGL sinks on 2026 capex hike, 22 luglio 2026
Alphabet Investor Relations — Risultati Q2 2026 (fonte primaria)