Políticas de Calidad de Datos — Guía Práctica

El 80% de los proyectos de analítica e IA fallan no por falta de algoritmos, sino porque los datos de partida tienen problemas de calidad que no se detectaron a tiempo. Valores duplicados, campos vacíos, fechas incoherentes, importes negativos donde no deben existir. Cuando estos problemas llegan al dashboard o al modelo, el resultado es desconfianza y, en el mejor caso, trabajo manual para corregirlos.

Las 6 dimensiones de calidad de datos

El marco más extendido para medir calidad de datos define seis dimensiones. No todas son igual de críticas en cada empresa o dominio, pero todas deben estar definidas explícitamente para poder medirlas.

Cómo definir una política de calidad de datos

Una política de calidad de datos es el documento que específica qué estándares deben cumplir los datos de un dominio, quién es responsable de garantizarlos y qué ocurre cuando no se cumplen. No es un documento técnico: es un acuerdo entre negocio y tecnología.

• Alcance: qué dominio de datos cubre la política (cliente, producto, proveedor...).
• Propietario: quién es el Data Owner que valida y aprueba las reglas.
• Dimensiones priorizadas: cuáles de las 6 dimensiones son críticas para este dominio.
• Reglas concretas: mínimo 5-10 reglas explícitas por dominio, redactadas en lenguaje de negocio.
• Umbrales de aceptación: qué % de registros inválidos es aceptable antes de activar una alerta.
• Proceso de remediación: quién actúa cuando se detecta una incidencia y en qué plazo.
• Revisión periódica: cada cuánto se revisa y actualiza la política.

Herramientas para implementar controles de calidad automáticos

Las políticas de calidad no son útiles si el control es manual. La verificación debe ocurrir automáticamente cada vez que los datos entran o se transforman en el sistema.

dbt Tests

Si tu pipeline de datos usa dbt (el estándar de facto para transformaciones SQL), puedes definir tests directamente en los archivos YAML de cada modelo. Los tests nativos cubren unicidad, no nulos, valores aceptados y relaciones referenciales. Para reglas más complejas, el paquete dbt-expectations añade validaciones de rango, formato y estadísticas.

Great Expectations

Great Expectations es una librería open source de Python que permite definir 'expectations' sobre los datos y validarlas en cualquier punto del pipeline: en la ingesta, después de transformaciones o antes de cargar en el data warehouse. Genera informes HTML de calidad que pueden publicarse como documentación de datos.

Herramientas comerciales

Para organizaciones con múltiples dominios y equipos distribuidos, herramientas como Collibra DQ, Informatica Data Quality o Talend Data Quality ofrecen interfaces visuales para definir reglas, dashboards de calidad y flujos de remediación. El coste de licencia suele partir de 30.000-50.000 €/año, lo que las hace adecuadas para empresas grandes o medianas con alta madurez de datos.

El proceso de remediación: qué hacer cuando los datos fallan

Definir reglas y detectar incidencias es solo la mitad del trabajo. La otra mitad es tener un proceso claro para remediar los problemas. Sin remediación, el control de calidad genera alertas que nadie gestiona.

• Clasificar la incidencia: ¿es un error puntual, sistémico o en la fuente?
• Asignar responsable: el Data Steward del dominio afectado recibe la alerta y la investiga.
• Corregir en origen: si el error viene de un sistema fuente (ERP, CRM), se corrige allí — no en el data warehouse.
• Documentar la causa: qué generó el error y qué cambio se hizo para evitar que se repita.
• Validar la corrección: volver a ejecutar el test para confirmar que el dato cumple la regla.

Plantilla mínima de política de calidad de datos

Una política de calidad escrita en una página suele tener más recorrido que un documento de treinta. La siguiente plantilla es el esqueleto que usamos como punto de partida en empresas medianas. Se rellena con el Data Owner del dominio en una sesión de 90 minutos.

• Dominio cubierto: clientes B2B (CRM + ERP).
• Data Owner: Dirección Comercial. Data Steward: responsable de operaciones comerciales.
• Dimensiones priorizadas: unicidad, completitud y validez del NIF/CIF, exactitud del segmento.
• Reglas: NIF único y formato válido; email obligatorio y con sintaxis correcta; segmento dentro del catálogo aprobado; fecha de alta no futura.
• Umbrales: máximo 0,5 % de registros con NIF inválido; máximo 2 % de registros sin email; tolerancia cero a duplicados por NIF.
• Remediación: incidencias se asignan al Data Steward en 24 h y se resuelven en 5 días laborables.
• Revisión: trimestral con Data Owner; rotura material del SLA escala al comité de gobierno.

Ejemplos de reglas concretas con dbt tests y SQL

Las reglas redactadas en lenguaje de negocio deben traducirse a controles ejecutables. En un stack moderno con dbt, la mayor parte de validaciones quedan declarativas en YAML. Para reglas más específicas, un test SQL singular cubre el caso. Estos son tres ejemplos típicos del dominio de clientes.

Unicidad y no nulos en YAML

• Sobre la columna nif del modelo dim_cliente: aplicar tests not_null y unique.
• Sobre la columna email: aplicar not_null y dbt_expectations.expect_column_values_to_match_regex con la expresión de validación de email.
• Sobre la columna segmento: accepted_values con la lista cerrada aprobada por la Dirección Comercial.

Regla de exactitud como test singular

Para validar que la fecha de alta nunca sea futura, un test singular en SQL devuelve las filas inválidas: SELECT cliente_id FROM {{ ref('dim_cliente') }} WHERE fecha_alta > current_date. Si la consulta devuelve filas, el test falla. Mismo patrón sirve para importes negativos donde no deben existir o porcentajes fuera del rango 0-100.

Gobierno de la política: revisión, ownership y mejora continua

Una política sin proceso de revisión envejece en semanas. Las reglas que aplicaban hace seis meses pueden bloquear pipelines que ahora ingestan datos legítimamente distintos. El gobierno de la política se sostiene con un calendario sencillo y un foro estable.

1. 1Revisión trimestral por dominio: Data Owner y Data Steward revisan métricas de calidad, falsos positivos y reglas obsoletas.
2. 2Revisión anual del marco: el comité de gobierno del dato actualiza umbrales globales y prioriza nuevos dominios.
3. 3Cambio controlado: toda nueva regla se prueba en modo warning durante al menos dos semanas antes de pasar a error.
4. 4Trazabilidad: cada regla tiene autor, fecha de aprobación y vínculo al objetivo de negocio que justifica su existencia.
5. 5Indicadores del propio gobierno: porcentaje de dominios con política activa, tiempo medio de remediación, ratio de reglas sin revisar en los últimos 12 meses.

Esta cadencia conviene encajarla con el resto del modelo de gobierno del dato y, si existe, con el catálogo de datos: las reglas vivas, sus métricas y sus responsables deben estar visibles desde el mismo lugar donde se documentan los datos.