Qué es un Prompt Engineer y qué hace en una empresa

El rol con más ruido de mercado: por qué casi nadie lo contrata bien

Cuando una empresa me pide ayuda para “contratar un Prompt Engineer”, la primera pregunta que hago no es sobre el perfil: es qué proceso quieres que mejore y cómo vas a saber que mejoró. En la mayoría de los casos no hay respuesta. Hay una intuición de que la empresa se está quedando atrás, un presupuesto aprobado por presión de directorio y un título que se vio en LinkedIn con un sueldo llamativo. Eso no es una vacante, es una compra de tranquilidad.

El desenlace se repite. Se contrata a alguien con buen manejo de las herramientas, se le da una cuenta empresarial y se espera que “traiga ideas de IA”. La persona produce demos, plantillas y una biblioteca interna de prompts que casi nadie usa después del tercer mes. No es incompetencia: nadie le entregó un proceso concreto con un dolor medible, y sin eso ningún rol de IA produce resultados. La reacción opuesta es igual de perezosa: declarar que el prompt engineering “ya murió” porque los modelos entienden mejor las instrucciones. Eso confunde una habilidad con un puesto.

Qué es de verdad el rol, más allá de escribir instrucciones bonitas

La palabra que define el trabajo es repetible. Cualquiera puede lograr que un modelo produzca una buena respuesta una vez, en una demo, con un caso elegido a mano. El oficio empieza cuando esa respuesta tiene que salir bien casi siempre, con entradas desordenadas, con clientes reales del otro lado y sin que alguien la revise una por una. Ahí es donde la mayoría de proyectos de IA se cae, y no por culpa del modelo.

Visto así, el rol se parece mucho menos a un redactor creativo y mucho más a alguien que hace control de calidad de un proceso. La materia prima no es la frase ingeniosa: son los casos reales de la operación, las excepciones que rompen la regla, las políticas internas que el modelo debe respetar y los datos que necesita a la vista para no inventar. El nombre describe la parte visible del trabajo, no la que genera valor: es como llamar “tipeador de consultas” a un analista de datos porque escribe SQL.

Qué hace en la operación concreta de una empresa

La vacante típica pide “dominio de técnicas avanzadas de prompting” y “creatividad para diseñar instrucciones”. La operación pide otra cosa: criterio de proceso, disciplina de medición y capacidad de conversar con un jefe de operaciones sin hablarle en técnico. En una empresa que ya tiene sistemas de IA funcionando, el día a día del perfil se ve así, y nada de esto suena glamoroso: justamente por eso separa a quien produce resultados de quien colecciona técnicas.

• Traduce una regla de negocio en una instrucción operable: se sienta con el área dueña del proceso, entiende qué respuesta es correcta y cuál es inaceptable, y lo convierte en criterios explícitos que un supervisor pueda auditar.
• Arma el set de casos de prueba: reúne cientos de ejemplos reales de la operación, incluidos los feos, y define la respuesta esperada de cada uno. Sin ese activo no hay forma honesta de decir si el sistema mejoró.
• Decide qué contexto ve el modelo y cuál no: qué documentos, qué historial, qué datos del cliente, qué políticas. Esa decisión pesa más en la calidad final que cualquier ajuste de redacción.
• Diagnostica la falla correcta: distingue si el error vino de una instrucción ambigua, un dato faltante, un proceso mal definido o un límite real del modelo. Cada causa tiene solución distinta y confundirlas cuesta semanas.
• Controla costo y latencia: más contexto suele dar mejores respuestas, y también cuesta más y responde más lento. Encontrar el punto sostenible para el negocio es parte del trabajo.
• Mantiene el sistema vivo: cuando el proveedor actualiza el modelo, cambia una política o aparece un tipo de caso nuevo, alguien vuelve a correr las pruebas y ajusta. Eso es lo que nadie presupuesta y lo que decide si la inversión sobrevive al primer año.

Por qué el puesto aislado se está diluyendo y hacia dónde migró el valor

Acá viene la parte incómoda y prefiero decirla directo: como puesto independiente, el Prompt Engineer se está diluyendo. No porque la habilidad haya perdido valor, sino porque el problema real dejó de estar en la instrucción y pasó a estar en el sistema que rodea al modelo. Esa es la diferencia entre escribir un buen prompt y hacer ingeniería de contexto: decidir qué información llega al modelo, en qué momento y con qué límites.

Los modelos actuales interpretan instrucciones razonables sin trucos de redacción. Lo que siguen sin poder hacer es adivinar el dato que no les diste, la política que nadie escribió o el criterio que operaciones tiene en la cabeza y nunca formalizó. Por eso los errores que hoy rompen un sistema en producción casi nunca se arreglan reescribiendo el prompt: se arreglan arreglando el contexto, las herramientas conectadas y el proceso de fondo.

El valor migró en tres direcciones a la vez. Hacia la ingeniería de contexto y los datos: quién decide qué ve el modelo. Hacia el diseño de sistemas: cómo se conectan modelo, herramientas, memoria y controles para que la tarea se complete de punta a punta. Y hacia la evaluación: cómo mides de forma continua que el sistema hace lo que dice hacer.

Cuándo tiene sentido contratarlo y cuándo es un error caro

Cuándo sí, como capacidad dedicada

