Diseño de prompts para flujos productivos: del playground a producción.
Un prompt que funciona en el playground 10 veces no funciona en producción 10.000 veces. Cómo diseñar prompts robustos: system prompts, few-shot, structured outputs, evaluación contra casos, caching y monitorización de costes.
Actualizado mayo 2026
Dos disciplinas distintas con la misma sintaxis.
En el playground de Anthropic, OpenAI o Azure prueba uno o dos casos hasta que la respuesta luce bien y se da por hecho que el prompt está listo. En producción ese mismo prompt va a recibir entradas que el creador nunca imaginó: textos vacíos, idiomas distintos, intentos de jailbreak, formatos inesperados, datos mal escritos. La diferencia entre los dos contextos es la causa más común de proyectos IA que se sienten bien en demo y fallan en uso real.
Un prompt productivo tiene cinco propiedades que un prompt de playground rara vez tiene: system prompt explícito y separado, ejemplos few-shot representativos, structured output con esquema validable, casos de evaluación versionados en repo y monitorización de calidad y coste en runtime.
No es complejidad por complejidad. Cada pieza resuelve un fallo real que hemos visto romper proyectos: el system prompt evita derivas de tono, los ejemplos evitan interpretaciones libres, el structured output rompe parsing manual frágil, los tests evitan regresiones cuando ajustas el prompt y la monitorización evita que la factura se dispare sin enterarte.
Lo que va en system y lo que va en user.
En todas las APIs serias (Anthropic Claude, OpenAI GPT, Azure, Bedrock) hay dos roles distintos: system (instrucciones permanentes del asistente, tono, formato, restricciones) y user (la petición concreta de esta llamada). Mezclar ambos en una sola cadena gigante es el error #1 que vemos en código de pymes.
En system va: rol del asistente ("eres un clasificador de emails comerciales"), formato de salida exigido ("responde solo JSON con campos X, Y, Z"), restricciones de comportamiento ("no respondas a preguntas fuera de comercial"), tono ("formal, breve, máximo 80 palabras"). Una vez. Inmutable durante el flujo.
En user va: la entrada variable de esta llamada. Email a clasificar, factura a parsear, pregunta del cliente, lo que sea. Cambia cada vez. Si hace falta contexto adicional (un perfil de usuario, datos de RAG), también va en user, bien marcado con etiquetas tipo XML para que el modelo distinga partes.
Beneficio práctico: con system separado puedes activar prompt caching (Anthropic, OpenAI, Bedrock) y pagar 10× menos por la parte fija a partir de la 2ª llamada. En un sistema que hace 5.000 llamadas/día, eso son cientos de euros al mes ahorrados sin tocar lógica.
Cuántos ejemplos meter y cómo
Mostrar al modelo ejemplos del input y output esperados sube la fiabilidad 20-40%.
Cero-shot · Solo para casos triviales
Sin ejemplos. Funciona en tareas obvias (traducir, resumir, contar). Mala idea en clasificación, extracción o cualquier formato propio: el modelo improvisa la estructura y los outputs son inconsistentes entre llamadas.
3-5 ejemplos · Sweet spot productivo
Casos representativos que cubren los formatos típicos + 1-2 casos borde (entrada rara, formato sucio). Subida de calidad fuerte vs cero-shot. Tamaño manejable: añade 500-1.500 tokens al system, cacheables.
10+ ejemplos · Solo si hay muchos casos borde
Cuando la entrada tiene patrones muy variados (clasificar reseñas en un sector con jerga propia, parsear contratos con cláusulas heterogéneas). Coste de tokens sube pero también la consistencia. Validar con casos test.
JSON validado, no texto libre.
Si tu sistema consume la respuesta del LLM con código (la mete en una base de datos, dispara una acción, alimenta otro flujo), NO uses texto libre. Pide JSON con esquema y validalo. Texto libre + parsing manual con regex es la receta más rápida de bugs en producción.
OpenAI ofrece "Structured Outputs" con esquema JSON garantizado desde GPT-4o. Anthropic admite "tool use" y JSON estricto en Claude 3.5+. Azure OpenAI y Bedrock heredan la capacidad. En la práctica: defines un esquema (campos, tipos, enums, requeridos) y el modelo está obligado a devolverlo así. Si no puede, falla limpio en vez de devolver "casi-JSON" con coma de más.
Buena práctica adicional: validar el JSON devuelto contra tu esquema en código (Zod en TypeScript, Pydantic en Python). Doble red de seguridad. Si la API garantiza esquema, la validación local cuesta milisegundos y atrapa el caso raro en el que el modelo se desvía. Ejemplo: clasificador de emails con esquema {categoria: enum, urgencia: 1-5, justificacion: string}.
Lo que necesitas en repo para no romper nada al "mejorar" un prompt
Set de evaluación (eval set) versionado
20-100 casos reales del dominio guardados en JSON o CSV en el repo. Cada caso tiene input + output esperado. Cuando ajustas el prompt, corres este set y comparas. Sin esto, "mejorar" un prompt rompe casos antiguos sin que te enteres.
Métricas automáticas por tipo de tarea
Clasificación: accuracy + matriz de confusión. Extracción: precision/recall por campo. Generación: BLEU/ROUGE o embedding similarity vs gold standard. Para tareas creativas, evaluación humana con sample 20-30 casos.
CI que corre evals antes de subir cambios
En GitHub Actions o equivalente: si modificas el prompt, los evals corren en pull request y reportan delta vs main. Bloquea merge si la regresión supera X%. Cuesta 1 día montar y ahorra cientos de horas de debugging.
Histórico de versiones del prompt
Cada prompt en producción tiene versión semántica (v1.0, v1.1) y se versiona en Git. Cuando algo falla, puedes hacer rollback al prompt previo en minutos. Sin versionado, "el que estaba antes funcionaba bien" se vuelve arqueología imposible.
Sample manual mensual
Una persona revisa 30-50 outputs reales del último mes, una vez al mes. Busca patrones nuevos de fallo que los evals automáticos no detectan. 1-2 h/mes. Insumo para añadir casos al eval set.
Pagar menos sin perder calidad.
Prompt caching permite que la parte fija del prompt (system, ejemplos, instrucciones largas) se cacheada al primer uso y se cobre 10× menos en llamadas posteriores que comparten el cacheo. Anthropic (Claude), OpenAI y Bedrock lo ofrecen en 2026. Para sistemas con prompts largos y miles de llamadas/día es el ahorro técnico más fácil que existe.
Ejemplo real: clasificador de emails con system + 5 ejemplos = 2.000 tokens fijos. Sin caching, 5.000 llamadas/día × 2.000 input tokens × 3 €/M = 30 €/día. Con caching, primera llamada paga full, las otras 4.999 pagan 0,30 €/M sobre los 2.000 tokens fijos = 3 €/día. Ahorro 27 €/día = 810 €/mes con un cambio de 0 líneas en el prompt.
Reglas para que caching funcione: la parte fija no puede cambiar entre llamadas (poner system con instrucciones genéricas, no con datos del usuario específico), llamadas tienen que llegar dentro de la ventana de cacheo (5 min Anthropic, 1 hora OpenAI), y hay que activarlo explícitamente en el SDK (no es automático en todas las APIs).
Otros controles de coste imprescindibles: seleccionar modelo correcto (Haiku/GPT-4o-mini para clasificación, Sonnet/GPT-4o para razonamiento), limitar max_tokens en respuestas, cortar contexto innecesario en RAG, monitorización en dashboard con alerta si gasto diario excede X.
Workflow recomendado paso a paso.
Prototipa en playground 30 min
Caso típico, modelo Sonnet o GPT-4o, prompt cero-shot rápido. Confirma que el modelo en abstracto sabe hacerlo. Si no sabe ni con prompt humano y casos a mano, el problema no es prompt: redefine caso de uso.
Estructura system + few-shot
Separa system (instrucciones permanentes) y user (input). Añade 3-5 ejemplos representativos en system. Define structured output si la respuesta la consume código. Mueve a SDK propio en lenguaje del proyecto.
Crea eval set 20-50 casos
Recoge inputs reales del dominio con outputs esperados. Compañeros del equipo etiquetan en 1-2 horas. Versionado en repo. Script que corre el eval contra el prompt actual y devuelve métricas.
Activa caching y monitoriza
Marca la parte fija como cacheable. Conecta dashboard de tokens y coste por día. Alerta si gasto excede umbral. Logs de errores y outputs raros guardados 30 días para análisis.
Lanza piloto 4 semanas + review
Activa para 10-30% del tráfico real. Recolecta outputs reales. A las 4 semanas: review manual de sample 50 casos, añade fallos al eval set, ajusta prompt si necesario, sube a 100% o sigue iterando.
Dudas que nos hacéis llegar
¿Quieres llevar tus prompts del playground a producción seria?
Sesión técnica de 60 minutos: revisamos tu prompt actual, identificamos riesgos en producción, te dejamos estructura system + few-shot + schema y plan de evaluación. Si necesitas implantación, podemos hacerlo con tu equipo o de cero.