Data Engineering para IA: por qué tus datos importan más que el modelo
Los proyectos de IA que fracasan rara vez es por el modelo elegido. Casi siempre es por datos sucios, inconsistentes o inaccesibles. Aquí cómo prepararte.
La industria gasta energía debatiendo GPT vs Claude vs Llama. La realidad: si tus datos están sucios, ningún modelo va a rescatar el proyecto. Y si tus datos están limpios, casi cualquier modelo decente funciona.
La regla del 80/20 de proyectos de IA
En proyectos empresariales de IA, el 60-80% del esfuerzo real va a data engineering: ingesta, limpieza, estructuración, indexación, monitoreo. Solo el 20-40% es entrenar o conectar modelos. Equipos que no presupuestan esto se quedan a medio camino.
Las 4 capas del data stack para IA
1. Ingesta (Ingestion)
Traer datos desde todas las fuentes: ERPs (SAP, Oracle, Microsoft Dynamics), CRMs (HubSpot, Salesforce), hojas de cálculo, APIs de proveedores, bases operativas, eventos de producto. Herramientas: Airbyte, Fivetran, custom Python pipelines.
2. Transformación
Limpiar, estructurar, deduplicar, normalizar. Generar modelos dimensionales (hechos + dimensiones) para analytics + modelos wide para ML. Herramienta dominante: dbt (versionado, tests, documentación).
3. Almacenamiento
Warehouse analítico (Snowflake, BigQuery, Redshift, Databricks) para BI + ML features. Vector DB (Pinecone, pgvector, Weaviate) para embeddings de documentos propietarios usados en RAG.
4. Serving
APIs de baja latencia para que aplicaciones (agentes, dashboards, productos) consuman los datos procesados. Feature stores (Feast) para ML. Cachés (Redis) para queries recurrentes.
Los 5 problemas de datos que matan proyectos de IA
Duplicados silenciosos
El mismo cliente existe 3 veces en el CRM con variaciones del nombre. El modelo entrena con el duplicado, predice mal, y nadie entiende por qué. Solución: reglas de deduplicación explícitas + monitoreo de duplicados nuevos.
Datos faltantes no declarados
El 40% de los registros no tienen un campo crítico, pero nadie lo sabe porque no está documentado. El modelo aprende a ignorar el campo o a usar NULL como señal, generando predicciones sesgadas. Solución: tests de data quality automáticos (dbt tests, Great Expectations).
Historiales inconsistentes
El campo "tipo de cliente" cambió de 3 categorías a 7 hace 2 años. Los datos antiguos están en el esquema viejo, los nuevos en el nuevo. El modelo no sabe. Solución: tablas de equivalencia y versionado de schemas.
Timezone y formatos de fecha
México tiene 3 zonas horarias. Las fechas vienen en UTC del CRM, en hora local del ERP, y el modelo predice churn con diferencia de 6 horas entre eventos que en realidad fueron simultáneos. Solución: normalización a UTC + flag de timezone del evento original.
Schema drift sin alertas
El equipo de producto agregó un campo en la tabla de transacciones. El pipeline sigue funcionando pero ignora el campo. Tres meses después, nadie recuerda. Solución: monitoreo de cambios de schema + alertas.
Patrón recomendado para PyMEs mexicanas
Stack mínimo viable para una empresa 50-250 personas que arranca con IA:
- PostgreSQL (o el warehouse que ya uses) como fuente de verdad
- dbt + GitHub Actions para transformaciones versionadas
- Airbyte (gratis en open source) para ingesta desde SaaS comunes
- pgvector en Postgres para embeddings (evitas Pinecone los primeros 6-12 meses)
- Metabase o Lightdash para dashboards
- Great Expectations para tests de data quality
Este stack cuesta $200-$800 USD/mes en infra para volúmenes de PyME, versus $2k-$5k+ USD/mes de soluciones enterprise. Escalas cuando lo justifique el volumen.
Orden correcto para construir
- 1Identifica 1-2 casos de uso de IA específicos que quieres habilitar
- 2Mapea qué datos necesitas para esos casos de uso (ni más, ni menos)
- 3Construye pipelines SOLO para esos datos — no intentes hacer un data warehouse completo de una vez
- 4Agrega tests de data quality antes de usar los datos en producción
- 5Despliega el caso de uso de IA encima
- 6Itera: agrega fuentes y casos de uso uno por uno
El error más común es intentar construir "el data warehouse completo" antes de tocar IA. Dura 18 meses, consume presupuesto, y cuando termina el negocio ya cambió.
Señales de que tu data foundation está lista
- Puedes contestar tus KPIs operativos básicos en <5 minutos con datos, no intuición
- Tu equipo de datos puede responder "¿cuál es la fuente de verdad de X?" sin dudar
- Hay tests automáticos que detectan anomalías en datos antes de que lleguen a dashboards
- Documentación de tablas y campos existe y se actualiza
- Hay política clara de quién puede acceder a qué datos
Si no marcas 3+ de los 5 anteriores, dedica los próximos 2-3 meses a data engineering antes de IA ambicioso. Te saldrá 10x más barato que intentar hacer ambos en paralelo.
Lo que también te preguntas
¿Necesito un data warehouse para hacer IA?
No obligatoriamente. Para casos acotados puedes hacer IA directamente sobre bases operativas con pipelines puntuales. Para casos complejos o múltiples, sí — el warehouse evita duplicación de esfuerzo y da una fuente de verdad.
¿Qué warehouse elegir: Snowflake, BigQuery o Databricks?
Snowflake si ya pagas enterprise y quieres analytics puros. BigQuery si ya estás en Google Cloud. Databricks si combinas analytics + ML pesado. Postgres + dbt si arrancas con presupuesto pequeño. No hay respuesta universal — depende del contexto.
¿Quién hace el data engineering: mi equipo interno o un proveedor?
Ideal: un híbrido. Proveedor externo en fase de construcción (3-6 meses), con hand-off y capacitación a equipo interno que lo mantiene después. Consultorías que construyen y se van dejan deuda técnica invisible.