Google Next 2026 para la ingeniería de datos: Looker, BigQuery y servidores MCP.

Google Cloud Next 2026 en Las Vegas se llevó a cabo con la envergadura que la marca implica, con ponencias principales y sesiones paralelas distribuidas en un enorme recinto. Para quienes trabajan en proyectos de Looker o BigQuery, las sesiones sobre análisis, integración de datos y análisis basado en agentes fueron las más relevantes. A continuación se detallan los anuncios que deberían cambiar la forma en que se abordan estos trabajos en los próximos doce meses, además de las lecciones extraídas de las conversaciones con clientes, que resultaron ser más útiles que la mayoría de las novedades de los productos.

El enfoque: de responder a actuar

El mensaje general de Google para las plataformas de análisis y datos es un paso de un “sistema de inteligencia” a un “sistema de acción”. El primero se refiere a la BI reactiva que responde cuando se le pregunta. El segundo consiste en un conjunto de agentes proactivos que monitorean métricas, resumen lo que encuentran y toman medidas en beneficio de la empresa.

Nada de esto es nuevo en esencia. Las alertas basadas en eventos y las respuestas automatizadas han existido en las herramientas de BI empresarial durante veinte años. Sin embargo, este énfasis renovado resulta útil, ya que modifica lo que está incluido en el alcance de un proyecto de entrega de Looker encargado en 2026.

Esto tiene una consecuencia práctica para quienes redactan un pliego de condiciones. Antes, los informes y los paneles de control eran el producto final completo. Ahora, la conversación también debe abarcar quién o qué consume los datos (personas o agentes), qué preguntas deben resolver esos agentes por sí mismos, y quién certifica las reglas de negocio de las que dependen. Los proyectos que omiten esta discusión tienden a descubrirla más tarde, durante la implementación, a un costo mayor.

Agentic Data Cloud y sus tres ideas

La presentación principal se centró en Agentic Data Cloud, la respuesta de Google a una discrepancia: las herramientas creadas para que los humanos comprendan los datos nunca estuvieron destinadas a un mundo donde los agentes de IA actúen por sí mismos sobre esos datos. Tres ideas sustentan este enfoque.

Los agentes necesitan significado además de datos. Dirigir un agente potente hacia un conjunto de datos en bruto con la esperanza de que entienda los asuntos empresariales es una apuesta costosa. Debe aprender que el “ingreso neto” no incluye las ganancias, que una métrica se calcula de manera diferente en dos unidades de negocio, o que una cláusula en un contrato modifica la ruta de un envío. El Knowledge Catalog tiene como objetivo capturar y mantener de forma continua ese conocimiento institucional, de modo que cada agente que trabaje con los datos parta de la misma comprensión estandarizada.

Los agentes deben actuar, no solo informar. Un ejemplo de conferencia: en lugar de un panel que muestre un aumento en las cancelaciones de pedidos, un agente detecta ese aumento, realiza un análisis de las causas raíz con los datos de logística y ventas, identifica el centro de distribución responsable, recomienda redirigir los envíos y activa un agente de monitoreo para ver cuándo mejoran las cosas. Nadie tuvo que pedírselo.

Los datos permanecen donde están. Las plataformas en la nube han exigido durante mucho tiempo que todo se traslade a un único lugar antes de que se pueda obtener valor de ellos. Aquí, los agentes consultan los datos dondequiera que se encuentren, ya sea en Google Cloud, AWS, Azure, Snowflake, Databricks o en sistemas locales, sin necesidad de realizar una costosa migración previa.

Looker como capa semántica y capa de experiencia

En términos concretos, la Agentic Data Cloud combina BigQuery, el Knowledge Catalog, Gemini y Looker, siendo Looker la capa de experiencia mientras los cuatro funcionan como un único sistema en lugar de productos separados. El análisis conversacional, los agentes de panel de control, los flujos de trabajo desencadenados y otras funciones de Looker son las formas en que esa arquitectura llega a los usuarios, punto en el que las personas perciben la diferencia entre la BI que solo genera informes y la BI que también toma acciones.

