El problema
Hay una forma muy común de pensar la calidad de datos: como una etapa que viene después. Primero se ingesta, después se transforma, después se carga, y en algún momento (cuando haya tiempo, cuando el pipeline esté "estable") se agregan validaciones.
El problema con este enfoque es que ese momento nunca llega. O llega tarde, cuando ya hay usuarios consumiendo datos que no cierran, dashboards que muestran números inconsistentes, y una confianza rota que cuesta mucho más reparar que prevenir.
La pérdida de tiempo no está en validar. Está en corregir todos los problemas que aparecen cuando no agarraste el problema de calidad a tiempo.
La idea central
La calidad de datos no es un módulo que se agrega al final del pipeline, sino algo que atraviesa todas las etapas, desde la ingesta.
Esto no significa que cada paso del pipeline tenga que tener cientos de validaciones. Significa que en cada etapa hay que preguntarse: ¿qué puede salir mal acá? ¿Qué suposiciones estoy haciendo sobre estos datos? ¿Cómo me entero si esas suposiciones dejan de ser ciertas?
Cuando la calidad se piensa como algo transversal, las validaciones aparecen donde tienen sentido: cerca del origen, donde el costo de detectar un problema es bajo y el impacto de propagarlo es alto.
Por qué importa en la práctica
Un dato es una representación simbólica de la realidad. La calidad de ese dato mide qué tan fehaciente es esa representación. Si el número no refleja lo que pasó, el problema no es de visualización ni de dashboard: es un problema de calidad en sentido fuerte.
Y acá está el punto crítico: el usuario que ve un dato que no le cierra, ya deja de confiar en vos. Remontar esa confianza es muy difícil, a veces imposible. Ni hablar si ese dato alimenta una decisión que puede generar una pérdida económica o algo más grave.
Cuando encontrás un problema de calidad al final del pipeline, tenés todo un linaje enorme por delante. Tenés que reconstruir paso a paso dónde se introdujo el error, qué transformaciones lo propagaron, qué otros consumos están afectados. Si hubieras testeado antes, más cerca del origen, el problema habría sido más acotado y más barato de resolver.
Trade-offs y consideraciones
Pensar la calidad como transversal no significa validar todo en todas partes. Eso sería tan inútil como no validar nada.
El punto es diseñar el pipeline con la calidad en mente desde el principio:
- En la ingesta: ¿los datos que llegan cumplen con lo que esperás? ¿Hay campos nulos que no deberían serlo? ¿Hay duplicados?
- En la transformación: ¿las suposiciones de negocio que codificaste siguen siendo ciertas? ¿Qué pasa si cambia el origen?
- En la carga: ¿el modelo de destino puede recibir lo que le estás mandando? ¿Hay constraints que podrían fallar?
Cada validación tiene un costo: tiempo de ejecución, complejidad de mantenimiento, decisiones sobre qué hacer cuando falla. Pero ese costo es predecible y controlable. El costo de no validar es impredecible y, cuando aparece, suele ser mucho mayor.
Dentro del gobierno de datos, el lugar donde el ingeniero de datos más tiene que intervenir es justamente la calidad. No es lo mismo que "hacer todo el gobierno corporativo". Pero sí es la parte donde la ingeniería tiene más impacto directo y más responsabilidad.
En resumen
La calidad de datos no se agrega al final. Se decide en cada etapa del pipeline, empezando por la ingesta.
Tratar la calidad como un módulo separado es una forma de postergarla indefinidamente. Y cuando finalmente aparecen los problemas, el costo de arreglarlos (en tiempo, en confianza, en impacto al negocio) es mucho mayor que el de haberlos prevenido.
La pregunta no es "¿cuándo agrego calidad?". Es "¿qué puede salir mal acá y cómo me entero?".