El data cleansing (o data cleaning) es el conjunto de procesos para corregir o eliminar datos incorrectos, incompletos, duplicados o mal formateados de un conjunto de datos. Es la fase de acción dentro de tu framework de data quality management: primero perfilas y detectas (data profiling), después mides con KPIs, y finalmente limpias. Este artículo cubre esa tercera fase en detalle.
Las cinco fases del proceso
1Detección
No se puede limpiar lo que no se ha identificado. Esta fase se apoya en el profiling y en las reglas de calidad ya definidas: nulos donde no deberían existir, valores fuera de rango, formatos inconsistentes, registros duplicados. El resultado debe ser una lista concreta de registros afectados, no una impresión general de que "los datos están sucios".
2Estandarización
Antes de corregir errores de contenido, hay que unificar formato: fechas en un único formato, mayúsculas/minúsculas consistentes, unidades de medida homogéneas, códigos de país normalizados (ES vs España vs Spain). Sin esta fase, la deduplicación del siguiente paso falla, porque el sistema no reconoce como iguales dos registros que en realidad lo son pero están escritos distinto.
3Deduplicación
Identificar y fusionar registros que representan la misma entidad real. La deduplicación exacta (mismo valor en todos los campos) es sencilla; la difícil es la deduplicación difusa, cuando dos registros de cliente tienen nombre casi idéntico, mismo teléfono pero distinto email. Aquí conviene definir reglas de negocio explícitas sobre qué registro "gana" cuando hay conflicto (el más reciente, el de la fuente más confiable, el más completo).
4Validación y corrección
Aplicar las reglas de calidad ya definidas para confirmar que los datos corregidos cumplen los umbrales esperados. Algunos errores se pueden corregir de forma automática (normalizar un código postal, completar un país a partir del código postal); otros requieren revisión humana porque la corrección automática podría introducir un error distinto al original.
5Enriquecimiento
Fase opcional pero frecuente: completar datos faltantes con fuentes externas o internas (verificar un NIF contra un registro oficial, completar coordenadas geográficas a partir de una dirección). El enriquecimiento mejora completitud, pero introduce una dependencia externa que también debe monitorizarse.
Automatización vs revisión manual
No todo se debe automatizar. La automatización tiene sentido cuando la regla de corrección es determinista y de bajo riesgo: normalizar formato de fecha, eliminar espacios en blanco, unificar mayúsculas. Es peligrosa cuando la corrección implica una decisión de negocio: decidir qué registro de cliente es el "correcto" entre dos duplicados con datos distintos, o inferir un valor faltante que después alimenta una decisión automatizada de la empresa. En sistemas de IA de alto riesgo bajo el AI Act, además, cualquier corrección automática sobre datos de entrenamiento debe quedar documentada: qué se cambió, por qué y con qué criterio.
Dónde limpiar en el pipeline
| Punto del pipeline | Ventaja | Riesgo |
|---|---|---|
| En origen (antes de ingesta) | Evita propagar el error a todo el pipeline | No siempre tienes control sobre el sistema origen |
| En la capa de staging | Mantienes una copia cruda para auditoría antes de limpiar | Requiere más almacenamiento y orquestación |
| En la capa de transformación (dbt, Spark) | La limpieza queda versionada junto con la lógica de negocio | Mezclar limpieza con transformación dificulta el debugging |
La práctica más robusta es limpiar en staging, conservando siempre el dato crudo original. Así puedes reprocesar si una regla de limpieza resulta estar mal definida, sin depender de volver a extraer del sistema origen.
Herramientas
Para volúmenes pequeños, OpenRefine sigue siendo una opción sólida y visual. Para pipelines de producción, la limpieza suele vivir como transformaciones dentro de dbt o Spark, apoyada en las reglas definidas con las herramientas de data quality que ya uses para detección.
El error más común
Limpiar sin corregir la causa raíz. Si cada semana llegan los mismos duplicados desde el mismo sistema origen, el problema no es de limpieza sino de proceso de captura. Un buen programa de data cleansing incluye siempre un ciclo de retroalimentación hacia el origen del dato, no solo un parche recurrente aguas abajo.