• Ya tienes sistemas de IA en producción tocando clientes, dinero o decisiones operativas, y cada error tiene un costo visible.
• Hay volumen suficiente para que la calidad sea un problema estadístico y no anecdótico: miles de interacciones al mes, no diez pruebas del gerente.
• El dominio es especializado y definir qué respuesta es correcta exige conocimiento profundo del negocio: normativa, contratos, salud, soporte técnico complejo.
• Ya hay un equipo técnico que construye el sistema y lo que falta es alguien dueño de la calidad, con tiempo dedicado a medir y corregir.

Cuándo no, y conviene resolverlo de otra forma

• Todavía no hay proceso definido ni caso de uso elegido. Contratar acá es pagarle a alguien para que descubra qué debería estar haciendo, y ese trabajo es de dirección.
• El objetivo real es que el equipo use mejor las herramientas de IA en su día a día. Eso es capacitación y diseño de flujos, no una contratación técnica.
• Hay un solo caso de uso y sigue en fase de prueba. Con apoyo externo por unas semanas aprendes más que con una contratación permanente prematura.
• La empresa no tiene datos ordenados ni procesos documentados. Ningún prompt compensa eso, y la persona termina siendo el pararrayos de una falla anterior.
• En la mayoría de empresas medianas la salida real es una tercera: tomar a alguien que ya conoce el proceso desde adentro y darle tiempo protegido, herramientas y acompañamiento técnico. El criterio del negocio es lo más difícil de enseñar.

Cómo evaluar a un candidato sin dejarte impresionar por el vocabulario

Esta es la regla que aplico y que le pido a todo cliente que use sin excepción: este perfil se evalúa por el resultado de negocio que produce, no por certificaciones ni por colecciones de prompts. Alguien que solo sabe nombrar técnicas y no puede explicar qué proceso mejoró es señal débil, por más fluido que suene y por más insignias que tenga en el perfil.

El vocabulario de este campo es fácil de aprender y difícil de verificar en una conversación corta: alguien puede hablar con soltura de cadenas de razonamiento y ventanas de contexto sin haber puesto nunca un sistema frente a un cliente real. Por eso la entrevista no debe ser una prueba de vocabulario, debe ser la reconstrucción de un caso, con las preguntas incómodas incluidas.

• Pide un proceso concreto: qué hacía la empresa antes, qué hace ahora y quién adentro nota la diferencia.
• Pide el número inicial y el final: qué porcentaje de casos resolvía bien la primera versión y cuánto resuelve hoy. Si nunca midió, no trabajó en producción.
• Pregunta cómo armó el set de pruebas y de dónde salieron los casos. Ahí se ve si trabajó con datos reales de la operación o con ejemplos inventados.
• Pregunta por el fracaso: qué caso no logró resolver y qué decidió hacer. Quien nunca chocó con un límite no estuvo cerca del problema.
• Pídele que le explique el sistema a alguien de operaciones sin jerga. Si no puede, tendrá ese mismo problema todos los días dentro de tu empresa.
• Revisa si distingue un problema de instrucción, uno de datos y uno de proceso mal definido. Confundir los tres es el error más caro del rol.

Una biblioteca de prompts no es un portafolio: equivale a que un contador te muestre su colección de fórmulas de Excel. Lo que importa es qué cerró, qué ordenó y qué decisión permitió tomar en una empresa de verdad. Si el candidato no tiene un caso propio porque recién empieza, está bien, pero entonces lo contratas como junior y el rol necesita a alguien encima con criterio de sistema.

Errores típicos que veo en empresas reales

• Crear la vacante antes que el caso de uso, para “explorar IA”, y luego sorprenderse de que no haya resultados atribuibles a nueve meses de salario.
• Colgar el rol de sistemas o de innovación, lejos del área que sufre el dolor. Sin acceso directo al proceso y a su gente, la persona trabaja a ciegas.
• Medir su desempeño por cantidad de prompts creados, plantillas publicadas o capacitaciones dictadas. Son métricas de actividad y ninguna dice si la operación mejoró.
• Confundirlo con un rol de contenido. Redactar textos de marketing con ayuda de IA es otra cosa, se evalúa distinto y no requiere el mismo perfil.
• No presupuestar el mantenimiento. Los sistemas se degradan cuando cambian los modelos, los procesos y los casos, y esa deuda aparece a los seis meses.

Cómo medir si el rol está funcionando

Un rol de IA sin métrica de negocio se vuelve indefendible frente a cualquier recorte de presupuesto, y con razón. Estas son las señales que le pido a un cliente que revise a los tres y a los seis meses. No cuentan como medición la cantidad de prompts en la biblioteca interna, las presentaciones al directorio ni las herramientas nuevas evaluadas.

• Porcentaje de casos que el sistema resuelve sin intervención humana, medido siempre sobre el mismo set de prueba, no sobre ejemplos elegidos a conveniencia.
• Tiempo de ciclo del proceso que el sistema toca, comparado contra la línea base previa a la implementación.
• Volumen de correcciones o reclamos generados por respuestas incorrectas, y su tendencia mes a mes.
• Cuántos procesos distintos de la empresa usan hoy lo que esa persona construyó, frente a cuántos lo usaban al inicio.
• Costo por caso resuelto, incluyendo consumo del modelo y horas de revisión humana, contra el costo del proceso manual anterior.
• Si el área operativa defiende el sistema cuando algo falla o lo desconecta a la primera queja. Esa reacción dice más que cualquier reporte.