Google Cloud Next 2026: con 200.000 millones de capex no se compra la madurez de producción

El artículo de Alex Scroxton en Computer Weekly sobre Google Cloud Next 2026 pone el dedo en la inquietud correcta — la industria produce demasiado slop de IA y demasiado poco valor — pero se detiene una planta por debajo de donde a mí me interesa tener la conversación. Como ingeniero DevOps que de verdad tiene que poner estos stacks en producción a escala enterprise, mi problema con Cloud Next no es la sesión de DJ amenizada con Gemini. Es la brecha entre la keynote y el runbook.

Thomas Kurian abrió el evento con una frase que debería poner en guardia a cualquier SRE: "Habéis superado el piloto, la fase experimental ha quedado atrás." Lo respalda un número real — tres cuartas partes de los clientes de Google Cloud ya usan la IA de Google de alguna forma — y un cheque real: cerca de 200.000 millones de dólares de capex comprometidos en infraestructura de IA. Silicio nuevo (TPU 8i para inferencia, TPU 8t para entrenamiento). La Gemini Agent Platform, presentada formalmente. El caso de Capcom: un workbench multiagente que ejecuta 30.000 horas humanas de trabajo al mes. Citi Sky, un asesor patrimonial bilingüe construido sobre todo el stack de IA de Google.

Ese es el paquete de marketing. El paquete técnico — el que nadie en el Moscone quiso tocar en el escenario principal — es la factura operativa que viene con las palabras "en producción".

La crítica del slop acierta, pero no es el muro de carga

La preocupación central de Scroxton es creativa: música generada por IA, arte generado por IA, el coste cultural de sustituir personas por mediocridad estadística. Es legítima, y a título personal la comparto casi entera. Pero desde mi silla, el slop es la consecuencia de una decisión más peligrosa: meter cargas de IA en entornos de producción compartidos sin la madurez operativa que esos entornos exigen.

El slop diluye una playlist de Spotify. Una IA mal puesta en producción en un banco diluye el rastro de auditoría. Lo primero es molesto. Lo segundo es una invitación abierta al regulador.

El encuadre hype contra realidad que elige la pieza de Computer Weekly es el artístico. Yo quiero insistir en el de ingeniería, porque ahí es donde van a aparecer los cadáveres.

"Más allá del piloto" no es un estado de ánimo. Es una disciplina.

Cuando Kurian dice que la fase experimental ha quedado atrás, la traducción honesta es: muchos clientes tienen un notebook en Vertex AI, una clave de API de Gemini y al menos una feature flag apuntando tráfico real a un modelo. Eso no es "en producción" tal y como usa el término un equipo de pagos o un equipo de SRE.

Para poner un modelo en producción, en el sentido que yo defendería ante un consejo de administración o ante un regulador, necesitas como mínimo:

• Observabilidad que entienda la carga de trabajo. Latencia p99 por modelo y por ruta. Coste de tokens por petición. Tasa de acierto de la caché. Deriva en los evals sobre un benchmark congelado. Nada de eso viene "gratis" con un despliegue de la Gemini Agent Platform. Lo construyes tú.
• Atribución de costes a nivel de equipo. Si tres pods comparten un endpoint de inferencia, ¿quién paga cada pico? Con 200.000 millones de capex aguas arriba de ti, la factura del cloud deja de ser una nota al pie de finanzas y se convierte en una preocupación de ingeniería de primer orden.
• Respuesta a incidentes que entienda los sistemas no deterministas. Un modelo que ayer acertaba y hoy se equivoca no es un bug de despliegue. Es una regresión de comportamiento sin un punto limpio al que hacer rollback. Tu runbook tiene que reflejarlo.
• Gobernanza que sobreviva a una auditoría. Trazabilidad de qué plantilla de prompt produjo qué decisión, contra qué versión del modelo y con qué contexto de retrieval. Si no puedes responder a eso en una declaración jurada, no tienes un sistema en producción. Tienes una demo con tráfico.