Explore, la versión nueva, va aún más allá. El antiguo modelo de selección de campos y filtros da paso a una interfaz visual de arrastrar y soltar similar a la de Google Search o Google Docs. Dentro de ella hay tres asistentes de Gemini: uno para navegar mediante lenguaje natural, otro que escribe expresiones de Looker a partir de texto en inglés sencillo, y otro que elige el tipo de gráfico más adecuado para la pregunta planteada.

Para los equipos de entrega, esto significa menos tiempo dedicado a guiar a las personas paso a paso a través de la capa de visualización y más tiempo invertido en la calidad de LookML y en la corrección semántica subyacente, ya que los asistentes razonan a partir de lo que define el modelo. Una capa semántica deficiente generará respuestas deficientes, ahora a escala conversacional.

Los Agentes de panel de control están generalmente disponibles. Los paneles de control dejan de ser artefactos estáticos y de solo transmisión: los usuarios pueden cuestionarlos, solicitar resúmenes del contenido y de los cambios, y explorar las razones detrás de una cifra durante la conversación. El ejemplo empresarial más destacado proviene de YouTube, donde los gerentes de socios consultan sobre los portafolios de creadores a partir de quince fuentes de datos fusionadas, todo desde lo que parece ser un panel de control Looker ordinario.

Los flujos de trabajo activados convierten a los agentes de respondedores pasivos en monitores proactivos. Las métricas se registran las 24 horas del día, y los equipos reciben alertas en el momento en que se supera un umbral. La hoja de ruta a corto plazo incluye agentes que redactan correos electrónicos o publican en Slack por sí mismos. Para el análisis operativo, esto es más valioso de lo que parece, y es un tipo de solicitud que los clientes no hacían hace dos años.

Otras noticias de Looker merecen mención:

• Agentes de Looker dentro de Gemini Enterprise. Los agentes desarrollados en Looker pueden publicarse en Gemini Enterprise y gestionarse junto con otros agentes empresariales. Para los clientes que invierten allí, Looker pasa a formar parte de una estrategia de IA más amplia en lugar de ser una herramienta de BI independiente.
• API de análisis conversacional, ahora en GA. Incluye integración nativa con el SDK de Looker, posibilidad de incrustación en iframe y una implementación de referencia de código abierto. Los equipos que integran análisis conversacional en sus propias aplicaciones ahora cuentan con una vía de soporte, y las conversaciones que se detuvieron porque la API solo estaba en versión de prueba pueden reiniciarse.
• LookML Agent para VS Code (versión de prueba). Una extensión que abarca todo el ciclo de vida de LookML, desde el lenguaje natural.
• Looker MCP como estándar abierto. Existe un servidor MCP gestionado junto con opciones de código abierto a través de MCP Toolbox. Conectar Looker a asistentes como Claude permite realizar análisis cruzados y razonamiento basado en agentes más allá de lo que Looker puede gestionar por sí solo.
• Integraciones con capas semánticas nativas. Looker puede leer directamente las definiciones de gráficos de BigQuery y las vistas semánticas de Snowflake, por lo que la lógica semántica ya presente en BigQuery no necesita ser reconstruida en LookML.
• Agentes de exploración múltiple. Un agente puede utilizar hasta cinco exploraciones al mismo tiempo. La configuración de Yahoo combina datos de recursos humanos, finanzas, búsquedas y soporte en agentes únicos distribuidos en varias instancias de Looker.

Qué aprendieron Yahoo y Virgin Media O2

Las sesiones de análisis conversacional de Yahoo y Virgin Media O2 resultaron ser las más valiosas para quienes realizan este tipo de trabajo. El hallazgo principal es que la precisión depende principalmente de dos factores: las consultas clave y las instrucciones para los agentes redactadas en YAML. Yahoo observó una mejor calidad de resultados al pasar las instrucciones de los agentes de JSON a YAML. Luego trasladaron las consultas clave y el glosario empresarial a LookML en lugar de mantenerlos en otro lugar, lo que redujo considerablemente la complejidad de las instrucciones, ya que el modelo ahora razona a partir de la capa semántica y no del contexto escrito a mano.

El resumen propio de Yahoo fue la frase más citada del evento: el análisis conversacional comienza con la capa semántica, no con la inteligencia artificial. Una vez que los datos y el modelo están listos, el análisis conversacional es prácticamente el siguiente paso en la evolución.

