A Data Marketplace Is
What Your Agents Need

Confianza, acceso y responsabilidad: cómo los marketplaces de datos habilitan a los agentes de IA

Hacer que los datos sean fiables y localizables ha sido durante años un reto persistente y sin resolver en la analítica de datos empresarial. Según el estudio de BARC Data Mesh and Data Fabric – From Theory to Application¹, el 73 % de los encuestados afirma que no es fácil encontrar los datos relevantes, y el 75 % confirma que a sus datos y análisis les falta fiabilidad e interpretabilidad.

Estas cifras son anteriores a la ola de la IA agéntica. A medida que los agentes de IA empiezan a automatizar procesos de negocio críticos, lo que está en juego crece de golpe: las carencias de infraestructura que ralentizan a los Data Consumers² pueden llevar a los agentes a actuar sobre datos incompletos o poco fiables. Un marketplace de datos es parte de la respuesta: hace que los datos sean localizables, fiables y accesibles de una forma que funciona tanto para personas como para agentes de IA.

Personas y agentes exigen las mismas cuatro condiciones a los datos de la empresa

Antes de llegar a la solución propuesta, profundicemos un nivel más en el diagnóstico. La investigación de BARC apunta de forma consistente a cuatro retos de datos fundamentales a los que se enfrentan hoy las organizaciones:

• Los Data Consumers no encuentran los datos adecuados (localizabilidad)
• No entienden qué significan los datos porque están mal explicados (contexto y semántica)
• No pueden acceder a los datos con suficiente rapidez por culpa de flujos de acceso manuales y complejos (gobernanza del acceso a datos)
• No pueden valorar si los datos que están consultando son fiables (señales de calidad)

Sostenemos que los agentes de IA se topan con esas mismas cuatro barreras, solo que con mucho menos margen para el error. Veamos dos ejemplos:

Por desgracia, no se trata de casos límite, sino de las consecuencias predecibles de desplegar agentes sobre una infraestructura de datos que no se diseñó pensando en la IA agéntica.

Con activos de datos cualesquiera no basta

Superar estas cuatro barreras no es solo una cuestión de plataforma de datos o de diseño de la interfaz. Empieza por cómo se empaquetan los datos para su consumo. Usemos una analogía: un principio activo farmacéutico a granel, como el AAS, no es un producto. La Aspirina³ sí lo es, porque es su versión dosificada y etiquetada, empaquetada con sus contraindicaciones, de un fabricante responsable y con un prospecto de uso. La analogía es simple: si quieres ofrecer algo en un marketplace, conviértelo en un producto fácil de evaluar, de consumir y de creer.

Definición de producto de datos: en profundidad para los curiosos

Un producto de datos es un activo de datos comprable, reutilizable, activo y estandarizado, diseñado para aportar valor medible aplicando los principios del product thinking. Incluye uno o varios artefactos enriquecidos con metadatos como políticas de gobernanza, Data Contracts y, opcionalmente, un SBOM (Software Bill of Material). Alineado con un dominio o caso de uso concreto, garantiza responsabilidad, evolución continua, escalabilidad y cumplimiento de los estándares de negocio y regulatorios.

Jacqueline Bloemen y Florian Bigelmaier (ambos de BARC), 2025, con un ligero ajuste sobre la definición de productos de datos de Bitol.

Descubre más sobre productos de datos en barc.com/data-products

Los productos de datos agrupan todo lo que necesita un consumidor: datos orientados a un propósito, metadatos, SLA, ownership claro, mantenimiento sostenido y condiciones de uso. Conjuntos de datos cualesquiera, sin ownership ni documentación semántica, no generan una demanda estable.

Ahora bien, esto no se construye de la noche a la mañana. La investigación de BARC muestra que el 49 % de las organizaciones señala como reto activo construir una organización y una mentalidad de producto de datos⁴, porque obliga a pasar de un modelo orientado al servicio a uno orientado al producto. Un marketplace puede actuar de catalizador en ese reto, pero no conviene subestimar la transformación cultural que exige.

El ownership de los productos de datos es la herramienta organizativa más potente de la que disponemos para aumentar la confianza en los datos. O dicho al revés: los productos de datos solo funcionarán si los owners del lado del negocio asumen la responsabilidad sobre los datos que generan sus procesos. Los Data Engineers y los desarrolladores de aplicaciones pueden construir la infraestructura para digitalizar y automatizar esos procesos, y pueden responsabilizarse de los pipelines técnicos que llevan los datos de A a B y los refinan. Pero no se les puede hacer responsables del proceso que crea los datos.

