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

Ingeniería de prompts por rol: cómo se ve lo bueno

La ingeniería de prompts por rol es una habilidad clave en selección de personal, pero «bueno» difiere según sea ingeniería, análisis, soporte, SDR, PM o reclutador. Una guía por vertical.

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

Hace un año, la ingeniería de prompts sonaba como una especialidad de nicho. Ahora es una habilidad base en casi todos los roles que tocan un teclado —y para los responsables de contratación, es una de las señales de mayor valor que se puede medir, porque predice si alguien envía los errores de la IA o los detecta. Pero aquí está lo que la mayoría de los equipos pasan por alto: la ingeniería de prompts por rol no se ve igual en todos los puestos. Lo que diferencia a un buen ingeniero no es lo mismo que diferencia a un buen agente de soporte. Esta es la guía central de nuestro clúster por vertical: una guía práctica sobre cómo se ve «bueno» en cada puesto y hacia dónde ir para profundizar según el rol que estés contratando.

La ingeniería de prompts no es una sola habilidad: tiene forma de rol

La competencia subyacente es universal: dar a la herramienta contexto y restricciones claros, luego verificar y corregir lo que devuelve. Es parte de AI Fluency, y la señal más fuerte es siempre la misma: detectar cuando la IA se equivoca con seguridad. Pero la tarea y los modos de fallo son específicos del rol, por eso los trucos de redacción predicen muy poco y una tarea realista y relevante para el rol predice mucho. A continuación se describe cómo funciona en los seis verticales que evaluamos, seguido de la guía en profundidad de cada uno.

Por qué el prompting se convirtió en una señal de contratación

Durante la mayor parte de la última década, las herramientas que usaba un candidato en el trabajo eran invisibles para la evaluación. Se medía el resultado e se infería la habilidad. Las herramientas de IA rompieron esa línea clara. Un entregable de aspecto convincente puede ser el trabajo cuidadoso del propio candidato, o puede ser un pegado sin revisar de un modelo que estaba sutil y costosamente equivocado. La brecha entre esos dos resultados es exactamente lo que mide la ingeniería de prompts: no si alguien puede producir una respuesta plausible, sino si puede distinguir una buena respuesta de una plausible.

Por eso el prompting se ha convertido silenciosamente en una de las cosas de mayor apalancamiento que se puede evaluar. Contratar a alguien que confía en el modelo sin espíritu crítico es contratar un canal para sus errores; contratar a alguien que trata cada resultado como un borrador a verificar es contratar un multiplicador. La diferencia no aparece en un CV, y rara vez aparece en una conversación sobre cómo alguien usa la IA —las personas se describen como cuidadosas con mucha más frecuencia de lo que lo son. Aparece cuando se les observa trabajando en una tarea real, que es el argumento completo para evaluarlo directamente.

La habilidad universal y el matiz específico del rol

Todo prompt sólido tiene la misma forma en su base. El candidato aporta el contexto que el modelo no podría haber adivinado, establece las restricciones que importan y —crucialmente— lee el resultado con suspicacia en lugar de alivio. Donde los roles divergen es en cómo se ve «error» y cuánto cuesta no detectarlo. El error de un ingeniero compila y envía un bug; el de un analista se convierte en un número en una presentación para el consejo; el de un agente de soporte llega a un cliente ya frustrado. El músculo de verificación es universal, pero sólo puedes ver si un candidato lo tiene dándole un modo de fallo de su trabajo real para que lo detecte.

Ingeniero de software

Pide a un asistente que escriba un cliente de API asíncrono con lógica de reintentos. Un candidato sólido especifica las restricciones desde el principio —patrones asíncronos modernos, manejo explícito de errores en las excepciones correctas—, lee el código generado y detecta los problemas sutiles: una llamada obsoleta, un reintento que silencia el error equivocado, un caso límite que falta. Luego los corrige y prueba. Un buen prompt aquí es inseparable de la revisión de código. Descubre qué más evaluar en una evaluación de ingeniero de software.

