8 min de lectura

Google ha anunciado en el Cloud Next 2026 componentes que convierten el multi-cloud de una teoría arquitectónica en una decisión operativa. Los CIO de la región DACH que aún crean que una estrategia cross-cloud fracasa por los costes de egreso y los silos de datos deberían prestar atención: la palanca ya no es el cómputo, sino dónde residen los datos y cuánto cuesta moverlos.

Lo más importante en resumen

• Cross-cloud Lakehouse (antes BigLake) permite ahora consultas en fuentes de datos de AWS, Azure y GCP sin replicación completa. La capa de caché cross-cloud almacena la primera lectura en el sistema de origen y reduce los costes de egreso en consultas recurrentes.
• Gemini Enterprise Agent Platform agrupa registros de agentes, registros de habilidades y gobernanza en una capa diseñada explícitamente para despliegues multi-cloud, sin ser un nuevo stack de proveedor, sino un plano de control sobre cargas de trabajo existentes.
• Agentic Data Cloud convierte el almacenamiento de datos en una cuestión estratégica: quien controla las tablas maestras controla el stack de agentes que las utiliza.
• AWS y Google han anunciado por separado una cooperación para despliegues multi-cloud, lo que facilita técnicamente la portabilidad de cargas de trabajo entre hyperscalers, pero intensifica la competencia por la capa de datos.
• Consecuencia operativa para los CIO: La pregunta ya no es «¿en qué nube?», sino «¿dónde permanece el origen, dónde se permite computar y quién asume el riesgo de la caché?».

El egreso como impuesto oculto de toda idea multi-cloud

Quienes en los últimos tres años han intentado distribuir cargas de trabajo entre dos hyperscalers conocen la reacción instintiva del área financiera: los costes de egreso. AWS, Azure y GCP cobran por gigabyte de tráfico saliente cantidades que, en una tubería de 80 terabytes al mes, suman rápidamente cinco cifras. Estas tarifas no son un error, sino la materialización del vendor lock-in en una partida contable. Los datos que una vez residen en un bucket salen caros.

La función de caché cross-cloud presentada por Google en el Next 2026 ataca precisamente este punto. Almacena localmente en la caché del lakehouse los datos que ya han cruzado la frontera entre nubes, de modo que las consultas recurrentes no generan egreso cada vez. Para un sistema de reporting que consume diariamente el mismo conjunto de datos de un bucket S3, esto puede reducir en un orden de magnitud el tráfico saliente. La verdad arquitectónica detrás: el caché no es nuevo, pero cuando un hyperscaler lo ofrece como servicio nativo más allá de las fronteras de otras nubes, desplaza radicalmente el cálculo de ROI para el multi-cloud.

Un ejemplo de la región DACH ilustra la magnitud

Un grupo industrial de tamaño medio que recopila sus datos de máquinas en AWS S3 y los analiza con GCP BigQuery registra, según sus propias cifras, unos 12 TB de egreso cross-cloud al mes. Con las tarifas actuales de AWS, esto supone cerca de 1.080 euros mensuales solo por movimiento de datos. Con una tasa de acierto en caché del 70 % para las consultas analíticas recurrentes, el tráfico saliente se reduce a unos 3,6 TB, y la factura a unos 330 euros. A lo largo del año, la diferencia asciende a 9.000 euros para una única ruta de datos. Quien gestione varias tuberías de este tipo habla rápidamente de efectos de seis cifras.

Del silo de datos al Lakehouse sin fronteras

El segundo cambio proviene del propio lakehouse. Google denomina «sin fronteras» a la nueva variante: la capa del lakehouse puede referenciar tablas que físicamente se encuentran en S3 o Azure Data Lake, sin necesidad de replicar los datos en BigQuery. Para los equipos de ingeniería, esto significa: menos ETL, menos trabajos de sincronización y menos puntos en los que una deriva de esquema pueda romper un informe. Para los CIO, esto implica que la pregunta sobre «a dónde pertenecen» los datos puede responderse de nuevo desde un punto de vista político y contractual, sin que cada respuesta desencadene inmediatamente un proyecto de migración.

