Google Cloud Next 2026: 200 Miliardi di Capex Non Comprano Maturità di Produzione

L'articolo di Alex Scroxton su Computer Weekly su Google Cloud Next 2026 atterra sulla preoccupazione giusta — l'industria produce troppo slop di IA e poco valore — ma si ferma un piano prima di dove vorrei avere la conversazione. Da ingegnere DevOps che deve realmente mettere questi stack in produzione a scala enterprise, il mio problema con Cloud Next non è il DJ set con Gemini. È la distanza tra la keynote e il runbook.

Thomas Kurian ha aperto l'evento con una frase che dovrebbe far sbattere le palpebre a qualsiasi SRE: "Avete superato il pilota, la fase sperimentale è alle spalle." Lo sostiene un numero reale — tre quarti dei clienti Google Cloud usano già l'IA di Google in qualche forma — e un assegno reale: circa 200 miliardi di dollari di capex impegnati in infrastruttura IA. Silicio nuovo (TPU 8i per inferenza, TPU 8t per training). Il Gemini Agent Platform presentato formalmente. Il caso Capcom: un workbench multi-agente che gira 30.000 ore umane al mese di lavoro. Citi Sky, un consulente patrimoniale bilingue costruito sull'intero stack IA di Google.

Questo è il pacchetto marketing. Il pacchetto tecnico, quello che nessuno al Moscone aveva voglia di discutere sul palco principale, è il conto operativo che arriva insieme alle parole "in produzione".

La critica dello slop ha ragione, ma non è il problema portante

La preoccupazione centrale di Scroxton è creativa: musica generata da IA, arte generata da IA, il costo culturale di sostituire umani con mediocrità statistica. È giusta, e la condivido in buona parte a livello personale. Ma da dove sono io, lo slop è a valle di una decisione più pericolosa: mettere workload IA in ambienti di produzione condivisi senza la maturità operativa che quegli ambienti esigono.

Lo slop diluisce una playlist Spotify. Una IA cattiva in produzione dentro una banca diluisce l'audit trail. La prima cosa è fastidiosa. La seconda è un invito aperto al regolatore.

L'inquadratura hype-versus-realtà che sceglie Computer Weekly è quella artistica. Io voglio insistere su quella ingegneristica, perché è lì che spunteranno i corpi.

"Oltre il pilota" non è un vibe. È una disciplina.

Quando Kurian dice che la fase sperimentale è alle spalle, la traduzione onesta è: molti clienti hanno un notebook Vertex AI, una chiave API Gemini e almeno un feature flag che punta traffico reale a un modello. Non è la stessa cosa di "in produzione" nel senso in cui un team pagamenti o un team SRE usa il termine.

Per mettere un modello in produzione, nel senso che difenderei davanti a un board o a un regolatore, come minimo serve:

• Osservabilità che capisca il workload. Latenza p99 per modello e per rotta. Costo dei token per request. Cache hit rate. Eval drift su un benchmark congelato. Niente di tutto questo arriva "gratis" con un deploy di Gemini Agent Platform. Te lo costruisci.
• Attribuzione di costo fino al team. Se tre pod condividono un endpoint di inferenza, chi paga quale picco? Con 200 Mld$ di capex a monte, la bolletta cloud smette di essere una nota a piè di pagina della finanza e diventa una preoccupazione primaria di ingegneria.
• Risposta agli incidenti che sappia di sistemi non deterministici. Un modello corretto ieri e sbagliato oggi non è un bug di deploy. È una regressione di comportamento senza un punto chiaro di rollback. Il runbook deve rifletterlo.
• Governance che sopravviva a un audit. Lineage di quale template di prompt ha prodotto quale decisione, contro quale versione di modello, con quale contesto di retrieval. Se non puoi rispondere a questo sotto deposizione, non hai un sistema di produzione. Hai una demo con traffico.

Nessuno di questi punti è stato titolo a Cloud Next. Sono stati dati per scontati. Questo è il buco.

