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.