Las 6 dimensiones de la calidad del dato explicadas con casos reales

Por qué importa distinguir las dimensiones

Una tasa de calidad global del 94% puede esconder realidades muy distintas. Un dominio con 94% de completitud y 100% de exactitud tiene un problema manejable: hay campos vacíos que se pueden recuperar. Un dominio con 100% de completitud y 94% de exactitud tiene un problema más grave: todos los campos tienen valor, pero uno de cada dieciséis valores es incorrecto, y eso es mucho más difícil de detectar y corregir.

Las seis dimensiones de calidad del dato son el estándar de la industria según DAMA-DMBOK y la referencia implícita del artículo 10 del AI Act cuando exige que los datos de entrenamiento sean "pertinentes, representativos, libres de errores y completos en la medida de lo posible". Cada una de esas palabras apunta a una dimensión concreta.

1. Completitud: el problema más visible y el más ignorado

La completitud mide si todos los valores requeridos están presentes. Es la dimensión más fácil de detectar automáticamente —un campo nulo es un campo nulo— y paradójicamente una de las más ignoradas en los programas de calidad porque se percibe como un problema menor.

Qué mide exactamente

Hay tres niveles de completitud que conviene distinguir. La completitud de campo mide qué porcentaje de registros tiene valor en un campo específico. La completitud de registro mide qué porcentaje de campos obligatorios tiene valor en un registro concreto. La completitud de entidad mide si existen todos los registros esperados para una entidad (por ejemplo, si todos los productos del catálogo tienen al menos un precio asociado).

Casos reales de impacto

En un sistema de e-commerce, el 8% de los registros de pedido tienen el campo de dirección de envío vacío. El dato es operativamente correcto durante el proceso de compra porque la dirección se extrae en tiempo real del perfil del cliente. Pero cuando ese pedido se exporta al sistema de logística, que espera la dirección embebida en el registro, el 8% de los pedidos falla silenciosamente. El problema no era de calidad del dato en origen: era de incompletitud en el formato de integración.

En un dataset de entrenamiento para un modelo de scoring de crédito, el 12% de los registros tiene el campo de historial de pagos vacío. El modelo aprende a tomar decisiones sin ese campo, pero en producción ese campo suele estar presente. El modelo no generaliza bien porque aprendió con un subconjunto sesgado de la realidad.

Cómo medirla y qué umbral fijar

En dbt: not_null test por campo. En Soda: missing_count y missing_percent. El umbral depende del campo: 100% para claves primarias y claves foráneas, ≥ 99% para campos de negocio críticos, ≥ 95% para campos opcionales relevantes.

2. Exactitud: el fallo más costoso y el más difícil de detectar

La exactitud mide si el valor de un dato refleja correctamente la realidad que pretende representar. Es la dimensión más crítica para la calidad de las decisiones y la más difícil de medir automáticamente, porque requiere conocer la realidad contra la que contrastar el dato.

Qué mide exactamente

Un dato puede estar presente, tener el formato correcto y ser técnicamente válido y aun así ser inexacto. El peso registrado de 75 kg cuando el peso real es 82 kg es un dato completo, válido y exactamente incorrecto. El nombre "Juan García" asignado a la persona que se llama "Juan Martínez" cumple todos los criterios de validez y es completamente inexacto.

Casos reales de impacto

En un sistema de gestión de activos, el valor contable de un inmovilizado es incorrecto en un 3% de los casos debido a errores en las imputaciones manuales de depreciación. Los balances cuadran —porque los errores se compensan entre sí en muchos casos— pero los análisis de rentabilidad por activo son sistemáticamente incorrectos. El problema lleva años en el sistema porque ningún control automático lo detecta: los valores están dentro del rango esperado y tienen el formato correcto.

En un modelo de recomendación de productos, las puntuaciones de los usuarios tienen un sesgo de exactitud: un bug en el formulario de valoración invirtió la escala durante tres semanas (5 estrellas se registraba como 1 y viceversa). El modelo entrenado con esos datos recomienda sistemáticamente los productos peor valorados como si fueran los mejores.

Cómo medirla y qué umbral fijar

La aproximación más efectiva es la validación contra fuentes autorizadas: tablas de referencia maestras, registros oficiales (NIF, IBAN, códigos postales) o sistemas de record designados. Para campos sin fuente de verdad externa, las reglas de negocio (rangos esperados, distribuciones históricas) son la mejor aproximación. Umbral de referencia: ≥ 98%.