Il numero di Capcom, letto da SRE

Il workbench di Capcom è genuinamente impressionante: un agente di ispezione visiva su Gemini Vision, un agente predittivo su dati storici, un agente di sapere istituzionale, un agente di efficienza dati. Risultato, secondo la keynote, "30.000 ore umane al mese".

Leggilo da ingegnere DevOps, non da CMO.

Trentamila ore al mese significano circa 170 FTE equivalenti di lavoro di agenti che girano in continuo contro dati di produzione. Le domande a cui vorrei risposta prima di firmare:

• Qual è l'SLO di ogni agente? Non l'SLA del fornitore del LLM. L'SLO composto end-to-end, incluso retrieval, post-processamento e il loop di revisione umana.
• Qual è il failure mode quando l'agente predittivo sbaglia silenziosamente per una settimana? Le predizioni non crashano. Driftano. Hai un eval offline che gira contro un golden set congelato, e un allarme quando le uscite dell'agente divergono di più di un X%?
• Chi è di reperibilità sullo stack di agenti? Se l'agente di efficienza del pod A sta affamando l'indice di retrieval del pod B di cache, chi pagina chi? "Il team di piattaforma" funziona solo se esiste e ha autorità.
• Qual è il percorso di rollback? I modelli sono versionati, ma i template di prompt, gli indici di retrieval e le definizioni di tool normalmente no. Un cambio cattivo in uno di questi tre può degradare la qualità senza scattare un singolo allarme di deploy classico.

Niente di esotico. È la noiosa checklist SRE che ha fatto la differenza tra "usiamo l'IA" e "l'IA funziona per noi" da due anni. Il tono della keynote — la fase sperimentale è alle spalle — rischia di spingere i clienti nel primo quadrante saltando il secondo.

Lo stack dell'Agent Platform: più strati, stesso on-call

Il Gemini Agent Platform sta sopra Vertex AI che sta sopra TPU che sta sopra la nuova generazione 8i/8t. Dalla prospettiva di un compratore sembra una storia integrata. Dalla prospettiva DevOps sembra quattro strati in più nel grafo delle dipendenze, ognuno con il suo proprio failure mode, il suo proprio sistema di quote, la sua propria curva di prezzo e la sua propria console dove un incidente si può nascondere.

Combinalo con la realtà autenticamente multi-cloud della maggior parte delle aziende e esce uno schema familiare: un Gemini Agent che si integra con workload su AWS, dati in Snowflake, auth in Okta, osservabilità divisa tra Datadog e un Grafana self-hosted. La slide pulita di Moscone nasconde una matassa.

Due conseguenze a cui starei attento da CTO in questo momento:

1. Il vendor lock-in non è più una questione di procurement, è una questione operativa. Una volta che i tuoi template di prompt, suite di eval e orchestrazione di agenti vivono dentro la piattaforma di un vendor, il costo di migrazione smette di misurarsi in licenze e passa a misurarsi in mesi di lavoro SRE.
2. Gli impegni di capex sono scommesse che fai per conto di qualcun altro. Quando un hyperscaler annuncia 200 Mld$ di capex, la promessa implicita è che i prezzi restano favorevoli mentre sale il carico. Il rischio implicito è che, tre anni dopo, l'economia unitaria forzi un reset di prezzi che atterra direttamente sulla roadmap del tuo team di piattaforma.

Nessuna delle due cose è apocalittica. Tutte e due sono il tipo di rischio che metti dentro un piano di piattaforma a tre anni quando lo scrivi onestamente.

Citi Sky e la parte dell'annuncio che effettivamente sostengo

Il caso che alzerei contro la critica dello slop è Citi Sky. Un consulente patrimoniale bilingue, costruito sullo stack IA di Google, esplicitamente inquadrato come aumento dei consulenti umani, non come sostituzione. Questo inquadramento è quello che ripeto in ogni post di questo blog: l'IA è implementabile e di valore quando amplia ciò che un esperto può fare per ora, non quando cerca di sostituire l'esperto.

