Qué es un contrato de datos
Un contrato de datos es el acuerdo escrito entre quien produce un dato y quien lo consume: qué se entrega, con qué forma, para qué se puede usar y cuándo está disponible.
La analogía más útil es la de una API. Nadie integra un servicio sin saber qué devuelve y con qué garantías. Con una tabla, en cambio, lo normal es descubrir las reglas el día que algo se rompe: alguien renombró una columna, dejó de etiquetar un dato sensible o cambió el horario de carga, y el tablero de otro equipo amaneció mal.
La idea que más se confunde: un contrato no es una suite de pruebas de calidad. La calidad dice si el dato está bien. El contrato dice además quién responde por él, qué columnas se garantizan, para qué se puede usar —también por un agente de IA— y si sigue gobernado. La calidad es una parte del contrato, no el contrato.
Qué tiene adentro
Un contrato completo tiene siete partes. La diferencia que importa entre ellas es cuáles puede comprobar una herramienta y cuáles quedan declaradas por escrito:
| Parte | ¿Se comprueba? | Qué aporta al gobierno | Qué dice |
|---|---|---|---|
| Detalle | — | Alguien responde por la promesa | Nombre, responsable y descripción |
| Términos de uso | No | La finalidad del dato, que ninguna prueba de calidad mira | Usos permitidos y no permitidos, también para agentes de IA |
| Esquema | Sí | Control de cambios: el productor sabe qué no puede tocar sin avisar | Las columnas que se garantizan |
| Reglas semánticas | Sí | Que el gobierno siga puesto, no solo que se haya puesto una vez | Condiciones sobre los metadatos: responsable, etiquetas, dominio |
| Seguridad | No | A quién está destinado el dato | Clasificación, quién consume y qué filas ve |
| Calidad | Sí | Que el dato esté bien | Las pruebas que forman parte del acuerdo |
| Acuerdo de servicio (SLA) | No | Cuándo se puede contar con el dato y cuánto dura | Frecuencia de actualización, latencia, hora de disponibilidad, retención |
La tabla sigue la estructura de OpenMetadata. El estándar abierto de contratos, ODCS (Open Data Contract Standard), organiza piezas equivalentes —esquema, calidad, acuerdo de servicio, equipo, roles— para que un contrato pueda viajar entre herramientas.
La prueba de que no es solo calidad
Un ejemplo sobre una tabla de clientes con datos de práctica. El contrato tiene tres reglas semánticas —la tabla tiene responsable, está marcada como dato sensible, pertenece a su dominio— y dos pruebas de calidad: identificador único y correo no nulo.
Se ejecutó tres veces. Antes de la segunda, a la tabla se le quitó la etiqueta de dato sensible. Los datos no cambiaron y las pruebas de calidad siguieron al 100%. El resultado:
El contrato falló y señaló la regla por su nombre, mientras la calidad seguía en verde. Una suite de pruebas sobre esa tabla no habría dicho nada: los datos estaban bien. Lo que se rompió es que la tabla dejó de estar gobernada —para la búsqueda, las políticas de acceso y cualquier agente que la consulte, pasó a ser un dato cualquiera—, y eso es justamente lo que un contrato vigila y una prueba de calidad no.
Cómo se escribe uno en OpenMetadata
Las capturas son de OpenMetadata 1.12 sobre una base de ejemplo; en versiones nuevas algún rótulo puede cambiar de lugar. El paso a paso completo, con todas las opciones, vive en la documentación oficial (enlace al final). Acá va el recorrido con el criterio de cada paso.
Antes de empezar: la tabla ya catalogada y curada —con responsable, dominio y etiquetas—, porque el contrato no carga esas cosas: comprueba que estén. Y las pruebas de calidad ya creadas sobre la tabla. Para ejecutar el contrato hace falta además el servicio de ingesta de OpenMetadata encendido: las pruebas de calidad corren ahí.
1. Abrir el asistente. En la ficha de la tabla, pestaña Contract → Add Contract. Hay tres formas de darlo de alta: escribirlo en la interfaz, o importarlo en el formato propio de OpenMetadata o en ODCS.
2. Detalle: quién responde. El título funciona como identificador —forma parte del nombre completo del contrato—, así que conviene sin espacios ni acentos. El responsable suele ser un equipo. Completá esta pestaña primero: el botón Save se enciende al pasar por la pestaña de reglas aunque falte el título, y si lo presionás, el error que aparece es un mensaje técnico del servidor, no un "falta el título".
3. Términos de uso: para qué se puede usar. Es el único lugar donde queda escrito el uso permitido del dato. Funciona bien en tres párrafos: uso permitido, uso no permitido y qué puede hacer un agente de IA con la tabla.
4. Esquema: qué se garantiza. Se marcan las columnas que usan los consumidores, no todas. Cada columna marcada es un compromiso; las demás el productor las puede cambiar sin romper el acuerdo.
5. Reglas semánticas: el corazón del contrato. Cada regla tiene nombre, descripción y una condición armada con tres desplegables: campo, operador y valor. Los campos disponibles son metadatos de la tabla: responsable, descripción, etiquetas, nivel de criticidad, dominio, producto de datos, entre otros.
Dos criterios. Una regla por cosa: cuando el contrato falla, muestra el nombre de la regla que no se cumplió, así que tres reglas separadas dicen qué se rompió y una sola con todo adentro dice solamente que algo se rompió. Y escribí la descripción como la explicación que va a leer quien encuentre el contrato en rojo, porque es el texto que se guarda como motivo.
6. Seguridad: a quién está destinado. Clasificación, política de acceso, identidades y filtro de filas. Todo es texto libre: la clasificación no se toma de las etiquetas del catálogo y la política no se aplica. Es una declaración.
7. Calidad. Se eligen, entre las pruebas que ya existen sobre la tabla, las que forman parte del acuerdo. OpenMetadata crea para el contrato su propio agente de ejecución y lo borra junto con él.
8. Acuerdo de servicio. Frecuencia de actualización, latencia máxima, hora a la que el dato tiene que estar disponible, retención y la columna que marca cuándo se actualizó cada fila.
9. Guardar y ejecutar. Al guardar, el contrato queda aprobado: no hay paso de revisión en el asistente. Guardar no lo ejecuta; la rueda dentada de arriba tiene Run now, y además OpenMetadata trae una aplicación que ejecuta todos los contratos una vez por día. Con el resultado, la frontera de la tabla de arriba se ve en pantalla: esquema, reglas semánticas y calidad llevan su estado; acuerdo de servicio y seguridad no llevan ninguno.
Cada ejecución queda en el historial del contrato. En el ejemplo: cumple, incumple, cumple.
Lo que conviene saber antes de confiar en él
Medido ejecutando, no leído en un folleto:
- Tres de siete partes se comprueban. Esquema, reglas semánticas y calidad. Términos, seguridad y acuerdo de servicio quedan escritos junto al dato, y hacerlos cumplir depende de otros controles: permisos, monitoreo de frescura, revisión de usos.
- Un cambio de tipo no hace fallar el contrato. El esquema falla si una columna garantizada deja de existir, pero si cambia de tipo sigue en verde: de un entero a texto queda anotado como diferencia; de un entero a otro entero más grande, ni eso.
- Nace aprobado. Si tu organización necesita aprobación formal de un contrato, ocurre fuera de la herramienta.
- La exportación a ODCS pierde la parte de gobierno. De un contrato escrito en la interfaz no salen el texto de los términos de uso, ni las reglas semánticas, ni las de calidad. Para moverlo a otra instalación de OpenMetadata, la exportación propia (Export) lo lleva completo.
Cuándo vale la pena escribir uno
Vale la pena cuando una tabla la consumen varios equipos o agentes de IA, cuando tiene datos sensibles, o cuando los cambios del productor ya rompieron algo aguas abajo. Ahí el contrato convierte en regla lo que hoy es una conversación que se olvida.
Todavía no, si la tabla no tiene responsable ni etiquetas: el contrato comprueba un gobierno que tiene que existir antes. El primer paso es catalogar y curar (OpenMetadata). Tampoco rinde en una tabla que solo usa quien la produce: no hay nadie del otro lado del acuerdo.
Y si lo que necesitás es solamente probar que el dato está bien, lo que buscás es una herramienta de calidad, como Great Expectations: el contrato empieza donde esa pregunta termina.
Para ir más profundo
- Documentación oficial de contratos en OpenMetadata: docs.open-metadata.org — Data Contracts
- ODCS, el estándar abierto de contratos de datos: github.com/bitol-io/open-data-contract-standard