Los perfiles de datos se han redibujado varias veces en pocos años y la GenAI reabre el ejercicio. El debate oscila entre dos caricaturas: la desaparición de los roles de datos en favor de un único GenAI Engineer y la afirmación contraria de que nada se mueve porque llamar a una API no sería una profesión.
Este análisis toma otro ángulo. Parte de las responsabilidades que se ejercen de verdad, muestra dónde los sistemas LLM, RAG y de agentes añaden, desplazan o no modifican nada, y deja al lector situar su propio puesto.
Empezar por las responsabilidades, no por los títulos
Un mismo título cubre ámbitos muy distintos según el tamaño de la empresa, la madurez de su plataforma y la organización de los equipos. Una lista de responsabilidades, en cambio, sí se puede comparar entre organizaciones.
- Recogida, transformación, calidad y disponibilidad de los datos.
- Experimentación y modelado: hipótesis, protocolos, comparación de enfoques.
- Ingeniería ML: industrialización, reproducibilidad, empaquetado, pruebas.
- Serving: exposición del sistema, latencia, escalado.
- Evaluación: definir qué es un buen resultado y medirlo de forma defendible.
- Observabilidad: saber qué ocurre en producción y detectar degradaciones.
- Integración aplicativa: encajar el sistema en un producto y sus recorridos.
- Sistemas LLM / RAG / agentes: orquestación, recuperación, herramientas, salvaguardas.
Estas responsabilidades no se reparten igual en todas partes. En una estructura pequeña una sola persona puede asumir seis; en un gran grupo una sola puede repartirse entre tres equipos.
Data Engineer
La GenAI añade una familia de datos a un puesto que ya manejaba muchas: los corpus documentales. Llegan con dificultades propias, casi siempre infravaloradas por quien descubre el tema a través del modelo.
- Fuentes documentales heterogéneas: formatos, versiones, duplicados, escaneados.
- Ingesta y parsing: extracción de texto, estructura, tablas, adjuntos.
- Metadatos: origen, fecha, ámbito, estado de validez, idioma.
- Calidad: detectar versiones obsoletas, documentos truncados, contenidos duplicados.
- Permisos: quién puede ver qué, cuestión central cuando el sistema responde con documentos internos.
- Frescura: qué hay que reindexar, con qué frecuencia y con qué retraso aceptable.
- Pipelines para la recuperación: troceado, indexación, actualización incremental.
- Observabilidad de datos: saber qué entró en el índice y qué quedó fuera.
Sería falso concluir que el Data Engineer pasa a ser «quien prepara los datos para un LLM». Los almacenes, los pipelines analíticos, los contratos de datos y la fiabilidad de los flujos existentes no desaparecen: siguen siendo la base sobre la que se apoya todo lo demás, incluidos los casos GenAI.
Data Scientist
Es el rol cuyo valor peor se entiende en los proyectos GenAI, porque se asocia al entrenamiento de modelos cuando la mayor parte de su competencia está en el método.
- Experimentación: comparar dos enfoques en condiciones donde comparar tenga sentido.
- Hipótesis: decir qué se cree y cómo se sabría que es falso.
- Métricas: elegir qué hay que medir y qué no dice la medida.
- Evaluación: construir un conjunto de prueba representativo, con casos difíciles.
- Análisis de errores: clasificar los fallos por causa y no por síntoma.
- Datos de prueba: construirlos con los expertos de negocio y mantenerlos en el tiempo.
- Comprensión del comportamiento del sistema: dónde es estable y dónde no.
Estas competencias se transfieren bien: un sistema RAG o un agente se juzga igual que un modelo, con protocolo, conjunto de prueba y análisis de errores. La diferencia es que la salida es texto o una acción, lo que hace más difícil formalizar qué es «un buen resultado» y más valiosa a quien sabe hacerlo.
Esto no significa que todo Data Scientist deba convertirse en AI Engineer. Seguir en modelado, análisis y apoyo a la decisión es una trayectoria completa, y muchos problemas no tienen ninguna razón para resolverse con un LLM.
ML Engineer
El ML Engineer trabaja allí donde un sistema deja de ser una demostración. La GenAI apenas cambia la naturaleza de ese ámbito, pero lo extiende a objetos nuevos.
- Integración en una aplicación y en una cadena existente.
- Serving, latencia, escalado, comportamiento ante picos.
- Despliegue, versionado, vuelta atrás.
- Monitorización y alertas sobre señales con sentido para ese sistema.
- Reproducibilidad: poder rehacer, explicar y recuperar un resultado.
- Fiabilidad: degradación controlada, gestión de errores, dependencias externas.
- Coste: equilibrio entre calidad, latencia y gasto por petición.
- Infraestructura y evaluación en producción, distinta de la evaluación offline.
Las extensiones ligadas a la GenAI son concretas: llamadas a modelos externos sujetos a cuotas y a cambios de comportamiento, cadenas de recuperación que vigilar, agentes cuyas acciones deben limitarse y trazarse, sistemas híbridos donde conviven un modelo clásico y un LLM. La competencia de fondo —sostener un sistema en producción— no cambia.
AI / GenAI Engineer
Es el rol más difícil de describir porque no tiene definición estable. Según la organización, solapa responsabilidades existentes, las complementa o se especializa en un objeto concreto.
- Solapamiento: en un equipo pequeño hace trabajo de ML Engineer sobre sistemas GenAI.
- Complemento: junto a un equipo de datos existente, asume integración aplicativa, orquestación y evaluación de sistemas con LLM.
- Especialización: recuperación, agentes, herramientas, salvaguardas, calidad de salida, coste.
Buscar una definición universal de este puesto es perder el tiempo. Leer una oferta identificando las responsabilidades descritas informa mucho más que fiarse del título.
Comparativa cualitativa de responsabilidades
La lista siguiente es deliberadamente matizada: indica tendencias, no casillas cerradas. En una organización concreta el reparto puede ser distinto sin ser anormal.
- Ingesta y calidad de datos — Data Engineer: a menudo central. Data Scientist: colaboración frecuente. ML Engineer: depende del contexto. AI/GenAI Engineer: depende del contexto.
- Permisos y frescura de los corpus — Data Engineer: a menudo central. Data Scientist: poco habitual. ML Engineer: colaboración frecuente. AI/GenAI Engineer: frecuente.
- Experimentación e hipótesis — Data Engineer: poco habitual. Data Scientist: a menudo central. ML Engineer: frecuente. AI/GenAI Engineer: frecuente.
- Métricas y conjuntos de prueba — Data Engineer: colaboración frecuente. Data Scientist: a menudo central. ML Engineer: frecuente. AI/GenAI Engineer: frecuente.
- Serving, latencia, escalado — Data Engineer: depende del contexto. Data Scientist: poco habitual. ML Engineer: a menudo central. AI/GenAI Engineer: frecuente.
- Observabilidad y evaluación en producción — Data Engineer: colaboración frecuente. Data Scientist: colaboración frecuente. ML Engineer: a menudo central. AI/GenAI Engineer: frecuente.
- Orquestación LLM, RAG y agentes — Data Engineer: depende del contexto. Data Scientist: depende del contexto. ML Engineer: frecuente. AI/GenAI Engineer: a menudo central.
- Integración de producto y recorridos de usuario — Data Engineer: poco habitual. Data Scientist: depende del contexto. ML Engineer: frecuente. AI/GenAI Engineer: a menudo central.
- Coste por petición y compromisos técnicos — Data Engineer: depende del contexto. Data Scientist: colaboración frecuente. ML Engineer: a menudo central. AI/GenAI Engineer: a menudo central.
Una misma persona puede ocupar varias columnas según el proyecto. El objetivo no es clasificar personas, sino hacer visible lo que alguien tiene que cubrir.
Cómo saber dónde posicionarse
La pregunta «qué puesto elegir» está mal planteada. Una mejor es: qué responsabilidades quiero asumir y con qué profundidad.
- 1
Qué te gusta resolver
punto de partidaUn problema de fiabilidad, uno de medición, uno de modelado y uno de integración no dan la misma satisfacción. Es el criterio más estable en el tiempo.
- 2
Profundidad software
exigenciaSostener un sistema en producción exige software: pruebas, versiones, dependencias, incidencias. Unos disfrutan ahí, otros lo padecen.
- 3
Profundidad de datos
exigenciaEntender de dónde vienen los datos, cuánto valen y qué no cubren sigue siendo determinante, también en sistemas GenAI.
- 4
Experimentación o producción
equilibrioBuscar lo que funciona y hacer que se sostenga son oficios vecinos pero distintos, con ritmos diferentes.
- 5
Interacción con producto
orientaciónAlgunos roles viven cerca de los usuarios y de los compromisos de producto; otros trabajan aguas arriba, en la plataforma.
- 6
Nivel de responsabilidad
compromisoContribuir, decidir, sostener en producción o arbitrar la arquitectura no son el mismo compromiso.
Ninguno de estos ejes designa un mejor puesto. Solo ayudan a reconocer, en una oferta o en el puesto actual, lo que encajará contigo a largo plazo.
Situar la propia posición
Útil para describir un puesto actual o leer una oferta sin fiarse del título.
- Sé nombrar las responsabilidades que asumo, al margen de mi título.
- Sé cuáles comparto con otro equipo y cuáles son solo mías.
- Sé decir si mi trabajo acaba en el prototipo o llega hasta la explotación.
- Sé qué parte de mi trabajo es de datos, de modelo, de software o de producto.
- Puedo citar una decisión técnica que defendí y el criterio que la sostuvo.
- Sé qué responsabilidades quiero asumir después y cuáles no quiero.
Para recordar
- Los títulos cubren ámbitos muy distintos: razonar por responsabilidades es más fiable.
- La GenAI añade fuentes documentales, permisos y frescura al lado de los datos.
- La experimentación y el análisis de errores se transfieren bien a los sistemas GenAI.
- Las competencias de ingeniería ML siguen siendo centrales en cuanto hay producción.
- AI / GenAI Engineer no tiene definición universal: el ámbito depende de la organización.
- No hay un mejor puesto, solo responsabilidades que encajan contigo o no.
- LLM
- RAG
- AI Engineering