Quien migra un prompt entre proveedores suele encontrarse con una trampa simple: los nombres parecen equivalentes, pero la arquitectura no lo es. En agosto de 2026, OpenAI, Anthropic y Google convergen en la idea de separar las instrucciones de alto nivel de la solicitud inmediata del usuario, pero cada API representa esa separación de una forma diferente. Copiar un payload cambiando solo el nombre del modelo puede alterar la autoridad, el contexto e incluso el significado de una instrucción.
La respuesta corta es esta: developer message es una capa explícita en OpenAI, pero no es un rol universal. En la API de Claude, las reglas persistentes de la aplicación normalmente van en system, mientras que la conversación usa user y assistant; los modelos compatibles también permiten instrucciones system en medio de la conversación. En la API de Gemini, la regla de alto nivel va en system_instruction y los turnos de conversación usan user y model. Por lo tanto, el concepto es portable; el nombre del rol no lo es.
Qué significa realmente la jerarquía de instrucciones
La jerarquía de instrucciones es el mecanismo por el cual el modelo decide qué hacer cuando recibe orientaciones incompatibles de fuentes diferentes. La cuestión no es solo el orden en que aparece el texto. El punto central es la autoridad atribuida al origen de esa instrucción.
Si una aplicación dice que la respuesta debe obedecer una regla y el usuario pide lo contrario, el resultado depende de dónde se colocó la regla y de cómo ese proveedor interpreta esa capa. Lo mismo vale para instrucciones encontradas en documentos, páginas web, salidas de herramientas o historial de conversación. Tratar todo como texto equivalente aumenta el riesgo de que prevalezca la
instrucción equivocada.
Esta distinción ganó un peso especial en OpenAI en 2026. El 10 de marzo, la empresa publicó IH-Challenge, un trabajo orientado a entrenar modelos de frontera para seguir instrucciones según el nivel de confianza. La publicación resume el orden operativo usado en ese contexto como system por encima de developer, developer por encima de user y user por encima de tool. El Model Spec de OpenAI es aún más amplio e incluye niveles que el desarrollador no controla directamente, como Root, por encima de System.
Para quien construye aplicaciones, esto lleva a una regla práctica: no confundas la posición en el payload con la autoridad. Una instrucción debe estar en la capa semántica correcta.
OpenAI: developer es una capa propia y está por encima del usuario
Entre los tres proveedores, OpenAI es quien publica la jerarquía de manera más explícita. La documentación actual de la Responses API describe mensajes con roles que indican la jerarquía para seguir instrucciones e informa que developer o system tienen precedencia sobre user. El Model Spec organiza la cadena de autoridad en Root, System, Developer, User y Guideline.
Root y parte de System están bajo el control de la propia OpenAI. Para el desarrollador de la aplicación, la capa más importante es Developer. Allí deben ir las reglas del producto, el comportamiento persistente, el formato esperado, los límites del agente y otras instrucciones que el usuario final no debería poder sustituir simplemente escribiendo una solicitud contraria.
User representa la solicitud del usuario y los datos que proporciona para esa interacción. Assistant representa respuestas anteriores del modelo y ayuda a formar el historial, pero no debe tratarse como sustituto de una instrucción de la aplicación. Las salidas de herramientas y el contenido recuperado de fuentes externas exigen un cuidado adicional porque pueden contener texto que parece un comando, aunque debe tratarse como dato.
Por qué system y developer todavía generan confusión en
OpenAI La confusión existe porque system se utilizó históricamente como el lugar donde el desarrollador colocaba el prompt principal. La documentación de Chat Completions informa hoy que, con los modelos o1 y posteriores, los developer messages sustituyen a los antiguos system messages para esa finalidad. Al mismo tiempo, la API sigue exponiendo system en distintas superficies y el Model Spec mantiene System como un nivel por encima de Developer.
Para aplicaciones nuevas, esto favorece una convención clara: usa Developer para las reglas que pertenecen a tu aplicación y User para la solicitud del usuario. Si la superficie utilizada ofrece un campo instructions, trátalo como el área de instrucciones de alto nivel prevista por la API y comprueba cómo se serializa para el
modelo elegido. En la Responses API, las instructions de una respuesta anterior no se cargan automáticamente solo porque reutilices previous_response_id; si la regla necesita seguir vigente, la aplicación debe proporcionarla de nuevo según el flujo de la API.
Esta diferencia es importante porque una arquitectura robusta no debe depender de una memoria implícita. Una regla persistente es responsabilidad de la aplicación, no un efecto secundario del historial.
Claude: system existe, pero no hay un developer message equivalente
En la API de Claude, la estructura tradicional de la Messages API es diferente. El campo system de nivel superior recibe las instrucciones que deben guiar a Claude desde el inicio, mientras que el array de mensajes representa la conversación con roles user y assistant. La referencia oficial destaca justamente que el system prompt no es, en el formato clásico, un turno común insertado como primer elemento de messages.
Esto significa que un developer message de OpenAI no debe convertirse literalmente en un rol llamado developer al migrar a Claude. La función semántica de esa regla normalmente debe mapearse a system.
En 2026 apareció un matiz nuevo. La documentación de Claude pasó a permitir, en modelos compatibles, mensajes con role system en medio de la conversación. Sirven para introducir o actualizar instrucciones de sistema sin reescribir todo el prefijo. En esas superficies, una instrucción system posterior tiene precedencia sobre una instrucción system anterior para los turnos siguientes. El recurso depende del modelo y no convierte developer en un nuevo rol de la Messages API.
El historial assistant no es una capa de política
Claude también permite que mensajes assistant aparezcan en el historial y, en algunos flujos, se usen para iniciar parcialmente la siguiente respuesta. Eso puede moldear la continuación, pero es otra cosa. El historial de respuestas no debe guardar reglas críticas que deberían estar en system.
También existe una diferencia entre el producto Claude y la Claude API. Anthropic publica notas sobre prompts de sistema usados en claude.ai y en las aplicaciones móviles, pero deja claro que esas actualizaciones del producto no son el mismo prompt que el desarrollador envía por la API. Al comparar proveedores, hay que separar el comportamiento de la aplicación de consumo del contrato de la API.
Gemini: system_instruction es la regla del desarrollador, sin role developer
En la Gemini API, el paralelo más cercano a la capa persistente de la aplicación es system_instruction. La documentación de Google describe este campo como una instrucción de sistema definida por el desarrollador y muestra su uso tanto en la generación de contenido como en la Interactions API.
En el formato GenerateContent, los contenidos de la conversación usan role user o role model. La propia referencia del tipo Content limita el productor del turno a esos dos valores. Por lo tanto, no existe un rol developer separado equivalente al de OpenAI. La regla que, en una arquitectura de OpenAI, iría a Developer suele colocarse en system_instruction en Gemini.
En la Interactions API, la forma puede parecer aún más simple: system_instruction aparece como parámetro de configuración y la solicitud puede enviarse en input. La idea sigue siendo separar el comportamiento estable de la solicitud inmediata.
La portada de este artículo usa la expresión developer instruction en la columna de Gemini como una capa conceptual de regla del desarrollador. En el payload real de la Gemini API, sin embargo, esa función se materializa en system_instruction; no hay un role developer separado en la estructura estándar de conversación.
System prompt es un concepto común, no un contrato común
La expresión system prompt se usa de forma amplia en el mercado para indicar instrucciones de alto nivel. Eso es útil en una conversación conceptual, pero puede entorpecer cuando alguien transforma el concepto directamente en código.
En OpenAI, System y Developer son niveles distintos en la especificación de autoridad, y Developer es la capa explícita para instrucciones de la aplicación. En Anthropic, system es el campo principal para ese tipo de regla y no existe un developer role equivalente. En Gemini, system_instruction es definido por el desarrollador, mientras que la conversación trabaja con user y model.
Por eso, una biblioteca interna no debería almacenar solo un texto llamado system_prompt y volcarlo en el mismo lugar para cualquier proveedor. Es mejor separar la intención de la instrucción de la sintaxis de la API.
Dónde colocar cada tipo de regla al trabajar con los tres proveedores
Reglas estables de la aplicación
La persona operativa, el idioma predeterminado, los límites del flujo, los criterios de respuesta y las reglas que no deben ser sustituidas por la solicitud del usuario pertenecen a la capa de aplicación. En OpenAI, el destino preferente para modelos modernos es Developer o el área de instructions equivalente de la superficie utilizada. En Claude, el destino es system. En Gemini, es system_instruction.
El contenido puede ser semánticamente el mismo, pero la aplicación debe tener adaptadores por proveedor. Ese es el punto en el que debe producirse la portabilidad.
Solicitud inmediata del usuario
La intención actual del usuario debe quedar en la capa destinada al usuario. En OpenAI y Claude, esto normalmente significa un mensaje user. En Gemini
GenerateContent, también es user; en la Interactions API, la solicitud puede aparecer en input.
Mezclar reglas permanentes dentro de cada solicitud del usuario vuelve el sistema más frágil, aumenta el costo de tokens y dificulta identificar por qué una respuesta incumplió el comportamiento esperado.
Historial de conversación
El historial sirve para la continuidad, no para almacenar políticas. OpenAI y Claude usan assistant para respuestas anteriores. Gemini usa model. Si una regla debe seguir siendo válida, debe continuar representada en la capa de instrucción apropiada, en lugar de depender de que el modelo la infiera a partir de una respuesta antigua.
Documentos, herramientas y contenido recuperado
Los datos procedentes de búsqueda, RAG, páginas, archivos y herramientas deben tratarse como evidencia o contexto, no como una nueva autoridad. Esta precaución es central frente al prompt injection: un documento puede contener la frase ignore las instrucciones anteriores sin que eso deba cambiar el objetivo de la aplicación.
OpenAI hizo explícita esta relación en su trabajo sobre jerarquía de instrucciones y en el Model Spec al tratar el contenido no confiable y las salidas de herramientas con menor autoridad. Anthropic y Google usan estructuras diferentes, pero la ingeniería segura sigue exigiendo que el desarrollador separe dato de comando en vez de confiar solo en la capacidad del modelo para adivinar la intención.
Qué ocurre cuando dos instrucciones entran en conflicto
Regla de la aplicación frente a solicitud del usuario
Imagina un asistente interno que debe responder únicamente con información encontrada en una base aprobada. Si el usuario le pide ignorar esa restricción e inventar una respuesta, la regla estructural debe seguir en la capa de aplicación. En OpenAI, eso significa Developer por encima de User. En Claude, la orientación debe estar en system, no escondida en un turno antiguo de assistant. En Gemini, debe estar en system_instruction, no mezclada con el texto de input.
El resultado práctico esperado es parecido, pero la justificación formal no es idéntica. OpenAI publica una cadena de autoridad explícita. Anthropic y Google documentan los campos y sus usos, pero no presentan la misma escalera pública de niveles con la misma nomenclatura. Por eso, es incorrecto vender la fórmula system mayor que user como si fuera una especificación universal idéntica entre los tres.
Una instrucción antigua frente a una regla nueva
En conversaciones largas, las reglas pueden cambiar. En OpenAI, la aplicación debe enviar la instrucción actual en la capa correcta y no confiar en un prompt antiguo cargado por el historial. En Claude, los modelos compatibles con system en medio
de la conversación permiten insertar una instrucción system posterior, que pasa a tener precedencia sobre instrucciones system anteriores para los turnos siguientes. En Gemini, la orientación debe actualizarse en la configuración de system_instruction del flujo que se está ejecutando.
El principio de implementación es versionar las reglas fuera de la conversación. El historial registra lo que ocurrió; la configuración actual determina cómo debe funcionar el agente ahora.
Prompt injection dentro de una fuente externa
Esta es la prueba que mejor revela si la arquitectura está separando autoridad de contenido. Si un archivo consultado contiene un comando dirigido al modelo, la aplicación debe tratarlo como parte del documento, no como una instrucción del desarrollador. Colocar contenido recuperado directamente en la misma capa de las reglas de la aplicación es un fallo de diseño, independientemente del proveedor.
Por qué una jerarquía de prompts no sustituye los controles de software
Incluso una jerarquía bien definida no debe utilizarse como único mecanismo de autorización. Si una acción exige permiso, la aplicación debe validar ese permiso en código. Si una salida necesita obedecer un schema, usa recursos de salida estructurada o una validación apropiada cuando estén disponibles. Si una herramienta puede causar un efecto real, limita parámetros, credenciales y alcance en el sistema que ejecuta la acción.
Los prompts orientan al modelo; no sustituyen el control de acceso, la validación de datos, las reglas de negocio ni el aislamiento de contenido no confiable. El trabajo de OpenAI de 2026 sobre jerarquía de instrucciones refuerza precisamente la importancia de enseñar al modelo a priorizar fuentes confiables, pero esto es una capa de defensa, no una licencia para eliminar controles deterministas.
Cómo diseñar una capa portable entre OpenAI, Claude y Gemini
La forma más estable es crear una representación interna independiente del proveedor. En lugar de pensar primero en system, developer o user, piensa en categorías semánticas: política de la aplicación, instrucciones operativas, solicitud del usuario, contexto no confiable e historial.
En la integración con OpenAI, la política y las instrucciones operativas se mapean a Developer o al mecanismo de instructions apropiado; la solicitud va a User; el historial mantiene sus roles. En la integración con Claude, la política y las instrucciones operativas van a system; la solicitud va a user; el historial alterna user y assistant. En la integración con Gemini, la política y las instrucciones operativas van a system_instruction; la solicitud entra como input o user; el historial usa user y model.
Esta arquitectura permite cambiar de proveedor sin fingir que las APIs son iguales. También facilita las pruebas, porque la misma regla interna puede representarse de maneras distintas y compararse en escenarios equivalentes.
La prueba mínima antes de declarar portable un prompt
Primero, provoca un conflicto directo entre la regla de la aplicación y la solicitud del usuario. El comportamiento esperado debe mantenerse estable en cada proveedor.
Después, coloca una instrucción maliciosa dentro de un documento o retorno de herramienta y confirma que se interpreta como dato. Esta prueba verifica si el adaptador elevó contenido externo a la capa equivocada.
Por último, cambia una regla en medio de una conversación larga. La prueba debe confirmar que la regla nueva es la que realmente se aplica y que el historial antiguo no sigue mandando por accidente. En Claude, esto también exige comprobar si el modelo elegido admite system en medio de la conversación; en OpenAI y Gemini, exige atención a cómo el estado y las instrucciones se reenvían en cada llamada.
La regla práctica para no confundir los tres
Si estás usando OpenAI, piensa en Developer para las reglas de la aplicación y en User para la solicitud final, recordando que la plataforma tiene niveles superiores que el usuario no controla. Si estás usando Claude, piensa en system para reglas persistentes y user para la solicitud, con assistant como historial y system en medio de la conversación solo cuando la superficie y el modelo lo admitan. Si estás usando Gemini, piensa en system_instruction para reglas definidas por el desarrollador y user o input para la solicitud, con model representando respuestas anteriores.
La semejanza entre los proveedores está en la separación de responsabilidades. La diferencia está en el contrato concreto de la API. Esa diferencia es la que debe preservarse en una migración.
Qué conviene revisar en proyectos existentes
Los proyectos que nacieron antes de la consolidación de developer messages en OpenAI pueden seguir concentrándolo todo en system. Las integraciones de Claude pueden cargar reglas críticas repetidas en mensajes user porque se adaptaron a partir de ejemplos genéricos. Las integraciones de Gemini pueden tratar system_instruction como si fuera un tercer turno de la conversación, cuando es un campo de configuración separado.
Revisar estos puntos suele aportar más previsibilidad que simplemente aumentar el tamaño del prompt. Una arquitectura más corta, con cada instrucción en el nivel correcto, es más fácil de probar y de portar.
También es importante registrar la fecha de implementación. Las APIs evolucionan rápidamente. Las diferencias descritas aquí reflejan la documentación oficial consultada el 24 de agosto de 2026. Antes de implantar una migración, confirma la referencia actual del endpoint, del modelo y del SDK elegido, especialmente para
recursos dependientes del modelo como los mensajes system en medio de la conversación en Claude.
Concepto común no significa implementación idéntica
OpenAI, Claude y Gemini permiten al desarrollador separar reglas estables de la solicitud inmediata, pero no ofrecen tres versiones del mismo esquema. OpenAI formaliza una capa Developer y una cadena de autoridad explícita. Claude concentra las reglas de aplicación en system y mantiene la conversación en user y assistant, con extensiones de system en medio de la conversación en modelos compatibles. Gemini usa system_instruction y restringe los roles de contenido a user y model en GenerateContent.
La mejor práctica, por tanto, no es memorizar una tabla de equivalencias, sino modelar la intención de cada instrucción en tu propio código. Después, cada adaptador envía esa intención al campo correcto del proveedor. Así es como la jerarquía deja de ser un detalle del prompt y pasa a formar parte de la arquitectura de la aplicación.
