Data quality framework: reglas de validación

Antes de fundar MERIDIAN, trabajando como Data/BI Engineer aprendí algo esencial: una transformación o un pipeline no se da por bueno solo porque se ejecute sin errores. Hay que comprobar volumen, consistencia y valores antes de confiar en lo que produce, y esa disciplina de validar antes de confiar es exactamente lo que un framework de calidad de datos convierte en proceso repetible.

La calidad de datos es uno de esos temas que todo el mundo reconoce como importante pero que pocas empresas abordan de forma sistemática. Lo habitual es que los problemas de calidad se descubran cuando un informe muestra cifras imposibles, cuando un modelo predictivo empieza a dar resultados absurdos o cuando un cliente recibe una factura errónea.

En ese momento se investiga, se corrige manualmente y se sigue adelante hasta la próxima incidencia. Es un ciclo reactivo que consume tiempo, genera desconfianza en los datos y, en muchos casos, alimenta la tentación de volver a Excel porque 'al menos ahí controlo lo que pasa'.

Un framework de calidad de datos rompe ese ciclo. No elimina todos los problemas (eso no existe), pero los detecta antes de que tengan impacto y proporciona un mecanismo para resolverlos de forma ordenada.

¿Qué es un framework de calidad de datos?

Un framework de data quality es una estructura organizada que define qué condiciones deben cumplir los datos para ser considerados válidos, cómo se comprueban esas condiciones, qué pasa cuando fallan y quién es responsable de actuar.

No es solo una herramienta ni solo un conjunto de tests automáticos. Incluye reglas de validación (la parte técnica), umbrales de aceptación (la parte de criterio), procesos de remediación (la parte organizativa) y métricas de seguimiento (la parte de mejora continua).

• Reglas de validación: condiciones que los datos deben cumplir. Si no las cumplen, se genera una alerta o un bloqueo.
• Umbrales: no todo fallo es igual de grave. Algunos justifican parar un pipeline, otros solo requieren una notificación.
• Procesos de remediación: quién investiga, quién corrige, en qué plazo y cómo se documenta.
• Métricas: tasa de cumplimiento, tiempo medio de resolución, tendencias de calidad por dominio de datos.

¿Qué tipos de reglas de validación hay?

Las reglas de validación se pueden clasificar en seis categorías principales, de menor a mayor complejidad. Un framework maduro combina todas, pero no hace falta empezar con las seis. Empezar con las tres primeras ya cubre la mayoría de problemas habituales.

1. Completitud (nulls y campos obligatorios)

La regla más básica: ¿están presentes los datos que deberían estar? Un pedido sin fecha, un cliente sin email, un producto sin precio. Las reglas de completitud comprueban que los campos obligatorios no son nulos y que las tablas tienen el volumen esperado de registros.

Ejemplo: la tabla de pedidos debería tener al menos 100 registros nuevos cada día laborable. Si un día aparecen 5, algo ha fallado en la ingesta aunque técnicamente los datos sean correctos.

2. Formato y tipo de dato

¿Los datos tienen el formato esperado? Un CIF que no cumple la estructura de 9 caracteres, un código postal con letras, una fecha en formato americano cuando debería ser europeo. Estas reglas son especialmente importantes cuando los datos vienen de fuentes externas o de entrada manual.

3. Rango y valores permitidos

¿Los valores están dentro de lo razonable? Un precio negativo, una edad de 250 años, un porcentaje superior a 100. Las reglas de rango definen los límites aceptables para cada campo numérico o de fecha. Son simples de implementar y detectan errores que pueden pasar inadvertidos durante semanas.

4. Integridad referencial

¿Las relaciones entre tablas son consistentes? Un pedido que referencia un cliente que no existe, un movimiento contable con un centro de coste que no aparece en la tabla maestra, un producto asignado a una categoría eliminada. Las reglas de integridad referencial comprueban que las foreign keys apuntan a registros reales.

Este tipo de reglas es especialmente crítico en pipelines ETL donde los datos se transforman y las relaciones pueden romperse durante la transformación.

5. Unicidad y duplicados

¿Hay registros duplicados donde no debería haberlos? Un cliente que aparece dos veces con el mismo CIF pero diferentes IDs internos, un pedido duplicado por un fallo en la ingesta, una transacción contable repetida. Las reglas de unicidad comprueban que las claves primarias y claves de negocio son únicas.

6. Reglas de negocio

Son las reglas más complejas y las que más valor aportan, porque reflejan la lógica específica de tu empresa. Un margen bruto no puede ser negativo en productos de catálogo estándar. La suma de asignaciones de un proyecto debe ser igual al presupuesto total. La fecha de entrega de un pedido no puede ser anterior a la fecha de creación.

Estas reglas las define negocio, no el equipo técnico. El framework debe facilitar que se expresen de forma que puedan ejecutarse automáticamente.

¿Con qué herramientas implementarlo?

Hay tres herramientas que dominan el espacio de data quality en stacks modernos. Cada una tiene su enfoque y sus puntos fuertes.

dbt tests

Si ya usas dbt para la transformación de datos, sus tests nativos son el punto de partida natural. dbt incluye cuatro tests genéricos de serie (not_null, unique, accepted_values, relationships) y permite crear tests personalizados como macros SQL. La ventaja principal es que los tests se ejecutan como parte del mismo flujo de transformación, sin necesidad de otra herramienta.

Limitaciones: dbt tests son binarios (pasan o fallan), no tienen umbrales configurables de serie (aunque se pueden implementar con paquetes como dbt-expectations) y la generación de informes de calidad requiere herramientas adicionales.

Great Expectations

Great Expectations (GE) es la opción más completa para equipos que trabajan en Python. Define las validaciones como 'expectations' (expectativas) que se agrupan en suites. Cada expectation es una regla de validación con parámetros configurables: en lugar de 'esta columna no es nula', puedes definir 'esta columna tiene menos del 2% de nulos'.

