A Data Marketplace is What Your Agent Needs

El ponente

Simon Harrer es software engineer de corazón y aterrizó en el mundo de los datos hace unos cinco años, con el auge del Data Mesh. Es coautor de "Java by Comparison" (que, comenta con una sonrisa, hoy forma parte de los datos de entrenamiento de varios modelos de lenguaje), tradujo al alemán el "Data Mesh" de Zhamak Dehghani y creó el sitio Data Mesh Architecture.

Mantiene la Data Contract CLI, que es open source, y forma parte del Technical Steering Committee que impulsa el Open Data Contract Standard.

Su trabajo del día a día es Entropy Data, la empresa que fundó con Jochen Christ y que cumplía un año justo la semana de la charla. Seis personas, clientes en ocho países, nada de capital riesgo y muchísimos tokens.

El spoiler, por delante

Toda la charla en una frase: los agentes necesitan marketplaces de datos para dos cosas: para leer datos y para construir productos de datos.

Todo lo que viene después es la defensa de esa afirmación, más dos demos en vivo que muestran cada mitad en acción. Primero leer, después construir.

¿Qué es un agente?

Pregunta a diez personas y te darán diez respuestas. La de Simon, imperfecta pero útil: un agente es un LLM que usa herramientas en un bucle. Conectas un modelo, le das una tarea y lo dejas correr en bucle: llama a herramientas, observa resultados, llama a más herramientas, hasta que decide que ha terminado.

Ese agente puede correr en tu portátil o en la nube. Lo puede arrancar una persona, otro agente, un evento o un latido que se dispara sin parar. El disparador da igual. El bucle es el mismo.

Y el bucle ya está resuelto: cualquier framework te lo regala. Los modelos hoy son un commodity (caro, pero commodity). Donde marcas la diferencia es en las herramientas. Las herramientas son la forma en que un agente lee, escribe, gestiona estado y toca el mundo exterior. Ahí pasa todo lo interesante.

La vía ingenua: darle todo al agente

Toma una tarea sencilla: "¿Quiénes son nuestros mejores clientes?" Dásela a un agente con un LLM y un bucle pero sin herramientas y no obtendrás nada: el modelo no tiene ni idea de quiénes son tus clientes. Hay que conectarlo a los datos de verdad.

Podrías enchufar el agente directamente a todas las bases de datos internas. Descubriría lo que hay, lo evaluaría, lanzaría SQL y devolvería una respuesta. La magia del bucle lo resuelve solo.

Y todos estaremos de acuerdo en que nadie va a hacer eso. Dale a un agente la llave maestra de todos los datos de la empresa y coleccionarás infracciones del RGPD por minuto. El acceso sin gobernanza no es una opción.

Pon un marketplace en medio

La solución es un marketplace de datos situado entre el agente y los datos, una capa de protección que le entrega al agente un conjunto de herramientas en lugar de las llaves en bruto:

• Descubrimiento: qué datos existen y dónde están
• Semántica: qué significan realmente los datos
• Calidad y señales de confianza: si los datos cumplen su contrato
• SLA: frescura, latencia, disponibilidad
• Términos de uso: qué puedes y qué no puedes hacer con los datos
• Gestión de acceso: solicitar acceso y después usarlo

El marketplace añade la gobernanza en medio. Y como cada llamada, hasta la propia consulta, pasa por esa capa, la gobernanza sigue activa incluso mientras se leen los datos. Esa capa intermedia que intercepta es toda la idea.

Un agente respondiendo una pregunta de negocio

La demo usa un agente embebido en el producto de Entropy Data, conectado al marketplace. El prompt: "Agrupa por país los pedidos de los últimos 30 días y visualízalo en un gráfico." (Corriendo sobre Haiku, por velocidad.)

A la derecha se ve cada paso. El agente analiza el propósito, busca el producto de datos de pedidos, filtra los últimos 30 días, agrupa y agrega por país y dibuja un gráfico. La respuesta llega como tabla: Francia lidera con 314 pedidos y Países Bajos le sigue con 294, tras unas dieciséis llamadas a herramientas.

La potencia está en esas llamadas a herramientas, no en la burbuja del chat. El agente nunca vio la base de datos en bruto. Descubrió, evaluó y consultó todo a través del marketplace.

Anclado en una capa semántica

