Contratación · July 29, 2026 · 9 min de lectura

Cómo contratar a un ingeniero de IA: habilidades a evaluar en 2026

Cómo contratar a un ingeniero de IA en 2026: qué hace realmente el puesto, la disciplina de evaluación que lo diferencia del ingeniero de machine learning y cómo ponerla a prueba.

← Parte de The five pillars of hiring: what assessments measure

Esta guía está dirigida a los responsables de contratación y líderes de ingeniería que están abriendo un puesto que no existía hace tres años. Un ingeniero de IA construye funcionalidades de producto respaldadas por LLMs —pipelines de recuperación, arneses de evaluación, orquestación de prompts y herramientas, todo dentro de un presupuesto de latencia y coste— y el puesto existe porque los modelos fundacionales transformaron «entrena el modelo» en «ingeniea alrededor del modelo». Lo necesitas cuando varias funcionalidades dependientes de modelos ya están en producción y el trabajo de mantenerlas honestas nunca para; no lo necesitas cuando una sola funcionalidad de chatbot podría encajar cómodamente en tu equipo existente. El puesto suele depender de ingeniería, cerca de la superficie de producto que alimenta, y no en un grupo de investigación apartado. Aquí está la parte incómoda: este es el título más rebautizado en tecnología ahora mismo, y la habilidad que realmente importa —saber cómo sabes que la funcionalidad funciona— es la que nunca aparece en un CV.

¿Qué hace realmente un ingeniero de IA?

Un ingeniero de IA lanza funcionalidades de producto construidas sobre modelos que no entrenó él. Una semana típica: ajustar un pipeline de recuperación que sigue mostrando documentos desactualizados, escribir un conjunto de evaluación que detecte la regresión antes que los usuarios, reducir una cadena de prompts que duplicó silenciosamente el presupuesto de latencia, y perseguir por qué el agente entra en bucle con una llamada de herramienta malformada a las 2 de la madrugada. El modelo es un componente; la ingeniería es todo lo que lo rodea.

Esa es la versión honesta del trabajo, y no se parece en nada a la demo. Fíjate en lo poco que aparece el «escribir un prompt ingenioso». El prompt es la hora fácil. Los días difíciles se dedican a las cosas que hacen que una funcionalidad con LLM sea segura de lanzar a usuarios reales:

• Construir y mantener el pipeline de recuperación —fragmentación, indexación, clasificación— para que el modelo responda desde el contexto correcto en lugar de inventarse uno con seguridad.
• Orquestar prompts y herramientas: encadenar llamadas, conectar el modelo a funciones y gestionar el caso en que una herramienta devuelve basura y el modelo lo cree de todas formas.
• Ser dueño del arnés de evaluación —los conjuntos de pruebas, la suite de regresión, las comprobaciones offline y online que responden a la única pregunta que importa: ¿esta funcionalidad funciona realmente?
• Mantener un presupuesto de latencia y coste: cachea lo que puedas, enruta las peticiones baratas a modelos más económicos y sabe al céntimo lo que cuesta una funcionalidad por cada mil llamadas.
• Rastrear los modos de fallo antes de que los clientes los encuentren —alucinaciones, inyección de prompts, deriva silenciosa cuando el modelo subyacente cambia bajo tus pies.
• Mantenerlo todo en producción con registros reales, fallbacks reales y un plan para el día en que el proveedor deprece el modelo sobre el que construiste.

¿Lo necesitas realmente?

Necesitas un ingeniero de IA cuando tienes superficie real de LLMs —varias funcionalidades respaldadas por modelos en producción, una carga de evaluación que nunca descansa y una línea de costes que ha empezado a doler—. Por debajo de eso, un buen ingeniero de software con verdadera fluidez en IA lo cubre, y abrir el puesto demasiado pronto solo significa pagar una prima por alguien que pasará la mayor parte de su tiempo en trabajo ordinario de backend.

Sé honesto sobre tu escala antes de publicar el puesto. Si tienes una funcionalidad de chatbot y un wrapper alrededor de una única API, la persona que quieres es un buen ingeniero de software que pueda trabajar fluidamente con un modelo —lee cómo contratar a un ingeniero de software y evalúa la fluidez en IA además—. Si tu problema es entrenar o ajustar modelos en lugar de construir sobre ellos, quieres el extremo más orientado a la investigación del espectro —esa es una contratación diferente, cubierta en cómo contratar a un ingeniero de machine learning—. El ingeniero de IA gana su lugar en el complicado centro: funcionalidades de LLM en producción con suficiente volumen para que la evaluación, el coste y el trabajo sobre modos de fallo se conviertan en una disciplina a tiempo completo, no en una misión secundaria.

¿Qué habilidades distinguen a un buen ingeniero de IA de uno rebautizado?

Cada título acuñado por el auge de la IA atrae CVs rebautizados, y este atrae los más: una tarde siguiendo un tutorial de API se convierte en «ingeniería de IA». El candidato rebautizado puede describir los prompts que escribió. El real puede decirte cómo sabía que la funcionalidad funcionaba —que es todo el trabajo—. Tres habilidades marcan la diferencia, y ninguna fotografía bien en un currículum.

• Disciplina de evaluación —la habilidad definitoria—. Construye el conjunto de evaluación antes de confiar en la corrección, distingue la evaluación offline de la online y trata «me pareció bien cuando lo probé» como una confesión, no como evidencia.
• Pensamiento orientado a modos de fallo —nombra las alucinaciones, la inyección de prompts y la deriva sin que se los pidan, y diseña para el caso en que el modelo se equivoque en lugar de asumir que tiene razón. Saben que una funcionalidad que funcionó la semana pasada puede romperse cuando el proveedor actualiza el modelo en silencio.
• Ingeniería de coste y latencia —razonan en tokens y milisegundos, saben cuándo un modelo más barato es suficiente y pueden decirte lo que cuesta una funcionalidad a escala sin necesitar una calculadora.
• Oficio de recuperación y orquestación —pipelines reales, no una única llamada de embedding: piensan en la fragmentación, la clasificación y qué ocurre cuando la recuperación no devuelve nada útil.
• Suficiente ingeniería de software para lanzar —registros, fallbacks, versionado del prompt como código. Un ingeniero de IA que no puede mantener su funcionalidad en producción es un prototipador con una demo bonita.

La forma más rápida de detectar a un ingeniero de IA rebautizado es preguntarle cómo sabía que su última funcionalidad funcionaba. El genuino habla del conjunto de evaluación y los modos de fallo que rastreó. El impostor habla del prompt del que estaba orgulloso. La misma pregunta, respuestas completamente diferentes.

¿Cómo se ponen a prueba esas habilidades?

No puedes hacer visible la disciplina de evaluación solo con preguntas, porque el candidato rebautizado ha leído los mismos artículos que tú. La única señal fiable es el trabajo con forma de trabajo real: pon una funcionalidad LLM realista delante de ellos, dales un modelo con el que trabajar y observa cómo lo dirigen, verifican su salida y lo corrigen cuando se equivoca con seguridad. Esa es la perspectiva de la fluidez en IA —estás evaluando la relación de trabajo entre la persona y el modelo, no su memoria de patrones de prompts—.

Construye la tarea alrededor de una funcionalidad rota de una manera interesante: un endpoint de recuperación que devuelve respuestas fluidas pero incorrectas; un agente que entra en bucle con una llamada de herramienta errónea; una cadena de prompts que silenciosamente está quemando el presupuesto de latencia. Luego observa. ¿Recurren a una evaluación antes de confiar en su propio cambio? ¿Nombran un modo de fallo que tú no mencionaste? ¿Notan la implicación de coste del modelo que acaban de elegir? Una prueba de muestra de trabajo como esta predice el comportamiento en el trabajo mucho mejor que una pizarra, y ejecutarla dentro de un AI Sandbox —donde un modelo está genuinamente disponible en lugar de estar prohibido— es la única forma de ver el comportamiento de fluidez en IA que define el puesto. Para puntuarla de forma consistente, cómo evaluar la fluidez en IA y el Marco 4D —Delegation, Description, Discernment, Diligence— te dan una rúbrica; Discernment y Diligence tienen más peso para un ingeniero de IA, porque detectar cuando el modelo se equivoca es exactamente el trabajo. Sí, este es el tipo de ejercicio que ejecuta nuestra plataforma; una versión casera con un repositorio roto y un cronómetro te enseñará la mayoría de las mismas cosas.

¿Cómo es el proceso de entrevistas?

Mantenlo corto —los buenos ingenieros de IA tienen varias ofertas y un proceso lento los pierde—. Apunta a una muestra de trabajo con forma real más una entrevista estructurada, no seis rondas de intuición. Una entrevista estructurada significa las mismas preguntas, el mismo orden y la misma tarjeta de puntuación para cada candidato, lo que hace que la comparación sea justa y la decisión justificable.

• Filtra por habilidades, no por pedigree —una tarea corta y relevante para el puesto que todos completan en las mismas condiciones, reemplazando la selección por currículum. Esto es la contratación AI-native, y amplía el grupo a ingenieros autodidactas que aprendieron este oficio porque no había ningún título para él.
• La muestra de trabajo —la sesión de la funcionalidad rota en el sandbox, puntuada en disciplina de evaluación, pensamiento sobre modos de fallo y conciencia de coste y latencia.
• Un entrevistador técnico repasa la muestra de trabajo del candidato con él: ¿por qué esa corrección, cómo la verificaste, qué comprobarías antes de lanzar? La historia de verificación importa más que la corrección.
• Una conversación conductual estructurada sobre responsabilidad y colaboración —cómo gestionaron una funcionalidad que se lanzó y luego se rompió en producción.
• Una tarjeta de puntuación por capacidad, rellenada de forma independiente antes de que nadie compare notas, para que la voz más alta en el debate no se convierta en la decisión.

¿Qué hay de la compensación y la seniority?

No publicamos cifras salariales —el mercado para este puesto cambia de precio cada trimestre y cualquier número aquí sería incorrecto para cuando lo leas—. Cualitativamente, los ingenieros de IA exigen una prima sobre los ingenieros de software generales ahora mismo porque la oferta de personas con verdadera disciplina de evaluación es escasa y la demanda no lo es. No dejes que esa prima te tiente a sobre-nivelar: un ingeniero de nivel medio con verdaderos instintos sobre modos de fallo vale más para un equipo de funcionalidades LLM que un título sénior con profundidad en tutoriales de prompts. Compara con tu propio mercado de ingeniería de software, añade por la habilidad AI-native demostrada que hayas observado realmente en la muestra de trabajo y ancla la oferta en evidencias más que en el buzzword del título.

Primeros 90 días: qué tiene buen aspecto

Un buen ingeniero de IA pasa el primer mes reduciendo tu incertidumbre, no añadiendo funcionalidades. Para la semana cuatro deberían haber construido o reforzado un conjunto de evaluación para una funcionalidad que no tenía ninguno, y haberte dicho algo incómodo y verdadero sobre cómo funciona realmente. Esa es la clave: una buena contratación hace que tus funcionalidades respaldadas por modelos sean medibles antes de hacerlas más sofisticadas.

• Semanas 1-4 —mapea las funcionalidades LLM existentes, encuentra las que funcionan sin evaluación real y monta un conjunto de evaluación que detecta una regresión que nadie había notado.
• Semanas 4-8 —lanza una corrección de modo de fallo que importa: un agujero de inyección de prompts cerrado, un pipeline de recuperación que deja de alucinar en contexto vacío, un fallback para el día en que el modelo se comporte mal.
• Semanas 8-12 —pone bajo control una línea de coste o latencia y deja una forma de mantenerla: un presupuesto, una ruta más económica, un panel que el equipo realmente consultará.
• Durante todo el proceso —hace que la relación del equipo con el modelo sea más honesta. Las funcionalidades no son necesariamente más sofisticadas el día 90; son medibles, más baratas de ejecutar y menos propensas a avergonzarte en producción.