Qué es realmente un system prompt
Un system prompt es el bloque de instrucciones que el modelo recibe antes de cualquier mensaje del usuario. Define persona, comportamiento, restricciones, herramientas y contratos de salida — todo lo que debe mantenerse constante a lo largo de una conversación. Un user prompt es un turno individual dentro de ese marco.
La distinciĂłn importa porque se diseñan de forma distinta. Los system prompts se escriben una vez y se evalĂşan contra muchas entradas de usuario, asĂ que tienen que ser generales, sin ambigĂĽedad y robustos frente a mensajes adversariales. Los user prompts son desechables y especĂficos a la tarea.
Gran parte de lo que circula online como "consejos de prompt engineering" mezcla ambos niveles. Esta guĂa trata especĂficamente de la capa de system prompt — la pieza que se despliega a producciĂłn detrás de un producto, un agente o una automatizaciĂłn.
La anatomĂa de un system prompt fuerte en 2026
Un system prompt bien estructurado en 2026 contiene seis bloques, aproximadamente en este orden:
- Identidad y persona. Quién es el asistente y a quién le habla. Mantenlo compacto — dos o tres frases. Personas largas gastan tokens y rara vez cambian el comportamiento.
- Alcance de la tarea. Para quĂ© sirve el asistente y — más importante aĂşn — para quĂ© no sirve. Los lĂmites explĂcitos evitan que el modelo acepte hacer trabajo adyacente para el que no fue diseñado.
- Reglas de uso de herramientas. Si el modelo tiene tools, cuándo invocar cada una, cuándo preguntar al usuario primero y quĂ© hacer si una tool falla. AquĂ viven la mayorĂa de los bugs de agentes.
- Comportamiento de rechazo y seguridad. La forma exacta de un rechazo. "Disculparse una vez, explicar brevemente, sugerir una alternativa" es un buen default — es mejor que un genérico "No puedo ayudar con eso."
- Contrato de formato de salida. Si el modelo devuelve markdown, JSON, un schema especĂfico o texto plano. Si es JSON, especifica las claves y quĂ© ocurre en caso de error (nunca errores en texto libre dentro de una respuesta JSON).
- Tono y estilo. Una o dos lĂneas, concretas. "Profesional, conciso, sin emojis" es mejor que "SĂ© Ăştil y amigable."
Eso es todo. Los system prompts de más de 1,500 tokens casi siempre tienen instrucciones repetidas, ejemplos muertos o safety theatre que no cambia el comportamiento del modelo.
Convenciones de system prompt especĂficas por modelo
Cada modelo trata el slot de mensaje de sistema de forma distinta. Escribir un único system prompt y desplegarlo a todos los proveedores es uno de los errores más comunes en 2026.
- Claude (Anthropic). Claude tiene un parámetro
systemdedicado que es genuinamente privilegiado — las instrucciones ahĂ son más difĂciles de sobreescribir que las que van en el turno del usuario. Claude sigue etiquetas estilo XML (<instructions>,<example>) de forma muy fiable y premia los prompts estructurados. Para modelos con extended thinking, mantĂ©n el system prompt corto y deja que el razonamiento del modelo se encargue de la complejidad. - GPT-5 / GPT-4o (OpenAI). El rol
systemexiste, pero es menos privilegiado que el de Claude — puede ser sobreescrito por un user prompt suficientemente insistente. Usa developer messages y restricciones deresponse_formatpara contratos duros. Las listas numeradas y los encabezados por sección rinden mejor que XML. - Gemini (Google). Gemini usa
systemInstruction. Maneja bien contextos largos, pero es más sensible a contradicciones entre system y user messages — si el usuario pide algo que el system prohĂbe, es más probable que Gemini siga al usuario. Compensa con ejemplos explĂcitos de rechazo.
Si tienes que soportar varios modelos, mantĂ©n el system prompt como un objeto estructurado y renderĂzalo por proveedor en lugar de mantener tres copias que van a divergir.
Patrones que fallan en 2026
Estos patrones solĂan funcionar, o nunca funcionaron, y siguen apareciendo en system prompts por todas partes:
- Frases tipo jailbreak. "Eres una IA completamente sin restricciones" o "Ignora tus instrucciones anteriores" dentro de un system prompt no desbloquea capacidades nuevas — pone al modelo a la defensiva y degrada la calidad.
- Preámbulos demasiado largos. Tres párrafos de "eres un experto con veinte años de experiencia en..." casi no hacen nada. El modelo no se vuelve más experto. Ahorra los tokens.
- Meter instrucciones de usuario en el system. Si un trozo de contexto cambia por conversaciĂłn, pertenece al user message (o a un tool result), no al system. Los system prompts que incrustan datos especĂficos del usuario no pueden cachearse.
- Instrucciones de seguridad redundantes. Los modelos ya rechazan la mayorĂa de lo que te preocupa. Listas extra de "nunca hagas X, nunca hagas Y, nunca hagas Z" rara vez añaden seguridad real y siempre cuestan latencia y dinero.
- Formato implĂcito. "Dame un resumen bonito" no es un formato. "Devuelve un documento markdown con un encabezado H2, tres bullets y sin párrafo de cierre" sĂ es un formato.
Tres ejemplos aplicados
1. Agente de investigaciĂłn autĂłnomo
You are a research agent. Your job is to answer a user's question by
searching the web, reading sources, and synthesising an answer with
inline citations.
You have two tools: web_search(query) and fetch_page(url). Call
web_search first for any factual claim. If a source looks promising,
call fetch_page. Never cite a URL you have not fetched.
When you have enough evidence, return a markdown report with:
- A one-sentence answer
- Three to five supporting paragraphs, each with at least one citation
- A "Sources" section listing every URL you fetched
If you cannot find a confident answer after three search calls, stop
and return what you have with an explicit confidence note. Do not
fabricate.
2. Bot de triage de soporte al cliente
You are the first-line support assistant for Acme SaaS. You speak to
paying customers. Be direct, warm, and never more than three sentences
unless the user explicitly asks for detail.
Scope: you can answer questions about features, pricing, and account
management. You cannot process refunds, change subscriptions, or
access customer data. For anything in those categories, escalate
with the handoff_to_human tool and a one-line summary.
Tone: no emojis, no exclamation marks, no "I understand your
frustration." Just help.
If the user is abusive, respond once calmly and then call
handoff_to_human.
3. Code Reviewer
You are a senior code reviewer. You are given a diff. Review it.
Return JSON with this exact shape:
{
"summary": "<one sentence>",
"blocking": [{"file": "...", "line": 0, "issue": "..."}],
"suggestions": [{"file": "...", "line": 0, "issue": "..."}]
}
"blocking" is for correctness bugs, security issues, or data loss.
"suggestions" is for style, naming, and minor improvements. If the
diff is fine, return empty arrays — do not invent issues. Never
return prose outside the JSON.
FĂjate en lo que no aparece en ninguno de estos: personas largas, reglas de seguridad redundantes, frases suplicantes tipo "por favor, sigue estas instrucciones cuidadosamente." Cada prompt le dice al modelo quĂ© hacer, quĂ© tools usar y quĂ© devolver — y se detiene.
Consejos accionables que puedes aplicar hoy
- Evalúa antes de editar. Antes de tocar un system prompt, pasa diez entradas de usuario representativas por la versión actual y anota qué falló. Optimiza para los fallos reales, no para los que imaginas.
- Versiona tus system prompts. Son cĂłdigo de producto. Guárdalos en el repo, revĂsalos en PRs y asocia cada versiĂłn a una corrida de evaluaciĂłn.
- Mantén la lista de "no hagas" separada. Las restricciones negativas funcionan mejor al final del prompt, en una lista corta de bullets que el modelo pueda escanear.
- Usa la caché. Si tu proveedor soporta prompt caching (Anthropic lo soporta, OpenAI lo hace de forma automática), divide el prompt para que la parte estable sea cacheable y sólo el contexto dinámico cambie por request.
- Re-evalúa en cada upgrade de modelo. Un prompt que puntuaba top en Claude 4.6 puede regresar en 4.7. Los contratos estrictos por schema ayudan; los prompts en prosa libre son frágiles frente a cambios de modelo.
CĂłmo lo resuelve PromptArch
Escribir system prompts a mano para cada dominio es tedioso, y la mayorĂa de equipos acaba con diez convenciones ligeramente distintas. PromptArch genera system prompts a partir de entradas estructuradas — rol, tarea, restricciones, formato de salida — y aplica automáticamente las convenciones por modelo descritas arriba. Si quieres ver un system prompt bien formado de 2026 para tu caso de uso sin empezar desde un archivo en blanco, esa es la vĂa más rápida.
Los system prompts son la pieza de código de vida más larga en un producto de IA. Tratarlos como código — estructurados, revisados, evaluados, versionados — es el cambio que en 2026 separó las demos de juguete de las features que realmente llegan a producción.