Contratación · August 2, 2026 · 10 min de lectura

Plantilla de descripción del puesto de ingeniero de prompts (gratuita, 2026)

Plantilla de descripción del puesto de ingeniero de prompts para 2026, con la sección de fluidez en IA que todas las demás plantillas omiten y los requisitos que realmente puede evaluar.

← Parte de Los cinco pilares de la contratación: qué miden las evaluaciones

Esta página es para el responsable de contratación, fundador o talent partner que ha decidido redactar una descripción del puesto de ingeniero de prompts y quiere una que sobreviva al contacto con candidatos reales. El puesto es propietario de la capa de instrucciones entre su producto y el modelo —los prompts, los mensajes de sistema y las instrucciones de agentes— más los conjuntos de evaluación que demuestran que esas instrucciones funcionan. Redactar la descripción es difícil por tres razones. El título es lo suficientemente joven como para que ninguna empresa signifique lo mismo con él. El boilerplate de mercado es escaso, anticuado y se copia a sí mismo. Y las candidaturas llegarán repletas de colecciones de prompts y certificados de cursos que parecen impresionantes y predicen casi nada. Este puesto se ubica donde la calidad del prompt es genuinamente el producto —automatización de soporte, sistemas de contenidos, instrucciones de agentes que se ejecutan a escala—, normalmente dentro de ingeniería o IA aplicada. A continuación encontrará una plantilla lista para copiar, más las dos secciones que todos los competidores omiten: qué evaluar y qué significa realmente la fluidez en IA aquí.

La plantilla de descripción del puesto de ingeniero de prompts

Copie las secciones a continuación y reemplace los marcadores entre corchetes. Conserve la sección de fluidez en IA: es la parte que separa una descripción que los candidatos respetan de una que pueden sortear.

Sobre el puesto

[Empresa] busca un ingeniero de prompts para ser propietario de la capa de instrucciones de [producto o sistema] —los prompts, los mensajes de sistema y las instrucciones de agentes que dan forma a cómo se comportan nuestros modelos en producción—. Tratará los prompts como código: versionados, probados frente a conjuntos de evaluación y medidos en lugar de estimados a ojo. Este puesto se ubica dentro de [equipo] y trabaja estrechamente con [ingeniería / producto / operaciones] para convertir «la salida se siente mal» en mejoras medidas y repetibles.

Responsabilidades

• Ser propietario de los prompts, los mensajes de sistema y las instrucciones de agentes para [superficie del producto], y de los conjuntos de evaluación que los mantienen honestos.
• Diagnosticar los fallos de salida de forma sistemática: reproducir el problema, agrupar los fallos por tipo, formular una hipótesis, cambiar una variable y medir el resultado frente a un conjunto de casos.
• Construir y mantener conjuntos de evaluación con salidas esperadas, para que cada cambio sea un número en lugar de una impresión.
• Versionar los prompts como código: con historial de cambios, posibilidad de revertir y un registro de qué cambio movió qué métrica.
• Detectar y diagnosticar regresiones en el comportamiento del modelo cuando cambia una versión o familia de modelos, y establecer salvaguardas para que la siguiente se detecte automáticamente.
• Decidir cuándo un problema está en la capa de instrucciones frente a la recuperación de información, los datos o el propio modelo, y enrutarlo en consecuencia.
• Colaborar con ingeniería en el diseño de recuperación de información y de llamadas a herramientas donde esas decisiones dan forma al comportamiento del modelo.
• Informar sobre la calidad de la salida frente a las métricas definidas a [stakeholders], en un lenguaje claro que un responsable no técnico pueda utilizar para tomar decisiones.

Requisitos

• Iteración sistemática demostrada: puede mostrar un caso en que convirtió una queja vaga sobre la calidad en una mejora medida y repetible.
• Experiencia en la construcción de conjuntos de evaluación y en razonar sobre la calidad de la salida como un número, no una sensación.
• Fluidez en los modos de fallo comunes —alucinación, deriva de formato, rechazo excesivo— y la corrección diferente que necesita cada uno.
• Juicio sobre los límites de la capa de instrucciones: dice «este es un problema de recuperación de información, no de prompt» cuando es verdad.
• Comodidad trabajando con al menos dos familias de modelos y comprensión de cómo difiere el comportamiento entre ellas.
• Comunicación escrita clara: puede explicar una compensación a un responsable no técnico sin esconderse detrás de la jerga.
• Suficiente alfabetización en ingeniería para trabajar dentro de una base de código versionada y razonar sobre el sistema alrededor del modelo.

Se valorará

• Experiencia siendo propietario de prompts para un producto en producción a escala, donde la deriva tenía un coste real.
• Bagaje en aprendizaje automático aplicado, análisis de datos o una disciplina cuantitativa.
• Familiaridad con sistemas de recuperación de información aumentada y frameworks de agentes.
• Experiencia construyendo o manteniendo un arnes de evaluación que funcionó de forma autónoma.

Expectativas de fluidez en IA

Esta es la sección que ninguna plantilla de primer ranking en el mercado incluye, y para un ingeniero de prompts es la más profunda de esta serie: el trabajo es la fluidez en IA. Péguela de forma literal:

• Evalúa la salida del modelo de forma sistemática, frente a un conjunto de casos con resultados esperados, en lugar de declarar que un prompt es «mejor» porque se lee mejor.
• Versiona los prompts como código: con historial, posibilidad de revertir y un registro claro de qué cambio movió qué métrica.
• Conoce los modos de fallo de al menos dos familias de modelos y cómo se comporta el mismo prompt de forma diferente entre ellas.
• Detecta regresiones sutiles en el comportamiento del modelo tras un cambio de versión, y verifica que una corrección se mantuvo en todo el conjunto antes de declarar la victoria.
• Usa herramientas de IA para avanzar rápido mientras comprueba su salida frente al sistema real: delegando lo que es seguro delegar, y detectando una respuesta confiada que está silenciosamente equivocada.

Qué ofrecemos

[Rango de compensación], [capital si aplica] y [beneficios]. Será propietario de una palanca que mueve visiblemente [la métrica que importa], con la infraestructura de evaluación y la autonomía para moverla. [Modalidad de trabajo: en remoto, híbrido, ubicación]. [Una línea honesta sobre el equipo y cómo trabaja.]

¿Cómo se adapta esta plantilla?

Ajuste la seniority con el alcance, no con una lista de requisitos más larga. Alguien que es propietario de los prompts de una única funcionalidad es una contratación diferente a alguien que es propietario de la estrategia de instrucciones de agentes para una línea de productos: ajuste el alcance y la retribución en consecuencia. Recorte con fuerza para una startup; amplíe las líneas de gobernanza e informes para una empresa grande. Luego elimine las tres cosas que la gente copia equivocadamente de las descripciones de puestos heredadas.

• Un requisito de titulación. Los ingenieros de prompts más fuertes suelen ser profesionales autodidactas y personas que se reconvierten desde campos cuantitativos; un filtro de titulación los descarta y no predice nada.
• «X años de ingeniería de prompts». La disciplina tiene unos pocos años de antigüedad como máximo. Quien afirme tener una década está redondeando, y el requisito premia silenciosamente a los primeros en adoptarla frente a los mejores profesionales.
• Un certificado o curso específico. Los certificados miden la asistencia, no la disciplina de medición sobre la que funciona este puesto. Pida en cambio una mejora medida.
• Una lista fija de herramientas o versiones de modelos específicas. Las familias de modelos cambian rápido; contrate por juicio transferible entre ellas, no por fluidez con el stack del trimestre actual.

Para una startup, reduzca las responsabilidades al bucle central: ser propietario de la capa de instrucciones, construir los conjuntos de evaluación, detectar las regresiones, y deje que una persona lo lleve junto a su otro trabajo. Para una empresa grande, añada las líneas de informes, revisión y documentación que la plantilla sugiere, y sea explícito sobre qué familias de modelos y superficies están en el alcance. La guía cómo redactar una descripción del puesto explica la mecánica general de redactar en torno a comportamientos observables.

¿Qué debería evaluar en lugar de confiar en el CV?

Relacione cada punto de requisito con algo que pueda observar, porque para este puesto el CV se acerca al ruido. El CV de un ingeniero de prompts es una biblioteca ordenada de prompts que funcionaron una vez, para algo, en algún lugar, y una plantilla que produjo una bonita salida de demo no le dice nada sobre si sobrevive a cien casos reales o a la siguiente versión del modelo. Evalúe el bucle, no el léxico. Los requisitos anteriores se corresponden con los cinco pilares públicos de la evaluación de candidatos de esta forma, solo a nivel de capacidad, sin puntuaciones:

• Cognitivo: el propio bucle de diagnóstico: leer los fallos, aislar una variable, razonar sobre la causa. Esta es la señal individual más fuerte para el puesto.
• Dominio: diseño de evaluación, alfabetización en recuperación de información y conocer los límites de la capa de instrucciones.
• Juicio situacional: decidir si un problema es un problema de prompt en absoluto, y qué escalar frente a qué corregir.
• Conductual: disciplina de medición frente a la tentación de declarar la victoria con una salida afortunada.
• Fluidez en IA: versionado de prompts, alfabetización en modos de fallo entre familias, y verificación del trabajo redactado con asistente frente al sistema real.

La forma de evaluar los cinco a la vez es una muestra de trabajo con forma de trabajo real: entregue al candidato un prompt mediocre y un conjunto de casos en que falla, y observe cómo diagnostica e itera. Ese es el trabajo comprimido en una hora, y es una prueba de muestra de trabajo en lugar de un cuestionario. Dado que el puesto es intrínsecamente AI-native, observe cómo trabajan con el modelo directamente: el Marco 4D de fluidez en IA (Delegation, Description, Discernment, Diligence) le proporciona una rúbrica, y cómo evaluar la fluidez en IA explica cómo distinguir señales fuertes de débiles mientras observa. Ejecutar el ejercicio en un AI Sandbox realista, donde el modelo está genuinamente disponible y se observa el proceso en lugar de solo el artefacto, es donde aterriza la perspectiva de nuestra plataforma de evaluación de habilidades AI-native. Para calibrar qué aspecto tiene la capa de instrucciones en otros puestos, ingeniería de prompts por puesto y la ingeniería de prompts para ingenieros de software son complementos útiles; la lógica de decidir si contratar vive en cómo contratar a un ingeniero de prompts, y si lo que necesita realmente es arquitectura de agentes, la descripción del puesto de ingeniero de agentes de IA es el puesto vecino.

¿Cómo se detecta a un ingeniero de prompts que no puede hacer realmente el trabajo?

Este es el peor problema de impostores en todo el panorama de contratación de IA, y vale la pena declarar la posición honesta con claridad. Porque el puesto tuvo un ciclo de hype, atrae a dos tipos de farsantes. El coleccionista de certificados, que ha completado varios cursos de «ingeniería de prompts» y puede recitar frameworks con acrónimos. Y el revendedor de plantillas, cuyo portfolio entero es una biblioteca de copiar-y-pegar. Ambos se entrevistan con fluidez. Ninguno puede convertir «la salida se siente mal» en una mejora medida. Vendemos evaluación de candidatos para ganarnos la vida, así que descuente mi encuadre como quiera, pero la señal se mantiene independientemente de quién lo diga: pregunte cómo saben que un prompt mejoró, y escuche si hay un número frente a un conjunto de casos en lugar de «se lee mejor». Las señales de alerta en una candidatura:

• Un CV que enumera colecciones de prompts y frameworks pero ninguna mejora de salida medida en ningún lugar.
• Prompts de portfolio sin ningún conjunto de evaluación detrás: salidas que tuvieron buen aspecto una vez, sin evidencia de que se mantienen en los casos o en las versiones del modelo.
• Vocabulario fluido («few-shot», «chain-of-thought») y ninguna historia sobre una actualización del modelo que rompió sus prompts y qué hicieron a continuación.
• Certificados sustituyendo al juicio demostrado, y una incomodidad cuando se le pide trabajar con un conjunto de casos que falla en vivo.
• La afirmación de que un prompt puede arreglarlo todo, sin ningún instinto sobre cuándo un problema es realmente de recuperación de información o de datos.

El umbral no es «¿usamos IA?», todo el mundo lo hace ahora. Es «¿cambia una persona que mueve la calidad de la salida unos puntos una métrica de negocio que nos importa?». Automatización de soporte donde una pequeña caída en la calidad de resolución se refleja en el churn; un sistema de contenidos que genera en volumen donde la deriva es un riesgo de marca; instrucciones de agentes que se ejecutan sin supervisión donde un mal caso límite cuesta dinero. Si la calidad del prompt es genuinamente el producto, contrate al especialista y evalúe el bucle. Si es una habilidad compartida, contrate para la fluidez en IA en todo el equipo: la guía de contratación basada en habilidades y un proceso de entrevistas estructuradas le servirán mejor que un título especialista que no necesita.

Una descripción del puesto de ingeniero de prompts que se lea como una especificación con la que probar contratará mejor que diez plantillas pulidas que se lean como una lista de deseos. Redáctela en torno a resultados medidos, conserve la sección de fluidez en IA que todos los competidores omiten, y evalúe el bucle —no el léxico—, o seguirá confundiendo un buen vocabulario con una habilidad real.