La otra cara de la moneda: quien controla la capa del lakehouse, controla la lógica de consulta. Google se posiciona aquí como un mediador neutral, lo que es estratégicamente inteligente, ya que su propio cómputo se convierte en el motor de consulta estándar sobre buckets ajenos. AWS y Azure tienen iniciativas comparables, pero están más arraigadas en sus propios ecosistemas. La elección de qué capa de lakehouse se convertirá en el estándar de facto en una empresa DACH es, por tanto, una decisión estratégica con un vendor con una larga vida útil.

«Hasta ahora, la multicloud era una respuesta de cumplimiento. Con las nuevas capas de lakehouse y caché, se convierte en una opción arquitectónica, pero la elección de quién lidera la capa de datos sigue siendo una decisión de bloqueo a largo plazo».

Pila de agentes: quien controla los datos, controla las habilidades

La Gemini Enterprise Agent Platform y la Agentic Data Cloud son el anuncio más estratégico. Google agrupa el Agent-Registry, Skill-Registry, Tool-Registry y la gobernanza en una capa diseñada explícitamente para gestionar conjuntamente cargas de trabajo de AWS, Azure y GCP. Con esto, Google no apuesta por «migrad vuestras aplicaciones a nosotros», sino por «nosotros seremos el plano de control sobre vuestras aplicaciones existentes». Desde la perspectiva de un CIO, esto resulta atractivo porque cambia la relación de inversión: en lugar de financiar un proyecto de migración de cargas de trabajo, se paga una suscripción abstracta de control.

Sin embargo, esto solo desplaza el riesgo una capa hacia arriba. Quien dentro de dos años descubra que el Agent-Registry y el inventario de herramientas están en Google, experimentará el mismo efecto de bloqueo con «cambiamos el plano de control» que la multicloud pretendía evitar. La única respuesta sostenible: imponer estándares abiertos para las definiciones de agentes, esquemas de habilidades y manifiestos de herramientas antes de que los formatos propietarios creen hechos consumados.

El cumplimiento normativo llega a la capa multicloud

Lo que a menudo se pasa por alto en el debate arquitectónico: el RGPD, la NIS2 y la Ley de IA de la UE no prescriben proveedores de cloud, pero sí establecen dónde deben procesarse los datos y quién puede acceder a ellos. Una capa de caché multicloud que almacene datos personales en una caché de GCP, aunque la tabla maestra esté en un centro de datos alemán de AWS, no es trivial desde el punto de vista de la protección de datos. La pregunta operativa es: ¿qué categoría de datos puede almacenarse en caché y dónde? ¿Y cómo se documenta el ciclo de vida de la caché cuando la autoridad de supervisión lo solicite?

La respuesta de los proveedores será el «caché basado en políticas», es decir, reglas que determinen qué clases de datos pueden cruzar qué fronteras entre clouds. En la práctica, esto significa que antes de construir la primera tubería multicloud en producción, debe existir un esquema de clasificación de datos. Quien lo posponga, se estará creando un generador de hallazgos en auditorías.

Tres preguntas clave antes del próximo paso en multicloud

1. ¿Dónde se encuentran los datos maestros y dónde pueden estar sus copias? El almacenamiento en caché parece una cuestión de rendimiento, pero en realidad es una cuestión de cumplimiento. Sin clasificación de datos, no hay caché multicloud.

2. ¿Qué motor de consulta se convertirá en el estándar? Las capas de lakehouse tienen una vida útil de cinco a diez años. La elección de si BigQuery, Athena, Synapse o Snowflake se convertirán en la ruta de consulta dominante es una decisión estratégica con un vendor, no una decisión de herramientas.

3. ¿Quién controla el plano de control de los agentes? Si el Agent-Registry y el inventario de herramientas están en manos de un hiperescalador, la multicloud puede funcionar bien a nivel de cómputo, pero a nivel de inteligencia vuelve a estar centralizada. Hay que abordar ahora las discusiones sobre estándares abiertos, no dentro de dos años.

Preguntas frecuentes