Saltar al contenido principal

Charla · data2day 2026

Agentic Analytics: From Hype to Real Value

Fabian Biberger (Founding Engineer, Entropy Data) ·

La charla de Fabian Biberger en data2day 2026, en Colonia, impartida en alemán con el título Agentic Analytics: Wie aus Hype echter Mehrwert wird. Recorre el camino de Entropy Data: de un servidor MCP a un chatbot con gobernanza, qué contexto necesita un agente para trabajar de forma fiable sobre los datos, y Apache Ossie para ontologías y modelos semánticos.

Diapositiva de título: Agentic Analytics, Wie aus Hype echter Mehrwert wird, Fabian Biberger, data2day, 07.10.2026, junto a una captura del chatbot de Entropy Data recomendando el producto de datos Orders

Un resumen editado de la charla, traducido del alemán.

Punto de partida, qué hacemos en Entropy Data: un marketplace de productos de datos (Data Contracts, multiplataforma, self-service), estándares abiertos de metadatos (metadatos portátiles, sincronización de metadatos con Git, herramientas open source, ODCS, ODPS, Apache Ossie) y automatización (pruebas de contrato automatizadas, scoring de calidad de datos, gobernanza asistida por IA, Data Contract CLI)

El punto de partida de Entropy Data

  • Un marketplace de productos de datos con Data Contracts, multiplataforma y self-service.
  • Estándares abiertos: ODCS, ODPS y Apache Ossie.
  • Automatización: pruebas de contrato con la Data Contract CLI, scoring de calidad de datos, gobernanza asistida por IA.
Motivación: 01 mejorar la búsqueda en el marketplace de datos, 02 habilitar IA analítica con gobernanza, 03 crear un entorno de pruebas para nuevos productos de datos, 04 habilitar el desarrollo de productos de datos asistido por agentes

Cuatro razones para ir a lo agéntico

  1. Mejor búsqueda en el marketplace de datos.
  2. IA analítica con gobernanza.
  3. Un entorno de pruebas para nuevos productos de datos.
  4. Desarrollo de productos de datos asistido por agentes.
MCP: un cliente de IA con una pregunta o una tarea de agente llama a Entropy Data, que ofrece herramientas MCP como Search, Fetch y Execute Query detrás de una capa de Data Governance, conectada al marketplace (metadatos de los productos de datos) y a la plataforma de datos (los datos reales). Varias herramientas, con soporte para comprobaciones de gobernanza y solicitudes de acceso

Primer paso: un servidor MCP

  • Los clientes de IA como Claude o ChatGPT se conectan al marketplace mediante MCP.
  • Herramientas: buscar productos de datos, recuperar Data Contracts, ejecutar consultas.
  • Entre medias están las comprobaciones de gobernanza y las solicitudes de acceso.
Bocadillo sobre una captura de chat difuminada: Qué buena pinta. Pero nunca podremos usarlo.

«Qué buena pinta. Pero nunca podremos usarlo.»

  • Gobernanza: MCP reúne los datos en un equipo personal, fuera de la gobernanza.
  • Disponibilidad: muchas empresas no tienen ningún cliente de chat aprobado, o solo Copilot.
  • Decisión: construir nuestro propio chatbot.
Estamos construyendo un chatbot: el chat de Entropy Intelligence, dentro del marketplace de Entropy Data, responde qué producto de datos usar para el comportamiento de compra de los clientes y recomienda Orders. Un panel lateral muestra el progreso, la finalidad, la gobernanza, el producto de datos, la semántica, el modelo de datos, la conexión y el SQL

Así que construimos un chatbot

  • Entropy Intelligence vive dentro del marketplace, bajo la gobernanza existente.
  • El system prompt se ajusta a los casos de uso de Entropy Data.
  • Las herramientas MCP están integradas directamente y la gobernanza no se puede eludir.
