Los ingenieros de machine learning construyen los sistemas que automatizan el trabajo de los demás. La pregunta de la recursividad — «¿reemplaza la IA a los ingenieros de ML que entrenan la IA?» — es la pregunta que le hacen a cada ingeniero de ML en una cena. Es, sobre todo, la pregunta equivocada. La lectura real de la exposición para la ingeniería de ML es más interesante: el rol se sitúa en territorio aumentado por la IA, el coste operativo de la IA para las tareas de ingeniería de ML es excepcionalmente alto, y el trabajo Human-critical se concentra en una franja más estrecha que en el caso de los ingenieros de software.
Las seis tareas de ingeniería de ML que modelamos
La ingeniería de ML es un rol híbrido — mitad ingeniero de software, mitad científico aplicado, mitad ingeniero de plataforma. Nuestro corpus v1 modela tareas representativas del rol: entrenar un modelo sobre un conjunto de datos etiquetado, evaluar el rendimiento del modelo, poner en producción un modelo entrenado, depurar regresiones del modelo en producción, diseñar el pipeline de entrenamiento (datos → features → entrenamiento → evaluación → despliegue) y proponer nuevos enfoques de modelado.
La lectura a nivel de celda
Entrenar un modelo sobre un conjunto de datos etiquetado es AI-augmented en nuestra semilla v1 — la parte mecánica (lanzar los jobs de entrenamiento, seguir los hiperparámetros, cambiar una tasa de aprendizaje) es de alta capacidad, y las herramientas de AutoML llevan tres años comiéndose esta capa del trabajo. Lo que mantiene la tarea en AI-augmented y no en Replaceable son las decisiones que los ingenieros de ML siguen teniendo: qué versión del conjunto de datos usar para entrenar, qué régimen de holdout es honesto para el despliegue, si una regresión en un segmento importa. Esas decisiones no son automatizables, y se asientan sobre la misma tarea en nuestra matriz.
Evaluar el rendimiento del modelo y redactar el informe de evaluación es AI-augmented. Producir la tabla de métricas es mecánico. Decidir qué métrica importa para la decisión de despliegue es cuestión de juicio. La IA es excelente con la tabla, mediocre con la conclusión.
Poner en producción un modelo entrenado detrás de una API es AI-augmented. El código estándar (handler de FastAPI, batching, monitorización) es de alta capacidad. Las decisiones no estándar — presupuesto de latencia, política de reintentos, estrategia de rollback de versión — están del lado humano. La celda se sitúa firmemente en la franja intermedia.
Depurar regresiones del modelo en producción baja a Human-led + AI-assisted, y aquí es donde el coste operativo de la IA del rol se dispara. El eje de fiabilidad aquí es malo: la IA diagnostica erróneamente las regresiones con aplomo, y un diagnóstico erróneo conlleva a la vez coste de supervisión y coste de error aguas abajo. Los minutos de supervisión por sesión de depuración son altos. Las horas de tarea son pocas, pero el peso en dólares por hora es grande.
Diseñar el pipeline de entrenamiento se sitúa en Human-led + AI-assisted en la parte profunda. La IA puede esbozar un DAG de pipeline; la IA no puede decidir que la actualización de datos tiene que terminar antes de la medianoche UTC porque el interesado europeo lee el panel a las 7 de la mañana CET, y el SLA del almacén aguas arriba es a las 2 UTC, de modo que la lógica de margen debe ser de tres horas y no los 30 minutos del manual. Eje de contexto alto. Ambigüedad alta.
Proponer nuevos enfoques de modelado es la tarea Human-critical del rol. La capacidad de la IA es media — la IA puede sugerir arquitecturas plausibles. La fiabilidad es mala — las sugerencias son recombinaciones de patrones del corpus de entrenamiento que pueden no encajar con el problema real. El eje de ambigüedad puntúa en lo más alto de la escala de valor irreducible: decidir qué problema abordar es lo que define la senioridad del ingeniero de ML. La IA no tiene nada en juego en la dirección de investigación de la empresa.
A grandes rasgos a lo largo de una semana típica
Para un ingeniero de ML de nivel intermedio a sénior en una empresa que despliega modelos (no un laboratorio de modelos fundacionales — esa es otra celda), la distribución base v1 sobre las tareas modeladas es: cero Replaceable, aproximadamente la mitad en AI-augmented (entrenamiento, informes de evaluación, despliegue de API de producción), y el resto repartido entre Human-led + AI-assisted (depuración de regresiones, diseño de pipeline) y Human-critical (decisiones de enfoque de modelado). El pill principal es territorio aumentado por la IA.
Se parece a la lectura de la ingeniería de software — y lo es, en la superficie. La diferencia aparece en el eje del coste operativo de la IA, donde las tareas de ingeniería de ML tienen las cifras de minutos-de-supervisión-por-salida más altas de todo nuestro corpus. Depurar una regresión requiere horas de atención humana por cada diagnóstico sugerido por la IA. El coste operativo, por tanto, no está dominado por la inferencia — está dominado por el tiempo del revisor al salario cargado de un ingeniero de ML sénior. El patrón Klarna se aplica de forma distinta aquí: un asistente de IA de alta capacidad que necesita la supervisión de un ingeniero de ML está haciendo arbitraje salarial contra el grupo de revisores más caro del equipo.
La pregunta de la recursividad
La versión de sobremesa: «¿Reemplazará la IA a los ingenieros de ML que entrenan la IA?». La respuesta honesta de la lectura v1 es: no para 2027. Las dos celdas que parecen más automatizables — el entrenamiento y la producción de tablas de evaluación — ya están en gran medida automatizadas, y lo están desde el AutoML. El trabajo restante del ingeniero de ML se concentra en el diseño de pipeline, la depuración de regresiones y las decisiones de modelado — tres celdas donde la brecha capacidad-fiabilidad es mayor y el coste operativo de la IA es más alto.
La lectura estructural es que la ingeniería de ML es uno de los pocos roles donde el aumento de capacidad de hecho eleva la demanda salarial para el trabajo human-critical restante, porque una mayor capacidad en las tareas de la mitad inferior libera horas del ingeniero de ML para el trabajo de dirección de investigación de alto apalancamiento que se capitaliza frente a los activos de modelo defendibles de la empresa. El marco de apalancamiento sin permiso de Naval se aplica: los ingenieros de ML que usan la asistencia de la IA para cubrir la capa mecánica sacan más de las mismas horas, no menos.
Lo que no modelamos — la celda del laboratorio de modelos fundacionales
Nuestro corpus v1 modela al ingeniero de ML aplicado típico en una empresa que despliega modelos. No modelamos al ingeniero de ML de un laboratorio de modelos fundacionales (Anthropic, OpenAI, DeepMind, Mistral, etc.). Ese rol tiene una forma diferente — la parte Human-critical es mucho más alta, la parte AI-augmented es más baja, y la capa financiera es sustancialmente distinta porque la salida del rol ES el sustituto que se mide. Lo añadiremos en una ampliación de corpus v1.5. Por ahora, trata esta entrada como la lectura del ingeniero de ML aplicado, no la del laboratorio de modelos fundacionales.
Qué hacer con esto
El movimiento económicamente sereno para un ingeniero de ML aplicado en 2026 es dejar que la IA haga los informes de evaluación y los handlers de API, y dedicar las horas liberadas al músculo de la depuración de regresiones y al juicio de diseño de pipeline. Estas son las celdas donde la senioridad se capitaliza. El reconocimiento de patrones para regresiones en producción es el tipo de destreza que se afila con las repeticiones y es difícil de transferir; las decisiones de modelado que se ven bien en un notebook y fallan en producción enseñan una clase de rigor operativo que la IA no puede ensayar en tu lugar.
Calcula tu Wagecard específico en wagecore.ai/start. Si estás en un laboratorio de modelos fundacionales, la coincidencia más cercana en nuestro corpus es el rol machine-learning-engineer con anulaciones manuales; lo indicaremos en la página de resultados. Lectura derivada de la matriz en /roles/machine-learning-engineer, lectura inter-celdas en directo en /insights/machine-learning-engineer. Metodología abierta en /methodology.