Existe una clase de fallo de datos que nunca dispara una alarma. El pipeline se ejecuta hasta el final, el informe se actualiza a su hora habitual, los números aparecen en el dashboard — y están mal. En el origen, alguien de un equipo aguas arriba renombró una columna, cambió el formato de una fecha o empezó a enviar valores en céntimos en lugar de euros. Nadie avisó, porque nadie sabía que aquel campo tenía consumidores al otro lado.
Este es el problema silencioso de la ingeniería de datos moderna. Los datos atraviesan decenas de sistemas y equipos, pero los acuerdos sobre lo que significa cada campo viven, en el mejor de los casos, en la cabeza de quien construyó el pipeline. Cuando esa persona cambia de proyecto, o cuando el volumen crece, aparece el coste — en informes rehechos, decisiones aplazadas y confianza perdida en el equipo de datos.
Un contrato de datos es la respuesta a este problema. Es un acuerdo explícito, versionado y verificable entre quienes producen los datos y quienes los consumen, que describe la estructura, el significado y las garantías de calidad de lo que se comparte. Este artículo explica qué es, qué debe contener y cómo introducirlo sin convertir todo en una burocracia que nadie cumple.
Qué es un contrato de datos
Un contrato de datos formaliza una promesa. El equipo que produce un conjunto de datos se compromete a entregarlo con una forma y una calidad determinadas, y a avisar antes de cambiar esa promesa. No es un documento olvidado en una wiki: es una especificación legible por máquinas, guardada junto al código y verificada automáticamente cada vez que los datos cambian.
La mejor analogía es una API. Cuando un equipo expone una API, publica un contrato — los campos, los tipos, lo que es obligatorio — y los consumidores construyen sobre esa promesa confiando en que no cambiará de un día para otro. Durante años, los datos analíticos no tuvieron esta disciplina: una tabla en un data warehouse se trataba como un detalle interno que cualquiera podía alterar. El contrato de datos lleva al mundo analítico el mismo rigor que la ingeniería de software aplica desde hace tiempo a sus interfaces.
El problema: datos que se rompen en silencio
Para entender el valor de un contrato hay que mirar cómo se rompen las cosas sin él. El fallo más común es un cambio de esquema aguas arriba: una columna que desaparece, cambia de tipo o empieza a admitir nulos. El pipeline puede no fallar de inmediato — a menudo sigue ejecutándose y escribiendo datos, solo que erróneos.
Después están los cambios de significado, aún más traicioneros porque el esquema ni siquiera cambia. El campo estado_encomenda pasa a incluir un valor nuevo que ningún informe preveía. La moneda de valor_total cambia de euros a dólares en una región. La definición de cliente activo se altera en el origen sin que el equipo de analytics lo sepa. El tipo sigue siendo correcto; el número deja de significar lo que significaba.
El denominador común es la ausencia de un acuerdo explícito. Quien produce los datos no sabe quién los consume, ni con qué expectativas. Quien los consume no tiene forma de saber que la promesa ha cambiado. Un contrato hace ese acuerdo visible y, sobre todo, verificable.
Qué incluye un buen contrato de datos
Un contrato útil va mucho más allá de la lista de columnas. Debe describir, de forma legible por máquinas y por personas, los siguientes elementos:
- Esquema y tipos. Los campos, sus tipos, cuáles son obligatorios y cuáles admiten nulos. Es la base, pero solo el comienzo.
- Semántica. Qué significa cada campo en lenguaje de negocio: unidades, moneda, zona horaria, la granularidad de cada fila y los valores permitidos en campos categóricos.
- Garantías de calidad. Reglas que los datos prometen cumplir — unicidad de la clave, rangos válidos, porcentaje máximo de nulos, integridad referencial.
- SLA y frescura. Con qué frecuencia se actualizan los datos, la latencia esperada y qué ocurre cuando una carga falla o llega tarde.
- Propiedad. Quién es responsable del conjunto de datos, cómo contactar con ese equipo y dónde se comunican los cambios.
- Versión. Un número de versión que permite evolucionar el contrato de forma controlada, distinguiendo cambios compatibles de cambios que rompen a los consumidores.
En la práctica, esto suele vivir en un fichero estructurado — YAML o JSON — guardado en el repositorio junto al pipeline que produce los datos. El formato importa menos que el principio: el contrato es código, revisado como código y probado como código.
Contrato, catálogo y gobernanza: qué es diferente
Es fácil confundir los contratos de datos con iniciativas vecinas, pero el foco es distinto. Un catálogo de datos describe lo que existe — ayuda a descubrir tablas y a entender su contenido. Un contrato va más allá: garantiza que lo que existe se comporta como se prometió, y hace fallar el build cuando no lo hace.
La gobernanza de datos, por su parte, define políticas a nivel de organización: quién puede acceder a qué, cómo se clasifica la información sensible, qué reglas de retención se aplican. El contrato es el mecanismo concreto que operacionaliza parte de esa gobernanza en el punto donde los datos cambian de manos. No compiten — se complementan. El catálogo hace los datos descubribles, la gobernanza fija las reglas, y el contrato hace las promesas verificables en el día a día.
Cómo implementarlo en la práctica
Lo que separa un contrato de datos de una buena intención es la verificación automática. Sin enforcement, un contrato es solo documentación — y la documentación siempre se aleja de la realidad. La idea central es simple: cada vez que el productor intenta publicar datos que violan el contrato, el proceso falla antes de que esos datos lleguen a los consumidores.
Esto suele materializarse en dos puntos. Primero, en el CI/CD del lado del productor: un cambio en el pipeline que rompa el esquema declarado no pasa las pruebas y no se integra. Segundo, en tiempo de ejecución: cada carga se valida contra el contrato y, si falla una regla de calidad, los datos se retienen en cuarentena en lugar de propagarse. Las herramientas de prueba de datos y de validación de esquema lo hacen accesible sin construir todo desde cero, y plataformas de transformación como dbt permiten declarar y probar expectativas junto a las propias transformaciones.
El punto esencial no es la herramienta, es el cambio de responsabilidad: el productor ya no puede alterar los datos en silencio. La promesa pasa a tener consecuencias en el momento en que se rompe, y no semanas después, en un informe erróneo.
Evolucionar el contrato sin romper a quien consume
Un contrato no es una jaula. Los datos evolucionan, y el contrato tiene que evolucionar con ellos — la cuestión es hacerlo sin pillar a los consumidores por sorpresa. La distinción decisiva es entre cambios compatibles y cambios que rompen.
Añadir una columna nueva es, casi siempre, un cambio compatible: quien ya consumía sigue funcionando. Eliminar una columna, cambiar su tipo o alterar el significado de un valor es un cambio que rompe — y exige un proceso. Ese proceso suele pasar por versionar el contrato, anunciar la nueva versión con antelación, mantener la versión antigua durante un periodo de transición y solo después retirarla. Es exactamente lo que hace un equipo de software cuando deja obsoleta una versión de API.
Tratar la evolución con esta disciplina transforma la relación entre equipos. En lugar de cambios unilaterales seguidos de incendios, hay un canal previsible: quien produce sabe que puede evolucionar, y quien consume sabe que tendrá aviso y tiempo para adaptarse.
Minicaso: una empresa de retail
Considérese una empresa de retail con tienda física y online, cuyo departamento de datos alimentaba unos cuarenta informes a partir de tablas compartidas por el equipo de e-commerce. En una actualización de la plataforma de tienda, el campo que indicaba el valor del pedido pasó a incluir el IVA, cuando antes lo excluía. Nada en el esquema cambió — el tipo seguía siendo decimal — y por eso ninguna prueba técnica detectó el problema.
Durante once días, los informes de ingresos sobrevaloraron las ventas en torno a un 23%, y las decisiones de reposición de stock se tomaron sobre esos números. Cuando por fin se detectó la discrepancia, corregir los informes y reconstruir el histórico afectado consumió casi dos semanas de trabajo de dos personas.
La respuesta no fue comprar una herramienta cara, sino introducir un contrato para las tres tablas más críticas de e-commerce. El contrato declaraba explícitamente que valor_encomenda excluía el IVA e incluía una verificación de rango por artículo. Meses después, se volvió a intentar un cambio similar aguas arriba — esta vez el build falló el mismo día, con un mensaje claro, y el equipo lo corrigió antes de que ningún informe se viera afectado. El coste del contrato fue de unos días de trabajo; el coste evitado, semanas recurrentes.
Errores comunes y por dónde empezar
La forma más rápida de hacer fracasar una iniciativa de contratos de datos es intentar contractualizar todo a la vez. Eso genera cientos de ficheros que nadie mantiene y una sensación de burocracia que aleja a los equipos. Algunos errores recurrentes, y cómo evitarlos:
- Empezar por la herramienta y no por el dolor. Identifique primero los conjuntos de datos cuya rotura causa más daño y empiece por esos.
- Contratos sin enforcement. Un contrato que no hace fallar el build es solo documentación que se alejará de la realidad. La verificación automática es lo que le da valor.
- Olvidar la semántica. Validar tipos es fácil; lo que rompe informes son los cambios de significado. Documente unidades, moneda y definiciones de negocio.
- No definir un responsable. Sin propiedad clara, nadie mantiene el contrato ni responde cuando falla.
Así que, por dónde empezar: elija uno o dos conjuntos de datos críticos, escriba un contrato mínimo que cubra esquema, semántica y dos o tres reglas de calidad, y conéctelo a la verificación automática. Demuestre el valor con una rotura evitada y deje que la adopción crezca a partir de ahí.
En la práctica
Los contratos de datos no son una tecnología nueva que instalar, sino una disciplina que adoptar: hacer explícitas, versionadas y verificables las promesas que ya existen de forma implícita entre equipos. El retorno no está en impresionar a nadie con arquitectura, sino en evitar la clase de fallo que erosiona en silencio la confianza en los datos.
Empiece pequeño, en el punto donde más duele, con verificación automática desde el primer día. Un solo contrato que atrape una rotura antes de que llegue a un informe suele pagar, por sí solo, todo el esfuerzo de crearlo. A partir de ahí, la pregunta deja de ser quién tocó estos datos y pasa a ser qué versión del contrato queremos para el próximo trimestre.