3. Consistencia: cuando el dato dice cosas distintas según dónde lo mires

La consistencia mide si un dato no contradice otros datos del mismo sistema o de sistemas relacionados. Es la dimensión que más frecuentemente genera pérdidas de confianza en los datos, porque sus fallos son visibles en las reuniones: el mismo KPI da resultados distintos según de qué sistema se extraiga.

Qué mide exactamente

Hay dos tipos de inconsistencias. Las inconsistencias internas ocurren dentro del mismo registro: el país es "ES" pero el prefijo telefónico es "+1", o la fecha de baja es anterior a la fecha de alta. Las inconsistencias externas ocurren entre sistemas: el CRM registra 45.000 clientes activos, el sistema de facturación registra 43.200 y el data warehouse muestra 46.800. Todas son "la verdad" según el sistema que las genera, pero son incompatibles entre sí.

Casos reales de impacto

Una aerolínea tiene el número de pasajeros transportados el mes anterior calculado de tres formas distintas según el sistema: el sistema operativo de vuelos cuenta los pasajeros embarcados, el sistema de revenue management cuenta los billetes vendidos y el data warehouse agrega los datos de ambos con una lógica de deduplicación que nadie documentó correctamente. El comité de dirección no puede comparar el rendimiento operativo con el rendimiento comercial porque los números de partida son incompatibles.

La causa raíz no es técnica: es la ausencia de una definición canónica de "pasajero transportado" acordada entre los propietarios de cada sistema. Eso es exactamente el trabajo del Data Steward y del Data Governance Committee.

Cómo medirla y qué umbral fijar

En dbt: tests de relación (relationships) y tests personalizados en SQL que validan condiciones entre campos. En Great Expectations: expect_column_pair_values_to_be_equal para consistencias entre campos. Las inconsistencias entre sistemas requieren comparaciones cruzadas en el pipeline de integración. Umbral: ≥ 99%.

4. Oportunidad: un dato correcto que llega tarde es un dato inútil

La oportunidad mide si el dato está disponible cuando se necesita. Es la dimensión más frecuentemente ignorada en los programas de calidad porque se percibe como un problema de infraestructura, no de calidad. Error: la oportunidad es una dimensión de calidad tan relevante como la exactitud en contextos donde las decisiones dependen de datos en tiempo real o con ventanas temporales muy cortas.

Qué mide exactamente

Hay dos aspectos de la oportunidad. La latencia mide el tiempo entre que el dato cambia en el sistema origen y está disponible en el sistema de consumo. La frescura mide si el dato en el sistema de consumo corresponde al estado actual de la realidad, no a un estado pasado que ya no es relevante.

Casos reales de impacto

En un sistema de gestión de inventario de una cadena de distribución, el stock disponible en tienda se actualiza en el data warehouse cada 4 horas. El sistema de e-commerce consulta el data warehouse para mostrar disponibilidad en tiempo real. Durante las 4 horas entre actualizaciones, el sistema puede confirmar pedidos de productos que ya no están disponibles en tienda. El resultado es un 2,3% de pedidos con incidencia de disponibilidad, que se gestionan manualmente a un coste de 12 euros por incidencia. Multiplicado por el volumen de pedidos, el coste anual de esa latencia supera el coste de implementar sincronización en tiempo real.

Cómo medirla y qué umbral fijar

Monitorizando el timestamp de la última actualización de cada tabla crítica y comparándolo con el SLA acordado. En dbt, un test personalizado que alerta si max(updated_at) < current_timestamp - interval 'X hours' es suficiente para detectar retrasos en la actualización. El umbral depende del dominio: minutos para datos operacionales, horas para datos analíticos, días para datos maestros.

5. Validez: las reglas que el dato debe cumplir antes de ser útil

La validez mide si el valor de un dato cumple las reglas de formato, rango y dominio definidas para ese campo. Es la dimensión más fácil de implementar automáticamente y la que más rápido muestra resultados en un programa de calidad que empieza desde cero.

Qué mide exactamente

Hay tres tipos de reglas de validez. Las reglas de formato verifican que el valor tiene la estructura correcta (un email con @, un NIF con letra de control válida, una fecha que existe en el calendario). Las reglas de rango verifican que el valor está dentro de los límites aceptables (una edad entre 0 y 120, un porcentaje entre 0 y 100). Las reglas de dominio verifican que el valor pertenece a un conjunto permitido de valores (el estado de un pedido es uno de los definidos en el catálogo).

