El Prompt Engineer no es un programador: es el intérprete entre el negocio y la IA
La mayoría de las organizaciones tratan el prompting como una habilidad técnica menor. Es en realidad una capacidad de diseño que requiere entender el problema de negocio, la lógica del modelo y los criterios de evaluación al mismo tiempo.
Cuando una organización decide contratar a alguien con el título de “Prompt Engineer,” la primera pregunta que surge en el área de RRHH es invariablemente la misma: ¿en qué departamento va? ¿Tecnología? ¿Marketing? ¿Operaciones? La pregunta revela una confusión de fondo: se asume que el rol pertenece a una disciplina técnica porque tiene la palabra “engineer” en el nombre, cuando en realidad es un rol de interfaz que opera en la intersección de múltiples dominios. Esa confusión sobre dónde poner al Prompt Engineer en el organigrama es síntoma de una confusión más profunda sobre qué hace realmente ese rol — y por qué cada vez más organizaciones lo necesitan.
El error del prompting como habilidad técnica
El error más común es tratar el prompting como una habilidad técnica: una serie de trucos y técnicas que cualquier persona con algo de experiencia en IA puede aprender en un taller de dos días. Bajo esta concepción, el Prompt Engineer es básicamente alguien que sabe “hablarle bien a ChatGPT” — una habilidad útil pero periférica, que puede terciarizarse o distribuirse entre el equipo existente.
Esta concepción produce resultados predecibles: los prompts funcionan bien en las demos, fallan en producción, y nadie entiende por qué. El equipo de tecnología dice que el problema es el modelo. El equipo de negocio dice que el problema es la implementación técnica. Nadie tiene el perfil para diagnosticar que el problema real es una brecha de diseño: el prompt no está construido para el caso de uso real, no considera los casos borde, no tiene criterios de evaluación definidos, y no refleja el contexto organizacional que hace que una respuesta sea útil.
La investigación sobre prompting en contextos organizacionales muestra que la diferencia de rendimiento entre un prompt bien diseñado y uno improvisado no es marginal. Pornprasit y Tantithamthavorn (2024) demostraron que en tareas de revisión de código automatizada, los enfoques de few-shot learning con prompts diseñados cuidadosamente superaron a los zero-shot en 46-659% en métricas de exactitud. La brecha entre “prompting básico” y “prompting diseñado” es una brecha de capacidad real, medible, con impacto directo en los resultados.
Qué hace realmente un Prompt Engineer
Un Prompt Engineer diseña la interfaz entre la capacidad del modelo y el problema de negocio. Eso requiere tres competencias que raramente coexisten en un mismo perfil:
Comprensión del problema de negocio. El Prompt Engineer necesita entender en profundidad el proceso que se está automatizando o augmentando: qué inputs recibe, qué outputs produce, cuáles son los casos normales y los casos borde, cuál es el costo de un error y cuál es el costo de un falso negativo. Sin esta comprensión, el prompt optimiza para una métrica equivocada — produce outputs que parecen correctos pero que no son útiles para el contexto específico.
Comprensión del modelo. No como programador del modelo, sino como usuario informado: qué tipos de instrucciones produce resultados más consistentes, cómo afecta el formato del prompt a la calidad del output, cuándo la especificidad ayuda y cuándo limita, cómo gestionar la variabilidad inherente de los modelos generativos. Golani (2025) documentó que las decisiones de implementación — qué tan detalladas son las instrucciones, si se usan ejemplos, cómo se estructura el contexto — tienen impacto comparable a las decisiones de selección del modelo en sí.
Capacidad de evaluación. El Prompt Engineer tiene que poder definir qué significa “bueno” para un output dado, diseñar criterios de evaluación antes de construir el prompt, y evaluar sistemáticamente el rendimiento a través de casos representativos. Sin esta capacidad, el diseño del prompt es intuición sin retroalimentación — se optimiza para los casos que se vieron, no para los casos que importan.
La posición organizacional correcta
La confusión sobre dónde poner al Prompt Engineer en el organigrama no es trivial — refleja una decisión estratégica sobre cómo la organización entiende la IA. Si el Prompt Engineer va a Tecnología, el riesgo es que los proyectos se optimicen para la elegancia técnica y la coherencia de la arquitectura, pero que los problemas de negocio se definan vagamente. Si va a una unidad de negocio específica, el riesgo es la fragmentación: cada área desarrolla sus propias prácticas sin transferencia de conocimiento.
La posición organizacional más efectiva es una que crea tensión productiva: el Prompt Engineer funciona como un especialista transversal — similar a cómo un UX designer o un analista de datos opera en muchas organizaciones — que trabaja con múltiples áreas de negocio pero con accountability por estándares de calidad que cruzan toda la organización. Esto requiere que el rol reporte a alguien con visibilidad estratégica suficiente para priorizar entre iniciativas, no a alguien que solo optimice por la urgencia del área más ruidosa.
Lo que la organización necesita antes de contratar el rol
El error más costoso es contratar un Prompt Engineer antes de que la organización esté lista para aprovecharlo. Tres condiciones necesarias:
Primero, inventario de casos de uso. Antes de contratar, la organización necesita tener claridad sobre qué problemas quiere resolver con IA. Sin este inventario, el Prompt Engineer pasa sus primeras semanas buscando dónde aplicar su expertise — un desperdicio de tiempo y señal de que la adopción de IA es reactiva, no estratégica.
Segundo, acceso a datos de evaluación. El prompting sin datos de evaluación es como diseñar sin usuarios: se puede producir algo que parece razonable, pero no hay forma de saber si funciona. La organización necesita poder proveer ejemplos de inputs reales y outputs de referencia para que el Prompt Engineer pueda evaluar sistemáticamente su trabajo.
Tercero, tolerancia a la iteración. El diseño de prompts es inherentemente iterativo: raramente se llega al prompt correcto en el primer intento, y el proceso de refinamiento requiere tiempo y capacidad de probar. Las organizaciones que esperan resultados definitivos en la primera iteración frustan al Prompt Engineer y terminan con prompts subóptimos.
La IA generativa es, fundamentalmente, una tecnología de interfaz: su valor depende críticamente de la calidad de la interfaz entre la capacidad del modelo y el problema real. El Prompt Engineer es el diseñador de esa interfaz. Las organizaciones que lo tratan como un técnico que “sabe de prompts” obtendrán resultados técnicos. Las que lo tratan como un rol de diseño estratégico — que entiende el negocio, entiende el modelo, y puede evaluar el resultado — obtendrán algo cualitativamente diferente.
Referencias
- Golani, R. R. (2025). LLM Fine-Tuning vs Prompt Engineering for Consumer Products. International Journal of Science and Applied Technology. DOI: 10.71097/ijsat.v16.i2.3098
- Pornprasit, C., & Tantithamthavorn, C. (2024). Fine-tuning and prompt engineering for large language models-based code review automation. Information and Software Technology. DOI: 10.1016/j.infsof.2024.107523