• Bueno: restringe la solicitud, lee el resultado, detecta código obsoleto o inseguro, verifica con una prueba rápida.
• Débil: pega la función generada y la envía, con casos límite sin manejar y todo.

Analista de datos

Pide una consulta SQL —digamos, ingresos netos por mes excluyendo cuentas de prueba internas— o la interpretación de un resultado. Un candidato sólido define la métrica y las exclusiones en el prompt, verifica los números contra lo que ya sabe y cuestiona un agregado convincente pero engañoso en lugar de pegarlo en un informe. La habilidad de prompting y el juicio analítico son el mismo músculo. Más en la evaluación de analista de datos.

• Bueno: especifica la métrica y las exclusiones, verifica el resultado, desconfía de un número que los datos no respaldan.
• Débil: acepta una consulta plausible, reporta una cifra que silenciosamente no cuadra.

Atención al cliente

Pide a la IA que redacte una respuesta a un cliente frustrado. Un candidato sólido le da la política relevante y el tono que quiere, luego verifica la exactitud del borrador, suaviza todo lo que suena robótico o condescendiente, y elimina una promesa exagerada que el modelo incluyó. En soporte, el prompt es solo la mitad del trabajo: la edición es donde se muestra el juicio. Consulta la evaluación de atención al cliente.

• Bueno: aporta política y tono, verifica la exactitud, ajusta hacia una empatía genuina, elimina las promesas excesivas.
• Débil: envía una respuesta genérica de IA que es incorrecta en cuanto a política o tonalmente inadecuada.

Desarrollo de ventas

Pide un correo en frío para un perfil específico. Un candidato sólido proporciona a la herramienta contexto real —quién es el comprador, la propuesta de valor, la única solicitud clara—, personaliza el resultado, lo reduce a algo que un vicepresidente ocupado leería realmente, y detecta cualquier «hecho» alucinado sobre el prospecto antes de que salga. El prompt lo prepara; el juicio lo hace creíble. Más en la evaluación de desarrollo de ventas.

• Bueno: aporta contexto, personaliza, ajusta a una solicitud concisa, detecta un detalle inventado.
• Débil: envía una ráfaga genérica de plantilla, a veces con un dato inventado.

Product manager

Pide un primer borrador de una especificación o una priorización. Un buen PM formula el problema y las restricciones con claridad, usa la IA para obtener un punto de partida rápido y luego aplica un juicio de producto real: detecta una suposición incorrecta, reduce el alcance que el modelo sobreañadió, lo ancla en usuarios y métricas en lugar de enviar el borrador tal cual. Consulta la evaluación de product manager.

• Bueno: formula el problema, usa la IA para un borrador y luego aplica juicio: detecta malas suposiciones y lo vincula a objetivos reales.
• Débil: envía una especificación generada por IA sin pensamiento de producto adicional.

Reclutador

Pide a la IA que redacte un mensaje de contacto o una rúbrica de criba. Un reclutador sólido aporta el contexto del rol y las señales imprescindibles, luego verifica el resultado buscando sesgo, relleno genérico y cualquier afirmación sobre el rol que no sea realmente cierta, y lo reescribe en algo en lo que un candidato confiaría. Hacer prompts bien aquí es juicio de talento en otra forma: saber cómo se ve lo bueno antes de que el modelo lo adivine. Más sobre el lado del reclutamiento en cómo contratar a un reclutador.

• Bueno: aporta contexto del rol y señales, revisa el resultado en busca de sesgo y relleno, mantiene toda afirmación verdadera.
• Débil: envía una ráfaga genérica escrita por IA que exagera el rol y parece spam.

Profundiza: una guía completa para cada rol

Cada vertical tiene su propia guía en profundidad: las mejores prácticas, un prompt trabajado, las señales de buen y mal desempeño y cómo se evalúa:

• Ingeniería de prompts para ingenieros de software: el prompting como revisión de código a la inversa.
• Ingeniería de prompts para analistas de datos: definiciones precisas y luego desconfiar del número.
• Ingeniería de prompts para atención al cliente: el borrador es fácil, la edición es el trabajo.
• Ingeniería de prompts para desarrollo de ventas: contexto dentro, credibilidad fuera.
• Ingeniería de prompts para product managers: la IA hace borradores, el juicio decide.
• Ingeniería de prompts para reclutadores: juicio de talento aplicado al modelo.

Dos errores habituales en la evaluación

El primer error es el cuestionario de prompts: pedirle a los candidatos que describan cómo redactarían una solicitud, o evaluarlos por su conocimiento de trucos de prompting. Esto mide vocabulario, no juicio, y es trivialmente falseable por cualquiera que haya leído algunos hilos sobre el tema. El segundo error es la sobrecorrección contraria: prohibir la IA en la evaluación porque te preocupa el fraude. Eso evalúa el trabajo tal como existía hace dos años, no como se hace hoy, y filtra a los candidatos equivocados: los que no pueden trabajar con las herramientas que todos los demás ya usan.

Ambos errores comparten una causa raíz: tratan el prompting como algo que se sabe en lugar de algo que se hace. La solución es dejar de evaluar el conocimiento sobre la IA y comenzar a observar la colaboración con ella, en una tarea que lleva los modos de fallo del rol real. Ese reenfoque también resuelve la preocupación por la integridad, porque cuando se espera el uso de la IA y la tarea se genera por puesto, la ruta más rápida hacia un buen resultado es la habilidad genuina: la misma lógica detrás de nuestro enfoque para prevenir el fraude en evaluaciones generadas por IA.

Cómo evaluarlo

No puedes medir nada de esto con un cuestionario sobre prompts, y desde luego no puedes medirlo prohibiendo la IA. Lo mides poniendo al candidato en una tarea realista y específica del rol con herramientas de IA disponibles y observando cómo trabaja: exactamente lo que hace una evaluación en AI Sandbox y cómo se mide AI Fluency como pilar. Es la forma honesta de evaluar el trabajo tal como se hace realmente: la idea central de la contratación AI-native. También se sitúa dentro de un cuadro más amplio: el prompting es uno de los cinco pilares de una evaluación de candidatos completa, no un truco aislado.

Dado que el AI Sandbox observa la colaboración real en una tarea ajustada al rol, la misma señal subyacente —¿detecta esta persona el modelo cuando está confidentemente equivocado?— emerge en cualquier puesto para el que estés contratando. Puedes ver cómo se compone una evaluación ajustada al rol para ver dónde encaja el prompting por vertical, o comenzar con nuestra guía de contratación de AI Fluency si quieres el marco más amplio primero.

Una nota práctica para construir la evaluación: resiste la tentación de sobrestructurar la tarea. Si explicas cada restricción y cada verificación que debe realizar el candidato, has hecho su prompting por él y no aprendes nada. La señal reside en lo que piensan en añadir y en lo que piensan en cuestionar cuando el encargo es realistamente abierto: la misma ambigüedad que enfrentarán en el trabajo. Una buena tarea de ingeniería de prompts se parece menos a un examen y más a un martes por la mañana: un problema real, las herramientas que todos usan realmente, y suficiente espacio para revelar si dirigen la herramienta o si la herramienta los dirige a ellos.

Evaluada de esta forma, la ingeniería de prompts deja de ser una palabra de moda y se convierte en uno de los predictores más honestos del rendimiento en el puesto. Elige el rol para el que estás contratando del clúster anterior, lee la guía en profundidad y sabrás exactamente cómo se ve «bueno» antes de que se siente tu primer candidato.

La ingeniería de prompts no es un truco de redacción que se contrata. Es juicio bajo la equivocación confiada de una IA, y se ve diferente en cada puesto de la mesa.