GE genera automáticamente documentación HTML de las validaciones (Data Docs), lo que facilita la comunicación con negocio. Tiene más de 300 expectations predefinidas y permite crear las tuyas propias. La curva de aprendizaje es mayor que la de dbt tests, pero la flexibilidad compensa en proyectos con requisitos complejos.

Soda

Soda es la opción más accesible para equipos mixtos (técnicos y no técnicos). Utiliza un lenguaje de configuración YAML (SodaCL) que permite definir checks de forma legible sin escribir código. También ofrece una interfaz web (Soda Cloud) para visualizar resultados y configurar alertas.

La ventaja de Soda es la velocidad de puesta en marcha y la facilidad para que perfiles de negocio entiendan y participen en la definición de reglas. La limitación es que para validaciones muy específicas o complejas, puede quedarse corta comparada con GE.

¿Cómo definir umbrales de alerta?

Uno de los errores más comunes al implementar un framework de calidad es tratar todos los fallos igual. Si cada test fallido para el pipeline y genera una alerta urgente, el equipo acaba ignorando las alertas. Es el equivalente a la alarma del coche que salta con el viento.

Un buen framework define tres niveles de severidad.

• Crítico (bloquea el pipeline): el fallo indica un problema grave que haría que los datos downstream fueran incorrectos. Ejemplo: la tabla de pedidos está vacía, una clave primaria tiene duplicados. El pipeline se para y se notifica al equipo de datos.
• Warning (no bloquea, pero genera alerta): el fallo indica un problema que merece investigación pero que no invalida el dataset completo. Ejemplo: el 3% de los registros tienen un campo nulo que debería estar relleno. Se notifica, se investiga en el siguiente ciclo.
• Informativo (se registra, no se notifica): desviaciones menores que se registran para análisis de tendencias. Ejemplo: el volumen de registros diarios es un 10% inferior a la media, pero dentro del rango estacional.

Definir estos umbrales requiere criterio de negocio. Una columna de email nulo puede ser un warning en una tabla de leads y un crítico en la tabla de clientes activos. Para profundizar en qué métricas medir, tenemos un artículo sobre KPIs de calidad de datos que complementa este tema.

Integración con gobernanza de datos

Un framework de calidad de datos no debería vivir aislado del programa de gobernanza. Si la empresa tiene (o está construyendo) un modelo de gobierno del dato, las reglas de validación son la capa operativa que hace tangible la gobernanza.

Quién define las reglas

En un modelo de gobernanza sano, las reglas técnicas las define el equipo de datos (data engineers, analytics engineers) y las reglas de negocio las proponen los data owners o stewards de cada dominio. El framework debe facilitar esa colaboración, no convertirla en un cuello de botella.

Quién responde cuando algo falla

Cada regla de validación debería tener un responsable asignado. Para reglas técnicas, suele ser el equipo de datos. Para reglas de negocio, el data owner del dominio afectado. Si nadie es responsable de un fallo, no se corrige.

Documentación y catálogo

Las reglas de validación deberían estar documentadas y accesibles, no enterradas en código que solo entiende quien lo escribió. Herramientas como el catálogo de dbt (dbt docs generate) o los Data Docs de Great Expectations ayudan, pero requieren el hábito de documentar. Si estás dando los primeros pasos en gobernanza, nuestra guía sobre implementar gobierno del dato paso a paso cubre el proceso completo.

¿Cómo empezar sin sobredimensionar?

El mayor riesgo de un framework de calidad de datos no es que sea incompleto, sino que sea tan ambicioso que nunca se ponga en producción. Este es un plan de arranque realista.

1. 1Identifica las 3-5 tablas más críticas de tu pipeline. Normalmente son las que alimentan informes de dirección, modelos de IA o procesos automatizados.
2. 2Define 3-4 reglas básicas por tabla: not_null en campos clave, unique en claves primarias, al menos una regla de rango o integridad referencial.
3. 3Implementa los tests en la herramienta que ya uses (dbt si lo tienes, Soda si no). No compres una herramienta nueva solo para esto.
4. 4Configura alertas básicas: un mensaje en Slack o un email cuando un test crítico falla. Sin plataformas complejas.
5. 5Revisa los resultados semanalmente durante el primer mes. Ajusta umbrales, elimina falsos positivos, añade reglas que faltan.
6. 6Amplía gradualmente: más tablas, más tipos de reglas, umbrales más finos. Solo cuando el equipo está cómodo con el proceso actual.

Un framework de calidad de datos útil no se construye en un sprint. Se construye de forma incremental, empezando por lo que más duele y expandiendo según la empresa gana madurez y confianza en el proceso.

¿Qué errores habituales conviene evitar?

• Escribir 200 reglas el primer día: genera fatiga de alertas, falsos positivos y abandono del framework.
• No involucrar a negocio: un framework definido solo por técnicos pierde las reglas de negocio, que son las que más valor aportan.
• No documentar por qué existe cada regla: cuando alguien nuevo se incorpora o cuando una regla falla, nadie sabe si es válida o un residuo histórico.
• Tratar la calidad de datos como un proyecto con fecha de fin: es un proceso continuo. Los datos cambian, las fuentes evolucionan, las reglas necesitan mantenimiento.
• Elegir la herramienta antes de definir las necesidades: primero las reglas, después la herramienta que las implementa de la forma más natural para tu equipo.

Si necesitas ayuda para diseñar e implementar un framework de calidad de datos adaptado a tu empresa y tus herramientas, es uno de los servicios que ofrecemos dentro de gobierno del dato y calidad.

Para más información, puedes consultar la informe de Gartner sobre datos listos para IA.