Calidad de datos: cómo medirla y quién responde de cada dato

La calidad de datos es el problema que nadie tiene en el presupuesto y todo el mundo paga. Se manifiesta en cosas pequeñas —un cliente duplicado, un albarán sin fecha, un CIF con espacios— hasta que un día el informe de ventas no cuadra con contabilidad, el comercial llama dos veces al mismo contacto y el modelo de previsión da un número que nadie se cree. Entonces aparece la frase de siempre: «los datos están mal». Que no es un diagnóstico, es una queja.

Esta guía es para quien tiene que convertir esa queja en algo gestionable: medir la calidad de datos con números, poner controles que avisen antes que el cliente y, sobre todo, decidir quién responde de cada dato. No hace falta una plataforma cara ni un equipo nuevo. Hace falta acotar, medir y asignar dueño.

¿Qué es la calidad de datos y en qué dimensiones se mide?

Un dato tiene calidad si sirve para la decisión que se va a tomar con él. Es una definición incómoda porque es relativa: el mismo maestro de clientes puede ser suficientemente bueno para facturar y desastroso para segmentar campañas. Por eso la calidad de datos no se mide «en general», se mide por dimensión y sobre un conjunto concreto.

Las seis dimensiones que usamos y que se pueden calcular con SQL, sin comprar nada:

| Dimensión | Qué pregunta responde | Ejemplo de métrica | |---|---|---| | Completitud | ¿Están los campos que necesito? | % de clientes activos con sector informado | | Unicidad | ¿Hay duplicados? | Nº de clientes con mismo CIF o mismo email | | Validez | ¿El valor cumple su formato o su lista? | % de códigos postales de 5 dígitos existentes | | Consistencia | ¿Cuadra entre sistemas? | Diferencia entre ventas del ERP y del CRM | | Exactitud | ¿Coincide con la realidad? | % de direcciones que no rebotan en el envío | | Actualidad | ¿Está al día? | Antigüedad media del último contacto registrado |

Dos avisos prácticos. La exactitud es la única que no se puede medir mirando solo la base de datos: exige contrastar con el mundo real —una devolución, una llamada, un inventario físico—, y por eso se mide por muestreo y no en continuo. Y la actualidad es la dimensión más olvidada: un dato correcto en 2023 y nunca revisado es un dato falso hoy con aspecto de dato bueno.

Si no puedes escribir la consulta que calcula una dimensión, no la estás midiendo: la estás opinando.

¿Por qué se degradan los datos en una empresa mediana?

Casi nunca por una causa espectacular. Se degradan por acumulación de decisiones razonables tomadas en momentos distintos:

• Campos libres donde debería haber listas. El clásico «sector» escrito a mano: «Hostelería», «hosteleria», «HORECA», «Bar» y «-». Cinco valores, un solo concepto.
• Migraciones a medias. Se cambió de ERP hace tres años, se volcó lo imprescindible y el histórico anterior quedó con otra codificación que nadie documentó.
• Integraciones que no reconcilian. Dos sistemas escriben sobre la misma entidad sin acordar cuál manda. Es el fallo que más caro sale y el que más tarda en verse; lo desarrollamos en integrar ERP y CRM sin romper nada.
• Formularios que piden lo que el usuario no quiere dar. Si el comercial necesita 14 campos obligatorios para guardar una oportunidad, rellenará basura en nueve.
• Nadie es dueño del dato. Cuando un campo es de todos, es de nadie. Ninguna herramienta arregla esto.
• Procesos que penalizan hacerlo bien. Si el objetivo del equipo es número de registros cargados, se cargarán registros, buenos o malos.

Dicho de otra forma: la mala calidad de datos casi siempre es el reflejo fiel de un proceso mal diseñado. Limpiar sin tocar el proceso es fregar con el grifo abierto; a los seis meses la suciedad ha vuelto exactamente al mismo sitio.

¿Qué controles automáticos merece la pena poner?

La regla es simple: el control se pone lo más cerca posible del origen y falla ruidosamente. Un dato malo detectado en el cuadro de mando ya ha contaminado tres decisiones por el camino.