¿Cómo supo el agente qué es un "pedido"? Porque cada campo está anclado en una capa semántica. En el grafo, la entidad Order enlaza con Shipping Address, Line Item, Customer, Order ID y métricas como Average Order Value y Contribution Margin.

Entropy Data lo construye sobre OSI, el Open Semantic Interchange, que arrancó Snowflake y hoy es una iniciativa amplia a la que se ha sumado Entropy Data. Así el agente sabe qué significa cada campo y cómo se conecta todo, y encima sobre un estándar abierto.

La interfaz es solo para las personas. El agente consume esos mismos metadatos directamente.

Productos de datos, contratos y consultas gobernadas

El agente eligió el producto de datos Orders y leyó su Data Contract: dos tablas, el esquema completo, las garantías, para confirmar que podía responder la pregunta. Después comprobó el acceso. Si le faltara, el agente lo solicitaría (y en algunos casos la solicitud está totalmente automatizada).

El acceso es por propósito. Cada consulta tiene que llevar un propósito, y una comprobación de gobernanza lo contrasta con el contrato: si el contrato prohíbe, por ejemplo, el uso para marketing, el marketplace detiene la consulta en pleno vuelo, antes de que llegue a Snowflake.

"Tienes que indicar un propósito en cada consulta. Ninguna persona haría eso jamás. Un agente lo hace sin esfuerzo, porque conoce su propio contexto, así que podemos comprobar el propósito y dejarla pasar o pararla. Ese es el poder del marketplace como capa que intercepta."

O trae tu propio agente

El agente de la demo va embebido en el producto, pero nada te obliga a eso. Puedes construir tu propio agente en el framework que quieras, con el modelo que quieras, y conectarlo al marketplace mediante herramientas MCP.

Por debajo llama exactamente a las mismas herramientas: descubrimiento, semántica, calidad, SLA, términos de uso y acceso. La opción embebida solo facilita el despliegue.

Por qué funciona: cinco factores de éxito

• Construido sobre productos de datos y Data Contracts: propiedad clara, mentalidad de cliente y garantías sobre los datos, expresadas en el Open Data Contract Standard.
• Anclado en la semántica: cada campo enlazado a una capa semántica compartida (OSI), para que el agente sepa qué significan las cosas.
• Metadatos optimizados para agentes sobre estándares abiertos: los formatos incluyen a propósito ejemplos, contexto y sinónimos. Genial para los agentes y, resulta, genial también para las personas.
• Cumplimiento por diseño: la capa intermedia revisa las consultas en pleno vuelo, lo que da mejor gobernanza y control de acceso por propósito.
• El marketplace como caja de herramientas: un único lugar central donde todo se junta. Enchufas una cosa y te llevas todo el beneficio, en vez de coser la semántica por aquí, la calidad por allá y el acceso en otro sitio.

"Si das soporte a los agentes, automáticamente se lo das a las personas. Si se lo das a las personas, no se lo das automáticamente a los agentes. Un agente sin los metadatos adecuados simplemente hace lo incorrecto con total seguridad."

Una necesidad, dos consumidores

Este es el corazón del estudio de BARC que da nombre a la charla: resulta que un agente de IA y un analista humano necesitan lo mismo de un marketplace de datos: poder descubrir, contexto y semántica, confianza y gobernanza, señales de calidad. Misma base, distinta interfaz.

Un agente hace lo que le dices y suele creer que tiene razón. Sin guardarraíles ni metadatos hará cosas que no pretendías; no por maldad, sino con toda la seguridad del mundo. Las personas al menos conocen las reglas no escritas. Así que hay que ser explícito, y ser explícito para el agente le sale gratis a las personas.

Construir "shelf warmers"

El producto de datos de ejemplo son los shelf warmers, jerga del e-commerce para el stock que se queda en la estantería, acumula polvo y nunca se vende. (Simon pasó una temporada en un retailer, de ahí vienen los ejemplos de e-commerce.)

El sueño es decirle a un coding agent "constrúyeme un proyecto dbt en Databricks para el producto de datos shelf warmers" e irte a otra cosa. No funciona, por dos motivos. El agente no sabe qué construir y no sabe cómo construirlo a la manera de tu empresa.

Resolver ambas cosas es el resto de la historia.

Paso 1, entender: empieza con una conversación

"Constrúyemelo" falla porque nadie decidió qué es el producto. Así que vuelves a la pizarra y hablas con la gente: ¿cuál es el propósito de este producto de datos y hasta dónde llega su alcance?

