Qué significa realmente “calidad de datos”

“Nuestros datos no tienen buena calidad.”

Escuchas esto constantemente en reuniones. El problema es que casi nadie dice exactamente qué significa eso. ¿Son datos incompletos? ¿Inconsistentes? ¿Viejos? ¿Irrelevantes? ¿Todo a la vez?

La frase “calidad de datos” se usa como paraguas para tapar agujeros muy distintos, y ese es precisamente el problema. En Machine Learning, los modelos no “sienten” la calidad de datos como concepto abstracto. Lo que sienten es:

• Un DataFrame con 40% de NaNs que lo inutiliza.
• Emails con formato inconsistente que no puedes parsear.
• IDs de usuario duplicados que rompen la lógica.
• Fechas registradas en tres formatos diferentes en la misma columna.
• Datos de hace 2 años que no reflejan la realidad actual.

Cada uno es un problema distinto, con consecuencias distintas, que requiere soluciones distintas.

En esta entrada vamos a desglosar qué es realmente la calidad de datos: no una métrica única, sino seis dimensiones independientes que necesitas evaluar por separado.

Las 6 dimensiones de la calidad de datos

No todas importan igual para cada caso, pero necesitas conocerlas todas.

Completitud: ¿falta información?

Definición: ¿hay datos donde debería haberlos?

En la práctica: ¿cuántos valores nulos, en blanco, o “unknown” hay en cada columna?

import pandas as pd

df = pd.read_csv("clientes.csv")

# Completitud: qué % de datos no están en blanco
completitud = (1 - df.isnull().sum() / len(df)) * 100
print(completitud)

# Output:
# nombre           100.0%
# email             85.0%  ← 15% missing
# telefono          62.0%  ← 38% missing
# fecha_registro    10.0%  ← 90% missing

¿Por qué importa?

En Analytics Lane

Por qué migrar tus proyectos TypeScript a ES Modules en 2026

Depende de la columna:

• Si nombre tiene 100%, bien.
• Si email tiene 85%, quizás está bien (usuarios sin email registrado). Lo mismo aplica para telefono.
• Si fecha_registro tiene 10%, es un problema grave: no sabes cuándo llegó ese usuario.

¿Cómo lo arreglas?

• Imputación: rellenar valores faltantes (media, moda, forward fill).
• Exclusión: eliminar filas con demasiados NaNs.
• Investigación: a veces los NaNs significan algo (usuario anónimo, opcionalmente no respondió).

La trampa: una columna 100% completa puede tener muchos valores “unknown” o 0 que son en realidad valores faltantes disfrazados.

# Falso positivo: parece completo pero no lo es
df["edad"].value_counts()
# 0         4523  ← ¿0 años? Probablemente "desconocido"
# 25        1234
# 30         892

Consistencia: ¿están los datos en el mismo formato?

Definición: ¿el mismo concepto tiene representaciones diferentes?

En la práctica: valores que significan lo mismo pero se escriben distinto.

# Emails inconsistentes
emails = [
    "[email protected]",
    "[email protected]",
    "carlos @gmail.com",  # espacio
    "ana @ gmail . com",  # espacios
]

# Fechas inconsistentes
fechas = [
    "2024-01-15",
    "15/01/2024",
    "01-15-2024",
    "enero 15, 2024",
]

# Teléfonos inconsistentes
telefonos = [
    "+34 666 123456",
    "666123456",
    "+34666123456",
    "(+34) 666-123456",
]

Cada uno representa lo mismo pero de forma distinta. Cuando buscas [email protected], no encuentras [email protected].

¿Por qué importa?

Porque:

• Las búsquedas exactas fallan (df[df['email'] == '[email protected]'] no encuentra [email protected]).
• Duplicados falsos: la misma persona aparece dos veces bajo formatos distintos.
• Validación imposible: no puedes verificar que sea un email válido si está “carlos @gmail.com”.

¿Cómo lo arreglas?

# Normalizar emails
df['email'] = df['email'].str.strip().str.lower()

# Normalizar fechas
df['fecha'] = pd.to_datetime(df['fecha'], format='mixed')  # intenta varios formatos

# Normalizar teléfonos
df['telefono'] = df['telefono'].str.replace(' ', '').str.replace('-', '')

Validez: ¿están los datos en el rango esperado?

Definición: ¿tiene sentido cada valor individual?

En la práctica: valores que técnicamente existen pero no deberían estar ahí.

usuarios = {
    'nombre': ['Juan', 'María', 'Carlos', '???'],
    'edad': [25, 150, -5, 32],  # 150 años y -5 años ¿?
    'email': ['[email protected]', 'maria@gmail', '[email protected]', 'noesmail'],  # falta .com
    'salario': [30000, 1000000000, -5000, 45000],  # 1 billón y negativo
}

df = pd.DataFrame(usuarios)

¿Por qué importa?

• Edad 150: un error en input, un dato de alguien muy viejo que no debería contar, o un test.
• Email sin dominio: no es un email válido.
• Salario negativo: ¿una devolución? ¿un error? ¿deuda?

