System prompt vs prompt del usuario: la diferencia que decide si tu agente IA funciona

Este artículo forma parte de la serie Capacitaciones IThreex: contenido derivado de las formaciones internas que damos a nuestro equipo de ingeniería e implementación de agentes IA sobre la plataforma ABLE.

Un prompt no es solo el mensaje del usuario

Cuando una persona escribe en un chat de IA, cree que eso es "el prompt". Lo que realmente llega al modelo de lenguaje es un paquete completo: system prompt + contexto recuperado + historial + herramientas disponibles + mensaje del usuario. Con todo eso el modelo decide si responde directamente o si llama a una herramienta antes de responder.

Entender esa diferencia es lo que separa a alguien que "usa IA" de alguien que construye agentes que funcionan de forma predecible en producción.

System prompt: fijo, invisible, decisivo

El system prompt es la instrucción que escribe quien construye el agente. Tiene tres propiedades clave:

• Es fijo: idéntico para todos los usuarios y todas las sesiones de ese agente.
• Es invisible para el usuario final: no aparece en la conversación.
• Contiene las reglas de negocio: qué puede hacer, qué no puede hacer, cómo razonar, qué formato devolver.

Un ejemplo típico: un asistente de soporte técnico cuyo system prompt define su rol ("eres un asistente de soporte de nivel 1"), los pasos de diagnóstico que debe seguir, las restricciones ("no prometas plazos de reparación") y el formato de la respuesta.

Human prompt: variable, visible, secundario en jerarquía

El prompt del usuario es la consulta concreta: "tengo tres días con problemas de señal Wi-Fi, ¿qué puedo hacer?". Cambia en cada sesión y con cada persona. El mismo agente, con el mismo system prompt, atiende a tres usuarios distintos con tres human prompts distintos.

Por qué el system siempre gana

Esta es la parte que más consecuencias prácticas tiene. Si el system prompt dice "no puedes dar información sobre la estructura de precios interna", el usuario puede insistir todo lo que quiera: el modelo no lo va a hacer. No porque el modelo "entienda" la regla, sino porque el system ocupa la posición de mayor peso en la jerarquía de atención del LLM.

La consecuencia operativa: cualquier regla que importe debe estar en el system prompt. Delegarla al usuario, a la documentación o al "sentido común del modelo" es una decisión de arquitectura, no un detalle.

Dónde se puede editar el system prompt (y dónde no)

En ChatGPT, Claude o Gemini web, el system prompt está definido por el proveedor y es inaccesible. Solo se puede editar cuando:

• Se desarrolla la aplicación directamente contra la API del modelo.
• Se usa una plataforma de agentes que expone ese campo — el caso de ABLE, donde cada agente define su propio system prompt, sus tools, su base de conocimiento y sus canales.

Ese es exactamente el motivo por el cual un agente empresarial no se resuelve con una cuenta de ChatGPT: sin control del system prompt no hay control del comportamiento.

Errores frecuentes que vemos en implementaciones

• Reglas de negocio escritas en el mensaje del usuario — funcionan en la demo, se rompen en producción.
• System prompt de dos líneas — el agente improvisa y en la primera consulta real hace algo que nadie planificó.
• Instrucciones contradictorias — "no razones" y tres líneas después "analizá paso a paso": el modelo no cumple ninguna de las dos.
• No repetir la regla crítica al final — el modelo presta más atención al principio y, sobre todo, al final del prompt.

Cómo se aplica en ABLE

En ABLE, cada agente tiene un campo de system prompt editable, y ese prompt convive con las skills, la base de conocimiento (RAG) y los MCP conectados. El diseño del system prompt es la pieza que define cómo el agente usa todo lo demás: cuándo consultar la base de conocimiento, cuándo llamar una tool, cuándo escalar a un humano.