Google Cloud Next 2026: 200.000 milions de dòlars en capex no compren maduresa de producció

L'article d'Alex Scroxton a Computer Weekly sobre Google Cloud Next 2026 posa el dit a la inquietud correcta — la indústria produeix massa slop d'IA i massa poc valor — però es queda un pis per sota d'on jo vull que passi la conversa. Com a enginyer de DevOps que ha de posar aquests stacks en producció a escala enterprise de debò, el meu problema amb Cloud Next no és la sessió de DJ amb Gemini. És la distància entre la keynote i el runbook.

Thomas Kurian va obrir l'esdeveniment amb una frase que hauria de fer venir esgarrifances a qualsevol SRE: «Heu anat més enllà del pilot, la fase experimental ha quedat enrere.» El sosté una xifra real — tres quartes parts dels clients de Google Cloud ja fan servir la IA de Google d'una manera o altra — i un xec real: uns 200.000 milions de dòlars de capex compromesos en infraestructura d'IA. Silici nou (TPU 8i per a inferència, TPU 8t per a entrenament). Una Gemini Agent Platform presentada formalment. El cas Capcom: un workbench multiagent que mou 30.000 hores humanes de feina al mes. Citi Sky, un assessor patrimonial bilingüe construït sobre tot l'stack d'IA de Google.

Aquest és el paquet de màrqueting. El paquet tècnic — el que ningú al Moscone tenia ganes de tocar a l'escenari principal — és la factura operativa que ve amb les paraules «en producció».

La crítica del slop és encertada, però el mur de càrrega és un altre

La preocupació central de Scroxton és creativa: música generada per IA, art generat per IA, el cost cultural de substituir humans per mediocritat estadística. És legítima, i personalment en comparteixo bona part. Però des de la meva trinxera, el slop és la conseqüència d'una decisió més perillosa: enviar workloads d'IA a entorns de producció compartits sense la maduresa operativa que aquests entorns exigeixen.

El slop dilueix una playlist de Spotify. Una IA mal posada en producció dins d'un banc dilueix l'audit trail. Una cosa és una molèstia. L'altra és estendre una catifa vermella al regulador.

L'enquadrament hype-contra-realitat que tria l'article de Computer Weekly és l'artístic. Jo vull insistir en el d'enginyeria, perquè és allà on apareixeran els cadàvers.

«Més enllà del pilot» no és un estat d'ànim. És una disciplina.

Quan Kurian diu que la fase experimental ha quedat enrere, la traducció honesta és aquesta: molts clients tenen un notebook a Vertex AI, una clau d'API de Gemini i com a mínim una feature flag que apunta trànsit real cap a un model. Això no és «en producció» tal com fa servir el terme un equip de pagaments o un equip d'SRE.

Per posar un model en producció — en el sentit que jo defensaria davant d'un consell d'administració o d'un regulador — necessites, com a mínim:

• Observabilitat que entengui el workload. Latència p99 per model i per ruta. Cost de tokens per petició. Cache hit rate. Eval drift sobre un benchmark congelat. Res d'això no ve «de regal» amb un desplegament de la Gemini Agent Platform: t'ho has de construir tu.
• Atribució de costos fins al nivell d'equip. Si tres pods comparteixen un endpoint d'inferència, qui paga cada pic? Amb 200.000 M$ de capex aigües amunt, la factura del cloud deixa de ser una nota a peu de pàgina de finances i es converteix en una preocupació d'enginyeria de primer ordre.
• Resposta a incidents que entengui els sistemes no deterministes. Un model que ahir encertava i avui s'equivoca no és un bug de deploy: és una regressió de comportament sense cap punt net on fer rollback. El runbook ho ha de reflectir.
• Governança que sobrevisqui una auditoria. Traçabilitat de quina plantilla de prompt va produir quina decisió, contra quina versió del model i amb quin context de retrieval. Si no pots respondre això declarant davant d'un jutge, no tens un sistema de producció. Tens una demo amb trànsit.

