Por qué la calidad de datos es tu trabajo más importante

### La historia que me enseñó todo sobre calidad de datos

Año 2019. Empresa mediana de e-commerce, 200 empleados. El equipo de datos lleva 6 meses construyendo un pipeline hermoso: ingesta de pedidos en tiempo casi-real, transformación con Pandas, carga en el data warehouse, dashboard en Tableau que se actualiza cada hora. Todo funciona. Todo es bonito. El CTO está orgulloso.

Un martes de noviembre, el CEO presenta al consejo directivo el plan de expansión a tres nuevas ciudades. Los datos dicen que Barcelona, Valencia y Sevilla son las ciudades con más demanda. El consejo aprueba una inversión de 2.4 millones de euros. Abren almacenes, contratan personal, lanzan campañas de marketing.

Tres meses después, los números no cuadran. Las ventas en esas ciudades son un 60% menores de lo esperado. ¿Qué pasó? Un ingeniero junior investiga y descubre el horror: el campo "ciudad" del sistema de pedidos tenía 1.2 millones de registros con el valor NULL. El sistema de BI, en vez de excluirlos, los agrupaba en "Otros". Pero una actualización del pipeline de ETL en septiembre empezó a asignar la ciudad del almacén de origen cuando el campo era NULL. Resultado: los pedidos de toda España aparecían concentrados en las tres ciudades donde tenían almacén.

Nadie lo detectó. Ni una alerta. Ni un test. Ni una validación. El pipeline funcionaba técnicamente: no había errores de ejecución, no había logs de error, el dashboard se actualizaba puntualmente. Pero los datos eran mentira. Y la empresa tomó una decisión de 2.4 millones basada en esa mentira.

### GIGO: Garbage In, Garbage Out

Existe un principio en informática que tiene más de 60 años: GIGO — Garbage In, Garbage Out. Basura entra, basura sale. Da igual lo sofisticado que sea tu pipeline, lo bonito que sea tu dashboard, lo caro que sea tu data warehouse. Si los datos que entran son incorrectos, incompletos o inconsistentes, el resultado será igualmente incorrecto, incompleto o inconsistente. Pero con un barniz de legitimidad que lo hace MÁS peligroso que no tener datos.

Piensa en esto: ¿confiarías en un termómetro que siempre marca 36.5°C sin importar si tienes fiebre? Un dashboard que siempre muestra datos (aunque sean incorrectos) es exactamente eso — un instrumento roto que da falsa sensación de seguridad. Es PEOR que no tener instrumento, porque sin termómetro al menos sabes que no sabes. Con un termómetro roto, crees que sabes.

### La analogía de la fábrica: el inspector de calidad

Imagina una fábrica de automóviles. Los materiales llegan de proveedores externos (acero, plástico, chips electrónicos). ¿La fábrica simplemente los mete en la línea de producción sin mirarlos? Absolutamente no. Hay inspectores de calidad que verifican cada lote: ¿el acero tiene la dureza correcta? ¿Las dimensiones son las especificadas? ¿El chip pasa las pruebas eléctricas? Si un lote no cumple, se rechaza ANTES de que entre en la línea de producción.

Tú eres ese inspector de calidad, pero para datos. Tu "fábrica" es el pipeline de datos. Los "materiales" son los CSVs, APIs, bases de datos que alimentan tu sistema. Y tu trabajo es asegurarte de que lo que entra cumple con los estándares ANTES de que se convierta en un dashboard, un informe o una decisión de negocio.

1# La diferencia entre un pipeline que "funciona" y uno que VALIDA
2import pandas as pd
3
4pedidos = pd.read_csv("pedidos_hoy.csv")
5
6# ❌ Sin validación: carga y sigue (funciona... hasta que un día no)
7cargar_en_warehouse(pedidos)
8
9# ✅ Con validación: comprueba ANTES de cargar
10assert len(pedidos) > 0, "El fichero llegó vacío"
11assert pedidos['importe'].min() >= 0, f"Hay importes negativos: {pedidos['importe'].min()}"
12assert pedidos['pedido_id'].is_unique, f"Hay {pedidos['pedido_id'].duplicated().sum()} duplicados"
13assert pedidos['ciudad'].notna().all(), f"{pedidos['ciudad'].isna().sum()} pedidos sin ciudad"
14
15# Si llegamos aquí, los datos pasan el mínimo
16cargar_en_warehouse(pedidos)

