Los 4 principios del data ownership

El data ownership es probablemente el gran problema sin resolver de la gestión de datos. Vamos a resolverlo.

Solo los datos de los que alguien se siente responsable son datos sobre los que podemos construir nuestros procesos y decisiones de negocio. Ese alguien limpia inconsistencias y se asegura de que los datos estén completos. Ese alguien se ocupa de que todos los pipelines estén en verde. Ese alguien cuida una buena documentación. Ese alguien es alguien con quien puedes hablar cuando tienes preguntas. Y ese alguien se lleva el mérito por el valor que otros crean con sus datos.

¿Eres tú ese alguien?

Felicidades. Estás haciendo un gran trabajo. Pero seamos honestos: hay muchos más datos en tu organización donde ese alguien falta, o donde no sabes si existe.

Por supuesto, todo gira en torno al ownership. El ownership de los datos es difícil. Pero por suerte, hoy tenemos métodos y herramientas que pueden ayudar.

Los 4 principios del data ownership

Estos son algunos principios que nos han resultado útiles al hablar de data ownership:

Bien, veamos qué queremos decir con esto:

You build it, you own it

Cuando los datos entran en tu dominio, te conviertes en el owner. Tú defines los campos de los formularios, tú construyes las API, tú controlas el pipeline de entrada. Sabes qué significa un enum de estado. Conoces el significado de las seis columnas de timestamp diferentes. Sabes qué pasa en los casos de error y en los casos límite. Tú construyes el sistema, así que son tus datos. Es tu trabajo saberlo. Eres el data owner. Sin excusas.

Normalmente recomendamos ownership de equipo, no de personas individuales. Esto evita problemas cuando alguien está de vacaciones o cuando cambia la composición del equipo. En algunas organizaciones vemos una división entre equipos de IT y equipos de negocio. Ahí recomendamos que el equipo que más trabaja con los datos asuma el rol principal de owner: para productos de datos source-aligned suele ser el equipo de IT; para productos de datos consumer-aligned suele ser el equipo de negocio o un equipo proxy.

Publica productos de datos

Todos hemos mirado dentro de los catálogos de datos corporativos (Collibra, Informatica, DataHub, el que quieras), y después de ver la cantidad de data assets indexados automáticamente (algo así como 2.321.021 tablas y archivos) y los detalles tan técnicos (serialización, formatos de archivo, encodings), queda muy claro que esos assets rastreados automáticamente no ayudan a asumir el ownership. Demasiado técnicos y demasiados.

Así que introduzcamos los productos de datos. Aunque es difícil encontrar una definición genérica de producto de datos (¿es una tabla, un esquema, un modelo semántico de Power BI, un topic de Kafka, una API, un proyecto dbt, ...?), centrémonos en el valor: datos que alguien quiere usar. Ese alguien puedes ser tú o tu equipo. Puede ser otra unidad de negocio. Y puede ser un agente de IA.

Lo importante de los productos de datos es: los datos solo se convierten en un producto de datos si alguien asume el rol de owner de esos datos. No hay producto de datos sin owner. Punto.

Esto también significa: en las empresas no hay millones de productos de datos. Normalmente solo hay unos pocos cientos. Menos es mejor: obtenemos una cantidad manejable de objetos que los owners pueden mantener y curar.

Para que otros encuentren los productos de datos, el owner los publica activamente en un marketplace de datos curado, no en un catálogo técnico de data assets.

Haz cumplir los Data Contracts

Hablemos ahora de los Data Contracts. Los Data Contracts especifican lo que un Data Consumer (de nuevo, una persona o un agente) puede esperar al consumir los datos. Son las API del producto de datos.

Esto incluye:

• Términos de uso
• Esquema
• Semántica
• Calidad de datos
• SLA
• Endpoints

Los términos de uso incluyen la descripción de negocio, el propósito de los datos, el uso aceptable y las limitaciones desde el punto de vista técnico, de cumplimiento y de Data Governance. En los casos de uso agénticos esto es extremadamente útil para indicar a los agentes de IA qué productos de datos pueden usar para tareas concretas y en qué contextos son relevantes esos datos.

El esquema incluye la estructura de tablas y columnas, además de detalles lógicos y de gobernanza, como clasificaciones de datos, marcadores de PII, descripciones semánticas, datos de ejemplo y data lineage.

Las tablas y columnas también se pueden vincular a un modelo de datos de negocio conceptual o a estándares del sector para añadir información semántica, formando un grafo de conocimiento completo para encontrar datos relacionados (de nuevo, muy útil para casos de uso agénticos).

Las reglas de calidad de datos y los SLA definen garantías sobre los datos y expectativas de negocio, como requisitos de no nulos, reglas a nivel de fila, rangos de valores válidos, frescura, etc. Los motores de calidad pueden leer estas reglas, conectarse a los endpoints de las bases de datos y validar los datos. Un motor de calidad de datos open source es la Data Contract CLI.

Existe un estándar del sector: el Open Data Contract Standard (ODCS), gestionado por Bitol, un proyecto Linux Foundation AI & Data. ODCS define un formato YAML para Data Contracts. Aquí tienes un ejemplo compacto:

apiVersion: v3.1.0
kind: DataContract
id: orders
name: Orders
version: 1.0.0
status: active
description:
  purpose: Order data for analytics, reporting, and AI use cases.
  usage: Analyze order volumes and revenue, build dashboards, train forecasting models.
  limitations: Not suitable for real-time use cases. Contains PII, do not use for marketing without consent.
schema:
  - name: orders
    physicalType: TABLE
    description: One row per order. Includes successful and cancelled orders.
    properties:
      - name: order_id
        logicalType: string
        description: Internal order ID. Do not show this to a customer.
        primaryKey: true
        required: true
        unique: true
        examples:
          - 99e8bb10-3785-4634-9664-8dc79eb69d43
      - name: order_timestamp
        logicalType: timestamp
        description: The time when the order payment was successfully confirmed.
        required: true
      - name: order_total
        logicalType: integer
        description: The order total amount in cents, including tax, after discounts.
        required: true
        quality:
          - type: library
            metric: nullValues
            mustBe: 0
    quality:
      - type: library
        metric: rowCount
        mustBeGreaterThan: 100000
        description: If there are less than 100k rows, something is wrong.
slaProperties:
  - property: freshness
    value: "24"
    unit: hours
    description: New orders are available within 24 hours.
team:
  name: sales
  description: This data product is owned by the "Sales" team
servers:
  - server: production
    type: snowflake
    account: my-account
    database: sales
    schema: dp_orders_v1

Un Data Contract se puede definir para un conjunto de datos existente. O se puede escribir contract-first, para definir los requisitos de un nuevo producto de datos antes de que existan los datos. Muy potente. Pero ambos caminos están bien.

Ahora bien, ¿quién es responsable del Data Contract? Normalmente, el Data Product Owner es dueño del Data Contract de su producto de datos. Pero especificar el contrato puede ser un esfuerzo colaborativo: haz un workshop con tus Data Consumers y discute sus expectativas sobre los datos, campo por campo. Y anota lo que discuten los expertos del dominio: esa es la semántica que quieres capturar.

Sé tu primer cliente

Bien, ya sabemos cómo especificar productos de datos con Data Contracts. Pero la pregunta central sigue abierta: ¿por qué debería alguien asumir el rol de owner de un producto de datos?

Bueno, una respuesta es: porque tu jefe te lo pide. Y es comprensible. El apoyo y la atención del management son una parte importante del proceso de adopción.

Pero hablemos también de la motivación intrínseca: el propósito. ¿Qué propósito podría tener tu producto de datos para ti? Sí. Construyamos el primer producto de datos para tu propio equipo, con los datos de tu propio dominio y con un buen dashboard. Para que tú puedas tomar mejores decisiones y construir grandes funcionalidades de IA en tu dominio. Conecta Claude a tu producto de datos para chatear con tus datos. Construye un bucle agéntico con tus datos para recibir un mensaje de Slack cuando pase algo relevante en tu aplicación.

Ya ves la idea. Construye un producto de datos para ti mismo que genere valor. ¡Ese es un gran propósito! Itera hasta que estés satisfecho. Cuando estés orgulloso, publícalo en el marketplace de datos para los demás. Gana fama y reconocimiento. Tu producto de datos aporta valor a tu negocio. Ayudar a los demás también es un gran propósito.

Herramientas que ayudan

Hay algunas herramientas que te ayudan a asumir el ownership.

Primero, para especificar el producto de datos, hay dos herramientas interesantes:

ODCS Excel Template. Sí, usa Excel para hacer un borrador de un Data Contract. Probablemente es la herramienta con la mejor experiencia de usuario para los usuarios de negocio. Envíalo por correo a otras personas e itera. Cuando estés satisfecho, usa el conversor de la Data Contract CLI para convertir hacia y desde YAML.

Data Contract Editor. Si prefieres un editor web, usa el Data Contract Editor open source, que además trae un editor visual de diagramas entidad-relación, campos de formulario para todas las propiedades de ODCS y linting. Totalmente personalizable con propiedades y secciones propias.

Data Product Builder. Para implementar el producto de datos, usa coding agents como Claude Code y OpenAI Codex. El Data Contract les dice qué construir. Las skills describen cómo, según el stack tecnológico y las políticas de Data Governance de tu organización. Un marketplace de datos les dice qué productos de datos upstream usar. Una vez que tienes el Data Contract, implementar un producto de datos conforme solo lleva unos minutos.

Data Contract CLI. Para comprobar que el producto de datos implementado cumple la especificación y las promesas del Data Contract, usa la herramienta open source Data Contract CLI. Intégrala en Airflow, GitHub Actions, Databricks Jobs, etc. para verificar que tu producto de datos siempre entrega la calidad de datos prometida.

Entropy Data. Nuestra herramienta comercial que reúne todas estas herramientas para ayudar a los Data Product Owners a tomarse en serio su rol de owner. Entropy Data también ofrece un marketplace de datos neutral respecto a proveedores en una aplicación web fácil de usar.

Empieza gratis, o explora la demo interactiva.