La IA eleva lo que está en juego con la calidad de los datos. Los responsables de negocio disponen ahora de una palanca organizativa poco habitual: los problemas de calidad que durante años se toleraron como «cuadros de mando poco precisos» se traducen, en un mundo agéntico, en automatizaciones rotas y agentes poco fiables. Esa consecuencia es difícil de ignorar.

Cuando los productos de datos no hablan el mismo idioma

Hay otra dimensión en la que fallan los conjuntos de datos cualesquiera: la interoperabilidad. Un único producto de datos bien empaquetado es útil, pero es al combinar dos o más cuando el conocimiento se multiplica. Y combinar productos de dominios distintos exige una semántica compartida. ¿Significa «cliente» lo mismo en el dominio de ventas que en el de logística? ¿Sigue «ingresos» las mismas reglas de reconocimiento en finanzas que en el reporting comercial? Empaquetar los datos como producto puede, paradójicamente, reforzar esa fragmentación: el ownership por dominio da a los equipos menos incentivos, no más, para alinear sus definiciones con el resto de la organización.

Una forma de resolverlo es trabajar con definiciones documentadas de manera más explícita. Los productos de datos no solo tienen que explicar qué contienen, sino también cómo se relacionan sus términos clave con los términos equivalentes de otros productos, cómo los amplían o cómo los contradicen. Un marketplace de datos que saque a la luz esas relaciones, señalando de forma explícita dónde coinciden las definiciones y dónde divergen, convierte el descubrimiento pasivo en una combinación informada. Así, tanto los consumidores como los agentes pueden decidir de forma explícita qué definición usar y por qué, en lugar de combinar sin saberlo representaciones incompatibles del mismo concepto del mundo real.

Data Contracts: la pieza que falta para automatizar el acceso a los datos

Establecer un ownership real es el método organizativo más habitual para aumentar la confianza en los datos, pero hay una forma de reforzar todavía más la relación entre Data Producer y consumidor: los Data Contracts.

Los Data Contracts detallan qué se entrega y bajo qué condiciones. Esto sirve a varios objetivos. Primero, un contrato formaliza la relación entre productor y consumidor. En la práctica, significa que el consumidor sabe exactamente qué esperar de un producto de datos, quién responde por él y a quién dirigirse si algo se rompe. En lugar de una dependencia informal de quien construyó el pipeline, la relación se vuelve explícita: un owner con nombre y obligaciones definidas, y un consumidor con derechos de uso claramente enunciados y ligados a un propósito concreto.

Segundo, es una fuente estructurada de información sobre el producto de datos, comparable al prospecto que acompaña a un medicamento, siguiendo con la analogía anterior. Tener las señales de calidad incorporadas al contrato permite a los consumidores, y sobre todo a los agentes, valorar si encaja con su propósito antes de consumirlo.

Tercero, los contratos hacen que la calidad de los datos sea verificable. Un contrato define qué se supone que entrega un producto de datos y puede incluir expectativas de formato, completitud y actualidad. Así, los datos reales pueden validarse automáticamente contra esas especificaciones. Para los agentes esto es especialmente relevante: en lugar de propagar problemas de calidad aguas abajo, un agente puede comprobar si los datos encajan con su propósito antes de procesarlos.

Cuarto, los contratos permiten automatizar la gestión de accesos. Si las reglas sobre quién puede usar un producto de datos y con qué propósito ya están escritas, el sistema puede aprobar las solicitudes de acceso automáticamente, sin intervención humana. Para una persona esto significa acceder antes a los datos que necesita. Para los agentes importa aún más, porque acabarán solicitando acceso a los datos con mucha más frecuencia de la que nunca lo hicieron las personas.

Aun así, los Data Contracts no bastan por sí solos. Igual que en el mundo real, donde los contratos rigen relaciones concretas pero operan dentro de un marco legal más amplio, los Data Contracts necesitan políticas de alcance corporativo que los contextualicen. Las políticas definen qué está permitido o prohibido con carácter general y qué estándares seguir; los contratos concretan reglas adicionales dentro de esos límites para un producto de datos específico.

El marketplace de datos: donde todo encaja

Toda plataforma de datos madura tiene al menos un repositorio de metadatos técnicos, igual que toda biblioteca tiene un índice. Ese tipo de herramientas ayuda a localizar los datos. Lo que no puede hacer es generar confianza. Un índice de metadatos te dice que un conjunto de datos existe, pero no si es fiable, qué significa en tu contexto de negocio o si encaja con tu caso de uso. La confianza, construida con contexto, semántica y señales de calidad (como se ha explicado antes), es lo que convierte el descubrimiento pasivo en demanda real y lo que hace tan valioso a un marketplace de datos interno.

