Calidad de datos: cómo mejorarla sin parar la operación

El 30% que nadie quiere mirar

Un ejecutivo de una empresa logística nos dijo una vez: “Nuestros datos están bien, simplemente no siempre cuadran.” Esa frase resume el estado de la calidad de datos en la mayoría de las organizaciones. Nadie dice que los datos son malos. Dicen que “hay algunas inconsistencias” o que “a veces hay que ajustar manualmente.”

La realidad es menos amable. IBM estima que los datos de baja calidad cuestan a las empresas estadounidenses 3.1 billones de dólares al año. Gartner calcula que el 30% de los datos críticos de negocio de una organización típica son inexactos, incompletos o duplicados. No estamos hablando de datos históricos enterrados en un data warehouse que nadie consulta. Estamos hablando de los datos que alimentan decisiones operativas diarias: direcciones de envío, precios de productos, estados de pedidos, información de clientes.

El impulso natural cuando alguien reconoce el problema es proponer un “proyecto de limpieza de datos.” Reunir un equipo, limpiar la base de datos durante tres meses, declarar victoria y volver a lo normal. El problema es que los datos se ensucian continuamente. Sin mecanismos que prevengan y detecten la degradación, tres meses después del proyecto estarás en el mismo punto. O peor, porque la organización pensará que el problema está resuelto.

Profiling: medir antes de actuar

No puedes mejorar lo que no mides. El data profiling es el diagnóstico que precede al tratamiento. Consiste en analizar sistemáticamente los datos existentes para entender su estructura real (no la documentada, la real), sus patrones, sus anomalías y sus vacíos.

Un profiling básico cubre cuatro dimensiones:

Completitud. Qué porcentaje de registros tiene cada campo relleno? Si tu tabla de clientes tiene 50.000 registros pero el campo “email” está vacío en 12.000, tu completitud de email es del 76%. Eso puede ser aceptable o catastrófico dependiendo del caso de uso.

Unicidad. Cuántos duplicados existen? Duplicados exactos son fáciles de detectar. Duplicados fuzzy (Juan García y J. García Martínez que son la misma persona) requieren algoritmos de matching más sofisticados. Herramientas como dedupe de Python o la función SOUNDEX de SQL ayudan, pero el matching fuzzy siempre requiere validación humana en los casos ambiguos.

Consistencia. Los mismos datos representados de formas diferentes. “Madrid” vs. “MADRID” vs. “28001 Madrid” en un campo de ciudad. “España” vs. “ES” vs. “Spain” en un campo de país. Fechas en DD/MM/YYYY vs. MM/DD/YYYY (pesadilla clásica). La inconsistencia no es un error en sí misma; es un multiplicador de errores en cualquier proceso que consuma esos datos.

Validez. Los datos cumplen las reglas de negocio? Un NIF tiene un formato definido. Un código postal español tiene 5 dígitos. Un email tiene una estructura validable. Un precio no puede ser negativo. Estas reglas parecen obvias, pero sin validación activa, los datos inválidos entran y se propagan.

Herramientas de profiling van desde lo básico (pandas profiling en Python, que genera un informe HTML completo en una línea de código) hasta plataformas dedicadas como Great Expectations, Soda, o Monte Carlo. La herramienta importa menos que la disciplina de ejecutar el profiling periódicamente y actuar sobre los resultados.

Reglas de validación: la primera línea de defensa

Las reglas de validación actúan en el punto de entrada de los datos. Antes de que un registro se escriba en la base de datos, pasa por un conjunto de validaciones. Si falla, se rechaza o se marca para revisión.

Las reglas se organizan en tres niveles:

Reglas de esquema. El tipo de dato es correcto, el campo obligatorio está presente, el valor está dentro de un rango aceptable. Estas reglas son deterministas y pueden implementarse en la capa de base de datos (constraints, check clauses) o en la capa de aplicación (validación de formularios, validación de API). Implementarlas en la base de datos es más seguro porque es imposible saltárselas. Implementarlas solo en la aplicación deja la puerta abierta a imports directos o integraciones que bypasean la validación.

