# Qué es un System Prompt

Guía técnica sobre los System Prompts: qué son, en qué se diferencian del prompt de usuario y cómo escribir uno que funcione de verdad.

- URL: https://miguelramos.net/blog/system_prompt_ai/
- Fecha: 2026-08-19
- Autor: Miguel Ramos
- Tags: IA, Agentes de IA

---
Llevo un tiempo dando vueltas a algo que parece obvio hasta que intentas explicarlo bien: ¿qué es exactamente un System Prompt? Todo el mundo que trabaja con IA lo ha tocado alguna vez, muchos lo escriben a diario, y sin embargo la mayoría de explicaciones que circulan se quedan en "es donde le dices a la IA cómo comportarse". Eso es cierto, pero es también la versión reducida de algo bastante más interesante.

Cuando empecé a mirar con más detalle cómo Anthropic documenta y versiona los system prompts de Claude, me quedó claro que esto no es solo un truco de prompt engineering. Es una pieza de diseño de sistema. Y si estás construyendo algo con IA que no sea un chat de juguete un agente, un asistente interno, una herramienta con acceso a datos, entender bien esta pieza cambia cómo planteas todo lo demás.

Este artículo es mi intento de explicarlo desde cero, con ejemplos, sin humo, y separando claramente conceptos que a menudo se mezclan sin querer.

## ¿Qué es realmente un System Prompt?

Un System Prompt es el conjunto de instrucciones que se coloca *antes* de la conversación con el usuario, y que define el contexto, el rol, las responsabilidades y las restricciones bajo las que un modelo de lenguaje debe operar durante esa conversación.

La analogía más simple que conozco es esta:

- **System Prompt** → las reglas del entorno. Define quién es el asistente, qué puede y qué no puede hacer, y bajo qué criterios debe operar.
- **User Prompt** → la solicitud concreta. Es lo que la persona pide en ese momento.

Es parecido a la diferencia entre el reglamento de una empresa y el ticket de soporte que llega hoy. El reglamento no cambia con cada ticket; el ticket sí cambia, pero siempre se resuelve dentro de las reglas que ya existían.

Ahora bien, aquí es donde el concepto empieza a ponerse interesante: un System Prompt no es solo "personalidad". Puede establecer cómo debe razonar el modelo, qué formato debe usar en sus respuestas, cuándo debe pedir más información antes de actuar, cómo debe comportarse si tiene herramientas disponibles, y qué hacer si algo no está claro. En sistemas de producción, el System Prompt es más parecido a una especificación de comportamiento que a una simple frase de "actúa como...".