| Punto de control | Qué comprueba | Qué pasa si falla | |---|---|---| | Formulario o pantalla de alta | Formato, listas cerradas, obligatoriedad real | No deja guardar, con mensaje claro | | Carga o integración | Esquema, tipos, duplicados contra lo existente | Se rechaza el registro y se avisa al responsable | | Almacén analítico | Volumen esperado, nulos, rangos, claves huérfanas | Se marca el conjunto como no fiable ese día | | Informe o cuadro de mando | Cuadre con la fuente contable | Se muestra la advertencia en el propio panel | | Revisión periódica | Exactitud por muestreo, duplicados blandos | Tarea asignada con plazo |

Un conjunto mínimo de comprobaciones automáticas que cubre el 80 % de los sustos, ordenado por esfuerzo:

1. Frescura: ¿llegaron hoy los datos de ayer? Es el fallo más frecuente y el más fácil de detectar. 2. Volumen: ¿el número de filas está dentro del rango de las últimas semanas? Un día con la mitad de pedidos suele ser un problema de carga, no de negocio. 3. Nulos en campos críticos: umbral por campo, no global. 4. Unicidad de la clave: un pedido, una fila. Suena obvio y falla más de lo que parece tras una integración. 5. Integridad referencial: pedidos cuyo cliente no existe en el maestro. 6. Rangos y dominios: importes negativos, fechas en el futuro, estados fuera de la lista. 7. Cuadre entre sistemas: la suma de facturación del almacén analítico frente al ERP, con una tolerancia definida y aceptada.

Dos consejos que evitan el fracaso más común, que es que nadie mire las alertas: empieza con pocas reglas y tolerancias generosas —ajustar es fácil, recuperar credibilidad después de un mes de falsos positivos no—, y manda cada alerta a una persona concreta, no a un buzón compartido.

¿Quién responde de cada dato?

Aquí es donde un plan de calidad de datos se gana o se pierde. La asignación tiene tres papeles y ninguno es «el de informática»:

• Dueño del dato (negocio). Decide qué significa el campo, qué valores son válidos y con qué nivel de calidad se puede vivir. El maestro de clientes suele ser de comercial; el de artículos, de producto o compras; el de proveedores, de compras.
• Responsable operativo. Quien lo introduce y lo corrige en el día a día. Necesita que corregir sea fácil y que su jefe cuente ese trabajo como trabajo.
• Custodio técnico. Quien implementa los controles, mantiene los avisos y arregla las tuberías cuando se rompen. Es el perfil de ingeniería de datos, no el de quien decide reglas de negocio.

Con esos tres papeles, el artefacto mínimo es una tabla de una página por cada conjunto crítico: nombre del dato, sistema origen, dueño, definición en una frase, reglas de validez y umbral acordado. Cinco o seis conjuntos bastan para empezar —clientes, artículos, pedidos, facturas, proveedores— y se amplía cuando estos estén en verde. Es la parte operativa de lo que contamos en gobierno del dato, reducida al mínimo que se sostiene sin comité.

Un detalle que marca la diferencia: acordar el umbral por escrito y con un número. «El sector debe estar informado en el 95 % de los clientes activos» es gestionable. «Hay que tener los datos bien» no significa nada y garantiza que la discusión se repita cada trimestre.

¿Cómo arrancar un plan de calidad de datos en 90 días?

Sin comprar herramienta y sin parar nada. El objetivo del primer trimestre no es tener datos perfectos: es tener datos medidos, con dueño y con tendencia conocida.

| Semanas | Qué se hace | Entregable | |---|---|---| | 1-2 | Elegir 2 conjuntos críticos por impacto en decisiones | Alcance escrito y aceptado | | 3-4 | Perfilado: contar nulos, duplicados, valores fuera de dominio | Foto inicial con números | | 5-6 | Definir dueños, definiciones y umbrales | Tabla de una página por conjunto | | 7-8 | Implantar 5-7 controles automáticos con aviso | Alertas llegando a personas | | 9-10 | Limpieza del pasivo priorizada por impacto | Registros corregidos y trazados | | 11-12 | Arreglar el proceso que generaba el error | Lista cerrada, campo obligatorio o validación en origen |