Si entrenas un modelo de predicción de ingresos con estos datos, aprenderá patrones rotos.

¿Cómo lo arreglas?

# Definir rangos válidos
edad_valida = (df['edad'] >= 18) & (df['edad'] <= 100)
salario_valido = (df['salario'] > 0)

# Filtrar
df_limpio = df[edad_valida & salario_valido]

# O marcar como sospechoso
df['edad_valida'] = edad_valida

Precisión/Exactitud: ¿son correctos los datos?

Definición: ¿refleja el dato la realidad?

En la práctica: un valor que está bien formateado, es válido, pero es falso.

# El email está bien formateado y es válido, pero no es el de Juan
{
    'nombre': 'Juan García',
    'email': '[email protected]'  # Email correcto pero no es de Juan
}

# La edad es un número válido (25-100), pero es falsa
{
    'nombre': 'Carlos',
    'edad': 45  # Pero en realidad tiene 35
}

# La ubicación es válida pero es de hace 5 años
{
    'usuario_id': 123,
    'ciudad': 'Madrid',  # Pero se mudó a Barcelona el año pasado
}

Nota la diferencia con validez:

• Validez: “¿tiene sentido el formato?” (¿es un email válido? ¿la edad es un número entre 0-120?)
• Precisión: “¿es verdad lo que dice?” (¿es realmente el email de esa persona? ¿tiene realmente esa edad?)

¿Por qué importa?

Es el más difícil de detectar. Un modelo puede entrenarse sin problemas, pero hará predicciones basadas en mentiras.

¿Cómo lo arreglas?

Es complicado. Necesitas:

• Validación cruzada: contrastar con otras fuentes (¿ese email existe? ¿responde?).
• Comparación temporal: ¿cambió demasiado entre dos registros?
• Detección de anomalías: ¿ese valor es un outlier que no encaja?

# Detectar anomalías de edad (si casi nadie tiene 45, pero algunos sí, es raro)
import numpy as np

z_scores = np.abs((df['edad'] - df['edad'].mean()) / df['edad'].std())
anomalias = z_scores > 3  # Más de 3 desviaciones estándar

df[anomalias]  # Revisa estos manualmente

Unicidad: ¿hay duplicados?

Definición: ¿hay registros duplicados o casi-duplicados?

En la práctica: el mismo usuario, transacción, o evento aparece dos o más veces.

usuarios = pd.DataFrame({
    'id': [1, 2, 2, 3, 4, 4],
    'nombre': ['Juan', 'María', 'María', 'Carlos', 'Ana', 'Ana'],
    'email': ['[email protected]', '[email protected]', '[email protected]', 
              '[email protected]', '[email protected]', '[email protected]']
})

# ID duplicados: 2 y 4 aparecen dos veces
duplicados = usuarios[usuarios.duplicated(subset=['id'], keep=False)]
print(duplicados)

Variantes:

• Duplicados exactos: fila idéntica repetida.
• Duplicados de clave: mismo ID pero otros valores ligeramente distintos.
• Casi-duplicados: [email protected] vs [email protected] (¿mismo usuario?)

¿Por qué importa?

• Sesgo en análisis: cuentas a Juan 3 veces en lugar de 1.
• Problemas de integridad: violas la lógica de tu BD (ID único debería serlo).
• Modelos entrenados mal: el algoritmo “ve” patrones repetidos que no existen.

¿Cómo lo arreglas?

# Eliminar duplicados exactos
df_limpio = df.drop_duplicates()

# Eliminar duplicados en columna específica (mantén el primero)
df_limpio = df.drop_duplicates(subset=['id'], keep='first')

# Casi-duplicados: necesitas lógica custom
# (es la más complicada)

Integridad/Actualidad: ¿están los datos vigentes y conectados?

Definición: ¿los datos son actuales y coherentes con el resto del sistema?

En la práctica: dos cosas.

Parte A: Actualidad

# Datos viejos
df['fecha_registro'].max()  # 2023-03-15
df['fecha_actualizacion'].max()  # 2024-06-30

# Si hoy es 2026, tus datos tienen entre 2 y 3 años
# ¿reflejan la realidad actual?

Trabajas con datos que no reflejan el ahora. Si predices demanda de clientes basándote en datos de 2021, probablemente falles.

Parte B: Integridad referencial

# Tabla de usuarios
usuarios = pd.DataFrame({
    'id': [1, 2, 3],
    'nombre': ['Juan', 'María', 'Carlos']
})

# Tabla de órdenes
ordenes = pd.DataFrame({
    'id': [101, 102, 103],
    'usuario_id': [1, 2, 999]  # ¿usuario_id 999? No existe
})

# usuario_id 999 rompe la integridad: ¿de quién es esa orden?

¿Por qué importa?

• Actualidad: modelos entrenados con datos viejos no predicen bien el presente.
• Integridad referencial: si la orden no sabe a quién pertenece, tus análisis están incompletos o incorrectos.

¿Cómo lo arreglas?

