Hay una pregunta que casi nunca nos hacemos en los proyectos de datos, y es la más importante de todas: cuando el pipeline termina en verde y el dashboard se refresca… ¿alguien ha comprobado que los datos sean correctos? En la mayoría de las organizaciones, la respuesta honesta es no. Validamos el proceso, en cambio, el dato, no.
Recientemente, trabajando con un cliente del sector pharma, nos encontramos con las consecuencias de ese hueco: archivos cargados manualmente que llegaban con errores y tardaban meses en descubrirse. Nuestra respuesta fue construir un motor de calidad de datos gobernado por metadatos sobre Microsoft Fabric. En cuestión de días teníamos una demo funcionando que detectaba anomalías automáticamente, aislaba los registros problemáticos y mostraba la salud de los datos en un dashboard de Power BI. Con este artículo queremos compartir cómo funciona, qué decisiones de diseño lo hacen especial y cuándo tiene sentido aplicarlo.
Si tu organización depende de cargas de archivos para alimentar su datalake, probablemente has vivido alguna de estas situaciones:
Todos estos problemas comparten un origen común: el pipeline valida que el proceso funcione, pero nadie valida que los datos sean correctos. El job termina en verde, los archivos se cargan, y el error viaja silenciosamente hasta los dashboards.
Nuestro cliente tenía unas 30 fuentes alimentando sus predicciones de volumen, varias de ellas dependientes de cargas manuales. Y el tiempo medio de detección de un error se medía en meses. El coste real no era técnico: era la pérdida de confianza en los datos.
La decisión de diseño que lo cambia todo: reglas fuera del código
Cuando planteamos este tipo de proyectos, la tentación es montar una arquitectura completa con las validaciones embebidas en el código de los pipelines. Funciona, pero tiene un problema: cada regla nueva, cada umbral que cambia, cada validación que el negocio quiere ajustar... es un desarrollo, un despliegue y un ticket al equipo técnico.
Nosotros lo planteamos al revés: Las reglas no viven en el código. Viven en una tabla de configuración.
Un catálogo central (un simple CSV convertido en tabla Delta) donde cada fila es una regla: qué columna valida, qué tipo de comprobación aplica, qué umbral usa, qué severidad tiene y si está activa o no. El motor lee ese catálogo en cada ejecución y aplica lo que encuentra.
¿Qué significa eso exactamente? Que añadir, modificar o desactivar una validación es editar una fila en una tabla. Sin código. Sin despliegues. Sin esperar al equipo técnico. El negocio recupera la autonomía y la solución evoluciona a su ritmo.
Cómo funciona la arquitectura
El flujo completo, de principio a fin, corre íntegramente dentro de Microsoft Fabric:
2. Una pipeline de Data Factory detecta los archivos nuevos (por nombre, tamaño y hash del contenido, para pillar también las modificaciones silenciosas) y lanza el motor.
3. Un notebook de PySpark aplica las reglas del catálogo, archivo a archivo. Los registros que pasan siguen su camino; los que fallan se aíslan automáticamente en una zona de cuarentena con trazabilidad completa: qué regla violaron, en qué archivo venían, cuándo se detectó.
4. El sistema mueve automáticamente los propios archivo según su resultado dentro del lakehouse: los limpios a una carpeta de procesados, los problemáticos a una carpeta de anomalías. Un vistazo a las carpetas y sabes el estado del sistema.
5. El motor registra todo en tablas Delta optimizadas para crear un modelo semántico con conexión Direct Lake para alimentar un dashboard de Power BI.
El resultado: cada ejecución produce un health score global, un registro histórico de qué pasó y una lista accionable de qué investigar.
Aquí está la parte interesante. No todas las validaciones son iguales, y dividirlas en tres familias nos permite cubrir problemas muy distintos:
Y el detalle elegante: el baseline se promociona solo. Cuando un archivo pasa todas las reglas críticas con una salud superior al 95%, se convierte automáticamente en la nueva referencia. El sistema aprende qué es "normal" sin que nadie tenga que mantenerlo a mano.
La demo: sembrando errores a propósito
Cuando llegó el momento de enseñárselo al cliente, no usamos archivos perfectos que pasaran todas las reglas. Eso queda bonito, pero no demuestra nada.
Preparamos seis archivos con datos realistas del sector y les sembramos errores intencionados: revenues negativos, regiones inválidas, nulos en columnas críticas, fechas con formatos imposibles y un archivo diario con un 60% menos de unidades que el día anterior, simulando una carga truncada.
Ejecutamos el motor en directo. El resultado:
El equipo del cliente entendió enseguida lo que llevaba meses sin tener: un sistema que dice, en el momento, qué archivos puedes usar con confianza y cuáles no.
Es la pregunta que nos hacen siempre, y la respuesta tiene dos partes.
Hoy, las reglas las define un humano que conoce el negocio. Es una base sólida, pero tiene un techo: solo detectas aquello para lo que alguien escribió una regla.
El siguiente paso (y el diseño ya lo contempla) es que un modelo analice el histórico de datos, descubra patrones y proponga reglas nuevas al catálogo: rangos habituales, correlaciones entre columnas, distribuciones típicas. El humano revisa cada propuesta y la acepta o la rechaza. Si la acepta, entra en el catálogo como una fila más.
Lo mejor de este enfoque es que no rompe nada: las reglas sugeridas por IA viven en la misma tabla que las escritas a mano. El motor ni las distingue. Y el humano mantiene el control en todo momento, algo especialmente relevante en sectores regulados como pharma.
Un framework de calidad de datos gobernado por metadatos no es una solución mágica, pero sí es una de las formas más directas de resolver un problema que frena a muchas organizaciones: los datos están ahí, pero nadie sabe si son de fiar. La inversión inicial es contenida, el patrón escala añadiendo filas (no complejidad) y el retorno se nota desde la primera ejecución.
Nosotros ya lo tenemos funcionando: el motor validando archivos en Fabric, la cuarentena aislando registros problemáticos y Power BI mostrando la salud del dato en tiempo real. No es teoría, es algo que funciona hoy.
La confianza en los datos no se recupera con un parche: se construye con un sistema que detecta los problemas antes de que lleguen a los dashboards.
No hace falta un macroproyecto para empezar. Basta con identificar las fuentes más críticas, definir las primeras reglas con el negocio y ver la primera ejecución del motor señalando lo que hasta ahora pasaba desapercibido. A partir de ahí, el camino sigue un proceso natural.¿Quieres saber si encaja en tu entorno? ¡Hablemos! 🙂