Las semanas 11 y 12 son las que casi todo el mundo se salta y las únicas que hacen que la mejora dure. Si el duplicado nacía porque el alta de cliente se hace en dos sitios, mientras eso siga así seguirás limpiando duplicados en 2028.

Y una advertencia sobre el perfilado inicial: prepárate para que el número sea peor de lo que dirección espera. Es normal y es buena señal. El primer informe de calidad de datos no se presenta como una denuncia, se presenta como una línea base con la que comparar dentro de tres meses.

¿Cómo afecta la calidad de datos a los proyectos de IA?

Más de lo que se admite en las presentaciones. Un modelo aprende del histórico que le das: si el histórico tiene el 30 % de los pedidos sin canal informado, el modelo aprenderá que ese canal no existe, y lo hará con total convicción. Tres efectos concretos:

• Sesgo silencioso. Los registros mal cumplimentados casi nunca están repartidos al azar: suelen concentrarse en una delegación, un turno o un tipo de cliente. El modelo hereda ese hueco y falla justo donde menos lo esperas.
• Modelos que no se pueden evaluar. Si la etiqueta —el resultado que quieres predecir— está mal registrada, no puedes saber si el modelo acierta. Es el problema que tumba la mitad de los pilotos, como analizamos en por qué fracasan los pilotos de IA.
• Respuestas seguras y falsas. En asistentes que consultan documentación propia, un documento obsoleto no genera un error: genera una respuesta impecable con información caducada. La calidad documental es calidad de datos también.

Por eso el orden que defendemos es siempre el mismo: primero saber qué dato tienes y en qué estado, después decidir el caso de uso. Está desarrollado en datos antes que IA, y es la diferencia entre un piloto que se queda y uno que se explica muy bien y no se usa.

Preguntas frecuentes

¿Cuál es un nivel aceptable de calidad de datos?

Depende del uso, y por eso se fija por campo y no de forma global. Para facturar, el CIF y la dirección fiscal necesitan estar cerca del 100 %; para segmentar una campaña, un 90 % de sector informado suele bastar. El error es exigir perfección en todo: cuesta muchísimo y no mejora ninguna decisión.

¿Hace falta comprar una herramienta de calidad de datos?

Al principio, no. Las primeras decenas de controles se escriben en SQL sobre el almacén que ya tienes y se lanzan con el mismo planificador que mueve los datos. Una herramienta específica tiene sentido cuando hay muchos conjuntos, varios equipos y necesidad de trazar linaje; antes de eso suele ser una licencia que oculta que nadie es dueño de nada.

¿Quién debe liderar la calidad de datos, negocio o tecnología?

Negocio define y tecnología implementa. Si lidera tecnología en solitario, acaban imponiéndose reglas que el negocio no reconoce y la gente busca cómo esquivarlas. Si lidera negocio sin apoyo técnico, se queda en una lista de deseos sin controles automáticos que la sostengan.

¿Se puede limpiar el histórico con IA?

En parte y con criterio. La normalización de textos, la detección de duplicados blandos y la clasificación de campos libres se resuelven bien con modelos, y ahorran semanas de trabajo manual. Lo que no se puede es inventar un dato que nunca se registró: si la fecha de alta no existe, no hay modelo que la recupere, solo que la estime, y conviene marcarla como estimada.

Si reconoces tu casa en tres o cuatro de los problemas de esta guía, lo útil no es un plan de gobierno de 40 páginas: es mirar dos o tres conjuntos de datos reales, contar nulos, duplicados y descuadres, y ponerle números a lo que hoy es una sensación. Eso es la auditoría y sale con una lista priorizada de qué arreglar primero. Si prefieres contarnos antes dónde duele, hablemos media hora y te decimos con franqueza si tu caso es de limpieza, de proceso o de las dos cosas.