# Actualidad: revisa fechas, agenda rescrapeos
print(df['fecha_ultima_actualizacion'].max())

# Integridad referencial: encuentra huérfanos
usuarios_validos = set(usuarios['id'])
ordenes_invalidas = ordenes[~ordenes['usuario_id'].isin(usuarios_validos)]
print(ordenes_invalidas)  # Qué órdenes apuntan a usuarios inexistentes

Las 6 dimensiones en una tabla

La verdad incómoda: no todas importan igual

Aquí está lo que tu jefe probablemente no te dice:

• Completitud y consistencia son las que más destruyen análisis. Si tus datos están llenos de NaNs o en formatos inconsistentes, estás perdido. Son relativamente fáciles de arreglar.
• Unicidad arruina análisis estadísticos: sesga conteos, duplica pesos, enseña al modelo patrones falsos. Es más difícil de arreglar.
• Validez es importante pero es un chequeo manual: verificar que edad está entre 0 y 120 es mecánico.
• Precisión es el enemigo invisible. Podría ser que tus datos estén “limpios” en todas las otras dimensiones pero sean falsos. Es muy difícil detectar. A veces solo te das cuenta cuando tu modelo falla en producción.
• Integridad depende de tu arquitectura. Si tienes datos duplicados en diferentes sistemas, necesitas reconciliar. Si datos envejecen rápido, necesitas una pipeline de actualización.

El framework: cómo evaluar la calidad de TUS datos

No existe una métrica única de “calidad de datos”. Lo que importa depende del problema.

Paso 1: Identifica qué dimensiones importan

# Para un modelo predictivo de churn
importancia = {
    'completitud': 'CRÍTICA',      # sin datos no predices
    'consistencia': 'CRÍTICA',      # features ruidosas = predicciones ruidosas
    'validez': 'ALTA',              # outliers pueden engañar al modelo
    'precisión': 'CRÍTICA',         # si el target es falso, entrenas basura
    'unicidad': 'ALTA',             # duplicados sesgaban el modelo
    'integridad': 'MEDIA',          # mientras mantengas coherencia entre tablas
}

Paso 2: Cuantifica cada una

# Completitud
completitud_por_columna = (1 - df.isnull().sum() / len(df)) * 100

# Consistencia (custom, depende de cada columna)
emails_validos = df['email'].str.contains(r'^[\w\.-]+@[\w\.-]+\.\w+$')
consistencia_email = (emails_validos.sum() / len(df)) * 100

# Unicidad
duplicados = df.duplicated().sum()
unicidad = ((len(df) - duplicados) / len(df)) * 100

# Integridad
datos_vigentes = (df['fecha_actualizacion'] > '2024-01-01').sum() / len(df) * 100

Paso 3: Decide qué toleras

umbrales = {
    'completitud_minima': 90,      # Tolerarás máx 10% NaN
    'consistencia_minima': 95,     # Tolerarás máx 5% valores mal formateados
    'duplicados_maximos': 0,       # Cero tolerancia
    'datos_vigentes_minima': 80,   # Máx 20% datos viejos
}

# Verifica
es_bueno = (completitud_promedio >= umbrales['completitud_minima'] and
            consistencia_email >= umbrales['consistencia_minima'] and
            duplicados <= umbrales['duplicados_maximos'] and
            datos_vigentes >= umbrales['datos_vigentes_minima'])

if not es_bueno:
    print("❌ Datos no pasan control de calidad")
else:
    print("✅ Calidad aceptable")

El overhead: por qué “calidad de datos” es en realidad un problema de ingeniería

“Calidad de datos” suena pasivo, como si los datos tuvieran mala suerte. La verdad es que es un problema de diseño e ingeniería:

• Completitud: tu formulario no fuerza campos obligatorios, o la BD permite NULLs en columnas críticas.
• Consistencia: no hay normalización en input, o diferentes sistemas escriben datos distintos.
• Validez: validación débil en frontend y backend.
• Precisión: nadie verifica con la realidad, o los datos entran de forma poco confiable.
• Unicidad: no hay constraints de unicidad en la BD, o no hay deduplicación.
• Integridad: falta mantenimiento, datos se replican a sistemas desactualizados, o no hay sincronización.

Solución: es un trabajo de data engineering, no solo de analysis. Necesitas:

• Validación en entrada (no aceptes emails inválidos).
• Normalización automática (lowercase, trim, formatos estándar).
• Constraints en BD (unicidad, no nulls, foreign keys).
• Pipelines de actualización (datos no envejecen).
• Monitoreo continuo (alertas cuando algo baja de calidad).

Conclusiones

“Calidad de datos” no es una cosa. Son seis cosas distintas, cada una con su detección, coste de arreglo, e impacto.

Lo importante es que cuando alguien diga “nuestros datos no tienen buena calidad”, preguntes:

“¿Habla de completitud, consistencia, validez, precisión, unicidad o integridad? Porque eso cambia cuál es el problema y cómo lo solucionamos.”

Probablemente no sepa la respuesta. Pero tú sí.

Imagen de Pete Linforth en Pixabay