Data quality management: qué es, cómo medirlo y por qué importa al AI Act

Qué es el data quality management

El data quality management es el conjunto de procesos, políticas, roles y herramientas que garantizan que los datos de una organización son precisos, completos, consistentes, oportunos y aptos para el uso previsto. No es una validación puntual en el momento de la ingesta. No es un informe de calidad que alguien genera una vez al trimestre. Es un proceso continuo con métricas definidas, umbrales acordados con el negocio, alertas automáticas cuando se incumplen y responsables de remediación con mandato real para actuar.

La distinción entre validación de datos y data quality management es importante: la validación es una verificación puntual en un momento del pipeline. El data quality management es el sistema que rodea esa validación: quién definió las reglas, por qué, con qué umbral de aceptación, quién recibe la alerta cuando falla y qué proceso de remediación se activa. Sin ese sistema, la validación es ruido sin contexto.

Las seis dimensiones de la calidad del dato

El estándar de referencia en la industria, DAMA-DMBOK, define seis dimensiones principales para medir la calidad del dato. Cada dimensión requiere métricas y reglas específicas, y su importancia relativa varía según el dominio y el caso de uso.

1. Completitud

Mide si todos los valores requeridos están presentes. Un campo obligatorio nulo es un problema de completitud. Se expresa como porcentaje: qué proporción de registros tiene el campo relleno. El umbral de aceptación lo define el negocio: en algunos campos un 95% es aceptable; en datos de entrenamiento para IA de alto riesgo puede exigirse el 100%.

2. Unicidad

Mide si hay duplicados donde no debería haberlos. Un cliente registrado dos veces con el mismo identificador, una transacción procesada dos veces, un producto con dos registros activos. Los duplicados no detectados generan sesgos en modelos de IA y errores en reportes financieros. Se mide como porcentaje de registros únicos sobre el total de registros esperados.

3. Validez

Mide si los valores cumplen las reglas de formato, rango y dominio definidas. Un código postal con seis dígitos donde solo hay cinco, una fecha de nacimiento en el futuro, un importe negativo donde solo se admiten positivos. Las reglas de validez son las más fáciles de automatizar y las primeras que deben implementarse en cualquier pipeline de datos.

4. Consistencia

Mide si el mismo dato tiene el mismo valor en distintos sistemas o en distintos puntos del pipeline. El cliente que en el CRM tiene un nombre y en el sistema de facturación tiene otro. La métrica que en el informe de ventas vale X y en el informe financiero vale Y con la misma definición. La consistencia es la dimensión más difícil de medir porque requiere cruzar fuentes, y la más costosa cuando falla porque destruye la confianza en los datos de toda la organización.

5. Puntualidad

Mide si el dato está disponible cuando se necesita. Un dato correcto que llega tarde es un dato inútil para la decisión que dependía de él. Se mide como retraso respecto al SLA acordado: si el pipeline debe completarse a las 8:00 y se completa a las 10:00, hay un problema de puntualidad independientemente de si los datos son correctos.

6. Precisión

Mide si el valor refleja la realidad que pretende representar. Es la dimensión más difícil de medir automáticamente porque requiere contrastar el dato con una fuente de verdad externa. Un peso registrado como 75 kg cuando el peso real es 82 kg es un problema de precisión que ninguna regla de validación detectará si 75 está dentro del rango aceptable. En datos de entrenamiento para IA, la precisión deficiente es el origen más frecuente de sesgos no detectados.

Por qué el AI Act exige data quality management

El artículo 10 del AI Act es explícito: los datos de entrenamiento, validación y prueba de sistemas de IA de alto riesgo deben cumplir criterios de calidad adecuados al propósito del sistema. Específicamente, el Reglamento exige que los datos sean:

• Pertinentes, representativos, libres de errores y completos en la medida en que sea posible.
• Con las características estadísticas adecuadas, incluyendo la representación de las personas o grupos sobre los que el sistema operará.
• Sometidos a prácticas de gestión de datos apropiadas, incluyendo el análisis de posibles sesgos.

Esto no es una declaración de principios: es una obligación auditable. AESIA y la AEPD pueden solicitar evidencia de que los datos de entrenamiento cumplen estos criterios. Sin un proceso de data quality management documentado y continuo —con métricas, umbrales, alertas y registros de remediación— esa evidencia no existe.

Para ver cómo encaja el data quality management en el framework completo de gobernanza y las fechas clave de cumplimiento, consulta los artículos Cómo implementar un Data Governance Framework efectivo en la era del AI Act y AI Act key dates: qué debe hacer tu empresa en cada hito regulatorio.

Cómo implementar data quality management paso a paso

Paso 1: define las reglas de calidad con el negocio, no solo con el equipo técnico

Las reglas de calidad del dato no las puede definir el equipo de ingeniería en solitario. Necesitan input del negocio: qué valores son aceptables para este campo, qué porcentaje de nulos tolera este proceso, qué rango de valores tiene sentido para esta métrica. El equipo técnico traduce esas reglas a código; el Data Owner valida que las reglas reflejan la realidad del negocio; el Data Steward las mantiene actualizadas cuando el negocio cambia.