Casos reales de impacto

En un sistema de gestión de pacientes, el campo de fecha de nacimiento permite la entrada de fechas futuras sin validación en el formulario. El 0,7% de los registros tiene fechas de nacimiento posteriores a la fecha actual, lo que hace que los cálculos de edad sean negativos y los filtros de grupos de edad los excluyan de todos los análisis. En un contexto sanitario, excluir sistemáticamente a esos pacientes de los análisis puede distorsionar los resultados de estudios clínicos.

En un dataset de entrenamiento para un modelo de clasificación, el campo de categoría de producto tiene 47 valores distintos pero el catálogo oficial solo define 12. Los 35 valores adicionales son variantes tipográficas, errores de codificación y categorías obsoletas que el modelo aprende como si fueran categorías distintas, reduciendo su capacidad de generalización.

Cómo medirla y qué umbral fijar

En dbt: accepted_values, expression_is_true para rangos, tests de regex con macros personalizadas. En Great Expectations: expect_column_values_to_match_regex, expect_column_values_to_be_between. Umbral de referencia: ≥ 99,5% para campos de negocio críticos, 100% para claves y campos identificadores.

6. Unicidad: los duplicados que cuestan más de lo que parecen

La unicidad mide si existen registros duplicados donde no debería haberlos. Es el problema de calidad con mayor impacto económico directo y el que más frecuentemente se descubre tarde: cuando los duplicados llevan meses o años en el sistema y han contaminado análisis, modelos y decisiones.

Qué mide exactamente

Hay dos tipos de duplicados. Los duplicados exactos son registros idénticos o con el mismo identificador único que aparecen más de una vez. Son fáciles de detectar con una consulta SQL. Los duplicados fuzzy son registros que representan la misma entidad real pero con variaciones: "Juan García López" y "J. García López" y "JUAN GARCIA LOPEZ" son tres registros distintos en el sistema que representan a la misma persona. Detectarlos requiere algoritmos de similitud de texto.

Casos reales de impacto

En una empresa de telecomunicaciones, el proceso de migración de dos CRMs distintos tras una fusión genera un 4,2% de clientes duplicados en la base consolidada. El equipo de ventas no lo sabe y asigna a dos comerciales distintos al mismo cliente. El cliente recibe dos llamadas de renovación en el mismo día, con ofertas distintas y precios distintos. El impacto no es solo operativo: genera una experiencia de cliente que destruye confianza y, en algunos casos, activa el derecho de portabilidad.

En un modelo de recomendación entrenado con historial de compras, los clientes duplicados hacen que el modelo sobrepondera sus patrones de compra: un cliente con tres registros tiene tres veces más peso en el entrenamiento que un cliente con un único registro. El modelo aprende a recomendar productos que gustan a los clientes duplicados, no a la base de clientes real.

Cómo medirla y qué umbral fijar

Para duplicados exactos: unique test en dbt sobre la clave natural. Para duplicados fuzzy: herramientas como Splink (open source) o IBM MDM (enterprise) con algoritmos de Levenshtein o Jaro-Winkler. El umbral de duplicados exactos debe ser 0% para claves primarias y < 0,5% para combinaciones de atributos de negocio.

Resumen: las 6 dimensiones de un vistazo

La dimensión que el AI Act añade: representatividad

Las seis dimensiones del estándar DAMA cubren la calidad del dato en entornos operacionales y analíticos. El AI Act añade implícitamente una séptima dimensión para los datasets de entrenamiento: la representatividad.

Un dataset puede ser completo, exacto, consistente, oportuno, válido y sin duplicados y aun así entrenar un modelo sesgado si no representa adecuadamente la distribución de la población sobre la que el sistema operará en producción. Un modelo de scoring de crédito entrenado principalmente con datos de clientes urbanos de renta media-alta puede ser técnicamente correcto en todas las seis dimensiones y sistemáticamente injusto con clientes rurales o de renta baja.

El artículo 10.4 del AI Act exige tener en cuenta "las características estadísticas necesarias, incluida la representación de las personas o grupos sobre los que el sistema operará". Medir y documentar esa representatividad es una obligación regulatoria que ninguna herramienta de data quality estándar cubre de forma nativa — requiere análisis específico del dominio y del caso de uso de cada sistema de IA.

