Data products y contratos de datos: tratar la información como producto con dueño

En la mayoría de las organizaciones, los datos se tratan como un subproducto. Los sistemas operativos generan registros porque necesitan funcionar, y quien quiere analizarlos se las arregla: extrae, limpia, interpreta y produce su versión.

El resultado de esa lógica es predecible. Cinco áreas construyen cinco procesos de limpieza distintos sobre la misma fuente. Cada una toma decisiones razonables y distintas sobre qué hacer con los casos raros. Los números de las cinco áreas dejan de coincidir. Y cuando alguien pregunta cuál es el correcto, la respuesta honesta es que todos lo son dentro de sus supuestos, lo cual es de poco consuelo en una reunión de directorio.

El concepto de data product invierte esa lógica.

Qué hace que un dato sea un producto

Un data product es un conjunto de datos tratado con las mismas exigencias que un producto de software: tiene un dueño, tiene consumidores identificados, tiene una interfaz estable, tiene compromisos de calidad y evoluciona con criterio.

Cinco propiedades lo definen en la práctica:

Dueño nombrado. Un equipo responsable de que ese dato exista, sea correcto y esté disponible. No un comité: un equipo.

Interfaz definida. Un esquema explícito: qué campos, con qué tipos, con qué significado. Documentado y versionado.

Compromisos de calidad. Con qué frecuencia se actualiza, qué completitud garantiza, qué latencia tiene, qué se considera un valor válido.

Descubribilidad. Se puede encontrar sin preguntarle a alguien. Un catálogo donde figura qué es, quién lo mantiene y cómo se accede.

Linaje. De dónde viene y por qué transformaciones pasó. Sin linaje, cuando un número está mal, la investigación es arqueológica.

La diferencia con el enfoque tradicional es de dirección de la responsabilidad. En el modelo de subproducto, el consumidor es responsable de que el dato le sirva. En el modelo de producto, el productor lo es.

Contratos de datos

El contrato de datos es la formalización de esa responsabilidad. Es un acuerdo explícito entre quien produce y quienes consumen que especifica al menos cinco cosas:

• El esquema: campos, tipos, restricciones.
• La semántica: qué significa cada campo, con precisión suficiente para que dos personas lo interpreten igual.
• Las garantías: frecuencia de actualización, completitud, latencia.
• Las reglas de evolución: qué cambios se consideran compatibles, con cuánta anticipación se avisan los que rompen, cuánto tiempo se sostienen versiones anteriores.
• El procedimiento ante fallas: a quién se le avisa y qué se espera.

Lo valioso de un contrato es que se puede verificar automáticamente. Una validación que corre en cada actualización y falla cuando el dato no cumple el contrato convierte una promesa en una garantía. Y detecta el problema en el origen, en el momento en que se produce, en vez de tres semanas después en un reporte gerencial.

Por qué esto se volvió urgente

Los contratos de datos existen como práctica desde hace años. Lo que cambió en 2026 es la urgencia, por dos motivos concretos.

El primero: los agentes consultan datos sin criterio para dudar. Una persona que ve un valor extraño en un reporte lo cuestiona, porque conoce el negocio y sabe que ese número no puede ser. Un agente lo usa y construye una recomendación sobre él. La calidad de los datos deja de ser un problema de reportes y pasa a ser un problema de decisiones automatizadas.

El segundo: la accesibilidad de datos internos para IA es una de las capacidades que determinan si la inversión en inteligencia artificial produce beneficio. Y accesible no significa solamente que exista una conexión técnica. Significa que el dato tiene definición, dueño, calidad conocida y permisos claros. Un dato accesible sin contrato es un dato que un agente puede consultar y no debería.

El error de empezar por el catálogo completo

La reacción organizacional típica ante esto es lanzar un programa de gobierno de datos que empieza catalogando todo. Ese enfoque tiene una tasa de éxito baja por un motivo estructural: produce valor solo al final, y como tarda años, se queda sin patrocinio antes de llegar.

La alternativa que funciona es al revés: empezar por los datos que ya están causando problemas.

Identifica los tres conjuntos de datos que aparecen en más discusiones sobre números que no cuadran. Para esos tres, y solo esos, haz el trabajo completo: dueño nombrado, esquema documentado, semántica escrita, garantías definidas, validación automática.

Ese trabajo toma semanas, no años. Y produce un efecto visible: las discusiones sobre esos números se terminan. Ese efecto es el argumento para el siguiente conjunto.

Las verificaciones que valen la pena automatizar

Un contrato de datos se vuelve real cuando se verifica solo. La pregunta práctica es qué verificar, porque la lista puede crecer sin límite y volverse ruido.

Cinco categorías cubren la mayor parte de los problemas reales.

Estructura. Que los campos declarados estén presentes, con el tipo correcto. Es la más básica y atrapa los errores más frecuentes: un campo que desaparece por un cambio aguas arriba, un tipo que cambia de número a texto.

Rangos y dominios. Que los valores estén dentro de lo posible. Fechas que no sean futuras cuando no pueden serlo, montos no negativos, códigos dentro del conjunto válido. Esta categoría atrapa errores que la estructura no ve: un campo correcto con contenido imposible.

Completitud. Qué proporción de registros tiene cada campo poblado, comparada con lo esperado. Un campo que normalmente está completo en la mayoría de los casos y de pronto aparece vacío en la mitad indica un problema aguas arriba, aunque cada registro individual sea válido.

Volumen. Cuántos registros llegaron respecto de lo habitual. Una caída abrupta suele significar que una fuente dejó de enviar, y es de los fallos que más tardan en detectarse porque no producen ningún error.

Frescura. Cuándo se actualizó por última vez. Un dato correcto pero viejo produce decisiones equivocadas con toda la apariencia de estar bien fundadas.

De las cinco, las dos últimas son las que más incidentes silenciosos previenen y las que menos se implementan, porque no verifican el contenido sino su llegada. Un proceso que falla y no envía nada no genera datos incorrectos: genera ausencia de datos, que los sistemas de calidad basados en validar registros no detectan.

Hay una decisión de diseño que conviene tomar explícitamente: qué hace el sistema cuando una verificación falla. Las opciones son bloquear la publicación, publicar con una marca de advertencia, o publicar y alertar. La respuesta correcta depende del uso: para un dato que alimenta decisiones automatizadas, bloquear. Para uno que alimenta análisis exploratorio, alertar suele bastar.

Lo que no funciona es alertar sin destinatario definido. Una alerta que llega a un canal que nadie revisa es equivalente a no tener verificación, con el costo adicional de haber generado la falsa sensación de control.

Cómo saber si tienes el problema

Cuatro señales, todas fáciles de verificar:

• Dos áreas reportan números distintos para el mismo indicador y ambas pueden defenderlos.
• Cuando alguien encuentra un dato incorrecto, no sabe a quién avisarle.
• Varios equipos mantienen su propia versión limpia de la misma fuente.
• Nadie puede decir con certeza de dónde sale un campo específico de un reporte importante.

Si tres de las cuatro aplican, el problema no es de herramientas de análisis ni de tablero. Es de ownership. Y ninguna plataforma de datos, por buena que sea, resuelve una ausencia de responsabilidad.