Por qué la IA hace al Data Engineer más necesario, no menos

Todos quieren un LLM encima de sus datos. El problema: si los datos son un desastre, la IA responde con confianza y se equivoca igual. Lo que nadie quiere escuchar.

Hay una demo que todos conocen. El CEO la vio en una conferencia, o alguien del equipo la replicó en un Jupyter notebook: le haces una pregunta en lenguaje natural a tu warehouse y el LLM te responde con una tabla prolija, un número concreto, a veces hasta un gráfico.

Impresionante.

Ahora intenta hacer eso con los datos reales de tu empresa. No el dataset de demo —tus tablas, tus columnas, las queries heredadas de 2019 que nadie toca porque nadie las entiende del todo.

Ahí empieza el problema.

¿Por qué el LLM no entiende tu negocio aunque entienda el lenguaje?

Esa distinción parece obvia pero tiene consecuencias enormes.

Cuando apuntas un LLM a tu warehouse, el modelo lee los nombres de las tablas, los nombres de las columnas, los comentarios que (probablemente no) existen en el esquema, y los ejemplos de datos que puede ver. Con eso construye su interpretación de qué significa cada cosa.

Si tu tabla se llama ventas_v3_final_USAR_ESTA, el LLM va a intentar inferir qué hay ahí. Si tu columna monto puede ser neto o bruto dependiendo del contexto y nadie lo documentó, el modelo va a elegir una interpretación. Con mucha confianza. Y va a estar mal la mitad del tiempo.

El problema no es la IA. El problema es que le estás dando datos que ni tú entiendes del todo.

¿Cómo se ve esto en la práctica?

Una empresa quiere hacer “chat con sus datos”. Contratan a alguien para el modelo, conectan el LLM al warehouse, y en la primera semana ya tienen respuestas raras.

Preguntan cuánto vendieron el mes pasado. El LLM responde con un número que no coincide con el del reporte de siempre. ¿Cuál está bien? Nadie sabe —porque hay tres columnas que podrían ser “ventas” y ninguna tiene documentación.

Preguntan quiénes son los 10 mejores clientes. El modelo devuelve una lista que incluye cuentas de prueba y clientes que se dieron de baja. Nadie filtró eso en el modelo —estaba en el conocimiento tácito del equipo que hacía los reportes a mano.

Preguntan por la rentabilidad por producto. El LLM arma algo, pero la lógica de negocio para calcular el margen real estaba enterrada en una query de 200 líneas que alguien escribió hace tres años y que hoy nadie entiende del todo.

En cada caso, la IA funcionó perfectamente. El problema era lo que le dieron de comer.

¿Qué trabajo sigue siendo necesario aunque uses IA?

Acá está el punto que el hype ignora: todo lo que hace que un LLM funcione bien sobre datos de negocio requiere trabajo de data engineering. No menos que antes. Más.

Alguien tiene que:

Diseñar el modelo de datos para que sea interpretable. No solo correcto —interpretable. Nombres claros, una sola fuente de verdad para cada métrica, tablas que representen conceptos de negocio y no artefactos técnicos de sistemas legacy. El resultado: los analistas hacen preguntas en segundos en lugar de esperar a que alguien escriba una query nueva.

Documentar qué significa cada campo. No como formalidad —como prerequisito funcional. Si cliente_id puede ser un cliente final o un distribuidor dependiendo de la tabla, el LLM no lo va a saber a menos que alguien lo escriba explícitamente. Y dbt tiene soporte nativo para documentar campos directamente en el código.

Asegurar la calidad de los datos antes de que la IA los toque. Cuentas de prueba filtradas, outliers identificados, fechas en formato consistente, nulos manejados con criterio. Todo eso que el analista hacía “de memoria” al preparar un reporte tiene que estar codificado en el pipeline.

Mantener todo eso actualizado. Porque el negocio cambia, los sistemas cambian, y el LLM no sabe que el año pasado cambiaron la lógica de descuentos y hay un período de datos que no es comparable con el resto.

