Cómo medir la calidad del dato: KPIs, umbrales y dashboards

Por qué medir la calidad del dato no es opcional

Sin métricas, la calidad del dato es una conversación de opiniones. El equipo de ingeniería cree que los datos están bien. El equipo de negocio cree que están mal. La dirección no sabe a quién creer. Nadie tiene razón ni está equivocado porque nadie ha medido nada.

Con métricas, la conversación cambia: la tasa de completitud del dominio de Clientes es del 91% esta semana, por debajo del umbral del 99% acordado con el equipo comercial, y hay 847 registros con el campo EMAIL vacío que bloquean la campaña de renovación del próximo lunes. Eso es una conversación accionable.

Además, en el contexto del AI Act, la medición de calidad deja de ser una buena práctica y se convierte en una obligación documentable. El artículo 10 del Reglamento exige que los datos de entrenamiento de sistemas de IA de alto riesgo sean pertinentes, representativos y libres de errores en la medida de lo posible, con evidencia de los análisis realizados. Sin métricas registradas, esa evidencia no existe.

Los 7 KPIs fundamentales de calidad del dato

Hay docenas de métricas posibles, pero siete cubren el 90% de los casos de uso reales. Estas son las que deben estar en cualquier dashboard de calidad que pretenda ser útil para el negocio y auditable para el regulador:

1. Tasa de completitud

Mide qué porcentaje de registros tiene valor en los campos obligatorios. Es la métrica más básica y la más frecuentemente ignorada. Un campo obligatorio con un 15% de nulos no es un problema técnico menor: es una fuente de datos infiable para cualquier análisis que dependa de ese campo.

Fórmula: (Registros sin nulos en campos obligatorios / Total de registros) × 100

Umbral de referencia: ≥ 99% para campos clave. ≥ 95% para campos de negocio relevantes.

2. Tasa de exactitud

Mide qué porcentaje de valores refleja correctamente la realidad. Es la dimensión más difícil de medir automáticamente porque requiere una fuente de verdad contra la que contrastar. En la práctica se aproxima validando contra tablas de referencia maestras o mediante reglas de negocio definidas.

Fórmula: (Registros válidos contra fuente / Total de registros) × 100

Umbral de referencia: ≥ 98%.

3. Tasa de duplicados

Mide qué porcentaje de registros están duplicados. Un 2% de duplicados en una tabla de clientes con un millón de registros son 20.000 clientes que reciben doble comunicación, generan doble coste y contaminan cualquier análisis de comportamiento o segmentación.

Fórmula: (Registros duplicados / Total de registros) × 100

Umbral de referencia: < 0,5%.

4. Tasa de consistencia

Mide qué porcentaje de registros no contiene contradicciones entre campos del mismo registro o entre tablas relacionadas. Un cliente con país "ES" y prefijo telefónico "+1" es un registro inconsistente. Una fecha de cancelación anterior a la fecha de alta también.

Fórmula: (Registros sin contradicciones / Total de registros) × 100

Umbral de referencia: ≥ 99%.

5. Tasa de validez de formato

Mide qué porcentaje de valores cumple las reglas de formato, rango y dominio definidas. Un NIF con formato incorrecto, un código postal de seis dígitos o una fecha 30/02 son problemas de validez que un test automatizado puede detectar en milisegundos.

Fórmula: (Registros con formato correcto / Total de registros) × 100

Umbral de referencia: ≥ 99,5%.

6. Latencia de actualización

Mide el tiempo desde que un dato cambia en el sistema origen hasta que está disponible en el sistema de consumo. Un dato correcto que llega con 48 horas de retraso es un dato inútil para las decisiones que dependían de él. Esta métrica es especialmente crítica en dominios operacionales como inventario, precios o disponibilidad.

Métrica: Tiempo medio de retraso respecto al SLA acordado por dominio.

7. Índice Global de Calidad (DQI)

La media ponderada de todas las dimensiones anteriores, adaptando el peso de cada una según la importancia para el dominio concreto. Es el KPI que se comunica a dirección y el que permite comparar dominios entre sí y hacer seguimiento de la evolución temporal.

Umbral de referencia: ≥ 95% como objetivo general. Dominios con datos de entrenamiento de IA deben aspirar a ≥ 98%.

Cómo definir umbrales: el error más frecuente