Una buena herramienta para eso es el Data Product Canvas gratuito del sitio Data Mesh Architecture: rellénalo en un taller en grupo, esboza un par de variantes y saldrás sabiendo el valor, las entradas y la forma de lo que quieres construir.

Paso 2, especificar: escribe el contrato

Cuando ya sabes qué quieres, especificas el contrato: lo que tu producto ofrecerá a sus consumidores y lo que el agente puede usar de verdad como punto de partida. Para shelf warmers es una única tabla: la unidad de stock (el ID), el nombre del artículo, cuándo se vendió por última vez y el processing time en que se insertó.

Puedes capturarlo como mejor le venga al equipo. La plantilla Excel de ODCS existe por demanda popular, no porque nadie la planificara, y luego se convierte a YAML. O usa el Data Contract Editor open source para escribir rápido un contrato conforme al estándar.

En cualquier caso acaba siendo YAML de ODCS, que además puedes visualizar, y después lo guardas en el marketplace.

Paso 3, construir: el agente lee el contrato

Ahora el coding agent puede traerse el contrato desde el marketplace y ponerse a construir: conoce la tabla destino y sus campos. Pero el contrato es solo la mitad de lo que le da el marketplace.

La otra mitad: el agente usa el marketplace para averiguar de dónde deben venir los datos. Descubre productos de datos existentes, evalúa cuáles pueden rellenar los cuatro campos, los combina e incluso solicita acceso; las mismas herramientas gobernadas que usaba el agente lector, ahora apuntando a construir el pipeline.

Saber cómo: skills en un plugin

El contrato y el marketplace cubren qué construir y dónde viven los datos. No cubren el cómo: tus convenciones, tu proceso interno, las buenas prácticas de dbt, las tecnologías que usas. Para eso añades skills desde un repositorio de plugins.

El dbt Data Product Builder, que es open source, agrupa skills como dataproduct-bootstrap (montar un proyecto dbt nuevo a partir de una plantilla), dataproduct-implement (traducir el esquema del contrato a modelos dbt y construirlos) y dataproduct-exampledata (extraer filas de ejemplo, quitar los datos personales que marca el contrato y sincronizarlas).

Lo instalas como plugin, aquí en Claude, y listo. Skills en el coding agent, marketplace conectado, prompt lanzado.

Un prompt y a otra cosa

Aquí el coding agent es Claude Code, con el plugin del data product builder instalado y el marketplace conectado. Toda la instrucción cabe en una línea:

"Implementa un producto de datos que cumpla el Data Contract con ID shelf-warmers."

A partir de ahí va solo. Se muestra como una grabación de pantalla, porque en vivo la construcción tarda unos diez minutos, así que aquí le damos al avance rápido.

El resultado

El agente disparó la skill de implementación, se lo pensó bien y escribió un proyecto dbt completo: Input Ports, Output Ports y la transformación que une los artículos con el stock actual y la última venta.

Al ejecutar el proyecto dbt, creó la base de datos, el esquema y la tabla SHELF_WARMERS en Snowflake. Tardó unos diez minutos y no hizo ni una sola pregunta.

Por el camino determinó que necesitaba dos productos de datos aguas arriba, solicitó acceso automáticamente (no eran sensibles, así que se aprobó solo) y después publicó el producto Shelf Warmers terminado de vuelta en el marketplace, donde los agentes lectores de la primera mitad de la charla ya pueden encontrarlo.

Paso 4, publicar: de vuelta al principio

Publicar cierra el círculo. El nuevo producto aterriza en el marketplace, donde otros agentes, y también las personas, pueden descubrirlo y solicitar acceso, exactamente igual que hizo la demo de lectura al principio de la charla.

Construir, publicar, leer. El mismo marketplace que permite a los agentes leer datos es el que les permite construirlos.

Extra: gestionar una solicitud de cambio

¿Y si un consumidor pide más, por ejemplo "falta el nombre de la marca, añádelo"? Primero cambias el contrato: añades una columna brand_name, anclada al concepto brand que ya existe en la capa semántica.

Ahora el contrato ya no coincide con Snowflake, así que vuelves al coding agent, "implementa el producto de datos shelf-warmers", y este actualiza el proyecto dbt para traer y exponer el campo nuevo, de forma automática y en un par de minutos. (Solo se cuenta, no se muestra, por tiempo.)