Paso 2: implementa las reglas como código en el pipeline

Las reglas de calidad deben vivir en el código del pipeline, no en un documento externo. Herramientas como dbt tests, Great Expectations o Soda permiten definir estas reglas como código versionado, integrarlas en el proceso de CI/CD y ejecutarlas automáticamente en cada run del pipeline. Si una regla falla, el pipeline puede detenerse, emitir una alerta o registrar la anomalía según la criticidad definida.

Paso 3: define umbrales de aceptación y niveles de criticidad

No todas las reglas de calidad tienen el mismo peso. Un campo de comentario libre con un 10% de nulos es tolerable; un identificador de cliente con un 1% de nulos es crítico. Define para cada regla: el umbral de aceptación (porcentaje de registros que deben cumplirla), el nivel de criticidad (bloquea el pipeline, genera alerta o solo registra) y el SLA de remediación (en cuánto tiempo debe resolverse si falla).

Paso 4: publica dashboards de calidad visibles para Data Owners

La calidad del dato no puede ser información que solo vea el equipo técnico. Los Data Owners necesitan visibilidad sobre el estado de la calidad de su dominio: qué reglas están fallando, con qué frecuencia, qué tendencia tienen y qué impacto tiene en los sistemas downstream. Un dashboard de calidad en Power BI o en la propia herramienta de data quality convierte esa información en algo accionable para quien tiene la responsabilidad y la autoridad de decidir sobre el dato.

Paso 5: establece procesos de remediación con responsables claros

Una alerta de calidad sin proceso de remediación es ruido. Define para cada tipo de incidencia: quién recibe la alerta, qué debe hacer, en qué plazo y cómo se documenta la resolución. La remediación puede ser automática —corrección en el pipeline— o manual —intervención del Data Steward o del sistema fuente— pero siempre debe tener un responsable y un registro. Ese registro es parte de la evidencia de data quality management que el AI Act puede requerir.

Herramientas de data quality management en 2026

Para equipos que empiezan, la combinación dbt tests + Soda cubre el 80% de los casos de uso con coste mínimo y curva de aprendizaje razonable. Monte Carlo o Bigeye añaden valor cuando el volumen de tablas hace inviable definir reglas manualmente para todo y se necesita detección automática de anomalías.

Data quality management en entornos complejos: lo que funciona

Reglas de calidad a dos niveles en entornos multi-entidad

En entornos con múltiples aerolíneas compartiendo plataforma de datos, las reglas de calidad deben operar en dos capas. Las reglas globales cubren los dominios maestros compartidos: identificadores de cliente, códigos de producto, fechas de operación. Estas reglas son iguales para todas las entidades y se aplican en la capa de integración. Las reglas locales cubren las particularidades de cada mercado: rangos de precios aceptables por ruta, formatos de documentación por país, umbrales de ocupación por tipo de aeronave. Sin esta distinción, las reglas globales generan falsos positivos en datos localmente correctos y las reglas locales no escalan al grupo.

Integración de dbt tests en el ciclo de despliegue

En proyectos de BI comercial, integrar los dbt tests en el proceso de CI/CD cambia radicalmente la forma en que el equipo trata la calidad del dato. Cuando un test de calidad que falla bloquea el despliegue de un modelo, la calidad deja de ser una tarea que se revisa a posteriori y se convierte en un requisito de la entrega. Los analistas aprenden a anticipar los problemas de calidad antes de que lleguen al dashboard, no después de que los Data Owners los reportan en una reunión.

Dashboard de calidad como herramienta de gestión para el Data Owner

En entornos con datos operacionales críticos, publicar el estado de la calidad del dato en un dashboard accesible para los Data Owners transforma la conversación sobre la calidad. El Data Owner deja de recibir informes de incidencias reactivos y pasa a tener visibilidad proactiva: qué campos tienen tendencia de degradación, qué reglas están cerca del umbral de fallo, qué dominio tiene la peor tasa de completitud esta semana. Esa visibilidad genera accountability real: el Data Owner que ve su dominio con un 88% de completitud en un campo crítico tiene incentivo para actuar antes de que se convierta en un problema de negocio.

Errores frecuentes en data quality management

