Google Cloud Next 2026: 200.000 Milions de Capex No Compren Maduresa de Producció
L'article d'Alex Scroxton a Computer Weekly sobre Google Cloud Next 2026 aterra a la inquietud correcta — la indústria produeix massa slop d'IA i massa poc valor — però es queda un pis curt d'on jo voldria tenir la conversa. Com a enginyer de DevOps que realment ha de posar aquests stacks en producció a escala enterprise, el meu problema amb Cloud Next no és el DJ set 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 pampallugar qualsevol SRE: "Heu superat el pilot, la fase experimental ha quedat enrere." Ho recolza un número real — tres quartes parts dels clients de Google Cloud ja fan servir la IA de Google d'alguna manera — i un xec real: aproximadament 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). El Gemini Agent Platform presentat formalment. El cas Capcom: un workbench multi-agent corrent 30.000 hores humanes al mes de feina. 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 discutir a l'escenari principal, és la factura operativa que ve amb les paraules "en producció".
La crítica del slop té raó, però no és el problema que sosté la càrrega
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 justa, i jo també la comparteixo en bona part a nivell personal. Però des d'on sec, el slop és aigües avall d'una decisió més perillosa: posar workloads d'IA en entorns de producció compartits sense la maduresa operativa que aquests entorns exigeixen.
El slop dilueix una playlist de Spotify. Una mala IA en producció dins d'un banc dilueix l'audit trail. La primera cosa és molesta. La segona és una invitació oberta al regulador.
L'enquadrament hype-versus-realitat que tria l'article de Computer Weekly és l'artístic. Jo vull insistir en l'enginyeril, perquè és aquí on apareixeran els cossos.
"Més enllà del pilot" no és un vibe. És una disciplina.
Quan Kurian diu que la fase experimental ha quedat enrere, la traducció honesta és: molts clients tenen un notebook a Vertex AI, una clau d'API de Gemini i com a mínim una feature flag apuntant trànsit real a un model. Això no és el mateix que "en producció" en el sentit que un equip de pagaments o un equip d'SRE fa servir el terme.
Per posar un model en producció, en el sentit que jo defensaria davant d'un board o d'un regulador, com a mínim necessites:
- Observabilitat que entengui el workload. Latència p99 per model i per ruta. Cost de tokens per request. Cache hit rate. Eval drift sobre un benchmark congelat. Res d'això ve "de regal" amb un desplegament de Gemini Agent Platform. Te'l fas tu.
- Atribució de cost fins a l'equip. Si tres pods comparteixen un endpoint d'inferència, qui paga quin pic? Amb 200.000M$ de capex aigües amunt teu, la factura del cloud deixa de ser una nota al peu de finances i passa a ser una preocupació primària d'enginyeria.
- Resposta a incidents que sàpiga de sistemes no deterministes. Un model que ahir era correcte i avui s'equivoca no és un bug de deploy. És una regressió de comportament sense un punt clar de rollback. El runbook ho ha de reflectir.
- Governança que sobrevisqui una auditoria. Lineage de quina plantilla de prompt va produir quina decisió, contra quina versió de model, amb quin context de retrieval. Si no pots respondre això sota declaració, no tens un sistema de producció. Tens una demo amb trànsit.
Cap d'aquestes coses va ser titular a Cloud Next. Es van donar per descomptades. Aquest és el forat.
El número de Capcom, llegit com un 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 de eficiència de dades. Resultat, segons la keynote, "30.000 hores humanes cada mes".
Llegeix-ho com un enginyer de DevOps, no com un CMO.
Trenta mil hores al mes signifiquen aproximadament 170 FTE equivalents de feina d'agents corrent contínuament contra dades de producció. Les preguntes que jo voldria respostes abans de signar això:
- Quin és l'SLO de cada agent? No l'SLA del proveïdor del LLM. L'SLO compost end-to-end, incloent retrieval, post-processament i el bucle de revisió humana.
- Quin és el failure mode quan l'agent predictiu s'equivoca silenciosament durant una setmana? Les prediccions no peten. Drifaten. Tens un eval offline corrent contra un golden set congelat, i una alerta quan les sortides de l'agent divergeixen més d'un X%?
- Qui està d'on-call de l'stack d'agents? Si l'agent de eficiència del pod A està afamant l'índex de retrieval del pod B de caché, qui ha de paginar a qui? "L'equip de plataforma" només funciona si existeix i té autoritat.
- Quin és el camí de rollback? Els models es versionen, però les plantilles de prompts, els índexs de retrieval i les definicions d'eines normalment no. Un mal canvi en qualsevol d'aquests tres pot degradar la qualitat sense disparar ni una alarma de deploy clàssica.
Res d'això és exòtic. És el checklist avorrit d'SRE que ha estat la diferència entre "fem servir IA" i "la IA ens funciona" durant dos anys. El to de la keynote — la fase experimental ha quedat enrere — corre el risc d'empènyer els clients al primer quadrant saltant-se el segon.
L'stack del Agent Platform: més capes, mateix on-call
El Gemini Agent Platform seu sobre Vertex AI que seu sobre TPU que seu sobre la nova generació 8i/8t. Des de la perspectiva d'un comprador això sembla una història integrada. Des de la perspectiva de DevOps sembla quatre capes més al graf de dependències, cadascuna amb el seu propi failure mode, el seu propi sistema de quotes, la seva pròpia corba de preus i la seva pròpia consola on un incident es pot amagar.
Combina-ho amb la realitat genuïnament multi-cloud de la majoria d'empreses i et surt un patró familiar: un Gemini Agent integrant-se amb workloads a AWS, dades a Snowflake, auth a Okta, observabilitat partida entre Datadog i un Grafana self-hosted. La diapositiva neta del Moscone amaga una bola de fils.
Dues conseqüències a què jo, com a CTO, prestaria atenció ara mateix:
- El vendor lock-in ja no és una pregunta de compres, és una qüestió operativa. Un cop les teves plantilles de prompts, suites d'evals i orquestració d'agents viuen dins de la plataforma d'un vendor, el cost de migració deixa de mesurar-se en llicències i passa a mesurar-se en mesos de feina d'SRE.
- Els compromisos de capex són apostes que fas en nom d'algú altre. Quan un hyperscaler anuncia 200.000M$ de capex, la promesa implícita és que els preus es mantenen favorables mentre puja l'ocupació. El risc implícit és que, tres anys més tard, la unitat econòmica obligui un reset de preus que aterra directament al roadmap del teu equip de plataforma.
Cap de les dues coses és apocalíptica. Totes dues són el tipus de risc que construeixes dins d'un pla de plataforma a tres anys quan l'escrius honestament.
Citi Sky i la part de l'anunci que sí endosso
El cas que jo aixecaria contra la crítica del slop és Citi Sky. Un assessor patrimonial bilingüe, construït sobre l'stack d'IA de Google, explícitament emmarcat com a augmentació dels assessors humans, no com a substitució. Aquest enquadrament és el que repeteixo a cada post d'aquest blog: la IA és implementable i valuosa quan amplia el que un expert pot fer per hora, no quan intenta substituir l'expert.
Citi Sky deixa també un senyal més silenciós que val la pena recollir: una institució financera regulada no aposta un producte d'assessoria patrimonial a la IA sense controls seriosos a sota. Sigui el que sigui que la keynote mostri, l'equip que hi ha darrere té data lineage, logging de decisions, revisió de model-risk-management i un patró human-in-the-loop que poden 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è voldria veure a la keynote de l'any vinent
Si Google Cloud Next 2027 vol convèncer la gent que realment manté aquests sistemes drets, això és el que jo posaria a l'escenari principal en comptes d'un DJ amb Gemini:
- Patrons de producció per a sistemes agèntics amb SLOs anomenats. No "corrim 30.000 hores al mes." Ensenya'm latència p99, bandes de eval drift i la taxa de revisió humana, i digues quins números no són negociables.
- Una història de cost-attribution de primera classe. Per equip, per agent, per ruta. Amb primitives de chargeback dins de la mateixa plataforma, no enganxades a sobre per cada client.
- Failure modes honestos per a l'Agent Platform. Què passa quan el retrieval és stale? Quan les crides a eines entren en bucle? Quan una API aigües avall rate-limita un agent a mig flux de conversa?
- Un model operatiu de referència per a equips de plataforma. Dimensionament, rotació d'on-call, separació entre enginyers de producte d'agents i enginyers de plataforma. El pitch de Coinbase de solo operators purs és un extrem; l'assumpció no parlada que el hyperscaler absorbirà la complexitat operativa per tu és l'altre. Tots dos estan equivocats.
- Una conversa adulta sobre evals. Com va mostrar el propi paper d'ActionNex de Microsoft per a AIOps, l'estat de l'art en incidents reals és al voltant del 53% de recall. Aquest no és un número que poses 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.
La línia que dibuixo
Scroxton té raó que la indústria produeix massa slop. Però el slop és un problema d'economia creativa. El problema d'infraestructura — i és amb el qual jo he de conviure — és que "en producció" s'ha redefinit silenciosament com "cridant un LLM des d'una request path que ja serveix usuaris." No són el mateix. La primera cosa requereix SLOs, observabilitat, cost-attribution, governança i resposta a incidents pensats per a sistemes no deterministes. La segona requereix una clau d'API.
Dos-cents mil milions de dòlars de capex compren molts TPUs. 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 esperant el seu primer divendres dolent.
Les empreses que guanyaran els pròxims dos anys d'IA no seran les que han adoptat més de pressa. Seran aquelles l'equip de plataforma de les quals s'ha negat a anomenar "producció" a res que encara no ho fos 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.
Posant IA en producció i no segur si la teva plataforma pot carregar el pes operatiu? Parla amb un CTO — t'ajudem a separar la keynote del runbook.
