Definición
El system prompt es el bloque de instrucciones que se le da al modelo antes de que empiece la conversación, y que define quién es, qué puede hacer y qué no.
Es un mensaje más dentro de la conversación, pero ocupa un lugar especial: los modelos actuales están entrenados para darle más peso que a lo que diga después el usuario. Es la diferencia entre "las normas de la casa" y "lo que pide un cliente".
En la práctica es donde se juega buena parte de la calidad de un asistente. El mismo modelo, con el mismo usuario, se comporta de forma completamente distinta según lo que pongas ahí.
Qué va dentro
Un system prompt que funciona suele cubrir cinco cosas:
- Papel y contexto. Quién es y para quién trabaja. "Eres el asistente de una empresa de suministro industrial que atiende a clientes profesionales."
- Alcance. De qué habla y de qué no. Esta parte evita la mitad de los problemas.
- Tono y formato. Cómo tiene que sonar y cómo estructurar la respuesta. Si esperas JSON, aquí se dice y se enseña el esquema.
- Reglas duras. Lo que nunca debe hacer: inventarse precios, prometer plazos, dar datos de otro cliente.
- Qué hacer cuando no sabe. Es la instrucción que más se olvida y la que más alucinaciones evita. Un modelo sin salida airosa se inventa una.
Ejemplo práctico
El asistente del teléfono de aeworks.tech tiene un system prompt corto y muy cerrado. La versión resumida de lo que dice:
- Es el asistente de un estudio digital de una sola persona, y atiende a visitantes de la web.
- Solo habla de los servicios que hay publicados, de plazos y de cómo se trabaja. De precios exactos no habla: dice el punto de partida y deriva a un presupuesto.
- No promete fechas concretas.
- Su objetivo real no es charlar: es entender qué necesita el visitante y quedarse con su contacto.
- Si no sabe algo, lo dice y ofrece el correo.
Lo interesante es la última instrucción: cuando ya tiene el contacto, tiene que terminar su mensaje con una línea con un formato exacto que el servidor detecta y convierte en un aviso. El modelo no "envía" nada: escribe una marca y el código hace el trabajo.
Ese patrón —el modelo escribe, el sistema ejecuta— es el que uso siempre que hay una acción con consecuencias. Es más aburrido que darle herramientas de escritura directa, y mucho más difícil de romper.
Errores comunes
- Escribirlo larguísimo. Cuatro mil palabras de instrucciones no dan cuatro mil palabras de obediencia: dan un modelo que se pierde y que además consume ventana de contexto en cada mensaje. Corto, ordenado y con lo importante arriba.
- Meter datos que cambian. Precios, stock o plazos dentro del system prompt caducan sin que nadie se entere. Eso va por RAG o por herramienta, no escrito a fuego.
- Contradecirse. "Sé conciso" y "explica cada decisión en detalle" en el mismo texto: el modelo cumplirá una y se saltará la otra, y no sabrás cuál.
- Confiar en él como seguridad. Un system prompt es una instrucción, no una barrera. Si un usuario puede convencer al modelo de saltárselo, se lo salta: eso es prompt injection. Lo que no debe pasar se impide en el servidor.
- Suponer que es secreto. Con insistencia suficiente, casi cualquier modelo acaba revelando o parafraseando sus instrucciones. No pongas ahí nada que no puedas ver publicado.
Cómo escribirlo bien
- Frases cortas e imperativas. El modelo sigue mejor "no des precios exactos" que "sería preferible evitar mencionar precios".
- Enseña ejemplos del formato exacto que esperas, en lugar de describirlo.
- Pon primero lo que sí tiene que hacer, y después las prohibiciones.
- Guárdalo en el código con control de versiones, no pegado en un panel. Es lógica de producto: merece revisión y merece historial.
- Cámbialo de uno en uno y vuelve a pasar tus evals. Tocar tres cosas a la vez y ver que empeora no te dice cuál fue.
Cuándo usarlo
Siempre que montes algo con un modelo que no sea una prueba de un minuto. Un asistente sin system prompt es un modelo genérico contestando lo que le parece, y se nota a la segunda pregunta.
