System prompt: las instrucciones permanentes de tu producto con IA

El system prompt son las instrucciones que el desarrollador da al modelo en cada petición. Qué lleva, qué no y por qué no es un lugar seguro para secretos.

info Definición Rápida

El system prompt es el conjunto de instrucciones permanentes que el desarrollador envía al modelo junto con la conversación para definir su rol, su tono, sus límites y su formato. El usuario normalmente no lo ve, pero lo siente en cada respuesta.

¿Qué es y cómo se usa en las APIs?

Un modelo no recuerda nada entre peticiones: cada llamada a la API lleva todo lo que el modelo necesita. El system prompt es la parte de esa llamada que fija el marco general y que el usuario no escribe. Es el lugar natural para decir qué es el producto, para quién trabaja, qué tono usa y qué formato debe entregar.

Cada proveedor lo nombra distinto:

Anthropic (Claude): un parámetro system de nivel superior en la Messages API. La referencia lo describe como una forma de dar contexto e instrucciones a Claude, por ejemplo un objetivo o un rol. Su guía de prompting indica que fijar un rol en el system prompt enfoca el comportamiento y el tono, y que incluso una sola frase marca la diferencia.
OpenAI: el rol developer (mensajes del desarrollador, con prioridad sobre los del usuario) y el parámetro instructions de la Responses API, que tiene prioridad sobre el input. Según la documentación, instructions solo se aplica a la petición actual: si encadenas respuestas con previous_response_id, las instrucciones anteriores no pasan al nuevo contexto.
Google (Gemini): un parámetro system_instruction que se envía junto con el resto de la petición.

El concepto es el mismo y el nombre cambia: revisa la documentación del proveedor que uses.

Como cualquier texto dentro de la ventana de contexto, el system prompt ocupa tokens en cada petición. Uno de 3.000 tokens se paga en cada turno, salvo que el proveedor ofrezca caché para esa parte; véase prompt caching.

Hay que distinguirlo de otros dos conceptos. El prompt del usuario es lo que la persona escribe en cada turno. El system prompt es lo que el equipo escribe una vez para todas las conversaciones. El context engineering es la disciplina más amplia de decidir todo lo que entra en la ventana de contexto: system prompt, historial, documentos recuperados y resultados de herramientas. El system prompt es una pieza de ese conjunto, no el conjunto entero.

También existe en productos conocidos. Anthropic publica los system prompts de claude.ai y de sus apps móviles, que dan información como la fecha actual y fomentan comportamientos como mostrar código en Markdown. Anthropic aclara que esas actualizaciones no se aplican a la API: quien usa la API parte sin ese prompt y escribe el suyo.

¿Qué debe contener?

Un buen system prompt responde a cinco preguntas:

Quién es el asistente: su rol y su relación con la marca.
Para quién trabaja: el público y su nivel de conocimiento.
Qué hace y qué no hace: tareas permitidas y límites explícitos.
Cómo habla: tono, longitud y idioma.
Cómo entrega la respuesta: formato, con un ejemplo si hace falta.

Escríbelo en prosa clara y en secciones cortas. Evita las listas de excepciones infinitas: si hay muchas, probablemente estás mezclando reglas con casos de prueba.

Un detalle práctico: los modelos recientes siguen mejor las instrucciones, y eso cambia el estilo. La guía de Anthropic advierte que Claude Opus 4.5 y 4.6 responden más al system prompt que los modelos anteriores, y que un lenguaje agresivo pensado para compensar la falta de atención (“CRITICAL: You MUST…”) puede provocar que la herramienta se use de más. Su consejo es suavizarlo y escribir “usa esta herramienta cuando…”.

¿Qué no debe contener?

Secretos. Claves de API, contraseñas, datos internos sensibles. Un usuario puede lograr que el modelo revele el contenido del prompt (la técnica se llama prompt leaking), así que no lo trates como un lugar privado.
Datos que cambian a diario. Precios, inventarios o políticas que se actualizan deben venir de una fuente consultada en el momento. Véase knowledge cutoff.
Instrucciones contradictorias. Si dos reglas se pisan, el modelo elegirá de forma impredecible.
Texto de relleno. Frases de cortesía o advertencias genéricas que no cambian el comportamiento solo ocupan espacio.

¿Dónde debe vivir cada cosa?

Tipo de información	Dónde va	Por qué
Rol, tono y formato	System prompt	Cambia poco y afecta a todas las respuestas
Política, precios, inventario	Herramienta o fuente consultada	Cambia con frecuencia y debe ser exacta
Historial del usuario	Mensajes de la conversación, resumidos si crece	Es específico de cada sesión
Claves y credenciales	Variables de entorno o un gestor de secretos, nunca en el prompt	El modelo no debe poder leerlas
Ejemplos de respuestas buenas	Pocos ejemplos en el system prompt o en la conversación	Enseñan el patrón con poco espacio; véase few-shot prompting