La práctica recomendada para los equipos es un cambio de enfoque. En lugar de escribir instrucciones largas y cuidadosamente elaboradas para los agentes, lo más adecuado es enriquecer el modelo en sí, ya que todo lo que se coloca en LookML está disponible para cada agente y cada usuario, mientras que lo que se incluye en una instrucción solo sirve a un agente y se vuelve obsoleto con el tiempo.

Como resultado, un buen modelo LookML para el análisis conversacional ha cambiado. La versión básica ahora incluye etiquetas, descripciones, sinónimos y comentarios en cada campo, consultas estándar integradas en LookML, además de un glosario empresarial en formato YAML dentro del modelo. Las instrucciones para los agentes se mantienen deliberadamente simples, ya que la capa semántica se encarga de la mayor parte del trabajo. La configuración de agentes de Dashboard, flujos de trabajo desencadenados y consultas estándar debería formar parte de los requisitos básicos de cualquier proyecto serio con Looker, y no estar incluida en una lista de elementos opcionales.

Regreso de Data Studio

Looker Studio ha sido rebautizado como Data Studio, con un alcance más amplio. Ahora maneja tres tipos de artefactos. El primero son los informes o paneles de control habituales, que reciben datos de BigQuery, conectores de Google y de socios SaaS, o de la capa semántica de Looker. El segundo es un agente de análisis conversacional desarrollado en BigQuery y publicado allí. El tercero es la nueva idea de “data apps”, en la cual los cuadernos de trabajo de Colab se publican como aplicaciones interactivas.

Las data apps se sitúan entre un panel de control y una aplicación completa. Son relevantes para clientes que dependen de Looker para la generación de informes operativos, desean mayor interactividad y prefieren no desarrollar una aplicación integrada completa.

Una consecuencia de la rebranding y de las nuevas funcionalidades de autoservicio es que el “Studio in Looker” integrado, que alguna vez se presentó como el futuro de la interfaz de usuario de Looker, ya no está disponible para las organizaciones que no lo habían activado, y está programado para ser retirado el 15 de junio de 2026.

BigQuery: agentes de ingeniería de datos y un servidor MCP gestionado

Una buena parte de las versiones preliminares del año pasado ya han pasado a estar disponibles de forma general. Esto incluye los agentes para ingeniería de datos y ciencia de datos, las analíticas conversacionales dentro de BigQuery y su API, el BigQuery ADK, un servidor MCP remoto gestionado para BigQuery, la herramienta MCP de código abierto y un complemento que registra datos telemétricos sobre el rendimiento de los agentes.

Algunos elementos más recientes son más importantes de lo que parecen a primera vista.

Escala dinámica de recursos. BigQuery añade capacidad de procesamiento cuando los agentes están activos y la elimina cuando están inactivos, sin necesidad de ajustes manuales. La objeción común respecto al costo de los análisis conversacionales a gran escala se reduce considerablemente.

Gráficos de BigQuery. Un motor de gráficos nativo que no requiere pasos de ETL, capaz de escalar hasta miles de millones de nodos y que admite ISO GQL. La adición más interesante es Measures en BigQuery Graph, que combina métricas reguladas con mapeo de relaciones y permite a los agentes razonar sobre dependencias de múltiples niveles.

Medidas como extensiones del razonamiento. Una forma útil de distinguir estos dos tipos de medidas es la siguiente: las medidas de LookML regulan los cálculos, definiendo qué significa una métrica y garantizando un SQL consistente para todos los analistas y agentes que utilizan Looker. Las medidas de gráfico, por su parte, regulan el razonamiento, al colocar las mismas definiciones de métricas dentro de un gráfico formado por entidades conectadas como productos, proveedores, centros y rutas, de modo que un agente pueda determinar por qué una métrica ha cambiado siguiendo las relaciones entre los factores que la influyen.

Servicios de migración

