Hay una pregunta que el catálogo de esta academia lleva meses respondiendo por partes: el curso de Fine-tuning demostró que el dataset es el modelo; el curso de RAG mostró que la calidad del retrieval decide la calidad de la respuesta; el de MLOps cubrió el ciclo de vida del modelo; y la Metodología de casos de uso puso “¿datos hoy?” como filtro eliminatorio. Todos apuntan al mismo eslabón y ninguno lo desarrolla: cómo se consiguen, mueven, limpian y sirven los datos. Ese eslabón es este curso.

La premisa que lo justifica es incómoda y tiene fuente: en un proyecto de IA real, el modelado es la parte chica. El tiempo de ingeniería se va en encontrar los datos, entenderlos, moverlos, limpiarlos, validarlos y mantener vivo el flujo que los entrega. El “80%” del título viene de la encuesta CrowdFlower de 2016 (60% limpiando y organizando + 19% recolectando, sobre unos 80 data scientists); las encuestas posteriores y más amplias lo ubican entre un tercio y la mitad del tiempo (Anaconda: 45% en 2020, ~38% en 2022). La cifra exacta se discute; lo que ninguna encuesta discute es que es la parte más grande del trabajo — y la que nadie pone en la demo. Y en la era de los modelos fundacionales, esa asimetría se agudizó: el modelo se arrienda por API; tu pipeline de datos no lo vende nadie.

La tesis del módulo

El modelo es commodity; el pipeline de datos es el foso. Cualquier competidor accede al mismo catálogo de modelos que tú — lo que no puede copiar es el flujo confiable que convierte tus fuentes desordenadas en datos limpios, frescos y servidos donde el modelo los necesita. Por eso el enfoque data-centric no es una preferencia metodológica: es la consecuencia lógica de que la única pieza diferenciable del stack sea la tuya.

Data-centric: mejorar los datos rinde más que mejorar el modelo

El enfoque data-centric (centrado en datos) invierte la pregunta habitual. En vez de “¿qué modelo/prompt/hiperparámetro mejora el resultado?” (model-centric), pregunta “¿qué mejora de los datos mejora el resultado?” — y en la práctica industrial, con el modelo ya siendo bueno, la segunda palanca suele rendir más:

Palanca	Model-centric	Data-centric
Clasificador se equivoca en facturas	Probar otro modelo, ajustar prompt	Descubrir que el 30% de las facturas de entrenamiento estaban mal etiquetadas
RAG responde desactualizado	Cambiar el LLM	El pipeline de ingesta corre semanal y los documentos cambian a diario
Fine-tuning no mejora	Más épocas, otro base	Deduplicar el dataset (el 40% eran casi-copias)
Modelo tabular degrada	Reentrenar más seguido	La fuente cambió un campo y nadie lo detectó (módulo 7)

La columna derecha es sistemáticamente menos glamorosa y más rentable — y cada una de sus filas es un módulo de este curso. La lección inaugural: cuando un sistema de IA falla en producción, la primera hipótesis es de datos, no de modelo. El que sabe diagnosticar y arreglar esa columna es el perfil que este curso construye.

Qué hace de verdad un data engineer en un equipo de IA

El rol, sin romanticismo: construir y operar los flujos que llevan datos desde donde nacen (sistemas transaccionales, APIs, archivos, eventos) hasta donde se usan (el warehouse del analista, el dataset del entrenamiento, el índice del RAG, el feature store del modelo en producción) — con frescura, calidad y costo bajo control. Sus entregables no son dashboards ni modelos: son pipelines que no se rompen a las 3 AM y, cuando se rompen, avisan antes de que el negocio lo note.

   EL TERRITORIO DE ESTE CURSO

  fuentes         el pipeline            consumidores
  ┌─────────┐     ┌──────────────────┐     ┌─────────────┐
  │ sistemas│ ──► │ ingesta          │ ──► │ analítica   │
  │ APIs    │     │ almacenamiento   │     │ dataset de  │
  │ archivos│     │ transformación   │     │ entrenamien.│
  │ eventos │     │ calidad·orquesta │     │ índice RAG  │
  └─────────┘     └──────────────────┘     │ features    │
                   módulos 3-7             └─────────────┘
                                            módulos 8-11

