Prompt engineering: escribir instrucciones que aguanten producción

El prompt engineering es el oficio de escribir las instrucciones que recibe un modelo de lenguaje para que haga algo útil de forma repetible. No es un truco ni una colección de frases mágicas que alguien vende en un PDF: es trabajo de especificación, parecido a redactar el procedimiento que le darías a una persona nueva en su primer día, con la diferencia de que esta persona no pregunta cuando no entiende algo. Simplemente rellena el hueco con lo que le parece razonable.

Esa es la distancia entre el prompt que te funciona en el chat un martes por la tarde y el que resiste mil ejecuciones automáticas sin que nadie lo mire. Esta guía va de la segunda cosa: qué lleva dentro un prompt de producción, de dónde sale el contexto, cómo se evalúa si va bien y por qué, pasado cierto punto, el problema deja de ser el prompt.

¿Qué es el prompt engineering y qué no es?

Un modelo de lenguaje genera la continuación más probable de lo que le das. No tiene tu contexto, no sabe cómo se llama vuestro ERP, no conoce vuestra política de descuentos y no distingue entre lo que es obvio para ti y lo que no lo es para nadie. Todo lo que no escribas, lo inventará con lo que tenga a mano.

El prompt engineering es, por tanto, el ejercicio de eliminar ambigüedad. Sirve para:

• Fijar el formato de salida para que el resultado sea procesable por otro sistema y no un párrafo bonito.
• Acotar el alcance, diciendo explícitamente qué debe hacer y qué no debe hacer nunca.
• Dar el contexto que falta: el vocabulario de la empresa, las reglas, los casos límite.
• Hacer el comportamiento estable, de forma que dos ejecuciones con entradas parecidas den resultados parecidos.

Y no sirve para lo que mucha gente espera. Un prompt no añade información que el modelo no tiene: si la respuesta depende de vuestro catálogo, hay que meter el catálogo. No arregla un proceso mal definido: si nadie en la empresa sabe cuándo se escala una incidencia, el prompt tampoco lo sabrá. Y no sustituye a la validación: un texto bien escrito puede estar perfectamente redactado y ser falso.

Si no puedes explicarle la tarea a un becario espabilado en un folio, no tienes un problema de prompt. Tienes un problema de proceso.

¿Qué lleva dentro un prompt que funciona?

Los prompts que sobreviven en producción tienen casi siempre las mismas seis piezas. No es una fórmula cerrada, pero si falta alguna suele notarse.

| Pieza | Qué resuelve | Error típico | |---|---|---| | Rol y objetivo | Sitúa el registro y el criterio | «Eres un experto en todo» | | Tarea concreta | Define qué se produce exactamente | Pedir dos cosas distintas a la vez | | Contexto | Aporta el dato que el modelo no tiene | Pegar 40 páginas «por si acaso» | | Formato de salida | Hace el resultado procesable | Pedir JSON sin dar el esquema | | Ejemplos | Enseña el matiz difícil de explicar | Ejemplos todos del caso fácil | | Límites y escape | Evita la respuesta inventada | No decir qué hacer si falta información |

La pieza que más se olvida es la última. Un prompt de producción tiene que decir, literalmente, qué hacer cuando la información no está: «Si el documento no contiene la fecha de vencimiento, devuelve `null` en ese campo; no la deduzcas». Sin esa frase, el modelo deducirá, porque deducir es exactamente lo que hace.

Sobre los ejemplos, un matiz práctico: dos o tres ejemplos bien elegidos valen más que quince. Y deben ser los casos raros, no los fáciles. El caso fácil ya lo resuelve sin ayuda; lo que necesita ver es la factura con dos números de pedido, el correo donde el cliente dice tres cosas a la vez, el albarán escaneado torcido.

¿Cómo se convierte un prompt en una plantilla reutilizable?

En el chat escribes el prompt entero cada vez. En producción no: tienes una plantilla con huecos que se rellenan con datos de cada ejecución. Ese paso —de texto suelto a plantilla parametrizada— es lo que separa un experimento de un sistema.