• Tratar la calidad del dato como un proyecto con fecha de fin. La calidad del dato es perecedera: un pipeline que hoy produce datos correctos puede producir datos incorrectos mañana si cambia el sistema fuente, si cambia el esquema o si cambia el negocio. Sin monitorización continua, la calidad se degrada en silencio hasta que alguien detecta un error en producción.
• Definir reglas de calidad sin input del negocio. Las reglas que define solo el equipo técnico suelen ser incompletas o incorrectas para el caso de uso real. El equipo técnico sabe qué valores son posibles técnicamente; el negocio sabe cuáles son aceptables operativamente. Ambas perspectivas son necesarias.
• Medir calidad solo en la ingesta, no en toda la cadena. Un dato puede entrar correcto al data lake y salir incorrecto del modelo semántico si una transformación intermedia introduce errores. La calidad debe medirse en cada capa relevante del pipeline, no solo en el punto de entrada.
• Alertas sin proceso de remediación. Una alerta que no tiene receptor claro, proceso definido y SLA de resolución es una alerta que se ignora. El 80% del valor del data quality management está en la remediación, no en la detección.
• Ignorar la dimensión de representatividad para datos de IA. En datos de entrenamiento para sistemas de IA, la completitud y la validez son necesarias pero no suficientes. La representatividad —que el dataset refleje adecuadamente la distribución de la población sobre la que el modelo operará— es la dimensión más crítica para el AI Act y la que más frecuentemente se omite en los procesos de calidad.
• No documentar los resultados de calidad como evidencia. Para el AI Act, no basta con tener reglas de calidad: hay que poder demostrar que se ejecutan, que los resultados se monitorean y que las incidencias se remedian. Sin registros históricos de las ejecuciones de calidad, esa evidencia no existe.

Conclusión: la calidad del dato no es un KPI técnico, es un SLA de negocio

El data quality management efectivo no se mide por el número de reglas definidas ni por la herramienta elegida. Se mide por si los datos que llegan a las decisiones de negocio —y a los modelos de IA que apoyan esas decisiones— son suficientemente correctos, completos y representativos para el uso que se hace de ellos.

Con el AI Act en aplicación plena, esa pregunta tiene ahora una dimensión regulatoria directa. Las organizaciones que ya tienen un proceso de data quality management documentado y continuo —con métricas, alertas, remediación y registros— tienen una ventaja significativa: el cumplimiento del artículo 10 es una extensión natural de lo que ya hacen. Las que no lo tienen deben empezar por los dominios más críticos, con las reglas más importantes y con las herramientas más simples que funcionen en su stack actual.

Checklist: data quality management operativo

• Dominios y datasets críticos identificados y priorizados para la implementación inicial.
• Reglas de calidad definidas por dominio con input del Data Owner y el Data Steward.
• Las seis dimensiones evaluadas para cada dominio: completitud, unicidad, validez, consistencia, puntualidad y precisión.
• Reglas implementadas como código en el pipeline (dbt tests, Great Expectations o Soda).
• Umbrales de aceptación definidos por regla, acordados con el negocio y documentados.
• Niveles de criticidad asignados: bloqueo, alerta o registro según el impacto.
• Alertas automáticas configuradas con receptor claro y SLA de respuesta definido.
• Proceso de remediación documentado con responsables asignados por tipo de incidencia.
• Dashboard de calidad publicado y accesible para Data Owners y equipo de compliance.
• Registros históricos de ejecuciones de calidad conservados como evidencia auditable.
• Análisis de representatividad y sesgos documentado para datasets de entrenamiento de IA (art. 10 AI Act).
• Proceso de revisión periódica de reglas cuando cambia el negocio o el sistema fuente.

Preguntas frecuentes sobre data quality management

¿Qué es el data quality management?

El data quality management es el conjunto de procesos, políticas, roles y herramientas que garantizan que los datos de una organización son precisos, completos, consistentes, oportunos y aptos para el uso previsto. No es una validación puntual: es un proceso continuo con métricas definidas, umbrales acordados con el negocio, alertas automáticas y responsables de remediación con mandato real para actuar.

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

Las seis dimensiones principales según DAMA-DMBOK son: completitud (¿están todos los valores requeridos?), unicidad (¿hay duplicados?), validez (¿los valores cumplen las reglas de formato y rango?), consistencia (¿el mismo dato tiene el mismo valor en distintos sistemas?), puntualidad (¿el dato está disponible cuando se necesita?) y precisión (¿el valor refleja la realidad?). Para datos de entrenamiento de IA, añade representatividad como dimensión crítica adicional.

¿Qué herramientas de data quality existen?

Las principales en 2026 son: dbt tests para validaciones integradas en el pipeline, Great Expectations y Soda para SLAs de calidad como código, Monte Carlo y Bigeye para detección de anomalías sin reglas predefinidas, y Collibra DQ para soluciones enterprise. Para equipos que empiezan, dbt tests más Soda cubre el 80% de los casos de uso con coste mínimo.

¿Por qué el AI Act exige data quality management?

El artículo 10 del AI Act exige que los datos de entrenamiento, validación y prueba de sistemas de IA de alto riesgo sean pertinentes, representativos, libres de errores y completos en la medida de lo posible, y que se haya realizado un análisis de sesgos. Sin un proceso de data quality management documentado y continuo, demostrar este cumplimiento ante AESIA o la AEPD con evidencia real no es posible.

¿Qué diferencia hay entre data quality y data validation?

La validación de datos es una verificación puntual en un momento del pipeline. El data quality management es el sistema completo que rodea esa validación: quién definió las reglas, con qué umbral, quién recibe la alerta cuando falla y qué proceso de remediación se activa. La validación es un componente del data quality management, no un sustituto. Una organización que solo valida en la ingesta tiene cobertura parcial; una que hace data quality management tiene cobertura continua y evidencia auditable.