Muchos marketplaces de datos se parecen a una experiencia de compra en Amazon, pero empiezan a fallar en cuanto quieres conseguir de verdad ese producto. Cuando un consumidor encuentra un producto de datos fiable, lo siguiente que espera es acceso inmediato. Ahí es donde muchas organizaciones siguen quedándose cortas, con flujos de aprobación manuales que tardan días o semanas. Un marketplace de datos resuelve la parte de descubrimiento de ese ciclo. En esencia es un buscador de metadatos curado que muestra los productos de datos con el contexto necesario para valorar su encaje y su fiabilidad. Hoy la mayoría de los marketplaces se queda ahí. La visión más ambiciosa, y la dirección hacia la que avanzan las implementaciones más maduras, es extenderlo también al aprovisionamiento del acceso. En lugar de limitarse a señalar al consumidor el producto de datos adecuado y dejarle abrir un ticket, el marketplace gobernaría y automatizaría también la propia solicitud de acceso.

Cuanto más compleja se vuelve una organización, más valioso es un marketplace de datos. Más dominios de negocio, más plataformas de datos, más equipos trabajando con datos: todo ello aumenta la necesidad de saber qué datos existen, dónde encontrarlos y cómo acceder a ellos. Hace falta un único punto de entrada fiable que aporte contexto suficiente para elegir y consumir el producto de datos adecuado.

El marketplace resuelve además una de las tensiones centrales de los productos de datos dentro del esfuerzo por dar más poder a los dominios de negocio: las organizaciones y arquitecturas federadas no están totalmente descentralizadas. Deben tener una columna vertebral bien definida. Muchas organizaciones trasladan, con buen criterio, el ownership y la creación de productos de datos a los dominios de negocio, pero dos cosas deben seguir siendo centrales: un único punto de acceso y descubrimiento (porque un marketplace obedece a leyes de escala) y un conjunto de políticas de gobernanza corporativas que apliquen a todos los productos publicados. El marketplace puede ser el hogar natural de ambas. Estos marketplaces pueden validar los contratos contra las políticas corporativas en el momento de la publicación y evaluar las solicitudes de acceso contra esas mismas políticas en el momento del consumo.

Conceder el acceso no es gobernar el acceso

Los marketplaces que van más allá del descubrimiento y llegan al aprovisionamiento del acceso ganan una capacidad de la que carecen los sistemas clásicos: pueden registrar no solo quién accedió a qué, sino por qué. Esta última dimensión (el propósito del consumo de datos) suele estar ausente del control de acceso clásico y, sin embargo, es el requisito previo para automatizar el acceso a datos a escala.

Por ejemplo, imagina una gran corporación que dispone de datos sobre el valor del cliente a lo largo de su vida. Un data scientist obtiene acceso para construir un modelo de priorización de ventas. Funciona muy bien. Después, un compañero de marketing pide usar esos mismos datos de CLV para segmentar campañas. El data scientist se los pasa de manera informal, sin una nueva solicitud de acceso. Los datos se están usando ahora para un propósito que nunca se autorizó.

En el caso de los analistas humanos, las señales informales, los procesos de revisión y el criterio profesional generan cierta fricción natural frente al uso sin permiso y frente al abuso flagrante. Los agentes de IA operan sin juicio moral y sin esa fricción. Intentar inculcarles esos escrúpulos nunca funciona al 100 %.

La consecuencia: las organizaciones tienen que proteger los datos en sí. Ya no pueden tratar la concesión del acceso como el final de la gobernanza. El control de acceso clásico es una decisión puntual: llega una solicitud, quien la presenta declara un propósito y el sistema concede o deniega el acceso. Una vez concedido, se da por hecho que el uso se mantiene dentro del alcance declarado. En el mejor de los casos, ese acceso se revisará cada varios años.

Volvamos al ejemplo, pero cambiando al data scientist por un agente de IA. El mismo producto de datos de CLV y el mismo propósito declarado: priorización de ventas. Tres meses después, el agente empieza a usar los datos para alimentar un modelo de riesgo que decide si un cliente puede comprar contra factura o si debe pagar por adelantado. Aunque tenga sentido de negocio, es claramente un propósito distinto que no se ha declarado ni aprobado. En una auditoría de cumplimiento, nadie puede explicar por qué el agente procesó datos de clientes fuera de su alcance original.