Reglas de negocio. El pedido tiene al menos una línea. El descuento no supera el 40%. La fecha de entrega es posterior a la fecha de pedido. Estas reglas codifican conocimiento de dominio y cambian con el negocio. Deben ser configurables, no hardcodeadas, para que el equipo de negocio pueda ajustarlas sin cambios de código.

Reglas estadísticas. El valor está dentro de N desviaciones estándar de la media histórica. Una factura de 50.000 euros cuando la media es de 500 requiere revisión, aunque sea técnica y legalmente válida. Estas reglas detectan anomalías que las reglas deterministas no capturan.

Great Expectations es el estándar de facto para implementar estas reglas en pipelines de datos. Define “expectations” (reglas) sobre los datos, las ejecuta contra cada batch, y genera un informe de validación. Las expectations se versionan en Git como cualquier otro código, lo que proporciona auditabilidad y colaboración.

Pipelines de limpieza automática

Las reglas de validación previenen la entrada de datos malos. Los pipelines de limpieza corrigen los datos malos que ya existen (o que entran por canales que no pasan por las validaciones).

Un pipeline de limpieza típico tiene tres fases:

Detección. Identificar registros que no cumplen los estándares de calidad. Puede ser un job programado que ejecuta las mismas reglas de validación sobre datos existentes, o un proceso más sofisticado que usa matching fuzzy para detectar duplicados.

Corrección. Para correcciones deterministas (normalizar mayúsculas, formatear teléfonos, corregir códigos postales), la automatización es segura. Para correcciones ambiguas (fusionar duplicados, corregir nombres), la automatización debe proponer y un humano debe aprobar. Automatizar la fusión de duplicados sin revisión humana es una receta para perder datos.

Verificación. Después de cada ciclo de limpieza, las métricas de calidad deben recalcularse para confirmar que la limpieza fue efectiva y no introdujo nuevos problemas. Un pipeline que corrige 500 registros pero corrompe 50 es un pipeline roto.

La cadencia de limpieza depende del volumen y la tasa de degradación. Para bases de datos con alta ingesta (miles de registros diarios), la limpieza debe ser continua. Para bases de datos más estables, una ejecución semanal puede ser suficiente.

El error más común es ejecutar el pipeline de limpieza una vez, celebrar la mejoría en las métricas, y no volver a ejecutarlo. Los datos se ensucian continuamente. El pipeline debe ser una operación recurrente, no un evento.

Data stewards: el rol que falta

La tecnología resuelve la mitad del problema. La otra mitad es organizativa. Quién decide que un 76% de completitud en emails es inaceptable? Quién define la regla de que un descuento no puede superar el 40%? Quién decide si dos registros ambiguos son duplicados o personas diferentes?

El data steward es el rol que responde a esas preguntas. No es un perfil técnico puro ni un perfil de negocio puro. Es alguien que entiende los datos, entiende el negocio, y tiene la autoridad para tomar decisiones sobre calidad.

En organizaciones pequeñas (menos de 50 personas), el data steward suele ser un rol parcial asumido por alguien de operaciones o de producto. En organizaciones medianas, es un rol dedicado o un equipo pequeño. En grandes empresas, es una estructura con stewards por dominio de datos (clientes, productos, transacciones) coordinados por un data governance officer.

Lo que no funciona es no tener a nadie. Sin un responsable definido, las reglas de calidad no se actualizan, los casos ambiguos no se resuelven, y las métricas de calidad se convierten en dashboards que nadie mira.

Dashboards de calidad: visibilidad continua

Un dashboard de calidad de datos muestra el estado de las métricas de calidad en tiempo real (o casi real). Las métricas fundamentales son:

• Completitud por campo y por tabla. Trending semanal.
• Tasa de duplicados detectados y resueltos.
• Tasa de registros inválidos que entran al sistema (por fuente).
• Tiempo medio de resolución de incidencias de calidad.
• Score global de calidad (un índice compuesto que pondera las dimensiones relevantes para el negocio).

El dashboard no es para tecnología. Es para negocio. Si el director comercial puede ver que el 8% de las direcciones de envío están incompletas, y eso se correlaciona con una tasa de devolución del 12%, la calidad de datos deja de ser un problema técnico y se convierte en un problema de negocio con un coste visible.