Cap d'aquestes coses no va ser titular a Cloud Next. Es van donar per fetes. Aquesta és la distància.

La xifra de Capcom, llegida amb ulls d'SRE

El workbench de Capcom és genuïnament impressionant: un agent d'inspecció visual sobre Gemini Vision, un agent predictiu sobre dades històriques, un agent de coneixement institucional, un agent que caça ineficiències de dades. El resultat, segons la keynote: «30.000 hores humanes cada mes».

Llegeix aquesta xifra com un enginyer de DevOps, no com un CMO.

Trenta mil hores al mes són aproximadament 170 equivalents a temps complet de feina d'agents girant contínuament contra dades de producció. Les preguntes que jo voldria veure respostes abans de signar-ho:

• Quin és l'SLO de cada agent? No l'SLA del proveïdor de l'LLM: l'SLO compost de punta a punta, incloent-hi el retrieval, el postprocessament i el bucle de revisió humana.
• Quin és el mode de fallada quan l'agent predictiu s'equivoca en silenci durant una setmana? Les prediccions no peten: deriven. Tens un eval offline corrent contra un golden set congelat, i una alerta per quan les sortides de l'agent divergeixin més d'un X%?
• Qui porta l'on-call de l'stack d'agents? Si l'agent d'ineficiències del pod A està deixant sense cache l'índex de retrieval del pod B, qui desperta qui? «L'equip de plataforma» només funciona si l'equip de plataforma existeix i té autoritat.
• Quin és el camí de rollback? Els models tenen versions, però les plantilles de prompts, els índexs de retrieval i les definicions d'eines normalment no en tenen. Un mal canvi en qualsevol d'aquests tres pot degradar la qualitat sense fer saltar ni una sola alarma de deploy clàssica.

Res d'això no és exòtic. És la checklist avorrida d'SRE que fa dos anys que marca la diferència entre «fem servir IA» i «la IA ens funciona». El to de la keynote — la fase experimental ha quedat enrere — corre el risc d'empènyer els clients cap al primer quadrant saltant-se el segon.

L'stack de l'Agent Platform: més capes, el mateix on-call

La Gemini Agent Platform va sobre Vertex AI, que va sobre TPU, que va sobre la nova generació 8i/8t. Vist des de la cadira del comprador, és una història integrada. Vist des de DevOps, són quatre capes més al graf de dependències, cadascuna amb el seu mode de fallada, el seu sistema de quotes, la seva corba de preus i la seva consola on un incident es pot amagar.

Suma-hi la realitat genuïnament multicloud de la majoria d'empreses i et surt un patró familiar: un Gemini Agent que s'integra amb workloads a AWS, dades a Snowflake, autenticació a Okta i observabilitat repartida entre Datadog i un Grafana autoallotjat. La diapositiva impecable del Moscone amaga una troca embolicada.

Dues conseqüències que jo, com a CTO, ara mateix vigilaria de prop:

1. El vendor lock-in ja no és una qüestió de compres: és una qüestió operativa. Quan les teves plantilles de prompts, les suites d'evals i l'orquestració d'agents viuen dins de la plataforma d'un sol proveïdor, el cost de migrar deixa de mesurar-se en llicències i passa a mesurar-se en mesos de feina d'SRE.
2. Els compromisos de capex són apostes que algú fa en nom teu. Quan un hyperscaler anuncia 200.000 M$ de capex, la promesa implícita és que els preus es mantindran favorables mentre la utilització s'enfila. El risc implícit és que, al cap de tres anys, els unit economics forcin un reajust de preus que aterri directament al roadmap del teu equip de plataforma.

Cap de les dues coses no és una catàstrofe. Totes dues són el tipus de risc que incorpores a un pla de plataforma a tres anys vista quan l'escrius amb honestedat.

Citi Sky i la part de l'anunci que sí que subscric

El cas que jo contraposaria a la crítica del slop és Citi Sky. Un assessor patrimonial bilingüe, construït sobre l'stack d'IA de Google i presentat explícitament com una eina que augmenta els assessors humans, no que els substitueix. Aquest enquadrament és el que repeteixo a cada post d'aquest blog: la IA és implantable i valuosa quan amplia el que un expert pot fer per hora, no quan intenta substituir-lo.