El Servicio de Migración de BigQuery ha sido renombrado como Servicios de Migración para Análisis de Datos, y se trata de una reforma de gran envergadura, por lo que quienes planeen pasar de Snowflake, Cloudera o Databricks en 2026 deberían reconsiderarlo. En el caso de Cloudera y Databricks, la evaluación es automática y genera un plan que enumera las cargas de trabajo con estimaciones del costo total de propiedad. El SQL de Hive, Snowflake y otros dialectos se traduce a GoogleSQL a nivel de compilador. La migración de tipo lakehouse maneja tablas en formatos Iceberg, Parquet y Hive, y un servicio de validación basado en agentes se ejecuta en tiempo real, evaluando la precisión tabla por tabla y columna por columna. Dado que las API de migración son accesibles a través de MCP, una herramienta como Claude Code podría orquestar toda la migración.

Las versiones anteriores del servicio tuvieron un rendimiento mixto en la traducción de consultas SQL complejas, y la nueva generación parece mucho más sólida. El panel de validación destaca, ya que se encarga de gran parte de las verificaciones manuales que durante años han retrasado los cronogramas de migración. Los equipos que anteriormente habían presupuestado semanas de trabajo de analistas comparando manualmente las cantidades de filas y los valores de columnas deberían revisar esas estimaciones.

Federación entre nubes

En cuanto a la federación, el Databricks Unity Catalog en AWS S3 ahora puede ser leído en ambas direcciones, y Snowflake Polaris y AWS Glue también pueden ser leídos desde BigQuery. Todo se basa en el estándar de catálogo REST Apache Iceberg, por lo que BigQuery puede consultar estos catálogos externos directamente sin necesidad de mover datos.

Para los clientes que no pueden o no quieren migrar por completo, el enfoque cambia. En lugar de insistir en que todo se traslade a BigQuery, la propuesta pasa a ser: dejar los datos donde están, acceder a ellos a través de BigQuery y añadir Looker y Conversational Analytics por encima. Las empresas de Snowflake que de otro modo quedarían excluidas de un enfoque analítico basado en GCP obtienen una verdadera opción, una que probablemente sirva como paso intermedio hacia migraciones más completas.

Lecciones de migración de Target, Wells Fargo y Virgin Media O2

Un panel formado por estas tres empresas reveló patrones que muchas personas han aprendido a costa de dificultades, pero que merecen ser repetidos.

La primera regla, y la más importante: llevar primero la capa semántica. Implemente la capa de Looker o BI en GCP para que los usuarios empresariales puedan acceder a los datos mientras la ingeniería de datos aún está en proceso de traslado, y cierre esa brecha con tareas de replicación táctica que copien los conjuntos de datos clave a BigQuery. Virgin Media O2 ha logrado esto a través de seis grandes migraciones de plataforma, y Wells Fargo ha respaldado este enfoque.

Otros patrones:

• Reducir el volumen de datos antes de migrar. La IA puede identificar datos no utilizados y duplicados de antemano; una empresa del grupo encontró que más del 80% de sus datos estaban duplicados.
• Primero realizar la migración directa y luego modernizarla. Refactorear durante la migración alarga los plazos de forma impredecible.
• Establezca mecanismos de gobernanza desde el primer día. Los contratos de datos, un glosario empresarial y las reglas de calidad de datos deben formar parte del programa de migración, ya que su implementación posterior suele fracasar una vez que se cierra la ventana política.
• Comience de forma sencilla con los contratos de datos. Elija un área definida, redacte contratos claros entre proveedores y consumidores para ese caso, y úselos como modelo de lo que constituye una buena práctica antes de escalar.

Target también propuso un enfoque útil que vale la pena adoptar: los “objetivos irracionales”. Elija metas que no puedan alcanzarse a menos que la plataforma se reconstruya utilizando métodos propios de la IA. De este modo, la discusión se desvía de cómo migrar hacia cómo transformar.

Kit de Agentes de Datos

En la versión de previsualización, el Data Agent Kit combina una extensión de VS Code con plugins para Gemini CLI, Cloud Code y Codex. Juntos, ofrecen habilidades y herramientas MCP para flujos de trabajo con datos de BigQuery: habilidades de tipo agente, servidores MCP, herramientas para acceder a BigQuery y plugins para una personalización avanzada de VS Code. Las propias habilidades son de código abierto y pueden ser adaptadas.

Las consultoras y los equipos de clientes que ya están desarrollando herramientas internas de entrega basadas en agentes deberían evaluarlo seriamente. Según una primera impresión, abarca la ingeniería a nivel de BigQuery y complementa la orquestación general de entregas y LookML, integrándose con los enfoques basados en habilidades que ya se utilizan.