Interfaz de usuario, control sobre la interfaz: un panel lateral con el producto de datos Customers y sus cuatro Output Ports con contratos, y doce conceptos semánticos como Order, Order ID, Customer ID, Customer Email y Billing Address
El chatbot responde a «dame acceso a customers»: recomienda el puerto de Databricks sin PII según las AI instructions del Data Product Owner, advierte de que el usuario aún no tiene acceso y muestra un botón Request Access con el aviso de que el acceso se ha aprobado

«Neue Features lassen sich einfach kommunizieren»: cuando controlas la interfaz, las nuevas funcionalidades son fáciles de comunicar.

Interfaz de usuario

  • Mejor trazabilidad gracias al panel de contexto: producto de datos, Output Ports, conceptos semánticos y finalidad de un vistazo.
  • Nuevas funcionalidades integradas directamente, por ejemplo un botón Request Access en plena conversación.
  • Elementos de interfaz reutilizados, como los chips y los iconos del marketplace, ayudan a los usuarios a orientarse.
Conexión con la plataforma de datos, una cuenta por organización: JD (marketing), Turk (control de gestión), Elliot (ventas) y Carla (data engineering) pasan todos por Entropy Data y una sola cuenta de servicio entropy-data hacia Databricks, que solo ve un usuario. El registro de auditoría muestra entropy-data SELECT orders, customers, revenue

¿Quién consulta realmente los datos?

  • Una sola cuenta de servicio para toda la organización.
  • Databricks solo ve un usuario: entropy-data.
  • El registro de auditoría ya no muestra quién accedió a qué.
Una cuenta por usuario con OIDC: los mismos cuatro usuarios pasan por Entropy Data, que obtiene su identidad de un proveedor de identidad como Entra ID, y cada usuario se conecta a Databricks con sus propias credenciales. Databricks ve y comprueba a cada usuario de forma individual. El registro de auditoría muestra jd, turk, elliot y carla
  • OIDC: el proveedor de identidad, por ejemplo Entra ID, traslada cada identidad a la plataforma.
  • Databricks comprueba cada acceso de forma individual y el registro de auditoría vuelve a ser útil.
  • Principio: decide primero bajo qué identidad se ejecuta el acceso a los datos.
El contexto adecuado: ¿qué necesita un agente para trabajar con éxito sobre los datos?
El contexto adecuado: siete factores alimentan el rendimiento de la analítica con IA (fiabilidad, calidad, consistencia): ontologías, modelos semánticos (métricas y dimensiones), modelo de datos documentado, estructura de la empresa, data lineage, datos de ejemplo y datos con calidad silver como mínimo

El contexto adecuado: siete factores

  • Lo básico: datos con calidad silver como mínimo y un modelo de datos documentado.
  • Los aceleradores: estructura de la empresa, data lineage y datos de ejemplo.
  • La semántica: modelos semánticos (métricas, dimensiones) y ontologías (conceptos compartidos).
Los mismos siete factores, ahora con los estándares y las herramientas que los cubren: ODCS para el modelo de datos documentado, la Data Contract CLI para la calidad silver, OpenLineage para el data lineage, Entropy Data para la estructura de la empresa y los datos de ejemplo. Las ontologías y los modelos semánticos aparecen marcados con signos de interrogación

Cinco cubiertos, dos pendientes

  • Modelo de datos y calidad silver: cubiertos por los Data Contracts y las pruebas de contrato.
  • Data lineage mediante los enlaces entre productos de datos y OpenLineage, datos de ejemplo en parte dentro de los Data Contracts, estructura de la empresa como equipos y dominios.
  • Todavía pendiente: los modelos semánticos y las ontologías.
El contexto adecuado: ¿cómo representamos las ontologías y los modelos semánticos para los agentes?
Apache Ossie (incubating), el estándar universal para datos semánticos: un esfuerzo de especificación de todo el sector para normalizar cómo se intercambian los metadatos semánticos entre plataformas de analítica, IA y BI, antes conocido como Open Semantic Interchange. 100 % neutral respecto al proveedor, configuración YAML, Apache 2.0, AI ready