Grafana con datos de Great Expectations, o herramientas dedicadas como Monte Carlo o Bigeye, proporcionan la visualización. Lo importante es que el dashboard sea visible, actualizado y accionable. Un dashboard que nadie revisa es decoración.

Calidad de datos y fuentes externas

Un aspecto que los equipos suelen ignorar es que la calidad de datos no depende solo de tus sistemas internos. Una parte significativa de los datos entra desde fuentes externas: APIs de proveedores, imports de clientes, integraciones con marketplaces, datos scraped de webs públicas.

Cada fuente externa es un vector de degradación. Un proveedor que cambia el formato de sus códigos de producto sin avisar. Un cliente que envía un CSV con codificación Latin-1 cuando tu sistema espera UTF-8. Un marketplace que empieza a incluir caracteres especiales en los nombres de producto.

La defensa es tratar cada punto de integración como un boundary de validación. Los datos que entran desde fuera pasan por las mismas reglas de validación (o más estrictas) que los datos generados internamente. Un pipeline de ingesta que acepta todo lo que le llega sin validar es una invitación al caos.

En la práctica, construimos un staging área para datos externos. Los datos llegan, se validan, se normalizan, y solo entonces se escriben en las tablas de producción. Los registros que no pasan la validación van a una cola de revisión donde un operador (o un proceso automatizado) los corrige o los rechaza. Este patrón añade latencia a la ingesta (segundos, no minutos), pero evita que datos corruptos contaminen la base de datos principal.

El coste de no hacerlo es real y medible. Un cliente nuestro del sector retail descubrio que el 23% de los errores en su catálogo de productos provenían de un solo proveedor que enviaba datos en un formato inconsistente. Implementar validación en la ingesta de ese proveedor redujo los errores del catálogo un 18% en el primer mes.

Gobernanza de datos vs. calidad de datos

Es fácil confundir gobernanza y calidad, pero son conceptos complementarios. La calidad se ocupa de que los datos sean correctos, completos y consistentes. La gobernanza se ocupa de quién puede acceder a qué datos, cómo se clasifican, cómo se retienen y cómo se eliminan.

Sin gobernanza, la calidad es insostenible. Si cualquiera puede modificar cualquier tabla sin control de acceso, las reglas de validación se bypasean por conveniencia. Si no hay políticas de retención, los datos obsoletos se acumulan y diluyen las métricas de calidad. Si no hay clasificación de sensibilidad, los datos personales se copian en entornos de desarrollo sin protección.

La recomendación práctica es empezar por la calidad (tiene ROI inmediato) y construir la gobernanza de datos incrementalmente. Pero no ignores la gobernanza indefinidamente. Un marco básico de gobernanza (catálogo de datos, control de acceso, política de retención) es necesario antes de que la complejidad de los datos supere la capacidad del equipo para gestionarlos manualmente.

Implementación incremental

No intentes arreglar toda la calidad de datos de una vez. El enfoque que funciona es incremental.

Semana 1-2: Ejecutar profiling sobre las tablas más críticas. Identificar los tres problemas con mayor impacto en el negocio.

Semana 3-4: Implementar reglas de validación en los puntos de entrada para prevenir nuevos datos malos. Esto detiene la hemorragia.

Mes 2: Construir el pipeline de limpieza para los datos existentes, empezando por los tres problemas identificados. Medir el antes y el después.

Mes 3: Desplegar el dashboard de calidad y asignar un data steward (aunque sea un rol parcial). Establecer una revisión semanal de métricas.

Ongoing: Expandir las reglas de validación, añadir nuevas fuentes al profiling, refinar el pipeline de limpieza basándose en los patrones que emerge.

El objetivo no es la perfección. Es la mejora continua con mecanismos que previenen la regresión. Un 95% de completitud mantenido consistentemente es mejor que un 100% que dura una semana y cae al 80%.

Los datos son el activo más subestimado de la mayoría de las empresas. No porque no tengan datos, sino porque los datos que tienen no son fiables. Mejorar la calidad de datos no es sexy, no genera titulares, y no impresiona en una demo. Pero es lo que permite que todo lo demás (analytics, IA, automatización, decisiones de negocio) funcione sobre una base sólida en lugar de sobre arenas movedizas.