Las pilas de datos empresariales se crearon para humanos que ejecutan consultas programadas. A medida que los agentes de IA actúan cada vez más de forma autónoma en nombre de las empresas, las 24 horas del día, esta arquitectura se está desmoronando y los proveedores se apresuran a reconstruirla. La respuesta de Google, anunciada en Cloud Next el miércoles, es Agentic Data Cloud.
La arquitectura tiene tres pilares:
Catálogo de conocimientos. Automatiza la curación de metadatos semánticos al inferir la lógica empresarial a partir de registros de consultas sin intervención manual del administrador de datos.
Casa en el lago entre las nubes. Permite a BigQuery consultar tablas de Iceberg en AWS S3 a través de una red privada sin tarifas de salida
Kit de agente de datos. Incluye herramientas MCP en VS Code, Claude Code y Gemini CLI para que los ingenieros de datos puedan describir resultados en lugar de escribir canalizaciones.
“La arquitectura de datos debe cambiar ahora”, dijo a VentureBeat Andi Gutmans, vicepresidente y director general de nube de datos de Google Cloud. “Estamos pasando de la escala humana a la escala de agentes”.
Del sistema de inteligencia al sistema de acción
La premisa central detrás de Agentic Data Cloud es que las empresas están pasando de operaciones a escala humana a operaciones a escala de agentes.
Históricamente, las plataformas de datos se han optimizado para generar informes, paneles y algunas predicciones, lo que Google caracteriza como “inteligencia reactiva”. En este modelo, los humanos interpretan los datos y deciden qué hacer.
Ahora, con la creciente expectativa de que los agentes de IA tomen acciones directamente en nombre de la empresa, Gutmans argumentó que las plataformas de datos deben evolucionar hacia sistemas de acción. “Necesitamos asegurarnos de que todos los datos empresariales puedan habilitarse con IA, lo que incluye datos estructurados y no estructurados”, dijo Gutmans. “Necesitamos asegurarnos de que exista el nivel adecuado de confianza, lo que también significa que no se trata sólo de obtener acceso a los datos, sino de comprenderlos realmente”.
El Catálogo de conocimientos es la respuesta de Google a este problema. Es una evolución de Dataplex, el producto de gobierno de datos existente de Google, con una arquitectura materialmente diferente debajo. Mientras que los catálogos de datos tradicionales requerían que los administradores de datos etiquetaran tablas manualmente, definieran términos comerciales y crearan glosarios, Knowledge Catalog automatiza este proceso mediante agentes.
La implicación práctica para los equipos de ingeniería de datos es que el Catálogo de conocimientos se escala a todo el conjunto de datos, no solo al subconjunto seleccionado que un pequeño equipo de administradores de datos puede mantener manualmente. El catálogo cubre de forma nativa BigQuery, Spanner, AlloyDB y Cloud SQL y está federado con catálogos de terceros, incluidos Collibra, Atlan y Datahub. La federación de copia cero amplía el contexto semántico de las aplicaciones SaaS, incluidas SAP, Salesforce Data360, ServiceNow y Workday, sin requerir movimiento de datos.
La casa del lago de Google pasa por la nube
Google tiene un lago de datos llamado gran lago desde 2022. Inicialmente se limitaba solo a los datos de Google, pero en los últimos años ha tenido algunas capacidades de federación limitadas, lo que permite a las empresas consultar datos que se encuentran en otros lugares.
Gutmans explicó que la federación anterior trabajaba a través de API de consulta, lo que limitaba las funciones y optimizaciones que BigQuery podía aplicar a los datos externos. El nuevo enfoque consiste en compartir almacenamiento a través del formato abierto Apache Iceberg. Esto significa que, según él, no importa si los datos están en Amazon S3 o en Google Cloud. “Realmente significa que podemos aportar todas las ventajas y todas las capacidades de la IA a estos conjuntos de datos de terceros”, afirmó.
El resultado práctico es que BigQuery puede consultar tablas Iceberg en Amazon S3 a través de Cross-Cloud Interconnect de Google, una capa de red privada dedicada sin tarifas de salida y con un rendimiento de precios que, según Google, es comparable a los almacenes nativos de AWS. Todas las funciones de BigQuery AI se ejecutan en estos datos entre nubes sin modificaciones. La federación bidireccional en versión preliminar se extiende a Databricks Unity Catalog en S3, Snowflake Polaris y AWS Glue Data Catalog mediante el estándar abierto Iceberg REST Catalog.
De escribir pipelines a describir resultados
Knowledge Catalog entre nubes y Lakehouse resuelven los problemas de contexto y acceso a datos. El tercer pilar aborda lo que sucede cuando un ingeniero de datos se sienta a construir algo con todo esto.
El kit de agente de datos se proporciona como un conjunto portátil de habilidades, herramientas MCP y extensiones IDE que se pueden incluir con VS Code, Claude Code, Gemini CLI y Codex. No introduce una nueva interfaz.
El cambio arquitectónico que permite es un paso de lo que Gutmans llamó “experiencia de copiloto prescriptiva” a una ingeniería basada en intenciones. En lugar de escribir una canalización de Spark para mover datos del origen A al destino B, un ingeniero de datos describe el resultado (un conjunto de datos limpio listo para el entrenamiento de modelos, una transformación que aplica una regla de gobernanza) y el agente selecciona si usar BigQuery, Lightning Engine para Apache Spark o Spanner para ejecutarlo y luego genera código listo para producción.
“Los clientes están cansados de construir sus propios oleoductos”, afirma Gutmans. “En realidad están más en modo de revisión que en modo de escritura de código”.
Donde divergen Google y sus rivales
La premisa de que los agentes necesitan un contexto semántico, y no sólo acceso a los datos, es compartida en todo el mercado.
Databricks tiene Unity Catalog, que proporciona gobernanza y una capa semántica en todo su lago. Snowflake tiene Cortex, su oferta de IA y su capa semántica. Tela de Microsoft incluye una capa de modelo semántico creada para inteligencia empresarial y, cada vez más, razonamiento de agentes.
La disputa no gira en torno a si la semántica es importante: todo el mundo está de acuerdo en que lo es. La disputa es sobre quién los construye y mantiene.
“Nuestro objetivo es simplemente obtener toda la semántica posible”, explicó, señalando que Google se federará con modelos semánticos de terceros en lugar de exigir a los clientes que empiecen de nuevo.
Google también está posicionando la apertura como un diferenciador, con una federación bidireccional entre Databricks Unity Catalog y Snowflake Polaris a través del estándar abierto Iceberg REST Catalog.
¿Qué significa esto para las empresas?
El argumento de Google –y que resuena en todo el mercado de infraestructura de datos– es que las empresas están atrasadas en tres frentes:
El contexto semántico se está convirtiendo en una infraestructura. Si su catálogo de datos todavía se selecciona manualmente, no se adaptará a las cargas de trabajo de los agentes, y Gutmans sostiene que la brecha solo se ampliará a medida que aumente el volumen de consultas de los agentes.
Los costos de salida entre nubes son un impuesto oculto sobre la IA de los agentes. Federación basada en almacenamiento a través de estándares abiertos Iceberg se perfila como la respuesta arquitectónica a Google, Databricks y Snowflake. Las empresas que se quedan con enfoques de federación patentados deberían probar estos costos en volúmenes de consultas a escala de agente.
Gutmans sostiene que la era de la escritura sobre tuberías está llegando a su fin. Los ingenieros de datos que pasen a la orquestación basada en resultados ahora tendrán una ventaja significativa.