Citi Sky lascia anche un segnale più silenzioso che vale la pena raccogliere: un'istituzione finanziaria regolata non scommette un prodotto di consulenza patrimoniale sull'IA senza controlli seri sotto. Qualunque cosa la keynote mostri, il team dietro ha data lineage, logging di decisioni, revisione model-risk-management e un pattern human-in-the-loop difendibile davanti all'OCC. Quella è la parte dell'iceberg che il congresso non mette in slide.

Se la tua iniziativa IA non ha un iceberg equivalente, non hai un Citi Sky. Hai un chatbot con un brand.

Cosa vorrei vedere alla keynote dell'anno prossimo

Se Google Cloud Next 2027 vuole convincere le persone che effettivamente tengono in piedi questi sistemi, ecco cosa metterei sul palco principale al posto di un DJ Gemini:

1. Pattern di produzione per sistemi agentici con SLO nominati. Non "giriamo 30.000 ore al mese". Fammi vedere la latenza p99, le bande di eval drift e il tasso di revisione umana, e dimmi quali numeri non sono negoziabili.
2. Una storia di cost-attribution di prima classe. Per team, per agente, per rotta. Con primitive di chargeback dentro la piattaforma stessa, non incollate sopra da ogni cliente.
3. Failure mode onesti per l'Agent Platform. Cosa succede quando il retrieval è stale? Quando le chiamate ai tool entrano in loop? Quando un'API a valle rate-limita un agente a metà di una conversazione?
4. Un modello operativo di riferimento per i team di piattaforma. Dimensionamento, rotazione di reperibilità, separazione tra ingegneri di prodotto di agenti e ingegneri di piattaforma. Il pitch di Coinbase dei solo operator puri è un estremo; l'assunzione non detta che l'hyperscaler assorbirà la complessità operativa per te è l'altro. Entrambi sono sbagliati.
5. Una conversazione adulta sugli eval. Come ha mostrato il paper di ActionNex di Microsoft per gli AIOps, lo stato dell'arte sugli incidenti reali è intorno al 53% di recall. Non è un numero che metti dietro un consulente patrimoniale senza uno strato di revisione umana molto spesso. Il tono della keynote dovrebbe rifletterlo, non truccarlo.

La linea che traccio

Scroxton ha ragione che l'industria produce troppo slop. Ma lo slop è un problema di economia creativa. Il problema di infrastruttura — ed è quello con cui io devo convivere — è che "in produzione" è stato ridefinito silenziosamente come "chiamando un LLM da una request path che già serve utenti." Non sono la stessa cosa. La prima richiede SLO, osservabilità, cost-attribution, governance e risposta agli incidenti pensati per sistemi non deterministici. La seconda richiede una chiave API.

Duecento miliardi di dollari di capex comprano molti TPU. Non comprano un team di piattaforma. Non comprano un runbook. Non comprano la maturità operativa che decide se l'IA del tuo stack è un moltiplicatore di produttività o un incidente latente in attesa del suo primo venerdì brutto.

Le aziende che vinceranno i prossimi due anni di IA non saranno quelle che hanno adottato più veloce. Saranno quelle il cui team di piattaforma si è rifiutato di chiamare "produzione" qualcosa che non lo era ancora davvero.

---

Fonti:

• Alex Scroxton, Google Cloud Next: It's time to create value, not slop, from the AI boom, Computer Weekly, 23 aprile 2026. computerweekly.com
• Keynote di Google Cloud Next 2026, Thomas Kurian — cifre di adozione dei clienti, TPU 8i/8t, Gemini Agent Platform.
• Casi studio Capcom e Citi così come presentati a Google Cloud Next 2026.

Stai mettendo IA in produzione e non sei sicuro che la tua piattaforma regga il peso operativo? Parla con un CTO — ti aiutiamo a separare la keynote dal runbook.