¿Qué pasa con la seguridad?

El system prompt no es una barrera de seguridad. La inyección de prompts indirecta consiste en esconder instrucciones en datos externos que la aplicación recupera, como un correo, una página web o un documento. El artículo de Greshake y colegas (2023) mostró que, en aplicaciones que integran modelos, un atacante puede plantar prompts en contenido que la aplicación recupera después, y así alterar su comportamiento o robar datos. Los autores señalaron que faltaban defensas efectivas.

El National Cyber Security Centre del Reino Unido (NCSC) escribió en diciembre de 2025 que los ataques de prompt injection quizá nunca se mitiguen del todo y que lo realista es reducir su probabilidad e impacto; advierte además contra productos que prometan “detenerlos”. La práctica habitual combina varias capas: filtrar entradas y salidas (véase guardrails), dar al agente solo los permisos mínimos, separar el contenido externo de las instrucciones y mantener supervisión humana en acciones sensibles. El system prompt ayuda, pero no basta.

¿Cuándo NO conviene un system prompt largo?

Cuando el producto es muy simple y una frase basta. También cuando las reglas cambian según el contexto del usuario: en esos casos es mejor cargar instrucciones específicas solo cuando hacen falta, en lugar de un prompt gigante que siempre se envía. Los asistentes de código lo hacen con archivos de instrucciones por proyecto; véase CLAUDE.md y AGENTS.md.

Ejemplo

Ejemplo ilustrativo: un asistente de soporte para una tienda de muebles tiene un system prompt de 1.800 tokens que incluye políticas de devolución, tabla de precios y una lista de 40 excepciones. Las respuestas son inconsistentes porque las excepciones se contradicen. El equipo lo reescribe: el system prompt define rol, tono y formato; la política y los precios se consultan con una herramienta en cada caso; y las excepciones pasan a una tabla que se revisa cada mes. El costo por conversación baja y las respuestas se alinean con la política vigente.

Errores comunes

Guardar claves o datos sensibles en el system prompt.
Confiar en que el prompt de sistema impide cualquier mal uso.
Acumular excepciones hasta que se contradicen.
Copiar prompts de ejemplo sin adaptarlos al producto.
No versionar el system prompt ni registrar qué versión produjo cada respuesta; sin eso no puedes detectar regresiones en prompts cuando cambias una frase.
Dar por hecho que un cambio de modelo no afecta al prompt: pruébalo con casos fijos antes de migrar.

Fuentes

Anthropic, “Prompting best practices” (rol en el system prompt; sensibilidad al system prompt en modelos recientes): https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
Anthropic, referencia de la Messages API (parámetro system): https://platform.claude.com/docs/en/api/messages
Anthropic, “System prompts” (notas de versión de los prompts de claude.ai y las apps; no aplican a la API): https://platform.claude.com/docs/en/release-notes/system-prompts
OpenAI, guía de generación de texto (roles developer y user, parámetro instructions): https://developers.openai.com/api/docs/guides/text
Google, documentación de generación de texto de Gemini (parámetro system_instruction): https://aistudio.google.com/docs/text-generation
NCSC, “Prompt injection is not SQL injection” (8 de diciembre de 2025): https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
Greshake et al., “Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection” (arXiv:2302.12173, 2023): https://arxiv.org/abs/2302.12173
Wikipedia, “Prompt injection” (incluye el prompt leaking): https://en.wikipedia.org/wiki/Prompt_injection

Preguntas frecuentes

¿Qué es un system prompt?

Es el conjunto de instrucciones que el desarrollador envía al modelo junto con cada petición, para definir su rol, su tono, sus límites y su formato. El usuario normalmente no lo ve.

¿El usuario puede leer el system prompt?

Puede intentar que el modelo lo revele, y a veces lo consigue; se conocen casos de sistemas que filtraron su prompt. Por eso no debe contener secretos ni datos que no quieras que se revelen.

¿Cuánto debe medir un system prompt?

Lo mínimo necesario para la tarea. Un prompt largo ocupa espacio en cada petición y puede diluir las instrucciones más importantes.

¿Un system prompt protege contra la inyección de prompts?

Solo parcialmente. Ayuda, pero no es una defensa suficiente: el NCSC británico advierte que la inyección de prompts quizá nunca se mitigue por completo. Conviene limitar permisos, separar datos externos de instrucciones y mantener supervisión humana en acciones sensibles.