El prompt engineering o ingeniería de prompts es la práctica de diseñar, estructurar y probar las instrucciones y el contexto que recibe un modelo para mejorar su comportamiento en una tarea concreta.
No consiste en encontrar una frase mágica. En un sistema empresarial, el prompt es una pieza versionada que trabaja junto a datos, herramientas, formato de salida, controles y evaluaciones.
Qué incluye realmente un prompt
En una aplicación, la entrada al modelo puede combinar varias capas:
- instrucciones del sistema: propósito, reglas estables y prioridades;
- petición del usuario: objetivo concreto de la interacción;
- contexto: documentos, datos, historial o estado necesarios;
- ejemplos: pares de entrada y salida que muestran el patrón esperado;
- definiciones de herramientas: acciones disponibles, parámetros y límites;
- esquema de salida: campos, tipos y condiciones que debe respetar la respuesta.
Por eso la ingeniería de prompts se solapa con la ingeniería de contexto, pero no son idénticas. La segunda decide además qué información, memoria y herramientas entran, en qué orden y con qué presupuesto.
Un método práctico
- Define el resultado. Expresa qué debe producir el sistema y para quién. Añade ejemplos de éxito y de fallo.
- Construye una línea base. Prueba una instrucción simple sobre casos representativos antes de añadir técnicas.
- Separa componentes. Distingue reglas estables, datos variables, ejemplos y formato. Evita mezclar instrucciones con contenido no confiable.
- Añade restricciones observables. Define fuentes permitidas, longitud, idioma, campos obligatorios y condiciones de abstención.
- Utiliza ejemplos cuando aporten patrón. Incluye casos variados y consistentes; no solo el ejemplo perfecto.
- Evalúa y versiona. Compara variantes sobre el mismo conjunto, registra modelo y configuración, y repite la prueba cuando cambie una dependencia.
Las guías actuales de Anthropic recomiendan establecer criterios de éxito y evaluaciones antes de optimizar prompts. Google describe el diseño de prompts como un proceso iterativo y destaca instrucciones claras, restricciones, ejemplos y formato de salida. La práctica común no es acumular trucos: es reducir ambigüedad y medir el resultado.
Ejemplo empresarial
Una empresa pide a un modelo «analiza esta reclamación y responde». El resultado mezcla resumen, decisión y texto para el cliente, sin distinguir hechos de supuestos.
El prompt revisado separa tareas: extraer campos con un esquema, citar los fragmentos que respaldan cada hecho, clasificar solo entre categorías autorizadas y devolver requiere_revision cuando falta evidencia. Una regla externa impide enviar la respuesta; la persona revisora decide después con el expediente visible.
La mejora procede de rediseñar la interfaz entre proceso y modelo, no de asignarle un personaje grandilocuente.
Técnicas que siguen siendo útiles
| Técnica | Cuándo aporta valor | Precaución |
|---|---|---|
| Instrucciones claras | Reducir ambigüedad de tarea y límites | No pueden suplir información ausente |
| Ejemplos en contexto | Mostrar categorías, tono o estructura | Deben cubrir variedad y no filtrar la prueba |
| Delimitadores y secciones | Separar instrucciones de documentos o datos | No son una barrera de seguridad por sí solos |
| Salida estructurada | Integrar la respuesta en sistemas | Es preferible usar validación de esquema cuando la plataforma la ofrece |
| Descomposición | Dividir una tarea compleja en pasos verificables | Añade llamadas, latencia y puntos de fallo |
| Herramientas | Obtener datos o ejecutar acciones | Necesitan permisos mínimos y validación fuera del modelo |
Pedir al modelo que revele un «razonamiento paso a paso» no debe tratarse como requisito universal ni como prueba de corrección. Para tareas complejas, es más útil solicitar una respuesta verificable, evidencia, cálculos comprobables o un plan de acciones; algunos modelos gestionan internamente su razonamiento y tienen instrucciones específicas.
Límites del prompt engineering
Un prompt no puede convertir una fuente incorrecta en correcta, garantizar determinismo, impedir por sí solo una inyección de instrucciones o ampliar de forma fiable capacidades que el modelo no posee. Tampoco sustituye controles de identidad, permisos, validación, observabilidad o supervisión.
Los prompts pueden comportarse de forma distinta al cambiar modelo o versión. Conserva pruebas de regresión y no migres una instrucción crítica basándote en dos ejemplos manuales.
Cuando el prompt crece para memorizar demasiadas excepciones, revisa la arquitectura. Puede ser mejor utilizar reglas, RAG, herramientas, rutas separadas o, para un patrón estable demostrado, fine-tuning.
Qué no debe confundirse con prompt engineering
- Prompt: la entrada concreta; prompt engineering es el proceso de diseñarla y evaluarla.
- Ingeniería de contexto: decide el conjunto completo de información, estado y capacidades disponibles.
- Fine-tuning: modifica parámetros con datos de entrenamiento.
- Guardrails: controles que previenen, detectan o contienen comportamientos; no deberían depender solo de instrucciones.
- Evaluación: demuestra si una configuración funciona; no es una fase opcional posterior al prompting.
La decisión útil
No guardes una biblioteca de «prompts que funcionan» sin tarea, modelo, fecha ni prueba. Conserva versiones ligadas a un conjunto de evaluación y a una decisión del proceso. Si no puedes explicar qué métrica mejoró, todavía tienes una anécdota, no una mejora.
Fuentes y lecturas recomendadas
- Anthropic: prompt engineering overview, criterios de éxito, evaluación y técnicas, consultado el 20 de agosto de 2026.
- Google AI for Developers: prompt design strategies, instrucciones, ejemplos, contexto y diseño iterativo, consultado el 20 de agosto de 2026.
- OpenAI Developers: prompt engineering, estrategias y consideraciones por tipo de modelo, consultado el 20 de agosto de 2026.
Definición y vigencia revisadas el 20 de agosto de 2026.