Una plantilla de clasificación de correos entrantes, por ejemplo, tiene fija la instrucción, fijo el catálogo de categorías válidas, fijos los ejemplos; y variable solo el cuerpo del correo y los metadatos del remitente. Esto trae tres consecuencias que importan:

1. La plantilla es código. Vive en el repositorio, se revisa antes de cambiarla y tiene historial. Si alguien edita la lista de categorías, queda registrado quién y cuándo. 2. Tiene versión. Cuando el resultado empeora el lunes, la pregunta «¿qué versión del prompt estaba activa el viernes?» tiene respuesta. Sin esto, la depuración es adivinación. 3. Se puede probar sola. Una plantilla con huecos se ejecuta contra un conjunto de casos guardados y se compara con lo esperado. Un prompt escrito a mano en una ventana, no.

Separa además lo que cambia cada semana de lo que no. Las reglas de negocio volátiles —umbrales, listas de proveedores, excepciones— es mejor que entren como contexto desde una fuente de datos que estar escritas dentro del prompt, donde se quedan obsoletas en silencio.

¿De dónde sale el contexto?

Aquí está el 80% del resultado y la parte de la que menos se habla. La calidad de la respuesta depende mucho más de qué información acompaña a la pregunta que de cómo esté redactada la pregunta.

Hay tres formas de meter contexto, de menos a más esfuerzo:

• Fijo en la plantilla. Vale para lo estable: el glosario de la empresa, el tono, las categorías. Si cabe en media página y cambia una vez al año, va aquí.
• Inyectado desde los sistemas. Para el dato del caso concreto: la ficha del cliente desde el CRM, el histórico de pedidos, el estado del ticket. Es una consulta normal a vuestras bases, no magia.
• Recuperado de un repositorio documental. Cuando la respuesta puede estar en cualquiera de diez mil documentos y no sabes cuál de antemano. Es lo que resuelve RAG, y conviene leerlo antes de montarlo porque falla cuando el repositorio está sucio.

Un aviso que ahorra dinero: más contexto no es mejor contexto. Pasar un documento entero cuando bastan dos párrafos encarece cada llamada, ralentiza la respuesta y —esto sorprende a mucha gente— empeora la precisión, porque la instrucción importante queda sepultada entre texto irrelevante. Recortar el contexto suele subir la calidad y bajar la factura a la vez.

¿Cómo se evalúa un prompt sin engañarse?

«Funciona bien» no es una medida. Si vas a poner esto en un proceso real, necesitas saber cuándo empeora, y para eso hace falta un conjunto de casos de prueba. No es nada sofisticado:

1. Reúne entre 30 y 50 casos reales. Sacados de vuestro histórico, no inventados. Incluye deliberadamente los raros y los que salieron mal. 2. Escribe la respuesta correcta de cada uno. Esto lo hace quien domina el proceso, no quien escribe el prompt. Es la parte más cara y la que no se puede saltar. 3. Define qué es acertar. Para datos extraídos, coincidencia exacta del campo. Para textos, una lista de comprobación de tres o cuatro criterios: ¿responde a lo que se pregunta?, ¿cita la fuente?, ¿respeta el formato?, ¿evita afirmar lo que no sabe? 4. Mide antes de tocar nada. Ejecuta el conjunto completo y apunta el resultado. Esa es tu línea base. 5. Cambia una cosa cada vez. Si tocas tres cosas y mejora, no sabes cuál funcionó ni cuál estaba empeorando a la vez. 6. Repite el conjunto entero en cada cambio. Es la prueba de regresión: lo normal es arreglar un caso y romper dos que iban bien.

Con esto montado, la conversación cambia de «a mí me parece que responde mejor» a «hemos pasado de 41 a 46 aciertos sobre 50, y los cuatro fallos nuevos son todos del mismo tipo». La segunda frase permite decidir; la primera, no.

Vigila también la deriva. Los modelos se actualizan y el prompt que iba fino en marzo puede comportarse distinto en septiembre sin que hayáis tocado una coma. Pasar el conjunto de casos una vez al mes cuesta poco y evita descubrirlo por una queja de un cliente. Es la misma lógica de monitorización que explicamos en MLOps para empresas.

¿Por qué el prompt no sustituye al proceso?

