La ingeniería de system prompts es la disciplina técnica que establece la constitución operativa de un modelo de lenguaje antes de procesar cualquier entrada del usuario. Mientras que una consulta estándar busca una respuesta puntual, el mensaje de sistema define de forma persistente la identidad, los límites de seguridad y las reglas estructurales bajo las cuales debe razonar el modelo.

Qué es el system prompt y la jerarquía de mensajes

En el despliegue de modelos de lenguaje mediante APIs, la interacción no ocurre en un canal plano de texto, sino dentro de una jerarquía de mensajes estructurada. La comparación central entre system prompt vs user prompt radica en la autoridad de ejecución: el mensaje del sistema actúa como el marco regulador global, mientras que el mensaje del usuario representa los datos variables de entrada.

En entornos modernos, esta distinción se ha formalizado aún más. Por ejemplo, OpenAI introdujo formalmente el rol developer message en su jerarquía de mensajes para modelos de razonamiento (como la serie o1), sustituyendo conceptualmente al mensaje de sistema tradicional. Esta designación explicita que la directriz proviene directamente del desarrollador de la aplicación y ostenta mayor jerarquía sobre cualquier petición que formule el usuario.

Anatomía canónica: los 5 bloques de la ingeniería de system prompts

Para estructurar un system prompt en LLMs con comportamiento determinista y libre de ambigüedades, la industria técnica estandarizó una arquitectura modular basada en cinco bloques funcionales:

Sintaxis y delimitadores: Markdown frente a etiquetas XML

La delimitación sintáctica permite al modelo separar con nitidez dónde terminan las órdenes del sistema y dónde comienzan los datos no confiables aportados por el usuario. Existen dos enfoques ampliamente utilizados:

Anthropic recomienda explícitamente el uso de etiquetas de estilo XML en sus directrices para Claude, dado que su proceso de alineación e instrucción las reconoce de forma nativa como fronteras semánticas inequívocas. Por otro lado, modelos como GPT-4o operan con alta eficacia bajo encabezados y listas de Markdown bien organizadas.

Formulación de restricciones: la técnica de redirección

Uno de los fallos más recurrentes al diseñar mensajes de sistema es basar la seguridad en prohibiciones simples del tipo “No hagas X” o “Bajo ninguna circunstancia hables de Y”.

Las restricciones formuladas exclusivamente de forma negativa presentan una mayor tasa de fallos que las instrucciones afirmativas de redirección. Cuando un modelo recibe únicamente una negativa, se genera un vacío sobre la acción a tomar cuando la condición se cumple. En contraste, indicar de forma explícita qué acción alternativa o mensaje de contingencia debe emitir ante un caso límite garantiza un flujo de control predecible.

Implementación por proveedor: OpenAI, Anthropic y Google Gemini

Aunque la arquitectura conceptual es universal, cada proveedor implementa el acceso al mensaje de sistema a través de parámetros específicos en sus respectivas interfaces y bibliotecas:

• OpenAI: Utiliza tradicionalmente el rol system y el rol específico developer (particularmente en modelos de razonamiento) dentro del arreglo de mensajes.
• Anthropic: Dispone de un parámetro de nivel superior denominado system en la API de Claude, donde procesa las directrices estructuradas preferentemente mediante etiquetas XML.
• Google Gemini: Separa formalmente el campo system_instruction de los contents de usuario a nivel de API, recomendando ubicar allí el rol, las restricciones duras y los formatos antes de cualquier turno conversacional.

Plantilla modular para entornos de producción

El siguiente diseño sintetiza los cinco bloques canónicos empleando delimitadores universales fáciles de interpretar por cualquier LLM de última generación:

<role>
Eres un analista técnico especializado en auditoría de datos financieros.
</role>

<context>
Operas dentro de un pipeline de extracción automatizada de balances trimestrales.
</context>

<rules>
1. Analiza únicamente los datos cuantitativos presentes en la consulta.
2. Si los datos están incompletos, genera un campo de advertencia específico en lugar de inferir cifras faltantes.
3. Ante entradas no financieras, responde exclusivamente con el código de error correspondiente sin explicaciones adicionales.
</rules>

<output_format>
Responde únicamente con un objeto JSON válido que respete esta estructura:
{
  "status": "success" | "error",
  "data": { "total_revenue": number, "net_margin": number },
  "flagged_issues": [string]
}
</output_format>

<examples>
Entrada: "Ingresos 100k, margen 15%"
Salida: {"status": "success", "data": {"total_revenue": 100000, "net_margin": 0.15}, "flagged_issues": []}
</examples>