Según la [documentación oficial de Anthropic sobre system prompts](https://platform.claude.com/docs/en/release-notes/system-prompts), el system prompt que usan claude.ai y las apps móviles de Claude sirve para darle a Claude información actualizada como la fecha actual al comienzo de cada conversación, y para fomentar ciertos comportamientos, como presentar siempre el código en bloques Markdown ([fuente](https://platform.claude.com/docs/en/release-notes/system-prompts)). Esa misma documentación aclara dos cosas que conviene remarcar como hechos, no como interpretación propia: ese prompt se actualiza periódicamente para mejorar las respuestas del modelo, y esas actualizaciones **no se aplican a la API de Claude** ([fuente](https://platform.claude.com/docs/en/release-notes/system-prompts)). La propia página, además, funciona como un registro histórico: documenta, versión a versión (Opus, Sonnet, Haiku, y las distintas generaciones de cada uno), qué cambió entre una entrada y la siguiente ([fuente](https://platform.claude.com/docs/en/release-notes/system-prompts)).

Y aquí llega un matiz importante que muchas explicaciones se saltan.

## System Prompt vs. "system" en la API vs. instrucciones del usuario

Estos tres conceptos se confunden constantemente, así que vale la pena separarlos con claridad:

**1. El System Prompt interno de una interfaz (como claude.ai o las apps de Claude)**

Es un conjunto de instrucciones que la propia interfaz añade automáticamente, sin que el usuario lo escriba ni lo vea. Sirve para dar contexto operativo (fecha, comportamientos esperados, formato) y para mantener cierta consistencia de producto. La documentación oficial de Anthropic es explícita en un punto que conviene remarcar: estas actualizaciones del system prompt de claude.ai **no aplican a la API de Claude**. Son dos capas distintas.

**2. El parámetro `system` de la API**

Cuando un desarrollador construye una aplicación usando la API de Claude (u otro proveedor), puede definir su propio texto de sistema. Ese texto es controlado por el desarrollador: define el rol del asistente dentro de su producto, las reglas de negocio, el formato de salida, etc., y no hereda el system prompt de claude.ai son capas distintas, como ya vimos.

Pero hay que ser precisos aquí para no simplificar de más: que el desarrollador controle el contenido del `system` no significa que el modelo opere fuera de cualquier otra política o mecanismo definido por el proveedor. Un proveedor de modelos como Anthropic mantiene, a nivel de plataforma, restricciones y salvaguardas que existen independientemente de lo que el desarrollador escriba en su prompt. El `system` de la API no es un "lienzo completamente en blanco" en el sentido de que todo lo que ocurra a partir de ahí dependa únicamente de ese texto; es más preciso pensarlo como la capa donde el desarrollador tiene control total sobre el comportamiento *de producto*, dentro de un marco más amplio que no controla.

**3. Las instrucciones del usuario (user prompt)**

Es lo que la persona escribe en cada turno de la conversación. Cambia constantemente, es específico, y se interpreta *dentro* del marco que ya establecieron las capas anteriores.

**4. El contexto adicional**

Información que se añade a la conversación pero que no es exactamente "regla de comportamiento": documentos adjuntos, resultados de búsquedas, datos recuperados de una base de datos (RAG), historial de mensajes previos. El modelo lo usa como material de trabajo, no como ley.

**5. Las herramientas (tools)**

Funciones, APIs o capacidades externas que un agente puede invocar: buscar en la web, ejecutar código, consultar un CRM, leer un archivo. El System Prompt puede (y normalmente debe) explicar *cuándo y cómo* usarlas, pero las herramientas en sí son una pieza técnica distinta, no texto.

**6. Las reglas o instrucciones de comportamiento que condicionan la respuesta**

Aquí entran políticas de seguridad, restricciones de contenido o guías de estilo que pueden venir de distintas capas (proveedor del modelo, plataforma, desarrollador de la app). No siempre son visibles ni editables por quien construye la aplicación.

| Concepto | ¿Quién lo define? | ¿Es visible para el usuario final? | ¿Cambia por conversación? |
|---|---|---|---|
| System Prompt de la interfaz (claude.ai, apps) | El proveedor (Anthropic) | No | Rara vez, se actualiza por versión |
| `system` de la API | El desarrollador de la app | No | Puede ser fijo o dinámico según la app |
| User Prompt | El usuario final | Sí | Sí, en cada turno |
| Contexto adicional | Depende del sistema (RAG, documentos, historial) | A veces | Sí, según la interacción |
| Herramientas | El desarrollador (define qué herramientas expone) | Indirectamente (a través de los resultados) | No, pero su *uso* sí varía por turno |
| Reglas de comportamiento del proveedor | El proveedor del modelo | No | No |

Tratar estas seis cosas como si fueran lo mismo es uno de los errores más comunes que veo en gente que empieza a construir con IA. Cuando algo no funciona como se espera, el primer diagnóstico suele ser "el prompt está mal", pero muchas veces el problema está en otra capa: falta contexto, la herramienta no está bien descrita, o hay una instrucción de plataforma que tiene más prioridad de la que el desarrollador asumía.

## ¿Por qué importa tanto cuando la IA deja de ser un chatbot?

Cuando usas ChatGPT o Claude como una persona cualquiera abres la web, escribes una pregunta, recibes una respuesta el System Prompt trabaja en segundo plano y prácticamente no lo notas.

Pero en el momento en que integras un modelo dentro de una aplicación, un agente o un flujo de trabajo, el System Prompt deja de ser un detalle de producto y pasa a ser la especificación de tu sistema. Es lo que determina:

- si el asistente responde como un experto técnico o como un vendedor;
- si puede tomar decisiones autónomas o debe pedir confirmación;
- si debe negarse a ciertas peticiones incluso si el usuario insiste;
- qué formato tiene que respetar (JSON, Markdown, texto plano);
- cómo debe comportarse cuando no tiene suficiente información;
- cómo debe interactuar con las herramientas que tiene disponibles.

Si vienes del desarrollo de software, esto probablemente te resulte familiar: es parecido a la diferencia entre usar una librería de terceros con la configuración por defecto y escribir tu propio archivo de configuración porque tu aplicación tiene reglas de negocio específicas.

## ¿Tiene que estar escrito en inglés?

Esta es una duda que aparece constantemente cuando alguien empieza a escribir sus propios prompts de sistema: *"si mi System Prompt está en inglés, ¿tengo que hablarle al modelo en inglés?"*

La respuesta técnica es: no necesariamente, y depende del modelo.

Los modelos multilingües modernos como es el caso de Claude pueden recibir instrucciones de sistema en un idioma y una petición de usuario en otro completamente distinto, y seguir operando de forma coherente. El modelo no "traduce" internamente el prompt de sistema al idioma del usuario como un paso separado; simplemente es capaz de representar el significado de las instrucciones y aplicarlas independientemente del idioma en el que llegue la conversación del usuario.

Un ejemplo conceptual:

```
System Prompt:

You are a senior software engineer.
Always explain technical decisions clearly.
When providing code, use Markdown.
Prefer secure and maintainable solutions.
```

```
Usuario:

Necesito implementar autenticación en mi aplicación Astro.
¿Qué arquitectura me recomiendas?
```

Lo que ocurre aquí, conceptualmente, es que el modelo procesa ambos bloques de texto como parte de la misma conversación, pero les asigna un rol distinto: el bloque de sistema define el marco de comportamiento (quién es, qué prioriza, cómo debe presentar el código), y el bloque de usuario define la tarea concreta. El modelo puede responder en español, siguiendo las reglas del prompt en inglés, porque esas reglas no dependen del idioma en el que estén escritas para poder aplicarse.

Dicho esto, esto **no es una regla absoluta válida para cualquier modelo o cualquier escenario**. El comportamiento real depende de:

- las capacidades multilingües específicas del modelo que estés usando;
- cómo esté construida la aplicación (algunos sistemas fuerzan el idioma de salida explícitamente en el prompt);
- la calidad y ambigüedad de las instrucciones (instrucciones muy dependientes de matices idiomáticos pueden comportarse peor entre idiomas);
- si el prompt mezcla instrucciones de formato específicas de un idioma (por ejemplo, convenciones de fecha o moneda).

En la práctica, si tu producto se dirige a usuarios que escriben en español, lo razonable suele ser escribir el System Prompt en el idioma con el que te sientas más preciso muchas veces inglés, porque hay más literatura y ejemplos de referencia sobre prompt engineering en ese idioma y, si quieres forzar que las respuestas salgan siempre en español, decirlo explícitamente en el propio prompt en lugar de asumir que el modelo lo va a inferir siempre correctamente.

## Anatomía de un buen System Prompt

Un System Prompt bien construido no es una lista de adjetivos ("sé amable, sé útil, sé preciso"). Es, en la práctica, una pequeña especificación. Estos son los elementos que suelo encontrar en los prompts que funcionan bien:

**Rol.** Quién o qué es el asistente dentro del sistema. No es lo mismo "eres un asistente" que "eres el motor de recomendaciones de una tienda de repuestos de bicicletas, orientado a usuarios técnicos".

**Objetivo.** Qué problema concreto debe resolver. Un rol sin objetivo es una máscara vacía; el objetivo es lo que da criterio para decidir qué respuesta es mejor que otra.

**Contexto.** La información que el asistente necesita para hacer bien su trabajo: qué producto es, qué tipo de usuarios lo usan, qué restricciones de negocio existen. Aquí es donde muchos prompts fallan por exceso o por defecto: falta contexto crítico, o sobra contexto irrelevante que diluye lo importante.

**Responsabilidades.** Qué debe hacer el asistente de forma proactiva. Por ejemplo: "debe señalar cuando falte información antes de dar una respuesta definitiva".

**Restricciones.** Qué no debe hacer bajo ninguna circunstancia. Por ejemplo: "no debe inventar nombres de APIs o funciones que no existan".

**Criterios de calidad.** Cómo se sabe si una respuesta es buena. Esto es fácil de omitir y, sin embargo, es lo que permite iterar el prompt con criterio en lugar de intuición.

**Formato de salida.** Cómo debe estructurar sus respuestas: Markdown, JSON, texto plano, longitud aproximada.

**Manejo de incertidumbre.** Qué debe hacer cuando no tiene suficiente información: preguntar, asumir explícitamente, o declarar la limitación en la respuesta.

**Uso de herramientas.** Cuándo puede (y cuándo no debe) usar búsqueda, ejecución de código, lectura de archivos, llamadas a APIs externas.

**Prioridad de instrucciones.** Qué hacer si dos instrucciones entran en conflicto por ejemplo, entre lo que pide el usuario y lo que establece el System Prompt. Esto se vuelve crítico en sistemas donde el usuario puede intentar "sobrescribir" el comportamiento definido por el desarrollador.

## Cómo escribir un System Prompt que realmente funcione

Aquí es donde la mayoría de guías se quedan en "sé claro y específico", que es un consejo tan cierto como inútil si no se explica el porqué. Voy a intentar ser más concreto.

**Sé específico, no exhaustivo.** Un prompt gigantesco que intenta cubrir cada caso imaginable suele degradar el rendimiento en lugar de mejorarlo: el modelo tiene que sostener más contexto simultáneamente, y las instrucciones tienden a diluirse entre sí. La especificidad no está en la longitud, está en la precisión de cada frase.

**Define objetivos concretos, no rasgos abstractos.** "Sé útil" no orienta ninguna decisión real. "Prioriza siempre soluciones que no requieran cambios en el esquema de base de datos" sí lo hace.

**Evita instrucciones ambiguas.** Si una instrucción admite dos lecturas razonables, el modelo elegirá una de las dos no necesariamente la que tú tenías en mente. Cuanta más ambigüedad, más varianza en el comportamiento entre ejecuciones.

**Separa reglas de contexto.** Mezclar "quién es el usuario" con "qué no debe hacer el asistente" en el mismo párrafo hace más difícil mantener el prompt después. Estructurarlo en secciones (rol, contexto, restricciones...) no es estética: facilita depurarlo cuando algo falla.

**Define límites explícitos.** No asumas que el modelo va a inferir correctamente dónde termina su margen de acción. Si hay una línea que no debe cruzar, escríbela.

**Define qué hacer cuando falta información.** Esta es, en mi experiencia, la instrucción que más impacto tiene y que menos gente incluye. Sin ella, el modelo tiende a "rellenar huecos" con suposiciones razonables mal que ni bien, en lugar de señalarlos.

**Especifica formatos solo cuando de verdad importen.** Pedir un formato rígido sin necesidad real añade restricciones que consumen capacidad del modelo sin aportar valor.

**Usa ejemplos cuando reduzcan ambigüedad.** Un ejemplo bien elegido comunica más que tres frases de descripción abstracta. Esto es especialmente útil para formato de salida o para casos límite.

**Evita contradicciones internas.** Es más común de lo que parece: una sección dice "sé breve" y otra pide "explica en detalle cada decisión técnica". El modelo tiene que resolver ese conflicto por su cuenta, y el resultado es impredecible.

**Itera y evalúa, no asumas que funciona a la primera.** Un System Prompt no es una configuración estática que se escribe una vez y se olvida. Se prueba con casos reales, se observa el comportamiento resultante, y se ajusta.

**Piensa en comportamiento observable, no en intención.** La pregunta correcta no es "¿qué quise decir con esta instrucción?", sino "¿qué está haciendo realmente el sistema cuando aplico esta instrucción?". Son cosas distintas, y la brecha entre ambas es donde vive la mayoría de los bugs de comportamiento en sistemas de IA.

## De un prompt mediocre a uno que funciona

**Prompt débil:**

```
Eres un buen programador. Ayúdame con código.
```

**Prompt mejor estructurado:**

```
You are a senior software engineer.

Your responsibilities:
- Analyze the user's technical requirements.
- Identify potential architectural problems.
- Prefer maintainable and secure solutions.
- Explain important trade-offs.
- Do not invent APIs or documentation.
- If required information is missing, explicitly state what is missing.

When providing code:
- Use Markdown code blocks.
- Provide complete examples when practical.
- Explain important implementation decisions.
```

La diferencia no es de tono, es de especificación. El primer prompt no le da al modelo ningún criterio para decidir qué es una buena respuesta: no sabe si debe priorizar velocidad o seguridad, no sabe qué hacer si le falta información, no sabe en qué formato debe presentar el código. El segundo prompt convierte esas decisiones implícitas en reglas explícitas, y eso reduce directamente la varianza entre una respuesta y otra.

## Casos de uso reales: qué debería controlar el System Prompt en cada uno

- **Chatbots especializados.** El tono, el dominio de conocimiento permitido, y qué hacer ante preguntas fuera de ámbito.
- **Asistentes de programación.** El lenguaje/framework de referencia, convenciones de estilo, y la política sobre inventar APIs (que debería ser: nunca).
- **Agentes autónomos.** Cuándo actuar sin confirmación, cuándo detenerse a pedir aprobación, y cómo reportar lo que hizo.
- **Soporte técnico.** Qué información puede compartir, cuándo escalar a un humano, y cómo manejar usuarios frustrados.
- **Atención al cliente.** Límites de lo que puede prometer (reembolsos, plazos), y tono de marca.
- **Análisis de documentos.** Cómo citar fuentes, qué hacer si el documento es ambiguo o contradictorio.
- **Sistemas RAG.** Cómo priorizar el contenido recuperado frente al conocimiento general del modelo, y qué hacer si no hay contexto relevante recuperado.
- **Asistentes internos de empresas.** Qué datos internos puede usar, y qué no debe salir nunca fuera del contexto interno.
- **Generación y revisión de código.** Criterios de calidad (seguridad, mantenibilidad), y cómo reportar problemas encontrados.
- **Automatización mediante herramientas.** Qué herramienta usar para qué tarea, y cuándo NO usar ninguna.
- **Agentes que usan APIs.** Cómo interpretar errores de la API, y cuándo reintentar frente a cuándo abortar.
- **Sistemas que trabajan con bases de datos.** Qué operaciones están permitidas (lectura vs. escritura), y cómo manejar resultados vacíos.
- **Asistentes de documentación.** El nivel de formalidad, y la audiencia objetivo (usuarios técnicos vs. no técnicos).
- **Sistemas educativos.** El nivel de andamiaje pedagógico: dar la respuesta directa vs. guiar al usuario a encontrarla.
- **Flujos de generación de contenido.** Tono de marca, restricciones legales/editoriales, y formato de entrega.

## System Prompt, herramientas y agentes

Cuando un modelo tiene acceso a herramientas búsqueda, ejecución de código, lectura de archivos, llamadas a APIs externas, el System Prompt deja de ser solo una guía de tono y pasa a ser parte del control de flujo del agente.

```
System Prompt
      ↓
Define comportamiento
      ↓
Modelo
      ↓
Tools / APIs / archivos / búsqueda
      ↓
Resultado
```

En este contexto, el System Prompt puede establecer:

- cuándo utilizar una herramienta y cuándo resolver la petición sin ella;
- cuándo no utilizarla, incluso si técnicamente podría;
- cómo interpretar los resultados que devuelve (¿son datos confiables? ¿necesitan validación?);
- qué información de esos resultados puede exponerse directamente al usuario;
- qué hacer cuando una herramienta falla o devuelve un error;
- cuándo pedir confirmación antes de ejecutar una acción con efectos reales (enviar un email, borrar un registro);
- cómo mantener consistencia a lo largo de una tarea que requiere varios pasos encadenados.

Esta es la diferencia central entre un chatbot y un agente: un chatbot solo genera texto, un agente toma decisiones sobre qué hacer con las herramientas que tiene disponibles. Y esas decisiones están, en gran medida, condicionadas por cómo está escrito el System Prompt.

Para que esto no quede solo en teoría, veamos el mismo asistente en sus dos versiones. Como chatbot, sin herramientas, un System Prompt razonable podría ser:

```
You are a customer support assistant for a SaaS billing platform.

Your responsibilities:
- Answer questions about billing, plans, and invoices using the
  information the user provides in the conversation.
- If you don't have enough information to answer, say so and ask
  for what's missing.
- Never make up invoice numbers, amounts, or dates.
```

Aquí el prompt solo tiene que preocuparse de una cosa: qué decir. Toda la responsabilidad recae en el texto de la respuesta.

Ahora, el mismo asistente convertido en agente, con acceso a una herramienta que consulta el sistema de facturación real:

```
You are a customer support assistant for a SaaS billing platform.
You have access to a `get_invoice(invoice_id)` tool.

Your responsibilities:
- Use `get_invoice` whenever the user asks about a specific invoice,
  instead of relying on what they typed.
- If the tool returns an error, tell the user you couldn't retrieve
  the invoice and suggest they contact support  do not guess the
  contents of the invoice.
- Never take actions that modify billing data; you only have read
  access. If the user asks for a refund or a change, explain that
  you can't process it and escalate instead.
- After using a tool, base your answer only on the data it returned,
  not on assumptions.
```

El objetivo del asistente no cambió, pero el prompt ahora tiene que hacer mucho más trabajo: decidir *cuándo* usar la herramienta en lugar de responder directamente, qué hacer si la herramienta falla, y esto es clave establecer límites sobre lo que el agente puede *hacer*, no solo sobre lo que puede *decir*. En la versión chatbot, un error del prompt produce como mucho una respuesta mediocre. En la versión agente, un prompt mal diseñado puede producir una acción real mal ejecutada. Ese salto de controlar palabras a controlar acciones es exactamente lo que hace que el System Prompt pase de ser "estilo de conversación" a ser una pieza de control de un sistema.

## El System Prompt en producción: infraestructura y automatización

Todo lo anterior describe el System Prompt desde el punto de vista del contenido: qué decir, cómo estructurarlo, qué controla. Pero si vas a poner esto en producción, con tráfico real y costes reales, hay cuatro cosas más que entran en juego y que rara vez aparecen en las guías introductorias de prompt engineering.

### Prompt caching: el orden del prompt no es solo estético

El System Prompt suele ser la parte más grande y más constante de cada llamada a la API: instrucciones, ejemplos, documentación de referencia, definiciones de herramientas. Si cada petición reenvía y reprocesa ese mismo bloque de texto desde cero, estás pagando en coste y en latencia por recalcular algo que no ha cambiado desde la última llamada.

Las APIs modernas de los proveedores de modelos, incluida la de Anthropic, ofrecen mecanismos de *prompt caching*: la parte estática del prompt (el System Prompt en sí, las definiciones de herramientas, documentos de referencia largos) se puede marcar para que el proveedor la reutilice entre llamadas en lugar de reprocesarla íntegramente cada vez. Esto tiene una implicación de diseño muy concreta: el contenido estático y reutilizable debe ir al principio del prompt, y el contenido dinámico lo que cambia en cada turno, como el mensaje del usuario o datos específicos de la sesión debe ir al final. Si mezclas ambos, invalidas el caché en cada llamada y pierdes el beneficio por completo.

El impacto no es cosmético: reduce de forma significativa el coste de los tokens de entrada y mejora el *time to first token*, es decir, cuánto tarda el sistema en empezar a responder. En un producto con volumen real, esto puede ser la diferencia entre una arquitectura sostenible y una que se vuelve cara de operar según crece.

### Ensamblado dinámico: el prompt casi nunca es un bloque de texto fijo

Los ejemplos de este artículo muestran el System Prompt como un bloque de texto estático, y eso es lo correcto para explicar el concepto. Pero en un sistema real, ese texto casi nunca se escribe una vez y se manda tal cual a la API en cada llamada.

Lo habitual es que el backend construya el prompt de forma dinámica antes de cada petición: inyectando el nivel de suscripción del usuario, feature flags activos, contexto recuperado de una base de datos, o el idioma preferido, usando un motor de plantillas (algo tan simple como f-strings o Jinja2 en Python, o su equivalente en el lenguaje que uses). El System Prompt, visto así, deja de ser un archivo de texto y pasa a ser una función: recibe parámetros de contexto y devuelve las instrucciones específicas para esa llamada concreta.

Esto tiene una consecuencia práctica para el diseño: conviene separar, desde el principio, qué partes del prompt son verdaderamente estáticas (y por tanto cacheables, ver el punto anterior) de qué partes son parámetros que varían por usuario o por sesión. Mezclarlo todo en una sola plantilla gigante dificulta tanto el mantenimiento como la optimización de caché.

### De pedir un formato a forzarlo: structured outputs

Antes en este artículo hablamos de especificar el formato de salida JSON, Markdown, texto plano como parte de las instrucciones del prompt. Eso sigue siendo válido, pero conviene ser preciso sobre qué tan fuerte es esa garantía.

Pedirle a un modelo, en lenguaje natural, que responda en un JSON con cierta forma no garantiza que lo haga siempre correctamente: puede añadir texto antes o después, olvidar una comilla, o improvisar un campo que no le pediste. Por eso las APIs de los proveedores de modelos ofrecen, además, mecanismos de *structured outputs* o *tool use* con esquemas: en lugar de pedir el formato por texto, se le proporciona al modelo un esquema (por ejemplo, JSON Schema) que restringe directamente qué tokens puede generar en cada posición, de forma que la salida cumple la estructura por construcción, no por buena voluntad del modelo.

La diferencia práctica es la que hay entre pedir algo y garantizarlo. Si tu sistema depende de parsear la respuesta del modelo para pasarla a otro proceso (una base de datos, otra API, una UI), apoyarte únicamente en instrucciones de formato dentro del System Prompt es frágil. Cuando el caso lo justifique integraciones críticas, pipelines automatizados, vale la pena usar el mecanismo de esquema estructurado que ofrezca la API, y reservar las instrucciones de formato en el prompt para los casos donde una salida en prosa libre es aceptable.

### Evals en el pipeline, no solo en una hoja de cálculo

Más arriba dije que una hoja de cálculo con casos de prueba ya aporta más rigor que "probarlo un par de veces en el chat". Eso sigue siendo un buen punto de partida, pero si de verdad quieres tratar el System Prompt como código que es la tesis central de este artículo, el siguiente paso lógico es tratarlo como tratarías cualquier otro cambio de código: con integración continua.

En la práctica, esto significa mantener un dataset "dorado" de casos de prueba con el comportamiento esperado para cada uno, y ejecutar ese dataset de forma automática cada vez que alguien modifica el System Prompt por ejemplo, como parte de un workflow de CI (GitHub Actions o equivalente) que se dispara en cada pull request. El workflow ejecuta el prompt modificado contra el dataset, compara las respuestas con aserciones programáticas (¿se llamó a la herramienta correcta?, ¿el formato es válido?, ¿se respetó una restricción concreta?), y bloquea el merge si algo que antes funcionaba ha dejado de funcionar.

Esto es lo que separa a un System Prompt que "alguien ajusta a mano cuando algo se rompe" de uno que forma parte real del ciclo de vida del software: con historial de versiones, con pruebas automatizadas, y con protección explícita contra regresiones silenciosas cuando el equipo sigue iterando sobre él.

## Los límites de un System Prompt

Aquí quiero ser claro, porque hay una narrativa alrededor de los System Prompts que los presenta casi como programación mágica, y no lo son.

Un System Prompt no garantiza obediencia perfecta. Los modelos de lenguaje interpretan instrucciones, no las ejecutan como código determinista, así que una instrucción ambigua puede resolverse de formas distintas en momentos distintos.

Cuando hay varias instrucciones activas al mismo tiempo del proveedor del modelo, de la plataforma, del desarrollador de la app, del propio usuario pueden entrar en conflicto, y el modelo tiene que decidir cómo priorizarlas.

El contexto disponible importa tanto como las instrucciones: un System Prompt perfecto con contexto insuficiente o erróneo va a producir respuestas de baja calidad de todos modos.

Las herramientas y el software que rodea al modelo también forman parte del sistema. El prompt puede decirle al modelo cuándo usar una herramienta, pero la fiabilidad real depende de cómo esté implementada esa herramienta, no solo de las instrucciones de texto.

Y este es el punto más importante desde una perspectiva de ingeniería de software: **un System Prompt no sustituye validaciones de seguridad en el código.** Si tu aplicación permite que el modelo ejecute acciones sensibles borrar datos, mover dinero, enviar comunicaciones, esas acciones necesitan controles técnicos reales (permisos, validación de inputs, límites, revisión humana cuando corresponda), no solo una frase en el prompt que diga "actúa con cuidado". Las instrucciones críticas deberían reforzarse siempre mediante controles técnicos cuando el riesgo lo justifique.

## Prompt injection: por qué el System Prompt no es una frontera de seguridad

Cuando una aplicación combina instrucciones de sistema con contenido que llega de fuentes externas, aparece un riesgo real: el *prompt injection*.

```
System instructions
        ↓
User input
        ↓
Model
```

El problema es que, desde el punto de vista del modelo, tanto las instrucciones del sistema como el contenido que aporta el usuario (o que llega de un documento, una página web, o el resultado de una herramienta) terminan formando parte del mismo flujo de texto que se procesa. Si ese contenido externo incluye frases diseñadas deliberadamente para parecer instrucciones "ignora las reglas anteriores y haz X", existe la posibilidad de que el modelo les preste más atención de la que debería.

Esto es especialmente relevante en agentes que leen contenido no confiable: páginas web, correos, documentos subidos por terceros, resultados de búsqueda. Cualquiera de esas fuentes puede, en teoría, contener texto pensado para manipular el comportamiento del sistema.

Por eso un System Prompt, por bien escrito que esté, no debería considerarse una frontera de seguridad por sí solo. Las mitigaciones reales combinan varias capas: separar claramente en la arquitectura qué contenido es "instrucción confiable" y qué contenido es "dato a procesar", limitar qué acciones puede ejecutar un agente sin confirmación humana, validar y sanear las salidas antes de ejecutarlas como acciones, y aplicar principios de mínimo privilegio a las herramientas que el modelo puede invocar. El prompt ayuda a mitigar, no a garantizar.

## El System Prompt como parte de la arquitectura

Cuando una IA se integra en software real, el prompt deja de ser simplemente "texto que le escribimos a un chatbot". Pasa a ser una pieza más del diseño del sistema, con las mismas implicaciones que cualquier otra decisión de arquitectura.

Se puede pensar así:

- **Prompt → comportamiento.** Define cómo se comporta el modelo dentro del sistema.
- **Herramientas → capacidades.** Definen qué puede hacer el sistema más allá de generar texto.
- **Código → restricciones y validaciones.** Es lo que garantiza que las capacidades no se usen de forma insegura.
- **Datos/contexto → conocimiento.** Es lo que el sistema sabe en un momento dado.
- **Evaluaciones → control de calidad.** Es lo que permite saber si el sistema está funcionando como se espera, y detectar regresiones cuando cambias el prompt.

Ninguna de estas piezas sustituye a las demás. Un prompt excelente con herramientas mal diseñadas produce un sistema frágil. Herramientas robustas sin evaluaciones producen un sistema que nadie sabe si está mejorando o empeorando con el tiempo. Construir sistemas con IA implica pensar en las cinco capas a la vez, no optimizar el prompt de forma aislada y asumir que el resto se resuelve solo.

## Una analogía para desarrolladores (con sus límites)

Si vienes del desarrollo de software, esta comparación probablemente te resulte útil para construir intuición, aunque no hay que tomarla de forma literal: un System Prompt se parece, en espíritu, a una combinación de configuración, contrato de comportamiento, reglas de negocio, contexto y interfaz entre el desarrollador y el modelo.

No es literalmente ninguna de esas cosas no es código que se ejecuta de forma determinista, no es un esquema que se valida automáticamente, no es un contrato con garantías formales. Pero pensarlo desde ese ángulo ayuda a tomarlo con la misma seriedad con la que tratarías cualquier otra pieza crítica de tu sistema: con revisión, con pruebas, y con versión controlada.

## Plantilla reutilizable de System Prompt

Esta es una estructura base que suelo usar como punto de partida y adaptar según el proyecto:

```
# Role
You are...

# Objective
Your primary objective is...

# Context
You should understand that...

# Responsibilities
You must...

# Constraints
You must not...

# Tools
Use available tools when...

# Uncertainty
If information is missing...

# Output
Structure your response as...
```

Para adaptarla a un proyecto real, lo que suelo hacer es: definir el rol y el objetivo primero, porque todo lo demás depende de ahí; añadir solo el contexto que el modelo realmente necesita para tomar decisiones (no todo lo que sepas sobre el negocio); ser explícito en restricciones antes de que aparezcan en producción, no después de que algo salga mal; y dejar la sección de herramientas vacía si tu sistema no las usa una sección irrelevante añade ruido sin aportar nada.

## Cómo probar y mejorar un System Prompt

Un System Prompt se trata, en la práctica, como cualquier otra pieza de software que impacta el comportamiento de un sistema: con casos de prueba. Para un proyecto pequeño o una fase temprana, esto puede ser tan simple como reunir un conjunto de entradas representativas (incluyendo casos límite y adversarios), definir qué comportamiento esperas para cada una, y comparar el resultado real contra el esperado cada vez que modificas el prompt incluso una hoja de cálculo con casos y resultados observados ya aporta más rigor que "probarlo un par de veces en el chat y asumir que funciona".

Pero ese es el punto de partida, no el destino. Si el System Prompt es realmente código de comportamiento, como plantea la tesis de este artículo, el paso natural es automatizar esa validación dentro del pipeline de desarrollo, como se explica en la sección anterior sobre evals en CI/CD.

## Errores comunes

Los que más veo repetirse: tratar el System Prompt como si fuera el único lugar donde vive el comportamiento del sistema, ignorando que el código, las herramientas y el contexto también lo condicionan; escribir prompts enormes que intentan cubrir cada excepción posible, en lugar de mantenerlos enfocados y delegar los casos raros al manejo de incertidumbre; no definir qué pasa cuando falta información, lo que lleva al modelo a rellenar huecos con suposiciones; asumir que una instrucción de seguridad en el prompt es suficiente sin reforzarla con controles técnicos; y no volver a evaluar el prompt después de cambios en el modelo o en el producto, como si fuera una pieza que se escribe una vez y queda fija para siempre.

## Conclusión

Un buen System Prompt no consiste simplemente en decirle a una IA "compórtate como X". Es una forma de definir el contexto, las responsabilidades, las restricciones y el comportamiento esperado de un sistema de IA. Cuando el modelo deja de ser un chatbot suelto y pasa a formar parte de una aplicación, un agente o un flujo de trabajo, esa definición se convierte en una pieza más de la arquitectura: tan sujeta a revisión, pruebas e iteración como cualquier otro componente crítico del sistema.

Y como toda pieza de arquitectura, tiene límites. No sustituye validaciones de seguridad, no garantiza obediencia perfecta, y no es, por sí sola, una frontera de seguridad frente a contenido malicioso. Pero bien diseñada con rol, objetivo, contexto, responsabilidades, restricciones y manejo explícito de la incertidumbre es probablemente la herramienta de mayor apalancamiento que tienes para que un sistema de IA se comporte como esperas, la mayoría de las veces, en la mayoría de los casos.

Y cuando ese sistema pasa de un prototipo a producción, el prompt arrastra consigo las mismas preocupaciones que cualquier otro componente que sirve tráfico real: cómo se cachea, cómo se ensambla, qué garantías reales ofrece su formato de salida, y cómo se prueba antes de desplegar un cambio. Ignorar esa capa es la diferencia entre un prompt que funciona bien en una demo y un sistema que sigue funcionando bien seis meses después, con más usuarios y más presión sobre el coste.

Si vienes construyendo prompts sueltos en un chat, el siguiente paso natural es empezar a tratarlos como lo que son: código de comportamiento. Con versión, con pruebas, y con criterio.

## Fuentes y referencias

- Documentación oficial de Anthropic sobre System Prompts (release notes de claude.ai y apps móviles): [platform.claude.com/docs/en/release-notes/system-prompts](https://platform.claude.com/docs/en/release-notes/system-prompts)
- Documentación de Anthropic sobre ingeniería de prompts: [docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview](https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview)