Let's Talk About Data Contracts: Standards, Tooling & Best Practices

Presentación

Hola, me llamo Simon. Soy software engineer de corazón y hace unos cuatro años acabé en el mundo de los datos. Vengo del ecosistema Java: soy coautor de un libro sobre clean code en Java que se llama "Java by Comparison". Dato curioso: ese libro se escribió antes de la IA, y ahora mismo hay una demanda porque los modelos de Anthropic lo procesaron de forma ilegal para entrenarse.

Trabajé mucho tiempo como consultor en INNOQ y en 2025 sacamos una startup de ahí. Soy co-founder y CEO de Entropy Data, donde construimos un marketplace de productos de datos basado en Data Contracts.

Junto con varios colegas traduje al alemán el libro "Data Mesh", lanzamos datamesh-architecture.com y datacontract.com, comantengo herramientas open source como la Data Contract CLI y el Data Contract Editor, y formo parte del Technical Steering Committee de BITOL, el proyecto de la Linux Foundation para los estándares de Data Contracts. Así que creo que hoy puedo hablarte de Data Contracts con bastante criterio.

¿Por qué estoy hoy aquí?

Una anécdota rápida. Hace alrededor de año y medio di una charla en la conferencia BARC "Heart of Data Mesh & Fabric" y Peter Baumann, de INFOMOTION, la publicó en LinkedIn. Se hizo bastante viral, más de 1.000 likes, con el título "A Data Contract Is Not a Contract". Provocador, claro, pero la gente hizo clic.

Así que hablemos de Data Contracts. Y cuando hablamos de datos, en realidad estamos hablando de confianza. Confianza en los datos. Eso es lo esencial.

¿Qué es un Data Contract?

Un Data Contract es un documento que define la propiedad, la estructura, la semántica, la calidad de los datos y las condiciones de uso para intercambiar datos entre un Data Producer y sus consumidores. Es como una especificación de API, pero para el mundo de los datos.

En el diagrama se ve: al consumidor le importa usar los datos, pero sobre todo le importa la confianza. El Data Contract juega un papel decisivo, porque el Data Producer ofrece datos y deja por escrito sus promesas en el contrato. Si esas promesas coinciden con los datos reales, el consumidor puede usarlos y confiar en el contrato.

Un Data Contract tiene muchos elementos. Los veremos en detalle, pero antes quiero contarte cómo llegamos a tener estándares.

El hueco: no había especificación para las APIs de datos

Hace unos años, en el mundo del software y de los datos, había una respuesta muy clara para las APIs REST: OpenAPI (el sucesor de Swagger). Para interfaces asíncronas tipo Kafka estaba AsyncAPI. Pero para los datos, si yo quería compartir un dataset grande, no había ninguna buena respuesta. Existían soluciones sueltas, nada estandarizado.

Y sin embargo teníamos APIs de datos por todas partes: CSV por SFTP (sí, ya oigo la primera risa), JSON en S3, tablas SQL en BigQuery, ficheros Iceberg, vistas de Snowflake, Delta Live Tables. Todo eso son interfaces. Alguien ha construido encima algo crítico, y si esa interfaz se rompe, se rompe también todo lo que hay aguas abajo.

Nos hacía falta una forma de confiar en que, si consumo un CSV de un servidor SFTP, ese CSV se mantiene estable y los datos tienen la calidad que se acordó.

Cada uno se hizo su propio formato

A medida que los datos se descentralizaban, cada vez más equipos empezaron a compartir datos con cada vez más consumidores. Ya no era un único equipo de datos con un servidor Oracle y un data warehouse.

Muchas empresas vieron la necesidad de los Data Contracts, y cada una se construyó su propio formato. Todas tenían el mismo problema y todas se hicieron su propia solución. ¿Lo único que tenían en común? Casi todas eligieron YAML. Bueno, alguna usó JSON, y alguna incluso Word y Excel. Pero entonces apareció un estándar.

El Open Data Contract Standard (ODCS)

El estándar que apareció es el Open Data Contract Standard. Viene originalmente de PayPal, una de esas empresas que se había hecho su propio formato de Data Contract. Lo liberaron como open source bajo licencia Apache y más tarde lo donaron a la Linux Foundation.

Yo me sumé al comité de estandarización. Quitamos los elementos específicos de PayPal y lo ampliamos para que lo pudieran usar otras empresas. Desde 2025 va por la versión 3 (ahora 3.1) y de verdad que se puede usar muy bien. Este año estamos viendo una adopción fuerte: Collibra se ha comprometido, OpenMetadata se ha comprometido y ya ha construido funcionalidades para el estándar.

Cubre fundamentos, esquema, calidad de datos, precios, equipo, seguridad, SLAs, infraestructura, soporte, reglas de negocio y propiedades personalizadas.

Fundamentos

En el bloque de fundamentos definimos el ID, el nombre, la versión y un estado para ir introduciendo y retirando contratos. ¿Cómo se versiona un Data Contract? Lo veremos luego, en la parte de buenas prácticas. Todos estos detalles puedes consultarlos en datacontract.com.

Esquema

La descripción del esquema es fundamental: define cómo están estructurados los datos. Defines tablas y sus columnas. Lo interesante es que tenemos tipos físicos y tipos lógicos. También incluimos ejemplos, clasificación de datos y nombres de negocio, con lo que ya vamos en dirección a la semántica. Puedes describir el esquema con muchísimo detalle.

Calidad de datos

La calidad de datos forma parte del contrato porque forma parte de lo que yo, como proveedor de datos, prometo a mis consumidores. Aquí tenemos una comprobación de calidad para valores inválidos usando una librería tipo Soda o Great Expectations, y comprobaciones basadas en SQL que son ejecutables. Con las herramientas adecuadas puedes verificar automáticamente si los datos reales cumplen el contrato.

Equipo

La sección de equipo te dice quién proporciona estos datos y cómo contactar con esa gente. ¿Cuál es el canal de Slack? ¿Cuál es el canal de soporte preferido? ¿De verdad responden? Esto es clave: cuando algo va mal con los datos, necesitas saber a quién escribir.

Condiciones de uso

Las condiciones de uso definen qué puedo hacer con los datos como consumidor y qué no. ¿Hay condiciones de licencia? ¿Aplica el RGPD? ¿Hay políticas internas de protección de datos que nos hemos impuesto nosotros mismos? ¿Qué me está permitido hacer con los datos y qué no? Esto también genera confianza.

Service Level Agreements

Los Service Level Agreements son los de siempre: retención de datos, frescura, latencia. Son esenciales y también se pueden verificar automáticamente. Aquí los tengo garantizados por escrito por el proveedor, negro sobre blanco.

Servidores e infraestructura

Y por último: ¿dónde viven realmente los datos? Aquí tengo un ejemplo con Postgres en Supabase. Pero puede ser cualquier cosa: Databricks, Snowflake, un CSV en S3 o cualquier otra plataforma de datos.

Automatízalo todo

Una vez que tengo un contrato con toda esta información, puedo hacer mil cosas con él:

• Testear: poner los datos y el contrato uno al lado del otro y comprobar si coinciden. Si no coinciden, lanzar una alerta y escalar.
• Generar código: producir el DDL de SQL, un modelo dbt o incluso dejar que la IA construya el proyecto dbt entero. Cuando la entrada y la salida están claras, la IA puede rellenar lo que hay en medio.
• Monitorización continua: comprobar constantemente si el contrato sigue cuadrando con los datos, que se van enriqueciendo sin parar.
• Distribuir metadatos: llevar el contrato (la fuente de verdad) a catálogos y metastores, y usarlo como documentación.
• Aprovisionar infraestructura: crear buckets de S3, configurar roles de IAM para un marketplace de datos, para que otros accedan sin fricción a los datos protegidos por el contrato.

Muy potente para automatizar.

Data Contract CLI

La herramienta imprescindible es la Data Contract CLI, un proyecto open source con unas 800 estrellas en GitHub. Lee un contrato, se conecta a cualquier plataforma de datos que se te ocurra y comprueba automáticamente si lo que dice el contrato coincide con los datos reales de la plataforma. Y te devuelve un informe.

Puedes ejecutarla en un pipeline, en Airflow, y seguir los resultados a lo largo del tiempo. Exporta a muchísimos formatos e importa desde fuentes de datos existentes para generar rápido tu primer contrato.

Data Contract Editor

Como a veces quieres editar a mano, construimos el Data Contract Editor, un componente web open source donde editas tus contratos de forma visual. La CLI está integrada directamente, así que desde la pestaña de test lanzas las comprobaciones del contrato con un solo clic.

Plantilla de Excel

Y la experiencia dice que, por muy bonito y reluciente que sea todo, la gente vuelve una y otra vez a nuestra vieja plantilla de Excel, que mapea exactamente el estándar ODCS. Para mucha gente, Excel es sencillamente la interfaz más fácil. No lo dirías, pero en este caso Excel no se muere. Y por supuesto, la CLI también puede leer el fichero de Excel para testear en CI.

Demo en vivo: testear contratos contra datos reales

En la demo abrí el Data Contract Editor con un contrato de dos tablas conectadas por una relación de clave foránea. A la derecha vemos una vista previa con descripciones, ejemplos, información de particionado, claves primarias, campos obligatorios, el equipo responsable, dónde viven los datos (Postgres) y los service level agreements.

Lo interesante: puedo lanzar una comprobación en vivo desde el editor, comparando el contrato con los datos reales. El informe muestra qué comprobaciones han pasado. Por dentro lo implementamos con Soda Core.

Este resultado se puede publicar junto al contrato en un marketplace. Y eso genera confianza, porque sé que hace unos segundos una máquina verificó que todo está en verde y puedo montar mi caso de uso o mi análisis sobre estos datos sin miedo.

Buena práctica: el mapeo 1:1:1:1:1

Un Data Contract en una versión mayor se corresponde con un Output Port de un producto de datos, que se corresponde con un esquema de base de datos (que puede contener varias tablas) y con un rol de lectura que puedo contratar.

Si consigues mantener ese mapeo, todo sigue siendo simple. Cuanto más te alejas de él (un contrato por tabla, y de repente tienes demasiados contratos; o varios roles por contrato, y de repente es demasiado complejo), más se complica todo. Desviarse sale caro.

Buena práctica: su hábitat natural

Los Data Contracts viven en el repositorio git del producto de datos. Tienes un fichero YAML con la descripción del producto de datos y un directorio datacontracts/ donde están los contratos como ficheros YAML.

Puedes definir contratos para los Output Ports (lo que ofrezco) y, si quieres, también para los Input Ports (lo que consumo). Por ejemplo: "de tu tabla solo uso las tres primeras columnas, el resto lo ignoro". Incluso puedes añadir tus propias comprobaciones de calidad además de las que ofrece el proveedor.

Buena práctica: ciclo de vida y evolución

Gestión del cambio clásica, basada en versiones mayores. Los cambios que rompen compatibilidad exigen una nueva versión mayor. Los que no la rompen (por ejemplo, añadir una columna) se resuelven con versiones menores y de parche, así que la V1 sigue activa mucho tiempo.

Cuando de verdad hace falta un cambio incompatible, saco la V2 junto a la V1. Hay un periodo de gracia en el que ambas versiones conviven, con la V1 marcada como deprecada y la V2 activa, para que los consumidores tengan tiempo de migrar. Cuesta algo de esfuerzo, pero mantiene las cosas limpias.

¿Data-first o contract-first?

Data-first es el enfoque más natural: ya tienes datos en Snowflake o en Databricks y los pones "bajo contrato". Puedes usar el import de la CLI para generar rápido una primera versión del contrato.

Pero desde el momento en que activas un contrato, este se convierte en la fuente de verdad. Si los datos se desvían, los datos están mal: el contrato, por definición, siempre tiene razón. Eso hace que pases de forma natural a contract-first, es decir, todos los cambios entran primero en el contrato y después en la implementación.

Ya tenemos nuestro primer cliente en Estados Unidos y son totalmente contract-first. Siempre crean primero el contrato y luego construyen el producto de datos. La ventaja: puedes discutir con precisión cómo es la interfaz y después construirla es fácil. Con la IA, las transformaciones prácticamente se escriben solas cuando la interfaz está bien definida.

Buena práctica: automatización

Puedes automatizar en tres momentos:

• A diario, desde la plataforma de datos: ejecuta datacontract test para verificar continuamente los contratos contra los datos de producción.
• En cada commit de una PR: ejecuta datacontract lint (incluidas las reglas de tu empresa) y datacontract test --server=staging para detectar problemas antes del merge. Una empresa puede imponer reglas del tipo "todo campo debe tener una clasificación de datos"; si no la tiene, la PR no pasa.
• En cada commit a main: ejecuta datacontract publish para llevar el contrato a tu marketplace de datos, donde la gente puede ver los datos y confiar en ellos.

Por qué los agentes de IA necesitan Data Contracts

Un Data Contract es, por definición, la fuente de verdad de los metadatos de un conjunto de datos ofrecido. ¿Qué puede haber mejor para una IA agéntica que mirar el contrato, comprobar si le sirve para la tarea que tiene entre manos, comparar varios contratos y usar después los datos protegidos por el contrato que mejor encaje?

En la demo le pregunté al agente de IA: "¿quiénes son mis mejores clientes?". Por detrás buscó productos de datos con contrato, encontró el adecuado, revisó el contrato para verificar que podía resolver la tarea, generó una consulta SQL, la ejecutó y devolvió la respuesta.

Ese es el futuro. Da igual qué cliente de IA uses: vienen agentes con mucha hambre de datos. Quieren entrar en Snowflake, en Databricks, donde sea que vivan los datos. El Data Contract y la capa de gobernanza entre los agentes y los datos son la línea de defensa.

La arquitectura: un servidor MCP de productos de datos

Desde el punto de vista de la arquitectura: arriba está el cliente de IA, abajo la plataforma de datos donde viven los datos, y en medio un marketplace con los metadatos. El agente de IA habla con un servidor MCP de productos de datos que sabe buscar, recuperar los metadatos junto con el contrato y ejecutar consultas.

La capa clave que hay en medio es la gobernanza: gestión de permisos, comprobación de las condiciones de uso, políticas globales, cuotas y controles de seguridad. Esto va a pasar, porque sencillamente es demasiado natural como para que no pase.

ODCS va a estar en todas partes

Swagger 1.0 salió en 2011 y hoy OpenAPI está en todas partes.

ODCS 3.0 salió en 2025. Creo que dentro de cinco años los Data Contracts serán tan omnipresentes como lo es hoy OpenAPI en el mundo de las APIs.

Gracias

Gracias por escuchar. Si quieres seguir la conversación, me encuentras en LinkedIn, puedes escribirme a simon.harrer@entropy-data.com o pasarte por www.entropy-data.com. Y si te gusta el open source, dale una estrella en GitHub a datacontract-cli.