Pocas expresiones se han extendido tan rápido en el mundo del dato como data product o, en su formulación original, data as a product: tratar los datos como productos. La idea nació en el ámbito de Data Mesh —del que ya hablamos en este blog al compararlo con Data Fabric— y ha saltado de la arquitectura interna de las organizaciones a los espacios de datos, donde se ha convertido en la unidad básica de intercambio: lo que un proveedor publica en el catálogo de un espacio de datos no es «un fichero», sino un producto de datos. De hecho, el primer estándar europeo sobre transacciones de datos confiables, EN 18235-1:2026, incluye el concepto de data product entre sus nociones fundamentales, junto al de dato y al de transacción.
El problema es que, como toda expresión de moda, se usa con alegría: cualquier CSV colgado en un repositorio aspira hoy al título de data product. En este artículo ponemos rigor en la definición: qué distingue a un producto de datos de un simple conjunto de datos, qué componentes debe tener y por qué esta distinción es la que separa a las organizaciones que están preparadas para compartir datos de las que solo lo parecen.
Lo que un data product NO es
Empecemos por descartar. No es un producto de datos:
-
- Un CSV en una carpeta compartida, por muchos datos valiosos que contenga: nadie responde de él, nadie sabe cuándo se actualizó y nadie garantiza que mañana siga ahí.
- Un volcado de base de datos entregado a petición: es una foto fija sin mantenimiento, sin versionado y sin compromiso de continuidad.
- Un dashboard bonito: es un consumo del dato, no el dato preparado para que otros construyan sobre él.
- Un dataset documentado a posteriori porque alguien lo pidió: la documentación reactiva no es diseño de producto, es arqueología.
El patrón común de estos casos es que los datos existen, pero nadie se ha comprometido con su consumo. Y el compromiso es, exactamente, lo que define a un producto.
La definición: datos diseñados para ser consumidos
Un producto de datos es una unidad autónoma de datos diseñada, mantenida y evolucionada para satisfacer las necesidades de sus consumidores, con un responsable identificado, unas garantías explícitas y un ciclo de vida gestionado. La palabra clave no es «datos»: es producto, con todo lo que asociamos a ella en cualquier otro ámbito: piense el lector en la diferencia entre la fruta del huerto de un particular y la fruta que llega al lineal de un supermercado con su calibre, su etiquetado, su trazabilidad y su responsable ante el consumidor. La fruta puede ser la misma; el producto, no.
La formulación clásica de Data Mesh resume los atributos que debe cumplir un producto de datos, y merece la pena repasarlos porque son un excelente cuaderno de exigencias:
-
- Descubrible (discoverable): se puede encontrar en un catálogo, con metadatos que explican qué es, qué contiene y para qué sirve.
- Direccionable (addressable): tiene una dirección estable y única; los consumidores acceden siempre por el mismo punto, aunque la implementación interna cambie.
- Confiable (trustworthy): declara sus niveles de calidad y los cumple; el consumidor sabe qué exactitud, completitud y actualidad puede esperar.
- Autodescriptivo (self-describing): su esquema, su semántica y sus condiciones de uso acompañan al dato; no hace falta llamar a nadie para entenderlo.
- Interoperable: utiliza estándares y vocabularios comunes que permiten combinarlo con otros productos.
- Seguro (secure): el acceso está gobernado por políticas explícitas, aplicadas de forma automática.
La anatomía de un data product
Si los atributos anteriores son el «qué», conviene aterrizar el «cómo»: ¿de qué se compone materialmente un producto de datos? De bastante más que de los datos:
|
Componente |
Qué aporta |
Lo hemos visto en esta serie |
|
Los datos |
El contenido: tablas, eventos, APIs, ficheros |
— |
|
Metadatos |
Descripción, semántica, linaje y etiqueta de calidad que hacen el producto descubrible y comparable |
Post sobre calidad y etiquetado (UNE 0081, DQV) |
|
Data contract |
El compromiso verificable: esquema, SLOs de calidad y servicio, versionado |
Post sobre permits, contracts y agreements |
|
Políticas de uso |
Condiciones de acceso y uso legibles por máquina (ODRL), que los conectores aplican |
Posts sobre el rulebook y los instrumentos |
|
Data product owner |
La persona responsable de que el producto satisfaga a sus consumidores y evolucione |
— |
|
Ciclo de vida |
Versiones, gestión de cambios, deprecación ordenada y, llegado el caso, retirada |
— |
Dos de estos componentes merecen subrayado. El primero es el data product owner: un producto sin propietario es un dataset huérfano con metadatos elegantes; alguien con nombre y apellidos debe responder de su calidad, priorizar su evolución y decidir su retirada, igual que ocurre con cualquier producto de software. El segundo es el ciclo de vida: la diferencia más visible entre un volcado y un producto es que el producto cambia sin romper a sus consumidores, mediante versionado y avisos de deprecación; quien haya sufrido la desaparición silenciosa de una columna en un fichero del que dependía sabe exactamente de qué hablamos.
Del data product interno al espacio de datos
Todo lo anterior aplica dentro de una organización, y es la base de arquitecturas como Data Mesh. Pero donde el concepto despliega todo su sentido es en los espacios de datos, porque allí el consumidor es externo y las garantías no pueden descansar en la confianza personal ni en el contexto compartido: tienen que estar empaquetadas en el propio producto.
De hecho, si se repasan los atributos y componentes anteriores, se comprobará que coinciden punto por punto con lo que un espacio de datos exige a sus ofertas: metadatos en el catálogo federado (descubrible), etiqueta de calidad (confiable), data contract con SLOs (compromiso), políticas ODRL aplicadas por los conectores (seguro) y vocabularios comunes del rulebook (interoperable). No es casualidad: el producto de datos es la forma que adopta el dato cuando está preparado para ser intercambiado con garantías, y por eso la terminología europea de EN 18235-1 lo sitúa entre sus conceptos de partida. Dicho en corto: los espacios de datos no intercambian datos; intercambian productos de datos.
Ejemplo de uso: una distribuidora eléctrica convierte sus curvas de consumo agregadas en un producto de datos: define a su propietaria, publica el producto en el catálogo del espacio de datos energético con sus metadatos y su etiqueta de calidad, compromete en el data contract la granularidad, la actualización horaria y la completitud mínima, y asocia una política de uso que prohíbe la reidentificación de consumidores. Tres años después, el producto va por su versión 2.3, ha cambiado dos veces de tecnología interna y ninguno de sus consumidores ha tenido que enterarse.
¿Cómo empezar a construir productos de datos?
Convertir datasets en productos es un cambio de mentalidad más que de tecnología, y se puede abordar de forma incremental:
-
- Elegir pocos y buenos: identificar dos o tres conjuntos de datos con demanda real, interna o externa; el producto se justifica por sus consumidores, no al revés.
- Nombrar propietarios: asignar un data product owner por producto, con mandato y tiempo reales, no honoríficos.
- Escuchar al consumidor: entender qué necesita quién lo va a usar (granularidad, frecuencia, formato) antes de empaquetar nada; es diseño de producto, no publicación de ficheros.
- Medir y etiquetar la calidad: evaluar conforme a UNE 0081 y hacer visibles los niveles en los metadatos, como veíamos en el artículo anterior.
- Formalizar el contrato: esquema, SLOs, versionado y política de cambios en un data contract, aunque el primer consumidor sea interno.
- Publicar y evolucionar: incorporar el producto al catálogo (interno o del espacio de datos) y gestionar su ciclo de vida con la misma seriedad que un producto de software.
La pregunta del título tiene ya respuesta: lo que convierte a un conjunto de datos en un producto no es la tecnología que lo sirve ni la elegancia de su documentación, sino el compromiso gestionado con quienes lo consumen: un propietario que responde, unos metadatos y una etiqueta de calidad que permiten elegirlo, un contrato que garantiza lo que entrega y un ciclo de vida que protege a sus consumidores del cambio. Esa es también la unidad con la que se construyen los espacios de datos: quien aprenda a fabricar productos de datos dentro de casa tendrá hecho lo difícil para competir fuera.
Si tu organización quiere identificar sus primeros productos de datos, definir sus contratos y garantías de calidad, o prepararlos para publicarse en un espacio de datos, en DQTeam podemos ayudarte. ¡Hablemos de datos!