Knowledge Catalog, anteriormente Dataplex, como contexto del agente

Dataplex ahora se denomina Knowledge Catalog y funciona como backend de contexto para los flujos de trabajo basados en agentes de Google Cloud. Está sustentado por tres pilares fundamentales. El primero agrega metadatos de los servicios de Google, incluido Looker, así como de catálogos de socios como Atlan, Collibra y SAP. El segundo enriquece esos metadatos mediante generación automática y un glosario empresarial ya en versión final. El tercero ofrece búsqueda semántica, a través de una API de contexto que permite a los agentes obtener lo que necesitan.

El caso más ilustrativo provino de Bloomberg Media. Su “Knowledge Gap Agent” aprende de los fallos de los agentes, detecta dónde el contexto de los datos es incorrecto o está faltante, y propone actualizaciones al Knowledge Catalog para su verificación por parte de humanos. El resultado principal: se generaron automáticamente 102 notas de uso en veinte tablas MVP, lo que aumentó en un 63% la precisión de un agente de acceso a datos mediante SQL.

Para proyectos de menor escala, Knowledge Catalog permanecerá en segundo plano. Para aquellos clientes que desarrollan agentes de análisis conversacional a gran escala, y cuyo conocimiento institucional aún no está codificado en ningún lugar al que pueda acceder un agente, este representa la pieza que falta. Bloomberg denominó a este problema subyacente el “problema de los 42 dólares”, que afecta tanto a los analistas humanos como a los agentes de IA: conocimientos que no están documentados en ninguna parte de la plataforma de datos.

En su ejemplo, un analista junior seleccionó las tablas adecuadas, escribió SQL válido y aplicó la lógica estándar de ingresos netos, pero obtuvo un resultado incorrecto. El proveedor de pagos cobra una tarifa de 42 dólares por cada disputa con el cliente, y dicha tarifa debe sumarse al cálculo de ingresos. La regla no se encontraba en ningún esquema, en ninguna secuencia de procesamiento ni en ningún documento accesible. Existía únicamente en una página de Confluence de 2017 cuyo autor ya había dejado la empresa.

¿Falta el motor semántico?

Una crítica que circuló posteriormente sostiene que Google se enfoca por completo en la capa de agentes, mientras que su contexto semántico y empresarial permanece relativamente débil. Según esta perspectiva, el Knowledge Catalog se asemeja a un agregador de metadatos, sin tener apenas las características de un verdadero sistema operativo empresarial como Frontier de OpenAI o Foundry de Palantir. Sin un motor semántico sólido que vincule el significado empresarial con los agentes, incluso las herramientas avanzadas corren el riesgo de generar resultados erróneos, alucinaciones o dar una respuesta correcta a la pregunta equivocada.

La mayor parte de esa diagnosis sigue siendo válida, y la capa semántica es más importante en un mundo basado en agentes que lo fue nunca en uno basado en paneles de control. La interpretación más optimista es que la capa semántica de LookML ya cubre la mayor parte de las funciones relacionadas con el contexto empresarial que se esperaría que realizara un sistema operativo empresarial. Elimina el problema de las múltiples versiones de la verdad, proporciona definiciones de métricas reguladas y funciona como almacén confiable de métricas para asistentes como Claude a través de MCP Toolbox.

El hecho de que el Catálogo de Conocimientos hablara poco sobre la integración de LookML en la conferencia no significa que LookML esté inactivo. El trabajo se lleva a cabo en una capa más profunda de la que buscan los críticos.

La evidencia concreta se encuentra en las prácticas recomendadas documentadas por Google para configurar Conversational Analytics en Looker. Estas prácticas se basan en dos fuentes principales: la estructura, los campos, las etiquetas, las descripciones y los sinónimos del modelo LookML, y los valores de campo distintivos extraídos de los datos, donde la cardinalidad (el número de valores únicos) determina cómo se utilizan dichos valores.

Para obtener los valores distintivos, Conversational Analytics utiliza el método de la API de Looker de larga data model_fieldname_suggestions. Este es el mismo mecanismo que se emplea para las sugerencias de filtros en el selector de campos y en los filtros de los paneles, y ahora se reutiliza como señal de referencia para el modelo. Por lo tanto, tres parámetros existentes de LookML, suggestions, suggest_explore y suggest_dimension, también sirven como herramienta para que los desarrolladores decidan qué valores debe conocer Conversational Analytics.