### El coste REAL de la mala calidad de datos

Gartner estima que la mala calidad de datos cuesta a las organizaciones una media de 12.9 millones de dólares al año. IBM calculó que las empresas estadounidenses pierden 3.1 billones (trillones americanos) de dólares anuales por problemas de calidad de datos. Pero esos son números abstractos. Veamos costes concretos que he visto en mi carrera:

• ▹Emails de marketing enviados a clientes muertos o inexistentes porque el campo "activo" no se validaba → pérdida de reputación + sanciones GDPR
• ▹Un informe fiscal con importes duplicados porque el pipeline de ingesta se ejecutó dos veces sin control de idempotencia → multa de Hacienda
• ▹El modelo de pricing calculó descuentos del 99% para 10.000 clientes porque un campo de porcentaje admitía valores > 100 → pérdida directa de 340.000€ en un fin de semana
• ▹El dashboard de retención mostraba un churn del 2% cuando el real era del 15% porque los clientes "eliminados" se excluían del cálculo en vez de contarse como bajas → decisiones estratégicas erróneas durante 8 meses

### Más horror stories: el hall de la infamia

No estamos solos en esto. Empresas mucho más grandes y con más recursos han sufrido desastres de calidad de datos:

• ▹NASA Mars Climate Orbiter (1999): se estrelló contra Marte porque un equipo usaba unidades métricas y otro imperiales. Un "error de datos" de 327 millones de dólares.
• ▹Knight Capital (2012): un despliegue incompleto activó código dormido que ejecutó operaciones bursátiles erróneas durante 45 minutos, perdiendo 440 millones de dólares. La empresa no sobrevivió como firma independiente: recibió un rescate de 400 M$ y en 2013 la absorbió Getco.
• ▹Public Health England (2020): un Excel en formato .xls truncó 15.841 registros de tests COVID porque superó el límite de filas del formato antiguo. Miles de contactos no fueron rastreados durante semanas — no fue un hospital, fue el pipeline de datos de un país entero.

### ¿Por qué esta skill te separa del resto?

Aquí va una verdad incómoda: la mayoría de ingenieros de datos junior construyen pipelines que FUNCIONAN pero no VALIDAN. Saben hacer ETL, saben Pandas, saben SQL. Pero no ponen ni un solo check de calidad. Es como construir un puente sin inspección: probablemente aguante... hasta que un día no aguante.

Un ingeniero mid/senior hace algo fundamentalmente diferente: ASUME que los datos llegarán mal. No es pesimismo — es experiencia. Después de ver suficientes NULLs inesperados, suficientes duplicados inexplicables, suficientes tipos de datos que cambian sin aviso... aprendes que la pregunta no es SI los datos tendrán problemas, sino CUÁNDO. Y tu trabajo es tener las defensas listas para ese momento.

### ¿Qué vamos a aprender en esta skill?

En las próximas 7 lecciones vamos a transformarte del ingeniero que dice "el pipeline funciona" al ingeniero que dice "el pipeline funciona Y los datos son correctos". Este es el mapa:

1. 01.Las 5 dimensiones de calidad de datos: un framework para pensar sobre qué puede salir mal
2. 02.Validación con Python puro: funciones, assertions y decoradores que puedes usar HOY
3. 03.Great Expectations: el framework profesional que usan empresas como Spotify, GitHub y Shopify
4. 04.Contratos de datos: acuerdos formales entre quien produce y quien consume datos
5. 05.Alertas y monitorización: enterarte del problema antes que el CEO
6. 06.Proyecto final: un pipeline completo con validación, alertas y reportes de calidad

Al terminar esta skill, nunca más construirás un pipeline sin validación. No porque sea una obligación, sino porque habrás interiorizado que es la única forma responsable de trabajar con datos. Vamos a ello.