Google Cloud Next 2026: 200.000 Millones de Capex No Compran Madurez de Producción

El artículo de Alex Scroxton en Computer Weekly sobre Google Cloud Next 2026 aterriza en la inquietud correcta — la industria produce demasiado slop de IA y muy poco valor — pero se queda un piso corto de donde yo quiero tener la conversación. Como ingeniero de DevOps que realmente tiene que poner estos stacks en producción a escala enterprise, mi problema con Cloud Next no es el DJ set con Gemini. Es la distancia entre la keynote y el runbook.

Thomas Kurian abrió el evento con una frase que debería hacer pestañear 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: aproximadamente 200.000 millones de dólares de capex comprometidos en infraestructura de IA. Silicio nuevo (TPU 8i para inferencia, TPU 8t para entrenamiento). Gemini Agent Platform presentado formalmente. El caso Capcom: un workbench multi-agente corriendo 30.000 horas humanas al mes de trabajo. 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 Moscone tenía ganas de discutir en el escenario principal, es la factura operativa que viene con las palabras "en producción".

La crítica del slop tiene razón, pero no es el problema que sostiene la carga

La preocupación central de Scroxton es creativa: música generada por IA, arte generado por IA, el coste cultural de sustituir humanos por mediocridad estadística. Es justa, y la comparto en buena parte a nivel personal. Pero desde donde me siento, el slop es aguas abajo de una decisión más peligrosa: meter workloads de IA en entornos de producción compartidos sin la madurez operativa que esos entornos exigen.

El slop diluye una playlist de Spotify. Una mala IA en producción dentro de un banco diluye el audit trail. Lo primero es molesto. Lo segundo es una invitación abierta al regulador.

El encuadre hype-versus-realidad que elige la pieza de Computer Weekly es el artístico. Yo quiero insistir en el ingenieril, porque ahí es donde aparecerán los cuerpos.

"Más allá del piloto" no es un vibe. 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 lo mismo que "en producción" en el sentido en que un equipo de pagos o un equipo de SRE usa el término.

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

• Observabilidad que entienda el workload. Latencia p99 por modelo y por ruta. Coste de tokens por request. Cache hit rate. Eval drift sobre un benchmark congelado. Nada de esto viene "gratis" con un despliegue de Gemini Agent Platform. Te lo construyes.
• Atribución de coste hasta el equipo. Si tres pods comparten un endpoint de inferencia, ¿quién paga qué pico? Con 200.000M$ de capex aguas arriba tuyo, la factura del cloud deja de ser una nota al pie de finanzas y pasa a ser una preocupación primaria de ingeniería.
• Respuesta a incidentes que sepa de sistemas no deterministas. Un modelo que ayer era correcto y hoy se equivoca no es un bug de deploy. Es una regresión de comportamiento sin un punto claro de rollback. El runbook tiene que reflejarlo.
• Gobernanza que sobreviva una auditoría. Lineage de qué plantilla de prompt produjo qué decisión, contra qué versión de modelo, con qué contexto de retrieval. Si no puedes responder eso bajo declaración, no tienes un sistema de producción. Tienes una demo con tráfico.

Ninguno de esos puntos fue titular en Cloud Next. Se dieron por supuestos. Ese es el agujero.

El número de Capcom, leído como 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 de eficiencia de datos. Resultado, según la keynote, "30.000 horas humanas cada mes".

Léelo como un ingeniero de DevOps, no como un CMO.

Treinta mil horas al mes significan aproximadamente 170 FTE equivalentes de trabajo de agentes corriendo continuamente contra datos de producción. Las preguntas que yo querría respondidas antes de firmar eso:

• ¿Cuál es el SLO de cada agente? No el SLA del proveedor del LLM. El SLO compuesto end-to-end, incluyendo retrieval, post-procesamiento y el bucle de revisión humana.
• ¿Cuál es el failure mode cuando el agente predictivo se equivoca silenciosamente durante una semana? Las predicciones no se rompen. Driftan. ¿Tienes un eval offline corriendo contra un golden set congelado, y una alerta cuando las salidas del agente divergen más de un X%?
• ¿Quién está on-call del stack de agentes? Si el agente de eficiencia del pod A está afamando el índice de retrieval del pod B de caché, ¿quién paga a quién? "El equipo de plataforma" solo funciona si existe y tiene autoridad.
• ¿Cuál es el camino de rollback? Los modelos se versionan, pero las plantillas de prompts, los índices de retrieval y las definiciones de herramientas normalmente no. Un mal cambio en cualquiera de esas tres cosas puede degradar la calidad sin disparar una sola alarma de deploy clásica.