Los equipos no tienen que esperar a que el producto haga esto; se puede armar la misma estructura a mano en un almacén de BigQuery. Además de un diccionario de datos estándar derivado de INFORMATION_SCHEMA, se puede mantener una guía en formato markdown, accesible para un asistente como una habilidad y regenerada periódicamente mediante un paso de análisis. Esta guía describe cada tabla con el número de filas, rangos de fechas, así como los conjuntos de valores y las cardinalidades de los campos categóricos de mayor importancia, de modo que el asistente sepa, por ejemplo, que una tabla de mensajes está distribuida entre iMessage, Slack, WhatsApp y otros en proporciones conocidas, en lugar de tener que adivinarlo.

Analítica conversacional ahora realiza lo mismo en la capa LookML, de forma generalizada para todos los usuarios de Looker. Tome una dimensión city rellenada con datos de clientes u operativos. El sistema tomará muestras de sus valores distintos, como Brighton, Hove y Londres, y permitirá que la cardinalidad decida cuánto peso deberá tener cada valor cuando los usuarios hagan preguntas.

Las herramientas a disposición del desarrollador de LookML son esos tres parámetros, que se utilizan de la siguiente manera:

view: customer {
  dimension: city {
    label: "Customer City"
    description: "The city associated with the customer's primary address. Most operational activity occurs in Brighton and Hove (UK head office) and London (UK secondary office)."
    type: string
    sql: ${TABLE}.customer_city ;;
    # Hard-code a curated list of values rather than letting Looker
    # run SELECT DISTINCT against a large table.
    suggestions: ["Brighton", "Hove", "London", "Edinburgh", "Manchester"]
  }
  dimension: customer_segment {
    label: "Customer Segment"
    description: "Customer tier based on annual recurring revenue."
    type: string
    sql: ${TABLE}.segment ;;
    # Pull suggestions from another view rather than scanning
    # the much larger customer fact table.
    suggest_explore: segments
    suggest_dimension: segments.segment_name
  }
}

Combinados con descripciones, sinónimos y algunas consultas clave integradas en el modelo, estos elementos proporcionan a la capa semántica de LookML exactamente lo que los críticos esperan de un sistema operativo empresarial: un contexto empresarial fundamentado y regulado para la capa de agentes, con muestreo de valores reales que tenga en cuenta la cardinalidad, todo ello gestionado a partir del mismo LookML que se utiliza en los paneles de control y las herramientas de exploración.

Por lo tanto, la interpretación del Catálogo de Conocimiento en comparación con LookML es diferente. Actualmente, LookML parece ser solo una de las muchas fuentes de información dentro de la arquitectura del Catálogo de Conocimiento, y es fácil comprender por qué esto puede parecer insuficiente. En los próximos doce a dieciocho meses, se espera que esto cambie significativamente, ya que Google tiene todos los motivos para convertir a LookML en la fuente principal del catálogo y no solo en una más entre varias.

El motor semántico que piden los críticos en realidad no falta, ya que gran parte de él ya existe en LookML. Lo que sigue sin resolver es si Knowledge Catalog evolucionará hasta convertirse en la capa de contexto empresarial que transmitirá el significado de LookML a través de toda la pila de agencias, o si otro producto ocupará ese papel. De cualquier manera, el tiempo invertido en hacer que LookML funcione correctamente es tiempo que se retribuye.

Leer más

• Notas prácticas: RAG está muerto. LLM Wiki, la idea de Andrej Karpathy, es lo que viene a continuación: Guía detallada de Notas prácticas: RAG está muerto. LLM Wiki, la idea de Andrej Karpathy, es lo que viene a continuación: contratos, verificaciones y espacios para código listo para usar para los equipos que desarrollan soluciones RAG.
• Spring AI en la empresa: Un agente de soporte con herramientas, RAG y revisión: Crea un asistente para la triaje de incidentes con Spring AI: prompts como contratos, salida estructurada, llamadas a herramientas, MCP, Qdrant RAG, capacidad de observabilidad y bucles de agente limitados.