El error más frecuente en los programas de data quality es definir umbrales sin input del negocio. El equipo técnico decide que el 95% de completitud es aceptable, lo implementa como alerta y seis meses después el equipo comercial descubre que ese 5% de registros incompletos son exactamente los clientes de mayor valor, que llevan sin recibir comunicaciones desde que se implementó el sistema.

El proceso correcto es el inverso: el negocio define qué impacto tiene cada punto de porcentaje de incumplimiento, y a partir de eso se establece el umbral. Si un campo de email incompleto bloquea una campaña con ROI estimado de 50.000 euros, el umbral de completitud de ese campo debería ser del 99,9%, no del 95%.

La conversación con el negocio para definir umbrales sigue esta estructura:

• ¿Qué decisiones dependen de este dato? — identifica el caso de uso real.
• ¿Qué ocurre si el dato falla? — cuantifica el impacto en términos de negocio.
• ¿Con qué nivel de confianza necesitas operar? — define el umbral mínimo aceptable.
• ¿En cuánto tiempo necesitas saberlo? — define la frecuencia de medición y el SLA de alerta.

SLA de datos: la diferencia entre un umbral y un compromiso

Un umbral de calidad sin SLA formal es un número que nadie defiende cuando hay presión de tiempo. Un SLA de datos es un acuerdo documentado entre el equipo de datos y el área de negocio que establece cuatro elementos:

• El umbral de calidad por dimensión y campo.
• La frecuencia de medición y el sistema de alertas.
• El responsable de recibir la alerta y el tiempo máximo de respuesta.
• El proceso de remediación y el criterio de cierre de incidencia.

Sin los cuatro elementos, el SLA no funciona. El caso más frecuente de fallo es tener umbral y alerta pero sin responsable claro: la alerta llega, nadie sabe quién debe actuar, y el problema persiste hasta que alguien lo detecta en producción.

Implementación técnica: dónde medir en el pipeline

La calidad debe medirse en tres puntos del pipeline, no solo en uno:

En la ingesta (fuente)

Validaciones en el punto de entrada del dato: formularios, APIs, archivos de carga. El objetivo es rechazar o marcar datos incorrectos antes de que contaminen el sistema. En entornos con Airbyte o Fivetran como herramienta de ingesta, estas validaciones se configuran como reglas de transformación en el proceso de carga.

En la transformación (pipeline)

Tests integrados en los modelos de dbt, reglas de Great Expectations o checks de Soda que se ejecutan automáticamente en cada run del pipeline. Si un test falla, el pipeline se detiene o emite una alerta según el nivel de criticidad configurado. Los resultados de cada ejecución se almacenan y alimentan el dashboard de calidad.

En el consumo (Data Warehouse / capa semántica)

Vistas validadas en Snowflake o BigQuery que solo exponen registros que superan los umbrales de calidad definidos. En Power BI, métricas calculadas que muestran el porcentaje de datos válidos en tiempo real junto al dato de negocio. El analista ve el número y también ve el nivel de confianza del dato que sustenta ese número.

El dashboard de calidad: qué debe mostrar y a quién

Un dashboard de calidad del dato no es un dashboard técnico de monitorización de pipelines. Es una herramienta de gestión que diferentes perfiles usan con objetivos distintos. El diseño debe reflejar esa diferencia:

El error de diseño más frecuente es construir un único dashboard con todas las métricas para todos los perfiles. El resultado es un panel que nadie usa porque es demasiado técnico para el negocio y demasiado incompleto para el equipo técnico. Tres vistas distintas del mismo modelo de datos, adaptadas a cada perfil, son infinitamente más efectivas.

Qué herramientas usar para medir y visualizar

La elección de herramienta depende del stack. Estas son las combinaciones más efectivas según el entorno:

Para profundizar en las herramientas de data quality management y cómo encajan en el framework de gobernanza, consulta el artículo Data quality management: qué es, cómo medirlo y por qué importa al AI Act.

Métricas de adopción del propio sistema de calidad

Hay un conjunto de métricas que muchos programas de data quality olvidan: las métricas sobre el propio sistema de calidad. Sin ellas, no sabes si el programa funciona o si simplemente existe en el papel.