Citi Sky deixa anar també un senyal més discret que val la pena recollir: una institució financera regulada no juga un producte d'assessoria patrimonial a la carta de la IA sense controls seriosos a sota. Ensenyés el que ensenyés la keynote, l'equip que hi ha al darrere té traçabilitat de dades, registre de decisions, revisió de model-risk-management i un patró human-in-the-loop que pot defensar davant de l'OCC. Aquesta és la part de l'iceberg que el congrés no posa a la diapositiva.

Si la teva iniciativa d'IA no té un iceberg equivalent, no tens un Citi Sky. Tens un chatbot amb marca.

Què demanaria a la keynote de l'any que ve

Si Google Cloud Next 2027 vol convèncer la gent que de debò aguanta aquests sistemes en marxa, això és el que jo posaria a l'escenari principal en lloc d'un DJ amb Gemini:

1. Patrons de producció per a sistemes agèntics amb SLOs amb nom i cognoms. No «movem 30.000 hores al mes»: ensenya'm la latència p99, les bandes d'eval drift i la taxa de revisió humana, i digue'm quines xifres no són negociables.
2. Una història d'atribució de costos de primera classe. Per equip, per agent, per ruta. Amb primitives de chargeback dins de la mateixa plataforma, no apedaçades a sobre per cada client.
3. Modes de fallada honestos per a l'Agent Platform. Què passa quan el retrieval s'ha quedat antic? Quan les crides a eines entren en bucle? Quan una API aigües avall limita el ritme d'un agent a mitja conversa?
4. Un model operatiu de referència per a equips de plataforma. Dimensionament, rotació d'on-call, repartiment entre enginyers de producte d'agents i enginyers de plataforma. El discurs de Coinbase dels solo operators purs és un extrem; l'assumpció tàcita que el hyperscaler t'absorbirà la complexitat operativa és l'altre. Tots dos són un error.
5. Una conversa adulta sobre evals. Com va ensenyar el paper d'ActionNex de la mateixa Microsoft aplicat a AIOps, l'estat de l'art en incidents reals volta el 53% de recall. Aquesta no és una xifra que posis darrere d'un assessor patrimonial sense una capa de revisió humana molt gruixuda. El to de la keynote ho hauria de reflectir, no maquillar-ho.

On poso la ratlla

Scroxton té raó que la indústria produeix massa slop. Però el slop és un problema de l'economia creativa. El problema d'infraestructura — i aquest sí que em toca viure'l a mi — és que «en producció» s'ha redefinit silenciosament com «cridar un LLM des d'un request path que ja serveix usuaris». No són el mateix. El primer exigeix SLOs, observabilitat, atribució de costos, governança i una resposta a incidents pensada per a sistemes no deterministes. El segon exigeix una clau d'API.

Dos-cents mil milions de dòlars de capex compren molts TPU. No compren un equip de plataforma. No compren un runbook. No compren la maduresa operativa que decideix si la IA del teu stack és un multiplicador de productivitat o un incident latent que espera el seu primer mal divendres.

Les empreses que guanyaran els pròxims dos anys d'IA no seran les que hauran adoptat més de pressa. Seran les que tenien un equip de plataforma que es va negar a dir-ne «producció» fins que ho va ser de debò.

---

Fonts:

• Alex Scroxton, Google Cloud Next: It's time to create value, not slop, from the AI boom, Computer Weekly, 23 d'abril de 2026. computerweekly.com
• Keynote de Google Cloud Next 2026, Thomas Kurian — xifres d'adopció de clients, TPU 8i/8t, Gemini Agent Platform.
• Casos d'estudi de Capcom i Citi tal com es van presentar a Google Cloud Next 2026.

Estàs posant IA en producció i no tens clar si la teva plataforma pot aguantar el pes operatiu? Parla amb un CTO — t'ajudem a separar la keynote del runbook.