La solución no pasa por revisar las definiciones de acceso más a menudo, sino por desplazar la lógica de gobernanza: del acceso como aprobación puntual al acceso como estado que se verifica de forma continua. Un marketplace de datos guarda tanto el contrato como el contexto necesarios para evaluar si una consulta concreta está dentro de los límites. También puede mostrar si las garantías declaradas en un Data Contract se están cumpliendo realmente. Eso lo convierte en el lugar natural para registrar el «porqué» de cada concesión de acceso y para hacer cumplir las normas cuando las consultas se desvían del propósito declarado.

Gobernar el acceso a los datos es solo una pieza de un puzle mucho mayor llamado AI Governance. Esa disciplina abarca también el comportamiento de los modelos, la calidad de las salidas, la explicabilidad, la observabilidad, la supervisión humana, el uso ético, la gestión de riesgos y el cumplimiento regulatorio, por citar unos pocos. Y ni siquiera dentro de la dimensión de los datos el control de acceso lo es todo: piensa en el sesgo, el consentimiento o las políticas de retención. Este artículo se centra en gobernar un aspecto muy importante: el acceso de los agentes a los datos.

Cuatro acciones para empezar

El camino no es un despliegue big bang del marketplace, sino más bien una transformación organizativa que se apoya en llevar al marketplace un producto de datos cada vez y en convencer a un equipo cada vez de que el esfuerzo merecerá la pena.

Las organizaciones que invierten en infraestructura de datos pero descuidan los marketplaces de datos, los contratos y el product thinking descubrirán que sus agentes de IA heredan el mismo déficit de confianza que lleva años lastrando a los analistas humanos. La infraestructura para una analítica a la altura de las personas y para una automatización a la altura de los agentes es, en su base, la misma. Las consecuencias de equivocarse, no.

Sobre Entropy Data

Entropy Data ofrece un marketplace de productos de datos, respaldado por Data Contracts, que funciona tanto para analistas humanos como para agentes de IA.

Está construido sobre estándares abiertos, con soporte nativo de Open Data Contract Standard (ODCS), Open Data Product Standard (ODPS) y Open Semantic Interchange (OSI), y contribuimos activamente a esos estándares para mejorarlos. Juntos hacen que los productos de datos sean localizables, contextualizados con semántica de negocio y accesibles mediante flujos de acceso automatizados, mostrando las señales de calidad que los consumidores necesitan para confiar en lo que encuentran. Los propios contratos se validan con nuestra popular Data Contract CLI de código abierto.

Tres bloques lo hacen posible:

En conjunto, dan a los agentes un punto de entrada fiable a través de la API y del Model Context Protocol (MCP), y dan a las personas un marketplace en el que pueden confiar.

Entropy Data se integra con todas las grandes plataformas de datos y está disponible como SaaS alojado en la UE, en tu propia nube o en despliegue on premises.

Entropy Data cuenta con la certificación ISO 27001 y está desplegado en producción en grandes empresas de sectores como logística, farmacéutico, medios y telecomunicaciones, y en múltiples geografías, entre ellas Estados Unidos, Australia, Suiza y la UE. Esto demuestra que nuestro marketplace de productos de datos respaldado por contratos escala mucho más allá de la fase piloto.

Sobre BARC

BARC es la principal firma de análisis de mercado en data & analytics, IA, corporate performance management (CPM) y ESG, con una reputación de asesoramiento imparcial y de confianza. Nuestros analistas expertos ofrecen una amplia gama de estudios, eventos y servicios de consultoría para la comunidad de data & analytics. Nuestra investigación evalúa con rigor software, fabricantes y proveedores de servicios, destaca las tendencias del mercado y aporta conocimiento que permite a nuestros clientes innovar con datos, analítica e IA. Los 25 años de experiencia de BARC en estrategia y cultura de datos, arquitectura de datos, organización y selección de software ayudan a sus clientes a transformarse en organizaciones realmente data-driven.

---

Notas

1. BARC Survey "Data Mesh and Data Fabric" 2024, tamaños de muestra: para la encuesta en total n=197, para las preguntas citadas: n=197 ↩
2. «Data Consumers» es simplemente el término que designa a las personas que necesitan datos para hacer su trabajo ↩
3. Aspirina® es una marca registrada de Bayer AG. Este informe es independiente y no está afiliado a Bayer ni cuenta con su respaldo. ↩
4. BARC Survey "Data Mesh and Data Fabric" 2024, tamaños de muestra: para la encuesta en total n=197, para las preguntas citadas: n=121 ↩

BARC Spotlight: A Data Marketplace Is What Your Agents Need © BARC 2026. Reproducido con permiso. Facilitado por Entropy Data.