Nada de esto fue titular en Cloud Next. Se dio por hecho. Esa es la brecha.

El número de Capcom, leído como lo leería un SRE

El workbench de Capcom es genuinamente impresionante: un agente de inspección visual sobre Gemini Vision, un agente predictivo sobre datos históricos, un agente de conocimiento institucional, un agente que caza ineficiencias en los datos. El resultado, según la keynote: "30.000 horas humanas cada mes".

Léelo como ingeniero DevOps, no como CMO.

Treinta mil horas al mes son aproximadamente 170 equivalentes a jornada completa de trabajo de agentes ejecutándose sin parar contra datos de producción. Las preguntas que yo querría tener respondidas antes de firmar eso:

• ¿Cuál es el SLO de cada agente? No el SLA del proveedor del LLM. El SLO compuesto de extremo a extremo, incluyendo retrieval, posprocesado y el bucle de revisión humana.
• ¿Cuál es el modo de fallo cuando el agente predictivo lleva una semana equivocándose en silencio? Las predicciones no se caen. Derivan. ¿Tienes un eval offline contra un golden set congelado y una alerta para cuando las salidas del agente diverjan más de un X%?
• ¿Quién está de guardia para el stack de agentes? Si el agente de ineficiencias del pod A está dejando sin caché al índice de retrieval del pod B, ¿quién despierta a quién? "El equipo de plataforma" solo funciona si ese equipo existe y tiene autoridad.
• ¿Cuál es la ruta de rollback? Los modelos están versionados, pero las plantillas de prompts, los índices de retrieval y las definiciones de herramientas normalmente no. Un mal cambio en cualquiera de los tres puede degradar la calidad sin disparar una sola alarma clásica de despliegue.

Nada de esto es exótico. Es la aburrida checklist de SRE que lleva dos años marcando la diferencia entre "usamos IA" y "la IA nos funciona". El tono de la keynote — la fase experimental ha quedado atrás — corre el riesgo de empujar a los clientes al primer cuadrante saltándose el segundo.

El stack de la Agent Platform: más capas, la misma guardia

La Gemini Agent Platform se apoya en Vertex AI, que se apoya en TPU, que se apoya en la nueva generación 8i/8t. Visto desde compras, parece una historia integrada. Visto desde DevOps, son cuatro capas más en el grafo de dependencias, cada una con su propio modo de fallo, su propio sistema de cuotas, su propia curva de precios y su propia consola donde un incidente puede esconderse.

Súmale la realidad genuinamente multi-cloud de la mayoría de las empresas y aparece un patrón conocido: un Gemini Agent integrándose con cargas en AWS, con datos en Snowflake, con autenticación en Okta y con la observabilidad repartida entre Datadog y un Grafana autogestionado. La diapositiva impecable del Moscone esconde una maraña.

Dos consecuencias a las que yo, como CTO, estaría prestando atención ahora mismo:

1. El vendor lock-in ya no es un asunto de compras: es un asunto operativo. En cuanto tus plantillas de prompts, tus suites de evals y tu orquestación de agentes viven dentro de la plataforma de un solo proveedor, el coste de migrar deja de medirse en licencias y empieza a medirse en meses de trabajo de SRE.
2. Los compromisos de capex son apuestas que otro hace en tu nombre. Cuando un hyperscaler anuncia 200.000 millones de capex, la promesa implícita es que los precios seguirán siendo favorables mientras crece la utilización. El riesgo implícito es que, tres años después, los unit economics fuercen un reajuste de precios que aterrice directamente en la hoja de ruta de tu equipo de plataforma.

Ninguna de las dos cosas es una catástrofe. Las dos son el tipo de riesgo que incorporas a un plan de plataforma a tres años cuando lo escribes con honestidad.

Citi Sky y la parte del anuncio que sí suscribo

El caso que yo contrapondría a la crítica del slop es Citi Sky. Un asesor patrimonial bilingüe, construido sobre el stack de IA de Google y enmarcado explícitamente como aumento de los asesores humanos, no como su sustituto. Ese encuadre es al que vuelvo en cada post de este blog: la IA es implementable y valiosa cuando amplía lo que un experto puede hacer por hora, no cuando intenta sustituir al experto.