Nada de esto es exótico. Es el checklist aburrido de SRE que ha sido la diferencia entre "usamos IA" y "la IA nos funciona" durante dos años. 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 del Agent Platform: más capas, mismo on-call

El Gemini Agent Platform se sienta sobre Vertex AI que se sienta sobre TPU que se sienta sobre la nueva generación 8i/8t. Desde la perspectiva de un comprador eso parece una historia integrada. Desde la perspectiva de DevOps parece cuatro capas más en el grafo de dependencias, cada una con su propio failure mode, su propio sistema de cuotas, su propia curva de precios y su propia consola donde un incidente se puede esconder.

Combínalo con la realidad genuinamente multi-cloud de la mayoría de empresas y sale un patrón familiar: un Gemini Agent integrándose con workloads en AWS, datos en Snowflake, auth en Okta, observabilidad partida entre Datadog y un Grafana self-hosted. La slide limpia del Moscone esconde una bola de pelo.

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

1. El vendor lock-in ya no es una pregunta de compras, es una cuestión operativa. Una vez tus plantillas de prompts, suites de evals y orquestación de agentes viven dentro de la plataforma de un vendor, el coste de migración deja de medirse en licencias y pasa a medirse en meses de trabajo de SRE.
2. Los compromisos de capex son apuestas que haces en nombre de otro. Cuando un hyperscaler anuncia 200.000M$ de capex, la promesa implícita es que los precios se mantienen favorables mientras sube la ocupación. El riesgo implícito es que, tres años después, la unidad económica obligue a un reset de precios que aterriza directamente en el roadmap de tu equipo de plataforma.

Ninguna de las dos cosas es apocalíptica. Las dos son el tipo de riesgo que construyes en un plan de plataforma a tres años cuando lo escribes honestamente.

Citi Sky y la parte del anuncio que sí endoso

El caso que yo levantaría contra la crítica del slop es Citi Sky. Un asesor patrimonial bilingüe, construido sobre el stack de IA de Google, explícitamente enmarcado como aumento de los asesores humanos, no como sustitución. Ese enmarque es el que repito 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 también una señal más silenciosa que vale la pena recoger: una institución financiera regulada no apuesta un producto de asesoría patrimonial a la IA sin controles serios debajo. Sea lo que sea lo que la keynote muestre, el equipo que hay detrás tiene data lineage, logging de decisiones, revisión de model-risk-management y un patrón human-in-the-loop que pueden defender ante la OCC. Esa es la parte del iceberg que el congreso no pone en la slide.

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

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

Si Google Cloud Next 2027 quiere convencer a la gente que realmente 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 nombrados. No "corremos 30.000 horas al mes". Enséñame latencia p99, bandas de eval drift y la tasa de revisión humana, y dime qué números no son negociables.
2. Una historia de cost-attribution de primera clase. Por equipo, por agente, por ruta. Con primitives de chargeback dentro de la plataforma misma, no pegadas encima por cada cliente.
3. Failure modes honestos para el Agent Platform. ¿Qué pasa cuando el retrieval está stale? ¿Cuándo las llamadas a herramientas entran en bucle? ¿Cuando una API aguas abajo rate-limita a un agente en mitad de una conversación?
4. Un modelo operativo de referencia para equipos de plataforma. Dimensionado, rotación de on-call, separación entre ingenieros de producto de agentes e ingenieros de plataforma. El pitch de Coinbase de solo operators puros es un extremo; la asunción no dicha de que el hyperscaler absorberá la complejidad operativa por ti es el otro. Ambos están equivocados.
5. Una conversación adulta sobre evals. Como mostró el propio paper de ActionNex de Microsoft para AIOps, el estado del arte en incidentes reales está alrededor del 53% de recall. Ese no es un número que pones 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 dibujo

Scroxton tiene razón en que la industria produce demasiado slop. Pero el slop es un problema de economía creativa. El problema de infraestructura — y es con el que yo tengo que convivir — es que "en producción" se ha redefinido silenciosamente como "llamando a un LLM desde una request path que ya sirve usuarios." No son lo mismo. Lo primero requiere SLOs, observabilidad, cost-attribution, gobernanza y respuesta a incidentes pensados para sistemas no deterministas. Lo segundo requiere una clave de API.

Doscientos mil millones de dólares de capex compran muchos TPUs. 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 viernes malo.

Las empresas que ganen los próximos dos años de IA no serán las que han adoptado más rápido. Serán aquellas cuyo equipo de plataforma se ha negado a llamar "producción" a algo que aún no lo era 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.

¿Poniendo IA en producción y no estás seguro de si tu plataforma puede cargar el peso operativo? Habla con un CTO — te ayudamos a separar la keynote del runbook.