Prompting: ¿competencia especializada o competencia profesional básica?

Dos discursos que impiden pensar

El primero acompañó la llegada de los modelos generativos al gran público: el prompting sería una disciplina nueva, con sus expertos y sus recetas. El segundo llegó como reacción, a medida que los modelos toleraban formulaciones imperfectas: si basta con pedir con normalidad, el tema ya no existiría.

Ambas posturas comparten un defecto: hablan de objetos distintos sin decirlo. Escribir una petición clara a un asistente para redactar un acta y diseñar la instrucción de sistema de un servicio que atiende miles de peticiones al día no son la misma actividad. Lo primero es uso. Lo segundo es una pieza de ingeniería. Confundirlos genera debates circulares y, dentro de las empresas, expectativas mal calibradas.

Este análisis no predice ni el auge ni la desaparición de un puesto de Prompt Engineer. Describe qué abarca en concreto la palabra «prompting» según el contexto y dónde está la dificultad real.

El prompting como competencia profesional general

Para quien usa sistemas de IA en su trabajo — análisis, redacción, síntesis, exploración, preparación de decisiones — el prompting no es una disciplina. Es la extensión de una competencia mucho más antigua: saber formular una petición. Lo que separa un uso eficaz de uno frustrante se reduce a unos pocos comportamientos, todos transferibles entre herramientas.

• Enunciar con claridad el objetivo: qué se busca y para qué servirá la salida. Una petición sin finalidad devuelve una respuesta genérica.
• Aportar el contexto útil: el material, el público, lo ya intentado, lo que queda fuera. El modelo no conoce la situación.
• Explicitar restricciones y formato: extensión, tono, estructura, nivel de detalle, idioma. Muchas decepciones vienen de un formato implícito.
• Iterar en lugar de pedirlo todo de golpe: corregir, acotar, pedir una variante, pedir que se explicite un razonamiento cuando aporta.
• Verificar la respuesta: contrastar hechos, cifras, citas y referencias. Una salida bien escrita no es una salida exacta.
• Saber cuándo no fiarse del resultado: temas donde el error sale caro, información reciente, ámbitos regulados, ausencia de fuente verificable.

Este nivel se transmite en unas horas de práctica acompañada. Produce una mejora real e inmediata y no justifica un título profesional. Sí empieza, en cambio, a figurar de forma implícita en muchas expectativas laborales, igual que usar bien una hoja de cálculo o un buscador documental.

El verdadero indicador de madurez: la verificación

La diferencia más visible entre dos usuarios no está en la formulación, sino en qué hacen con la respuesta. Uno la toma tal cual; otro sabe qué partes son verificables, cuáles no, y deja de usar la salida cuando la incertidumbre supera lo que el contexto permite. Ese juicio es una competencia profesional, no técnica.

El prompting como componente de un producto de IA

El asunto cambia de naturaleza en cuanto el prompt deja de escribirlo una persona para sí misma y pasa a ser una pieza de un sistema que se ejecuta de forma automática, para usuarios que no lo ven ni pueden corregirlo. El prompt es entonces código: tiene interfaz, dependencias, versiones, efectos secundarios y costes.

• Plantillas y variables: el prompt está parametrizado; lo que varía debe identificarse, escaparse y controlarse, también cuando la entrada viene del usuario.
• Instrucciones de sistema: definen el rol, el alcance, las prohibiciones y el comportamiento ante la duda. Suelen ser el lugar donde se juega la seguridad funcional.
• Contexto: qué se incluye, de dónde viene, cómo se selecciona, qué se hace cuando es demasiado largo o está vacío.
• Salidas estructuradas: un sistema aguas abajo consume la respuesta; el formato debe estar garantizado y hay que definir qué ocurre cuando no se respeta.
• Tool use: cuando el modelo puede desencadenar acciones, la cuestión pasa a ser de permisos, reversibilidad y validación humana.
• Versionado: un prompt modificado es un despliegue. Sin histórico, nadie puede explicar por qué cambió el comportamiento.
• Evaluación y regresiones: un conjunto de casos que se vuelve a ejecutar en cada cambio; si no, cada mejora local se paga en otro sitio sin que se note.
• Seguridad: entradas hostiles, intentos de secuestro de instrucciones, filtración de información presente en el contexto.
• Coste y latencia: la longitud del prompt y del contexto se paga en cada llamada y se nota en cada interacción.

En este plano, «escribir un buen prompt» es una competencia entre una docena, y rara vez la más limitante. Lo que bloquea un sistema en producción suele ser los datos, la evaluación, el tratamiento de los casos límite y la orquestación, no la elegancia de la redacción.

Comparativa: prompt personal y prompt de producción

Tomemos una misma necesidad: resumir una reclamación de cliente para preparar una respuesta. La versión personal y la integrada en un producto no responden a los mismos criterios de calidad.

El segundo no es «el mismo prompt mejor escrito». Es un componente de software del que el texto es solo una parte. Por eso la pregunta «¿hace falta un especialista en prompting?» no tiene respuesta general: depende del lugar del prompt en el sistema.

Qué desplaza realmente la evolución de los modelos

Las generaciones recientes siguen mejor las instrucciones, toleran formulaciones aproximadas y exigen menos contorsiones. Parte de las técnicas artesanales de los inicios — fórmulas rituales, estructuras rígidas, descomposiciones complejas para sortear limitaciones — pierde interés. Es un hecho observable y explica el segundo discurso.

Pero esa erosión afecta a la capa más superficial. No cambia nada de lo que queda fuera del modelo.

• El encuadre: un modelo más dócil no inventa el problema que hay que resolver, ni el alcance, ni los casos prohibidos.
• El contexto: la calidad de lo que se aporta sigue siendo determinante; ningún modelo adivina información a la que no accede.
• La evaluación: saber si una versión es mejor que otra es trabajo de medición, independiente de la generación del modelo.
• La orquestación: encadenar etapas, llamar a herramientas, gestionar fallos y reintentos sigue siendo ingeniería.
• El control: permisos, trazabilidad, comportamiento ante la duda y lugar de la validación humana.

Dicho de otro modo: los modelos absorben poco a poco los trucos, no las responsabilidades. Lo que es una decisión — qué debe hacer el sistema, con qué datos, hasta dónde y cómo se comprueba — no se delega en el modelo.

Situar con honestidad la propia práctica

Para un profesional, la cuestión no es zanjar un debate público, sino describir su nivel sin prometer de más. Se distinguen con claridad tres posiciones, y no abren las mismas puertas.

• Uso profesional: utilizo estos sistemas con regularidad en mi trabajo, sé formular, iterar, verificar y detectar los casos en los que no debo apoyarme en la salida.
• Diseño de uso: he construido modos operativos para un equipo, he definido qué puede delegarse al sistema y qué no, y he acompañado la adopción.
• Componente de producto: he contribuido a prompts integrados en un producto, con evaluación, tratamiento de casos límite, versionado y seguimiento del comportamiento en producción.

Las tres formulaciones son verificables en una entrevista. «Experto en prompt engineering» no lo es, y se vuelve pronto contra quien la usa. Describir el nivel real, con contexto y resultado, es a la vez más modesto y mucho más sólido.

• Prompting
• Cultura de IA
• Copilotos