• Cobertura de reglas: qué porcentaje de activos de datos tiene al menos una regla de calidad definida.
• Tiempo medio de resolución de incidencias: desde la detección hasta el cierre. Si supera el SLA acordado sistemáticamente, el proceso de remediación no funciona.
• Tasa de recurrencia: qué porcentaje de incidencias cerradas vuelve a abrirse en los 30 días siguientes. Una tasa alta indica que se está remediando el síntoma, no la causa raíz.
• Evolución del DQI a 90 días: la tendencia importa más que el valor puntual. Un DQI del 94% que lleva tres meses subiendo es mejor que uno del 97% que lleva dos meses bajando.

La pregunta que el dashboard no responde

Un dashboard de calidad del dato bien construido responde cuánto, dónde y con qué tendencia. Lo que no responde es por qué el problema ocurre ni cómo exactamente remediarlo en el contexto específico de cada organización.

La tasa de duplicados del dominio de Clientes es del 3,2%. Eso lo muestra el dashboard. Pero si ese 3,2% proviene de una integración con un CRM heredado que genera IDs distintos para el mismo cliente en función del canal de entrada, la solución no es técnica en primera instancia: es definir la regla de negocio de qué hace a dos registros ser el mismo cliente, acordarla entre los equipos que alimentan el CRM y entonces implementar la deduplicación. Ese proceso de definición y acuerdo es el trabajo de gobernanza que ninguna herramienta automatiza.

Conclusión: medir es el primer paso, no el último

Implementar KPIs de calidad del dato no soluciona los problemas de calidad: los hace visibles. La visibilidad es la condición necesaria para la mejora, pero no es suficiente. Lo que convierte la medición en mejora real es tener responsables con mandato para actuar sobre lo que el dashboard muestra, procesos de remediación definidos y la paciencia para trabajar en ciclos de mejora que no se cierran en semanas.

Para entender cómo estructurar los roles que gestionan la calidad del dato, consulta el artículo Roles y responsabilidades de un equipo de Data Governance.

Checklist: sistema de medición de calidad del dato

• Los 7 KPIs fundamentales definidos por dominio crítico.
• Umbrales acordados formalmente con los Data Owners, no decididos unilateralmente por el equipo técnico.
• SLAs de datos documentados con umbral, frecuencia, responsable y proceso de remediación.
• Medición en los tres puntos del pipeline: ingesta, transformación y consumo.
• Tests de calidad como código integrados en el proceso de CI/CD (dbt, Soda, Great Expectations).
• Resultados de cada ejecución almacenados y accesibles para histórico.
• Dashboard con tres vistas diferenciadas: Data Steward, Data Owner y dirección.
• Alertas automáticas configuradas con receptor claro y SLA de respuesta.
• Métricas de adopción del propio sistema: cobertura, tiempo de resolución y recurrencia.
• Revisión trimestral de umbrales con las áreas de negocio.

Preguntas frecuentes

¿Cuáles son los KPIs más importantes para medir la calidad del dato?

Los siete KPIs fundamentales son: tasa de completitud, tasa de exactitud, tasa de duplicados, tasa de consistencia, tasa de validez de formato, latencia de actualización e índice global de calidad (DQI). El DQI es la media ponderada de todos ellos y el indicador que se comunica a dirección.

¿Qué umbral de calidad del dato es aceptable?

Los umbrales dependen del dominio y el caso de uso. Como referencia general: completitud ≥ 99%, exactitud ≥ 98%, duplicados < 0,5%, consistencia ≥ 99%, validez ≥ 99,5% y DQI global ≥ 95%. Para datos de entrenamiento de IA de alto riesgo, el AI Act exige umbrales más exigentes documentados explícitamente.

¿Con qué herramienta construyo un dashboard de calidad del dato?

Power BI o Tableau conectados a los resultados de dbt tests, Soda o Great Expectations son las combinaciones más habituales. Con Snowflake y dbt, los resultados de los tests se envían a una tabla en Snowflake y se visualizan en Power BI sin infraestructura adicional.

¿Con qué frecuencia debo medir la calidad del dato?

La monitorización debe ser continua y automática en cada ejecución del pipeline. El reporting puede ser diario para Data Stewards, semanal para Data Owners y mensual para dirección. Las alertas deben activarse en tiempo real cuando se supera el threshold, no en el siguiente ciclo de reporting.

¿Qué diferencia hay entre un SLA de datos y un umbral de calidad?

El umbral es el valor mínimo aceptable de una métrica. El SLA es el acuerdo formal que establece ese umbral, la frecuencia de medición, el proceso de alerta y el tiempo máximo de remediación. Un umbral sin SLA es un número que nadie defiende cuando hay presión de tiempo.