Nada de esto es nuevo. Es data engineering de siempre. Lo que cambió es que antes podías esconder la deuda técnica en el conocimiento del analista. Ahora, si quieres que una IA lo entienda, tiene que estar explícito.

¿Qué sí cambia con IA? Siendo honestos

No todo es negativo. La IA sí cambia algunas cosas reales:

La exploración de datos es más rápida. Un analista puede hacer preguntas ad hoc sin escribir SQL. Eso tiene valor, aunque el analista tenga que validar las respuestas.

La documentación se puede generar con asistencia. Un modelo bien usado puede ayudar a escribir las descripciones de campos, detectar anomalías en los datos, sugerir nombres más claros. El data engineer sigue siendo el que valida y decide.

El acceso se democratiza, con supervisión. Áreas de negocio pueden explorar datos sin depender de un técnico para cada consulta. Pero alguien tiene que haber construido la capa que hace eso posible —y esa capa es la misma arquitectura Medallion que existía antes de la IA.

En todos estos casos, la IA amplifica al data engineer —no lo reemplaza.

¿La IA también afecta el trabajo de los analistas de negocio?

Sí, aunque de forma diferente a lo que se suele decir. El trabajo de exploración ad hoc —“dame los números de ventas por región para Q3”— efectivamente se puede automatizar mejor con un LLM bien configurado. Eso libera tiempo del analista para trabajo de mayor valor: interpretar los números, identificar oportunidades, proponer acciones.

Lo que no cambia: alguien tiene que validar que los números del LLM son correctos antes de tomar decisiones basadas en ellos. Y para validar, necesitas entender la fuente de los datos —lo que vuelve al punto inicial.

La pregunta que vale hacerse antes de invertir en IA

Antes de contratar a alguien para implementar un LLM encima de tus datos, hay una pregunta más honesta:

¿Tus pipelines los puede entender una IA? ¿O ni tú los entiendes del todo?

Si la respuesta es la segunda, el problema no es el modelo. Es la base. Y ningún LLM, por más sofisticado que sea, va a resolver eso por ti.

Esa base —datos limpios, modelo interpretable, documentación real, pipeline que se mantiene actualizado— es exactamente lo que se construye antes de que cualquier modelo la toque. Si estás considerando IA para tu empresa, hablemos antes de que contrates al equipo de IA. El orden importa.

Preguntas frecuentes

¿Cuánto tiempo lleva tener los datos “listos para IA”?

Depende del estado inicial. Para empresas medianas con 3-7 fuentes de datos en estado razonable, la preparación para IA toma entre 4 y 10 semanas: construcción del pipeline Bronze→Silver→Gold, documentación de tablas y campos, configuración de tests de calidad. Para datos en estado muy desorganizado (múltiples sistemas sin integrar, campos sin documentar, historial fragmentado), puede tomar más. El diagnóstico inicial (Data Audit) determina el alcance real.

¿Qué herramientas de IA sobre datos funcionan mejor sobre un Lakehouse bien diseñado?

Varias opciones: sistemas RAG (Retrieval Augmented Generation) que consultan documentación de datos; interfaces text-to-SQL que traducen preguntas en lenguaje natural a queries SQL sobre las tablas Gold; agentes de análisis que pueden ejecutar código Python sobre los datos. Todas dependen de que las tablas Gold tengan nombres claros, campos documentados y datos limpios. Sin eso, ninguna funciona de forma confiable.

¿Un data engineer puede ser reemplazado por un agente de IA?

Para tareas específicas y repetitivas (generar documentación de campos, detectar anomalías en datos nuevos, sugerir mejoras de naming), los LLMs pueden asistir significativamente. El trabajo de diseño de arquitectura, modelado de negocio, resolución de conflictos entre fuentes y validación de la lógica de negocio sigue requiriendo criterio humano. La analogía: igual que un copiloto de avión no reemplaza al piloto, un LLM de datos no reemplaza al data engineer.

---

Si estás considerando IA para tu empresa, lee también por qué fracasan los proyectos de IA antes de empezar. El problema casi siempre está antes del modelo.

Hablemos antes de que contrates al equipo de IA. El orden importa.