Calidad de datos: qué es, cómo se mide y dónde cuesta menos corregirla
En resumen
La calidad de datos es el grado en que un conjunto de datos cumple los requisitos del uso que se le va a dar. Se evalúa por dimensiones como exactitud, completitud, consistencia, validez, unicidad y actualidad, y el estándar internacional de referencia es ISO/IEC 25012.
Medirla es la parte conocida. La parte que casi nadie discute es dónde se coloca el control: en el origen, en el pipeline o en el consumo. Esa decisión determina qué errores puedes detectar y cuánto cuesta arreglarlos.
La industria mide mayoritariamente en la capa de consumo, que es la más cara y la más tardía. Ese sesgo tiene una razón histórica y ya está siendo corregido.
Qué es la calidad de datos
La calidad de datos es el grado en que un conjunto de datos cumple los requisitos del uso operativo o analítico que se le va a dar. No es una propiedad absoluta del dato, sino una relación entre el dato y su propósito: el mismo registro puede ser de calidad suficiente para un reporte mensual e insuficiente para alimentar un modelo de precios.
Esa condicionalidad es lo que hace que la calidad no se resuelva de una sola vez. Un dato correcto hoy puede dejar de ser apto mañana porque el uso cambió, no porque el dato haya cambiado.
Las dimensiones de la calidad de datos
Las dimensiones son las categorías bajo las que se evalúa un conjunto de datos. Existen varias taxonomías; la más citada como referencia formal es la del estándar ISO/IEC 25012, que desglosa la calidad en alrededor de quince características. En la práctica operativa, estas seis concentran casi todos los problemas reales:
Dimensión | Qué mide | Ejemplo de falla |
|---|---|---|
Exactitud | Si el valor corresponde a la realidad | El peso registrado de un embarque no coincide con el físico |
Completitud | Si están todos los campos requeridos | Un proveedor sin cuenta bancaria registrada |
Consistencia | Si el valor es el mismo en todos los sistemas | El mismo cliente con dos límites de crédito distintos |
Validez | Si cumple el formato y las reglas definidas | Un identificador fiscal con estructura incorrecta |
Unicidad | Si la entidad aparece una sola vez | El mismo material con dos números de parte |
Actualidad | Si refleja el estado vigente | Un catálogo de claves que no se actualizó tras un cambio oficial |
Una séptima dimensión, la aptitud para el propósito, no se mide igual que las demás porque depende del consumidor del dato. Es la que explica por qué un tablero puede estar en verde y aun así el equipo de finanzas no confiar en él.
Qué pasa cuando la calidad falla
El costo de la mala calidad es difícil de calcular porque se distribuye entre sistemas, equipos y tiempo. IBM lo plantea así en su análisis de enero de 2026: la mala calidad casi nunca se manifiesta en el punto donde falla, sino río abajo, como ingresos perdidos, ineficiencias y riesgo de cumplimiento. Ese retraso entre causa y síntoma es lo que la vuelve peligrosa.
El mismo análisis cita el estudio de CDOs 2025 del IBM Institute for Business Value, donde 43% de los directores de operaciones señalan los problemas de calidad de datos como su prioridad número uno en materia de datos.
Tres ejemplos de cómo se manifiesta, en dominios distintos:
Un catálogo desactualizado detiene la operación. Los sistemas fiscales y logísticos validan contra catálogos oficiales que cambian con el tiempo. Una clave que dejó de existir provoca rechazos en el momento de emitir el documento, no en el reporte del mes siguiente. El costo se paga en carretera, no en el tablero.
Un duplicado inmoviliza capital. El mismo componente dado de alta con dos nomenclaturas hace que dos plantas vean cada una la mitad del inventario real y ambas compren de emergencia. El inventario consolidado dice que hay cobertura.
Un error de ingesta envenena un modelo. El caso público más citado es el de Unity Technologies, que en 2022 reportó alrededor de 110 millones de dólares en ingresos perdidos después de que datos mal ingestados corrompieran los conjuntos con los que entrenaba sus modelos de publicidad. No fue un problema de modelo. Fue un problema de entrada.
Dónde se corrige un dato: las tres capas de control
Esta es la decisión que la mayoría de los artículos sobre el tema no plantea. La calidad se puede controlar en tres lugares distintos, y cada uno ve cosas que los otros no.
Capa de origen. El control vive en el momento en que el dato se crea o se captura: reglas de formato, obligatoriedad condicional, validaciones contra fuentes externas, aprobaciones antes de que el registro exista. Detecta el error cuando todavía no costó nada.
Capa de pipeline. El control vive en la ingesta y la transformación: pruebas de esquema, conteos de volumen, detección de anomalías, cuarentena de cargas incompletas. Detecta lo que el origen no puede ver, porque solo se nota al cruzar fuentes.
Capa de consumo. El control vive al final: el reporte que no cuadra, el modelo que se desvía, el usuario que levanta la mano. Detecta casi todo, siempre tarde.
Capa | Qué detecta bien | Qué no puede ver | Costo relativo de corregir |
|---|---|---|---|
Origen | Formato, reglas de negocio, entidades inválidas, campos faltantes | Errores que solo aparecen al cruzar sistemas | Bajo |
Pipeline | Cambios de esquema, cargas parciales, duplicados entre fuentes, anomalías de volumen | Datos formalmente válidos pero falsos | Medio |
Consumo | Incoherencias que el negocio reconoce como imposibles | Todo lo anterior, hasta que ya ocurrió | Alto |
La progresión de costos no es una intuición. La regla 1-10-100, usada desde hace años en gestión de incidentes, describe que corregir un problema en el punto de entrada cuesta aproximadamente una unidad, que propagado dentro del sistema cuesta cerca de diez, y que si alcanza al usuario final o a una decisión de negocio puede costar cien. Las cifras exactas varían por organización. La forma de la curva no.
Ninguna capa sustituye a las otras. Un programa serio tiene control en las tres. El problema es que la mayoría solo tiene control en la última.
Por qué la industria mide en la capa equivocada
El sesgo tiene un origen concreto: las herramientas de calidad de datos nacieron del lado analítico, se instalan donde viven los datos analíticos y, por lo tanto, miden donde el dato ya llegó.
Eso se declara abiertamente. En su artículo sobre el tema, Databricks afirma que es probable que cualquier dato que entre a una plataforma de análisis no cumpla los requisitos de calidad, y que la calidad se logra limpiando y transformando los datos a lo largo del tiempo. Toda su sección de mejora está organizada alrededor de la calidad durante el proceso de ETL.
Es una descripción honesta de cómo funciona hoy. También es una descripción de un problema asumido como ley natural. Si damos por sentado que el dato llega mal, la única pregunta posible es cuánta limpieza podemos costear.
Lo interesante es que la propia industria ya está moviéndose. En el análisis citado antes, IBM sostiene que los enfoques tradicionales, entendidos como revisar la calidad exclusivamente dentro del data warehouse, ya no escalan, y que las organizaciones deben hacer shift left sobre la integridad del dato: acercar la detección, la prevención y la remediación al momento en que el dato se crea, en lugar de esperar a que los problemas aparezcan río abajo. Entre las prácticas que recomienda está validar en el punto de entrada, no después del consumo.
Conviene notar la fecha. El artículo definicional de IBM que hoy domina las búsquedas de este tema se publicó en 2022 y no menciona nada de esto. El planteamiento de shift left es de enero de 2026. La distancia entre esos dos textos es exactamente la distancia entre cómo se explica la calidad de datos y cómo se está resolviendo.
Qué significa controlar en el origen
Mover el control hacia el origen no quiere decir poner un formulario con campos obligatorios. Quiere decir tres cosas concretas.
Que la regla de negocio se ejecute antes de que el registro exista, no después. Una validación que marca el registro y lo deja pasar produce una bandera que alguien revisará algún día. Una validación que detiene el proceso produce la ausencia del problema.
Que la verificación contra fuentes externas ocurra en el flujo, no en una revisión posterior. Consultar una lista de restricción después de que el registro ya está en el ERP y ya generó movimientos es auditoría, no calidad.
Que el proceso que produce el dato sea modificable. Las reglas cambian: se actualizan catálogos oficiales, cambia la normativa, cambian las políticas internas. Si cambiar una validación requiere un ciclo de desarrollo de semanas, el control de origen se degrada solo, sin que nadie lo toque.
Cuando el dato en cuestión describe una entidad que varios sistemas comparten, como un proveedor o un material, el control de origen se implementa concentrando la autoría en un solo lugar: el registro se crea una vez, bajo reglas, y desde ahí se distribuye. Para el resto de los datos, el control vive en la capa de ingesta y en los contratos entre quien produce y quien consume.
Cómo medir la calidad de datos: métricas y umbrales
Medir la calidad no es calcular un porcentaje global de datos buenos. Es instrumentar dimensiones específicas con umbrales definidos por quien consume el dato. El repertorio estándar (tasa de error por dimensión, cobertura de validación, tiempo medio de detección y de resolución, matriz de calidad y KPIs por industria) está desarrollado a detalle en nuestra guía de métricas de calidad de datos.
Hay dos métricas que rara vez aparecen en esos marcos y que son las que revelan la salud estructural del programa:
Distancia al origen de la detección. En qué capa se detectó cada problema. Si prácticamente todo se detecta en consumo, el programa no tiene control preventivo, tenga los tableros que tenga.
Tiempo entre un cambio de regla y su entrada en producción. Mide si tus controles pueden seguirle el paso a la realidad. Un control que tarda semanas en actualizarse deja de ser un control.
Ninguna de las dos aparece en los marcos clásicos porque ambos asumen que el punto de medición ya está decidido. En cuanto se vuelve una decisión, hay que medirla.
Calidad como evidencia, no solo como reporte
Hay una función de la calidad de datos que los marcos tradicionales no cubren: servir como prueba. En procesos donde varias áreas discuten sobre los mismos números, el problema no siempre es que el dato esté mal. A veces es que nadie puede demostrar en qué estado estaba.
Tres mecanismos resuelven eso:
Snapshot del estado inicial. Capturar el estado exacto de los datos en el instante en que se declara el inicio de un proceso. Elimina las disputas por movimientos que entraron tarde, porque hay un registro de qué existía y cuándo.
Ejecuciones simuladas previas. Correr el proceso completo antes del proceso real, para detectar anomalías con tiempo de reaccionar en lugar de descubrirlas en producción.
Bitácora auditable por etapa. Registrar tiempos y resultados por tabla o por lote, de modo que cuando algo tarda o falla se pueda señalar dónde exactamente, en vez de discutir sobre percepciones.
Esto no aparece en ninguna taxonomía de dimensiones, y es lo que en la práctica convierte una reunión de reclamos en una revisión de cinco minutos.
Calidad de datos y datos listos para IA
Un modelo hereda cada defecto de sus datos de entrada y los aplica a escala. Un agente que consulta un catálogo con duplicados los propaga a cada respuesta. La IA no filtra la mala calidad: la amplifica y la vuelve difícil de rastrear.
Por eso el desplazamiento del control hacia el origen dejó de ser una preferencia de arquitectura. Cuando los sistemas consumen datos de forma continua en lugar de episódica, revisar la calidad en una ventana de procesamiento nocturno deja de tener sentido: para cuando el reporte detecta el problema, el agente ya actuó sobre él decenas de veces.
Tres casos: dónde se colocó el control
Unificación de 21 países en 120 días. Un líder global en alimentos operaba su modelo logístico y comercial a través de tres proveedores distintos, con esquemas que cambiaban sin aviso y fuera de su control. Arkon Data ejecutó la validación exhaustiva de cargas históricas y datos actuales en la capa de ingesta, evitando por completo duplicidades y pérdidas de integridad en las 200 tablas migradas. El resultado: 21 países operando bajo una misma lógica de negocio, alrededor de 4,200 entidades de datos gobernadas por un equipo de 9 personas, y transición sin downtime. El control se puso en la entrada, con dos especialistas de QA dedicados a consistencia sobre unas 200 tablas por país.
Cierre financiero con evidencia transaccional. El mismo cliente consolidaba millones de transacciones en un proceso de hasta 6 horas que saturaba el ERP y terminaba en juntas de reclamos. Se implementó un mecanismo de foto inicial que captura el estado exacto de los datos en el segundo en que el cliente declara el cierre, más ejecuciones internas simuladas antes del cierre real y una bitácora auditable de tiempos por tabla. Los tiempos bajaron 72%, de hasta 6 horas a 1 hora 40 minutos soportando el doble de tablas contables, con cero impacto en el sistema fuente. Las juntas de una hora de reclamos se volvieron retrospectivas de 10 minutos.
Conciliación con validación externa. El cruce de millones de facturas contra cuentas contables era un proceso catalogado como imposible: el reporte nativo del ERP no corría y Power BI topaba con un límite estructural de 150,000 líneas frente a millones de registros. Con la lógica migrada y ciclos de pruebas históricas exhaustivas, la conciliación automatizada elevó el cuadre del 96% al 99%, de modo que hoy solo el 1% requiere validación manual, sobre 42 entidades de datos de múltiples países. El auditor externo, KPMG, adoptó el reporte resultante para la auditoría de las cuentas más críticas por encima de sus propias consultas.
Preguntas frecuentes sobre calidad de datos
1. ¿Cuál es la diferencia entre calidad de datos e integridad de datos?
La calidad es la categoría amplia: exactitud, completitud, validez, consistencia y las demás dimensiones. La integridad es un subconjunto centrado en que el dato no se corrompa ni se altere a lo largo de su ciclo de vida, y se trata más desde la perspectiva de seguridad y control de cambios.
2. ¿Qué es el perfilado de datos?
Es el proceso técnico de examinar un conjunto de datos en detalle, compararlo con sus metadatos y calcular estadísticas para descubrir patrones incorrectos, valores nulos y anomalías. El perfilado mide; la calidad es lo que se mide.
3. ¿Se puede llegar a cero errores?
No, y perseguirlo es caro e improductivo. El objetivo es definir umbrales de tolerancia por dimensión, según lo que el consumidor del dato necesita, y medir la desviación contra esos umbrales.
4. ¿Qué es shift left en calidad de datos?
Es mover la detección, la prevención y la corrección hacia el momento en que el dato se crea, en lugar de esperar a detectarlas en el almacén o en el reporte.
5. ¿La calidad de datos es lo mismo que gobierno de datos?
No. El gobierno define quién decide y quién responde por los datos. La calidad es una de las propiedades que el gobierno se encarga de garantizar, con métricas y umbrales propios.
6. ¿Por dónde se empieza un programa de calidad de datos?
Por identificar en qué capa se está detectando hoy la mayoría de los problemas. Si casi todos se detectan en consumo, el primer trabajo no es comprar herramienta, es mover controles hacia arriba. El recorrido completo, paso a paso, está en nuestra guía sobre cómo crear un plan de calidad de datos.
Del diagnóstico a la ejecución
La pregunta que conviene responder antes de invertir en herramientas es sencilla y casi nadie la tiene contestada: de los problemas de calidad que tu organización detectó el último trimestre, cuántos se detectaron en el origen, cuántos en el pipeline y cuántos cuando ya estaban en un reporte o en manos de un cliente.
La solución de calidad de datos de Arkon Data trabaja en dos frentes al mismo tiempo. Por un lado conecta los procesos de negocio con los datos que generan, de modo que las reglas se apliquen en el momento de la captura y el error deje de producirse. Por otro corrige el dato que ya está dañado, porque los registros que entraron mal antes de que existiera cualquier control siguen ahí y alguien tiene que limpiarlos.
Esa segunda parte es la que suele faltar en los planteamientos de shift left. Mover el control al origen detiene el problema, pero no repara lo acumulado. Un programa completo hace las dos cosas, y conviene hacerlas en ese orden: primero se cierra la llave, después se limpia.
El trabajo no empieza con una herramienta. Empieza con ingenieros de proceso levantando dónde nace realmente cada dato crítico, qué reglas se le aplican hoy, incluidas las que solo existen en la cabeza de quien las ejecuta, y qué tan dañado está el histórico. De ahí salen las dos rutas: los controles que evitan el siguiente error y la remediación de lo que ya entró.
Agendemos una conversación corta, sin compromiso, para revisar en qué capa estás corrigiendo hoy y qué tan grande es el histórico que hay que reparar.