El mapa del curso

Bloque	Módulos	Qué construyes
Básico (1-4)	La tesis · el mapa del pipeline · ingesta (batch, streaming, CDC) · dónde vive el dato (lake, warehouse, lakehouse)	El esqueleto: datos entrando y almacenados con criterio
Intermedio (5-8)	Transformación (ELT y dbt) · orquestación (Airflow/Dagster) · calidad y contratos · etiquetado y datos de entrenamiento	El pipeline confiable: transformado, agendado, validado
Avanzado (9-12)	Datos para LLM (dedup, PII, sintéticos) · el pipeline de un RAG a escala · features y tiempo real · gobernanza, linaje y costo	La especialización IA: los pipelines que alimentan modelos

El caso hilo conductor — porque este catálogo no abandona a sus personajes: la empresa del triaje de correos y el cotizador (la Metodología) ahora necesita alimentarlos: los correos históricos y sus clasificaciones para mejorar el triaje (dataset de entrenamiento, módulo 8), el catálogo y las cotizaciones para el cotizador (RAG, módulo 10), y los reportes de operación que el negocio pide (analítica, módulos 4-5). Tres consumidores, un pipeline — lo iremos construyendo pieza a pieza.

Frontera con los cursos vecinos (para no leer dos veces lo mismo)

MLOps cubre el ciclo del modelo (entrenar, versionar, desplegar, monitorear, reentrenar); este curso, el ciclo del dato que lo alimenta. Se tocan en el feature store (módulo 11 ↔ mlops-06) y en el versionado de datos (mlops-02): donde se toquen, enlazamos en vez de repetir.
RAG enseña la calidad del retrieval (chunking, embeddings, búsqueda); el módulo 10 de este curso cubre lo que RAG asume resuelto: la infraestructura de ingesta que mantiene ese índice fresco, completo y barato a escala.
Fine-tuning estableció qué dataset necesitas; los módulos 8-9 cubren el pipeline y tooling para armarlo.
ML clásico modela datos tabulares; este curso explica cómo llegaron limpios a esa tabla.

Errores comunes

Contratar el modelo y descubrir que faltan los datos. El orden del fracaso clásico. La Metodología puso “¿datos hoy?” como filtro eliminatorio exactamente por esto; este curso es lo que haces cuando la respuesta fue “casi”.
Tratar el pipeline como un script. El script que movió los datos una vez no es un pipeline: no reintenta, no valida, no avisa, no es reproducible. La diferencia entre ambos es el contenido de los módulos 5-7.
Diagnosticar fallas de IA como fallas de modelo. “El modelo empeoró” casi siempre es “los datos cambiaron”. La primera hipótesis es de datos — y para sostenerla necesitas la observabilidad de datos que iremos armando.
Confundir data engineering con big data. El foso no es el tamaño: un pipeline confiable de 50.000 correos vale más que un cluster mal operado de petabytes. Las herramientas de este curso escalan hacia arriba; el criterio aplica desde el primer gigabyte.
Saltarse este eslabón “porque usamos APIs de LLM”. El modelo arrendado necesita contexto, ejemplos, índices y evaluación — todos hechos de datos tuyos, movidos por pipelines tuyos. La API te ahorró entrenar, no el 80%.

La frase para llevarse

“Todos tus competidores llaman a los mismos modelos por las mismas APIs. Lo único del stack que es tuyo — y lo único que no pueden copiar — es el flujo que convierte tu desorden en datos limpios, frescos y servidos a tiempo. El modelo es commodity; el pipeline es el foso.”

Qué viene

Módulo 2: el mapa del pipeline. Antes de las herramientas, la anatomía: las cinco etapas que todo flujo de datos tiene (fuentes → ingesta → almacenamiento → transformación → servicio), qué decisión vive en cada una, y el vocabulario que ordena el resto del curso — batch vs. streaming, crudo vs. curado, push vs. pull. El diagrama que vas a dibujar en toda pizarra de aquí en adelante.

Data Engineering — Módulo 1: los datos son el 80% del trabajo