Citi Sky deja además una señal más discreta que merece la pena recoger: una institución financiera regulada no apuesta un producto de asesoría patrimonial a la IA sin controles serios por debajo. Mostrara lo que mostrase la keynote, el equipo que hay detrás tiene trazabilidad de datos, registro de decisiones, revisión de model risk management y un patrón de human-in-the-loop que puede defender ante la OCC. Esa es la parte del iceberg que la conferencia no pone en la diapositiva.

Si tu iniciativa de IA no tiene un iceberg equivalente, no tienes un Citi Sky. Tienes un chatbot con marca.

Lo que querría ver en la keynote del año que viene

Si Google Cloud Next 2027 quiere convencer a la gente que de verdad mantiene estos sistemas en pie, esto es lo que yo pondría en el escenario principal en lugar de un DJ con Gemini:

1. Patrones de producción para sistemas agénticos con SLOs concretos. No "ejecutamos 30.000 horas al mes". Enséñame la latencia p99, las bandas de deriva de los evals y la tasa de revisión humana, y dime qué números no son negociables.
2. Una historia de atribución de costes de primera clase. Por equipo, por agente, por ruta. Con primitivas de chargeback dentro de la propia plataforma, no atornilladas después por cada cliente.
3. Modos de fallo honestos para la Agent Platform. ¿Qué pasa cuando el retrieval se queda obsoleto? ¿Cuando las llamadas a herramientas entran en bucle? ¿Cuando una API aguas abajo limita el ritmo de un agente en mitad de una conversación?
4. Un modelo operativo de referencia para equipos de plataforma. Dimensionamiento, rotación de guardias, el reparto entre ingenieros de producto de agentes e ingenieros de plataforma. El discurso de Coinbase de los operadores en solitario es un extremo; la asunción tácita de que el hyperscaler absorberá la complejidad operativa por ti es el otro. Los dos están equivocados.
5. Una conversación adulta sobre evals. Como mostró el propio paper ActionNex de Microsoft para AIOps, el estado del arte en incidentes reales ronda el 53% de recall. Ese no es un número que pongas detrás de un asesor patrimonial sin una capa de revisión humana muy gruesa. El tono de la keynote debería reflejarlo, no maquillarlo.

La línea que trazo

Scroxton tiene razón en que la industria produce demasiado slop. Pero el slop es un problema de la economía creativa. El problema de infraestructura — y ese es el que a mí me toca vivir — es que "en producción" se ha redefinido en silencio hasta significar "llamar a un LLM desde una ruta de peticiones que ya sirve a usuarios". No son lo mismo. Lo primero exige SLOs, observabilidad, atribución de costes, gobernanza y una respuesta a incidentes diseñada para sistemas no deterministas. Lo segundo exige una clave de API.

Doscientos mil millones de dólares de capex compran muchas TPU. No compran un equipo de plataforma. No compran un runbook. No compran la madurez operativa que decide si la IA de tu stack es un multiplicador de productividad o un incidente latente esperando su primer mal viernes.

Las empresas que ganen los próximos dos años de la IA no serán las que adoptaron más rápido. Serán aquellas cuyos equipos de plataforma se negaron a llamar "producción" a algo hasta que lo fue de verdad.

---

Fuentes:

• Alex Scroxton, Google Cloud Next: It's time to create value, not slop, from the AI boom, Computer Weekly, 23 de abril de 2026. computerweekly.com
• Keynote de Google Cloud Next 2026, Thomas Kurian — cifras de adopción de clientes, TPU 8i/8t, Gemini Agent Platform.
• Casos de estudio de Capcom y Citi tal como se presentaron en Google Cloud Next 2026.

¿Estás poniendo IA en producción y no tienes claro si tu plataforma aguanta el peso operativo? Habla con un CTO — te ayudamos a separar la keynote del runbook.