Apache Ossie

  • Antes Open Semantic Interchange (OSI), ahora Apache Ossie.
  • Un proyecto Apache en incubación para modelos semánticos y ontologías.
  • Entropy Data lo soporta como formato para la semántica.
Ontología y modelo semántico: la ontología cubre los conceptos de negocio, las relaciones y las reglas; el modelo semántico cubre las dimensiones, las métricas y las agregaciones
Ontología, conceptos y relaciones: un grafo con Order, Line Item, Article, Product, Shipment, Shipping Address, Billing Address, Postal Address y B2B Customer, conectados por relaciones como places, contains, ships_to, bills_to, fulfilled_by, references, has_variant, is a y subsidiary_of

Ontología y modelo semántico

  • Ontología: conceptos como Order, con sus propiedades.
  • Las relaciones aportan significado: un pedido ships to una dirección de envío.
  • Más significado significa más contexto para el agente.
Modelos semánticos, métricas, dimensiones, agregaciones: los modelos semánticos de dbt, Power BI, Tableau, Looker y otros alimentan un único modelo semántico
  • Modelo semántico: métricas, dimensiones y agregaciones sobre los datos.
  • Conocido de dbt MetricFlow, Power BI, Tableau y Looker.
  • La lógica de cálculo, como el valor del pedido, se define en un solo lugar.
Mapeo de ontología: los conceptos de negocio se anclan en la capa semántica mediante un mapeo de la ontología al modelo semántico
  • Ossie ancla la ontología en los modelos semánticos.
  • Una capa de mapeo vincula cada concepto con el lugar donde aparece.
  • Con ese vínculo, el agente construye mejores consultas.
El contexto adecuado, completo: los siete factores ya están cubiertos, con Apache Ossie para las ontologías y los modelos semánticos

Por dónde empezar

  • Empieza por lo básico: un modelo de datos documentado y datos con calidad silver.
  • La estructura de la empresa, el data lineage y los datos de ejemplo llegan como refuerzo.
  • Los modelos semánticos y las ontologías aportan mejores resultados y más trazabilidad.
Identidad del agente: on behalf of the user, la identidad viene del contexto del usuario y el agente actúa en su nombre. Agent as a service: el agente recibe su propia identidad y se necesitan metadatos adicionales

Los agentes están llegando

  • Los agentes autónomos también necesitan una identidad.
  • On behalf of the user: la identidad viene del usuario, como hoy en el chatbot.
  • Agent as a service: una identidad propia, más metadatos como el operador.
Perspectiva, purpose-based access: un analista o un agente solicita acceso. El purpose-based access control pregunta por qué, con qué finalidad. El agente indica como finalidad el marketing directo. El PBAC compara la finalidad declarada con las condiciones de uso del Data Contract y la semántica, y solo entonces concede acceso a los datos

Perspectiva: Purpose-based Access

  • Los analistas y los agentes deben indicar para qué necesitan los datos.
  • La finalidad se comprueba contra las condiciones de uso del Data Contract y la semántica.
  • Una idea surgida del turno de preguntas: limitar el acceso en el tiempo, por ejemplo a la sesión del agente.
¡Gracias! ¿Preguntas? Pasa por nuestro stand, te lo mostramos todo en vivo encantados. Escribe a fabian.biberger@entropy-data.com. Prueba Entropy Intelligence: lanza la demo de 1 clic en www.entropy-data.com

Pruébalo tú mismo

Artículos relacionados

A Data Marketplace is What Your Agent Needs

Por qué los agentes de IA necesitan un marketplace de datos, para leer datos con herramientas gobernadas y para construir nuevos productos de datos, con dos demos en vivo.

¿Qué es Apache Ossie?

El estándar abierto para ontologías y modelos semánticos, antes conocido como Open Semantic Interchange.

¿Qué es Purpose-based Access Control?

Los agentes de IA deciden en tiempo de ejecución qué datos necesitan. Purpose-based Access Control comprueba cada consulta contra las condiciones de uso del Data Contract.