Hay un momento que mina la confianza de una organización entera: cuando alguien señala un número en un dashboard y dice "esto está mal", y tiene razón. A partir de ahí, todos los informes quedan bajo sospecha. Y lo más frustrante es que, casi siempre, el error no nació en el informe. Entró mucho antes, en un pipeline que nadie estaba vigilando. Por eso la calidad de datos no puede ser una ocurrencia tardía: tiene que verificarse de forma automática, en cada carga.
La regla es simple de enunciar y transformadora en la práctica: el error debe ser detectado por el sistema, no descubierto por el usuario.
Por qué un pipeline rápido no basta
Es tentador optimizar los pipelines solo para velocidad y volumen. Pero de nada sirve entregar datos rápido si esos datos están mal, de hecho es peor, porque un error rápido se propaga rápido. Un valor que falta, una clave duplicada o una fecha absurda recorren todo el sistema y acaban en un informe de dirección, donde alguien toma una decisión sobre ellos. La velocidad sin calidad no es eficiencia: es riesgo acelerado.
Las verificaciones que compensan
No hace falta un sistema complejo para ganar el 90 por ciento de la fiabilidad. Un conjunto de verificaciones simples, ejecutadas en cada carga, detecta la gran mayoría de los errores:
- Completitud: las columnas obligatorias no pueden llegar vacías. Un cliente sin identificador o una venta sin importe son banderas rojas.
- Unicidad: las claves no pueden tener duplicados, o los totales se inflan en silencio.
- Rangos: los valores tienen que tener sentido, una edad de 300 años o una venta negativa deben detenerse.
- Integridad referencial: una venta tiene que apuntar a un cliente y un producto que existan de verdad.
La regla de oro: parar, no publicar
La decisión más importante no es qué verificaciones hacer, sino qué hacer cuando una falla. La respuesta correcta es clara: cuando una verificación crítica falla, el pipeline debe detenerse y alertar, nunca publicar datos sospechosos en silencio. Es contraintuitivo (a nadie le gusta un pipeline que falla), pero un pipeline que se detiene a tiempo protege la confianza; uno que publica basura la destruye. Fallar alto y pronto es siempre mejor que corromper despacio y en secreto.
En la práctica: el Excel que delata el problema
Imagine un equipo financiero que, todos los meses, exportaba el informe a Excel y "corregía a mano" algunos números antes de presentarlo. Ese Excel paralelo era, en realidad, un síntoma: el pipeline entregaba datos que nadie confiaba. Al integrar validaciones automáticas en el origen, completitud, unicidad, rangos, los errores pasaron a detectarse en la carga, con alerta, en lugar de corregirse manualmente al final. El Excel paralelo desapareció, no por orden, sino porque dejó de ser necesario.
Calidad como parte del pipeline, no como parche
El gran cambio de mentalidad es dejar de ver la calidad como una tarea separada y pasar a verla como parte integrante del pipeline. Cada carga trae consigo sus propias garantías. Cuando la validación está incorporada, la confianza deja de depender de la suerte o de la vigilancia humana, y se convierte en una propiedad del sistema. Y en su organización: ¿los errores de datos los detecta el pipeline, o los descubre un gestor mirando un número que no cuadra?
