Google rediseñó su arquitectura de datos para que la IA deje de fracasar en las empresas
Durante años, los equipos de datos y los equipos de IA en las grandes corporaciones operaron como departamentos de países distintos. Los primeros construían almacenes, catálogos y pipelines. Los segundos desplegaban modelos, APIs y agentes. Ambos mundos se comunicaban a través de exportaciones manuales, procesos discontinuos y una fe ciega en que "el otro equipo ya lo resuelve". El resultado era predecible: los agentes de IA llegaban al entorno de producción y colapsaban ante datos que nadie había preparado para que una máquina autónoma pudiera leer, interpretar y actuar sobre ellos.
En Google Cloud Next 2026, Google nombró ese colapso con precisión: la separación entre plataforma de datos y plataforma de IA es el mayor freno al despliegue empresarial de agentes autónomos. Su respuesta fue la Nube de Datos Agéntica, una reconfiguración profunda de su arquitectura de datos que no añade una capa de IA encima de lo existente, sino que rediseña los cimientos para que los agentes sean usuarios de primera clase del dato empresarial.
La diferencia de ambición no es menor. No hablamos de conectores nuevos ni de dashboards enriquecidos con lenguaje natural. Hablamos de un rediseño estructural que obliga a replantear cómo cualquier empresa Fortune 500 —con datos repartidos entre AWS, Azure y Google Cloud— va a gobernar, servir y monetizar la información que ya posee.
El diagnóstico que los directivos prefieren ignorar
Hay un dato que incomoda: según la investigación que acompaña al lanzamiento, alrededor del 70% de las empresas descubren las fallas de su infraestructura de datos después de desplegar los agentes, no antes. Esto no es un problema técnico. Es un problema de liderazgo con disfraz técnico.
Los datos fragmentados, sin gobernanza, atrapados en silos de distintas nubes, no aparecieron de la noche a la mañana. Se acumularon durante años de decisiones apresuradas, adquisiciones corporativas mal integradas y una tendencia organizacional muy humana: aplazar la conversación difícil sobre la arquitectura real del dato porque "el negocio sigue funcionando". Hasta que deja de funcionar.
La arquitectura que Google presentó está compuesta por seis componentes que no son independientes entre sí, sino que forman un sistema con lógica secuencial. En la base, el Data Lakehouse Multinube, construido sobre el formato abierto Apache Iceberg, permite que BigQuery consulte datos alojados en AWS S3 y Azure ADLS sin necesidad de moverlos ni replicarlos, eliminando los costos de egreso y el riesgo de incoherencia entre copias. Sobre esa base opera el Motor Lightning para Apache Spark, una capa de ejecución vectorizada en C++ que entrega hasta 4,9 veces el rendimiento del Spark convencional. El dato no solo es accesible; es procesable a una velocidad que hace viable que un agente genere, ejecute y corrija código Spark en ciclos continuos sin que el costo se dispare.
Encima de esa infraestructura de ejecución viene la capa de inteligencia contextual: el Catálogo de Conocimiento, la evolución de Dataplex Universal Catalog presentada el 10 de abril de 2026. Esta pieza es la que más debería ocupar la atención de los arquitectos empresariales. El catálogo no requiere que los equipos de datos cataloguen manualmente los activos. Examina los registros de consultas, perfila tablas, analiza modelos semánticos de herramientas como Looker y extrae relaciones entre entidades desde archivos no estructurados. El resultado es un grafo de conocimiento dinámico, mantenido automáticamente, que responde a la pregunta que cualquier agente necesita resolver antes de actuar: qué datos existen, qué significan con precisión y si son confiables.
Cuando el almacenamiento deja de ser pasivo
La pieza que más radicalmente cambia la geometría operativa del dato es el Almacenamiento Inteligente, actualmente en vista previa. Hasta ahora, un archivo que entraba a un bucket de Google Cloud Storage era inerte hasta que alguien decidía procesarlo. Con esta funcionalidad, en el momento en que un archivo llega al bucket, el sistema lo etiqueta automáticamente, genera embeddings, extrae entidades relevantes y lo vincula al Catálogo de Conocimiento. PDFs, contratos, tickets de soporte, grabaciones de audio: todo se convierte en un activo buscable sin que ningún ingeniero intervenga.
Para los directivos que han estado aplazando proyectos de preparación de datos no estructurados —esos que "tomarán seis meses" de extracción, OCR, indexación y catalogación— esto reconfigura la ecuación de tiempo y costo de manera que no admite aplazamiento cómodo. Lo que antes era un proyecto con sponsor ejecutivo, presupuesto propio y fecha de entrega incierta, pasa a ser una consecuencia automática de la política de almacenamiento.
El Agente de Investigación Profunda, basado en Gemini 3.1 Pro, ilustra el caso de uso terminal de toda esta infraestructura. Opera combinando fuentes internas del Catálogo de Conocimiento y el Lakehouse con fuentes abiertas en internet, genera planes de investigación estructurados y entrega informes con citas verificables en minutos. Tareas que en áreas como inteligencia competitiva, ciencias de la vida o servicios financieros consumían entre una y tres semanas de trabajo analista pasan a ser el punto de partida, no el punto de llegada.
El Kit de Agentes de Datos completa el cuadro desde el lado del desarrollador. Ofrece herramientas MCP preconfiguradas y tres agentes especializados: uno que convierte instrucciones en lenguaje natural en pipelines gestionados eligiendo entre BigQuery, dbt, Spark o Airflow; otro que automatiza el ciclo completo de modelos de ciencia de datos; y un tercero dedicado a la observabilidad de infraestructura. El Protocolo de Contexto de Modelo actúa como una capa de interoperabilidad que permite que agentes de cualquier proveedor —Gemini, Claude, modelos propios— accedan a los activos de datos sin conectores a medida.
La multinube deja de ser una queja y se convierte en una decisión de arquitectura
Ninguna empresa entre las Fortune 500 opera exclusivamente en Google Cloud. Los sistemas SAP, Salesforce, Workday y Oracle están distribuidos entre AWS y Azure por razones históricas, contractuales y operativas que ningún mandato de CTO puede resolver con un memorando. Durante años, la multinube fue el argumento recurrente para no avanzar con ninguna iniciativa de IA a escala: "primero necesitamos consolidar el dato".
El Data Lakehouse Multinube desmonta ese argumento con especificidad técnica. Usando el Catálogo REST de Iceberg, la Interconexión Multinube y una capa de caché inteligente, BigQuery puede consultar datos en AWS S3 y Azure ADLS con latencia y costo comparables a los de datos nativos en Google Cloud. Un agente de adquisiciones puede combinar en una sola consulta datos de contratos almacenados en S3, inventario en Azure y registros transaccionales en BigQuery, todo bajo un catálogo Iceberg unificado, sin que ningún equipo de ingeniería deba gestionar un proceso de ETL entre nubes.
La implicación para los arquitectos de integración es de orden estratégico. La conversación deja de ser "cómo migramos todo a una sola nube" y se convierte en "cómo gobernamos un catálogo único sobre la distribución de datos que ya tenemos". No es la misma conversación. La primera tiene un costo político y financiero prohibitivo en la mayoría de las organizaciones maduras. La segunda es ejecutable sin disrumpir los contratos existentes con otros proveedores.
Lo que Google está proponiendo, en su conjunto, es un cambio de paradigma con consecuencias organizativas que van más allá de la arquitectura técnica. El MCP como capa de gobernanza de agentes exige ser gestionado con la misma disciplina que hoy se aplica a una puerta de enlace de APIs: versionado, autenticación, monitoreo, límites de uso. El Catálogo de Conocimiento deja de ser un proyecto de documentación y se convierte en una dependencia operativa de tiempo real, lo que implica acuerdos de nivel de servicio, mantenimiento continuo y un modelo de operación que los equipos de datos todavía no tienen diseñado.
La cultura de una organización no es el cartel enmarcado en la sala de juntas ni el discurso del CEO en la convención anual. Es la suma acumulada de todas las decisiones que los líderes tomaron cuando era más cómodo aplazar que decidir, más seguro delegar que asumir, más fácil culpar a la deuda técnica que reconocer que la arquitectura del dato refleja con exactitud quirúrgica la arquitectura del poder, del miedo y de las conversaciones que la dirección nunca tuvo el coraje de sostener.