Para ver cómo esto encaja en el framework completo de gobernanza de datos para el AI Act, consulta el artículo Cómo implementar un Data Governance Framework efectivo en la era del AI Act.

Por qué las dimensiones no son independientes

El error más frecuente al implementar un programa de data quality es tratar cada dimensión de forma independiente. En la práctica, los fallos en una dimensión pueden causar fallos en otras. Un problema de completitud — registros incompletos — puede causar problemas de consistencia si el campo vacío se rellena con un valor por defecto incorrecto aguas abajo. Un problema de unicidad — duplicados — puede causar problemas de exactitud si el proceso de deduplicación elige el registro incorrecto como maestro.

El análisis de causa raíz de cualquier problema de calidad debe explorar las seis dimensiones, no solo la dimensión donde el fallo se hizo visible. El síntoma y la causa pueden estar en dimensiones distintas.

Conclusión: las dimensiones son el vocabulario, no la solución

Conocer las seis dimensiones de la calidad del dato permite diagnosticar los problemas con precisión, comunicarlos con claridad y medir su evolución de forma objetiva. Pero el diagnóstico no es la solución.

Saber que la tasa de duplicados del dominio de Clientes es del 3,2% no resuelve el problema. Lo que lo resuelve es entender de dónde vienen esos duplicados, qué proceso los genera, qué regla de negocio debe aplicarse para identificar el registro maestro y quién tiene la autoridad para decidir esa regla. Esa es exactamente la conversación de Data Governance que el equipo técnico no puede tener solo.

Para entender cómo medir estas dimensiones con KPIs concretos y dashboards accionables, consulta el artículo Cómo medir la calidad del dato: KPIs, umbrales y dashboards.

Checklist: evaluación de las 6 dimensiones

• Completitud evaluada en campos obligatorios, relevantes y relaciones entre entidades.
• Exactitud validada contra fuentes autorizadas o tablas de referencia maestras.
• Consistencia comprobada tanto en reglas internas de registro como entre sistemas relacionados.
• Oportunidad monitorizada con SLA por dominio y alertas de retraso activas.
• Validez implementada como código en el pipeline (formato, rango, dominio permitido).
• Unicidad verificada en claves primarias (0%) y en claves naturales de negocio.
• Representatividad analizada para datasets de entrenamiento de sistemas de IA (AI Act art. 10.4).
• Análisis de causa raíz documentado cuando un fallo en una dimensión genera efectos en otras.

Preguntas frecuentes

¿Cuáles son las 6 dimensiones de la calidad del dato?

Las seis dimensiones estándar según DAMA-DMBOK son: completitud (ausencia de nulos en campos obligatorios), exactitud (el dato refleja la realidad), consistencia (sin contradicciones entre campos o sistemas), oportunidad (disponible cuando se necesita), validez (cumple reglas de formato y dominio) y unicidad (sin duplicados).

¿Qué dimensión de calidad del dato es la más importante?

Depende del caso de uso. Para sistemas de IA de alto riesgo, la exactitud y la representatividad son las más críticas. Para operaciones en tiempo real, la oportunidad. Para análisis financiero, la consistencia y la unicidad. No hay una dimensión universalmente más importante: el peso de cada una debe definirse según el impacto en el caso de uso concreto.

¿Cómo se detectan los problemas de consistencia en los datos?

Mediante reglas cruzadas entre campos del mismo registro o entre tablas relacionadas. En dbt, con tests de relación y tests personalizados en SQL. En Great Expectations, con expect_column_pair_values_to_be_equal. Las inconsistencias entre sistemas requieren comparaciones cruzadas en el pipeline de integración.

¿Qué diferencia hay entre validez y exactitud?

La validez mide si el valor cumple las reglas de formato y dominio (un NIF con formato correcto). La exactitud mide si el valor refleja la realidad (ese NIF es el correcto para esa persona). Un dato puede ser válido pero inexacto, y eso es imposible de detectar solo con reglas de formato.

¿Cómo afecta la calidad del dato a los modelos de IA?

Un modelo aprende de los patrones en sus datos de entrenamiento. Datos inexactos generan modelos que aprenden patrones incorrectos. Datos con problemas de representatividad generan modelos que no generalizan bien. Datos duplicados sobrepondera ciertos ejemplos en el entrenamiento. El AI Act exige documentar el análisis de calidad de los datasets de entrenamiento precisamente por estas razones.