Llega un momento, normalmente a las tres o cuatro iteraciones, en que el prompt deja de ser el cuello de botella. Las señales son bastante reconocibles:

• El prompt ocupa tres páginas y cada excepción nueva añade un párrafo.
• Dos personas del equipo no se ponen de acuerdo en cuál es la respuesta correcta de un caso del conjunto de prueba.
• Los fallos que quedan son todos por información que no está en ningún sitio.
• Nadie sabe decir quién revisa la salida antes de que llegue al cliente.

Ninguno de esos cuatro se arregla escribiendo mejor. El primero se arregla partiendo la tarea en dos pasos más pequeños. El segundo es un desacuerdo de negocio disfrazado de problema técnico: hay que resolverlo en una reunión, no en un editor. El tercero es un problema de datos. Y el cuarto es diseño de proceso: quién valida, con qué criterio y qué pasa cuando el sistema no está seguro.

Ese último punto merece una regla fija: define el umbral de intervención humana antes de poner nada en marcha. Qué casos pasan solos, cuáles van a revisión y quién los revisa. Si esa decisión se deja para después, en la práctica significa que nadie revisa nada. Lo mismo aplica a qué información puede salir de casa, que debería estar escrito en vuestra política de uso de IA y no en la cabeza de cada uno.

Errores que vemos una y otra vez

• Pedir dos trabajos en un prompt. «Resume y clasifica y redacta la respuesta» da tres resultados mediocres. Tres pasos encadenados dan tres resultados evaluables por separado.
• Prohibir en negativo sin dar la alternativa. «No inventes» funciona mucho peor que «si el dato no aparece en el texto que te paso, responde: no consta».
• Coleccionar prompts en un documento compartido. Acaba con catorce versiones, ninguna fechada y nadie sabiendo cuál es la buena. Repositorio o nada.
• Confundir que suene bien con que esté bien. Estos modelos escriben con seguridad absoluta tanto cuando aciertan como cuando no. La seguridad del tono no es señal de nada.
• No medir el coste por ejecución. Un prompt con contexto generoso multiplicado por veinte mil ejecuciones al mes es una partida presupuestaria, no un detalle.
• Formar al equipo con trucos en vez de con criterio. Lo útil no es la lista de frases mágicas, es entender qué información necesita el modelo. Lo tratamos en formación en IA para equipos.

Preguntas frecuentes

¿Hace falta contratar a un prompt engineer?

Como puesto aislado, casi nunca. Lo que funciona es que la persona que domina el proceso —la que sabe cuándo una factura es correcta o cómo se responde a una reclamación— trabaje con alguien que sepa montar la plantilla, la evaluación y la integración. El conocimiento difícil de conseguir es el del negocio, no el de redactar instrucciones.

¿Un prompt largo da mejores resultados que uno corto?

No por ser largo. Lo que mejora el resultado es la información pertinente y la ausencia de ambigüedad, y eso a veces exige extensión y a veces la penaliza. Si añades un párrafo y el conjunto de casos de prueba no mejora, quítalo: estás pagando por tokens que no aportan.

¿Los prompts sirven igual si cambiamos de modelo?

Trasladan bastante bien la estructura, pero no el comportamiento fino. Al cambiar de modelo hay que volver a pasar el conjunto de casos y, normalmente, ajustar el formato de salida y los ejemplos. Es una tarde de trabajo si tienes la evaluación montada, y una semana a ciegas si no la tienes.

¿Dónde guardamos los prompts de la empresa?

En el mismo sitio que el código que los usa, con control de versiones y revisión de cambios. Un documento compartido es cómodo el primer mes y una fuente de incidentes a partir del tercero, porque no hay forma de saber qué versión produjo qué resultado.

---

Si estás en el punto de llevar esto de las pruebas sueltas a algo que funcione dentro de un proceso real, lo que decide el resultado no es la redacción: es qué datos hay disponibles, quién valida la salida y dónde encaja en el flujo que ya existe. Eso es lo que miramos en la auditoría, y de ahí sale un plan con casos priorizados y lo que exige cada uno. Si ya lo tienes identificado y quieres contrastar el diseño con quien ha puesto unos cuantos en producción, hablemos.