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 hacés 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 intentá 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.

El LLM no entiende tu negocio. Entiende lenguaje.

Esa distinción parece obvia pero tiene consecuencias enormes.

Cuando le apuntás 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 vos entendés del todo.

Qué pasa 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.

Lo que alguien tiene que hacer igual

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.

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 querés que una IA lo entienda, tiene que estar explícito.

Lo que sí cambia con IA (para ser honestos)

No todo es doom. 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, 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.

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

La pregunta que vale hacerse

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 vos los entendés 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 vos.

Esa base — datos limpios, modelo interpretable, documentación real, pipeline que se mantiene actualizado — es exactamente lo que construimos 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.