Quem migra um prompt entre provedores costuma esbarrar numa armadilha simples: os nomes parecem equivalentes, mas a arquitetura não é. Em agosto de 2026, OpenAI, Anthropic e Google convergem na ideia de separar instruções de alto nível do pedido imediato do usuário, porém cada API representa essa separação de um jeito diferente. Copiar um payload trocando apenas o nome do modelo pode mudar a autoridade, o contexto e até o significado de uma instrução.
A resposta curta é esta: developer message é uma camada explícita na OpenAI, mas não é um papel universal. Na API do Claude, regras persistentes do aplicativo normalmente vão para system, enquanto a conversa usa user e assistant; modelos compatíveis também permitem instruções system no meio da conversa. Na API do Gemini, a regra de alto nível vai para system_instruction, e os turnos de conversa usam user e model. Portanto, o conceito é portável; o nome do papel não é.
O que realmente significa hierarquia de instruções
Hierarquia de instruções é o mecanismo pelo qual o modelo decide o que fazer quando recebe orientações incompatíveis de fontes diferentes. A questão não é apenas a ordem em que o texto aparece. O ponto central é a autoridade atribuída à origem daquela instrução.
Se uma aplicação diz que a resposta deve obedecer a uma regra e o usuário pede o contrário, o resultado depende de onde a regra foi colocada e de como aquele provedor interpreta essa camada. O mesmo vale para instruções encontradas em documentos, páginas da web, saídas de ferramentas ou histórico de conversa. Tratar tudo como texto equivalente aumenta o risco de a instrução errada vencer.
Essa distinção ganhou peso especial na OpenAI em 2026. Em 10 de março, a empresa
publicou o IH-Challenge, trabalho voltado a treinar modelos de fronteira para seguir instruções conforme o nível de confiança. A publicação resume a ordem operacional usada nesse contexto como system acima de developer, developer acima de user e user acima de tool. O Model Spec da OpenAI é ainda mais amplo e inclui níveis que o desenvolvedor não controla diretamente, como Root, acima de System.
Para quem constrói aplicações, isso leva a uma regra prática: não confunda posição no payload com autoridade. Uma instrução precisa estar na camada semântica correta.
OpenAI: developer é uma camada própria e fica acima do usuário
Entre os três provedores, a OpenAI é a que publica a hierarquia mais explicitamente. A documentação atual da Responses API descreve mensagens com papéis que indicam a hierarquia de seguimento de instruções e informa que developer ou system têm precedência sobre user. O Model Spec organiza a cadeia de autoridade em Root, System, Developer, User e Guideline.
Root e parte de System pertencem ao controle da própria OpenAI. Para o desenvolvedor da aplicação, a camada mais importante é Developer. É nela que entram regras do produto, comportamento persistente, formato esperado, limites do agente e outras instruções que o usuário final não deveria substituir apenas escrevendo um pedido contrário.
User representa a solicitação do usuário e os dados que ele fornece para aquela interação. Assistant representa respostas anteriores do modelo e ajuda a formar o histórico, mas não deve ser tratado como substituto de uma instrução de aplicação. Saídas de ferramentas e conteúdo recuperado de fontes externas exigem cuidado adicional porque podem conter texto que parece comando, embora deva ser tratado como dado.
Por que system e developer ainda causam confusão na OpenAI
A confusão existe porque system foi historicamente usado como o lugar onde o desenvolvedor colocava o prompt principal. A documentação de Chat Completions hoje informa que, com modelos o1 e mais novos, developer messages substituem as antigas system messages para essa finalidade. Ao mesmo tempo, a API continua expondo system em diferentes superfícies e o Model Spec mantém System como nível acima de Developer.
Para aplicações novas, isso favorece uma convenção clara: use Developer para as regras que pertencem ao seu aplicativo e User para o pedido do usuário. Se a superfície usada oferecer um campo instructions, trate-o como a área de instruções de alto nível prevista pela API e confira como ele é serializado para o modelo escolhido. Na Responses API, as instructions de uma resposta anterior não são carregadas automaticamente apenas porque você reutilizou previous_response_id; se a regra precisa continuar valendo, a aplicação deve fornecê-la novamente conforme o fluxo da API.
Essa diferença é importante porque uma arquitetura robusta não deve depender de memória implícita. Regra persistente é responsabilidade do aplicativo, não um efeito colateral do histórico.
Claude: system existe, mas não há developer message equivalente
Na API do Claude, a estrutura tradicional da Messages API é diferente. O campo system de nível superior recebe as instruções que devem orientar o Claude desde o início, enquanto o array de mensagens representa a conversa com papéis user e assistant. A referência oficial destaca justamente que o system prompt não é, no formato clássico, um turno comum inserido como primeiro item de messages.
Isso significa que uma developer message da OpenAI não deve ser convertida literalmente em um papel chamado developer ao migrar para Claude. A função semântica dessa regra normalmente deve ser mapeada para system.
Em 2026 surgiu uma nuance nova. A documentação do Claude passou a permitir, em modelos compatíveis, mensagens com role system no meio da conversa. Elas servem para introduzir ou atualizar instruções de sistema sem reescrever o prefixo inteiro. Nessas superfícies, uma instrução system posterior tem precedência sobre uma instrução system anterior para os turnos seguintes. O recurso é dependente do modelo e não transforma developer em um novo papel da Messages API.
O histórico assistant não é uma camada de política
Claude também permite que mensagens assistant apareçam no histórico e, em alguns fluxos, sejam usadas para iniciar parcialmente a próxima resposta. Isso pode moldar a continuação, mas é outra coisa. Histórico de resposta não deve guardar regras críticas que deveriam estar em system.
Há ainda uma diferença entre o produto Claude e a Claude API. A Anthropic publica notas sobre prompts de sistema usados no claude.ai e nos aplicativos móveis, mas deixa claro que essas atualizações do produto não são o mesmo prompt que o desenvolvedor envia pela API. Ao comparar provedores, é preciso separar comportamento do aplicativo de consumo e contrato da API.
Gemini: system_instruction é a regra do desenvolvedor, sem role developer
Na Gemini API, o paralelo mais próximo da camada persistente do aplicativo é system_instruction. A documentação do Google descreve esse campo como uma instrução de sistema definida pelo desenvolvedor e mostra seu uso tanto na geração de conteúdo quanto na API de Interactions.
No formato GenerateContent, os conteúdos de conversa usam role user ou role model. A própria referência do tipo Content limita o produtor do turno a esses dois valores. Portanto, não existe um papel developer separado equivalente ao da OpenAI. A regra que, em uma arquitetura OpenAI, iria para Developer costuma ser colocada em system_instruction no Gemini.
Na API de Interactions, a forma pode parecer ainda mais simples: system_instruction aparece como parâmetro de configuração e o pedido pode ser enviado em input. A ideia continua sendo separar o comportamento estável da solicitação imediata.
A capa deste artigo usa a expressão developer instruction na coluna do Gemini como uma camada conceitual de regra do desenvolvedor. No payload real da Gemini API, porém, essa função é materializada em system_instruction; não há um role developer separado na estrutura de conversa padrão.
System prompt é um conceito comum, não um contrato comum
A expressão system prompt é usada de forma ampla no mercado para indicar instruções de alto nível. Isso é útil em uma conversa conceitual, mas pode atrapalhar quando alguém transforma o conceito diretamente em código.
Na OpenAI, System e Developer são níveis distintos na especificação de autoridade, e Developer é a camada explícita para instruções do aplicativo. Na Anthropic, system é o campo principal para esse tipo de regra e não há developer role equivalente. No Gemini, system_instruction é definido pelo desenvolvedor, enquanto a conversa trabalha com user e model.
Por isso, uma biblioteca interna não deveria armazenar apenas um texto chamado system_prompt e despejá-lo no mesmo lugar em qualquer provedor. É melhor separar a intenção da instrução da sintaxe da API.
Onde colocar cada tipo de regra ao trabalhar com os três provedores
Regras estáveis do aplicativo
Persona operacional, idioma padrão, limites do fluxo, critérios de resposta e regras que não devem ser substituídas pelo pedido do usuário pertencem à camada de aplicação. Na OpenAI, o destino preferencial para modelos modernos é Developer ou a área de instructions equivalente da superfície usada. No Claude, o destino é system. No Gemini, é system_instruction.
O conteúdo pode ser semanticamente o mesmo, mas a aplicação deve possuir adaptadores por provedor. Esse é o ponto em que a portabilidade deve acontecer.
Pedido imediato do usuário
A intenção atual do usuário deve ficar na camada destinada ao usuário. Na OpenAI e no Claude, isso normalmente significa uma mensagem user. No Gemini GenerateContent, também é user; na Interactions API, o pedido pode aparecer em input.
Misturar regras permanentes dentro de cada pedido do usuário torna o sistema mais frágil, aumenta custo de tokens e dificulta identificar por que uma resposta desobedeceu ao comportamento esperado.
Histórico de conversa
Histórico serve para continuidade, não para armazenar política. OpenAI e Claude usam assistant para respostas anteriores. Gemini usa model. Se uma regra precisa continuar válida, ela deve continuar representada na camada de instrução apropriada, em vez de depender de o modelo inferi-la de uma resposta antiga.
Documentos, ferramentas e conteúdo recuperado
Dados vindos de busca, RAG, páginas, arquivos e ferramentas devem ser tratados como evidência ou contexto, não como uma nova autoridade. Esse cuidado é central contra prompt injection: um documento pode conter a frase ignore as instruções anteriores sem que isso deva mudar o objetivo do aplicativo.
A OpenAI tornou essa relação explícita no trabalho de hierarquia de instruções e no Model Spec ao tratar conteúdo não confiável e saídas de ferramentas com menor autoridade. Anthropic e Google usam estruturas diferentes, mas a engenharia segura continua exigindo que o desenvolvedor separe dado de comando em vez de confiar apenas na capacidade do modelo de adivinhar a intenção.
O que acontece quando duas instruções entram em conflito
Regra da aplicação contra pedido do usuário
Imagine um assistente interno que deve responder apenas com informações encontradas em uma base aprovada. Se o usuário pedir para ignorar essa restrição e inventar uma resposta, a regra estrutural deve continuar na camada de aplicação. Na OpenAI, isso significa Developer acima de User. No Claude, a orientação deve estar em system, não escondida num turno antigo de assistant. No Gemini, deve estar em system_instruction, não misturada ao texto de input.
O resultado prático esperado é semelhante, mas a justificativa formal não é idêntica. A OpenAI publica uma cadeia de autoridade explícita. Anthropic e Google documentam os campos e seus usos, mas não apresentam a mesma escada pública de níveis com a mesma nomenclatura. Por isso, é incorreto vender a fórmula system maior que user como se fosse uma especificação universal idêntica entre os três.
Uma instrução antiga contra uma regra nova
Em conversas longas, regras podem mudar. Na OpenAI, a aplicação deve enviar a instrução atual na camada correta e não confiar em um prompt antigo carregado por histórico. No Claude, modelos compatíveis com system no meio da conversa permitem inserir uma instrução system posterior, que passa a prevalecer sobre instruções system anteriores para os turnos seguintes. No Gemini, a orientação deve ser atualizada na configuração de system_instruction do fluxo que está sendo executado.
O princípio de implementação é versionar as regras fora da conversa. O histórico registra o que aconteceu; a configuração atual determina como o agente deve funcionar agora.
Prompt injection dentro de uma fonte externa
Esse é o teste que melhor revela se a arquitetura está separando autoridade de conteúdo. Se um arquivo consultado contém um comando ao modelo, a aplicação deve tratá-lo como parte do documento, não como instrução do desenvolvedor. Colocar conteúdo recuperado diretamente na mesma camada das regras do aplicativo é uma falha de desenho, independentemente do provedor.
Por que uma hierarquia de prompt não substitui controles de software
Mesmo uma hierarquia bem definida não deve ser usada como mecanismo único de autorização. Se uma ação exige permissão, a aplicação precisa validar a permissão em código. Se uma saída precisa obedecer a um schema, use recursos de saída estruturada ou validação apropriada quando disponíveis. Se uma ferramenta pode causar efeito real, limite parâmetros, credenciais e escopo no sistema que executa a ação.
Prompts orientam o modelo; não substituem controle de acesso, validação de dados, regras de negócio nem isolamento de conteúdo não confiável. O trabalho de 2026 da OpenAI sobre hierarquia reforça justamente a importância de ensinar o modelo a priorizar fontes confiáveis, mas isso é uma camada de defesa, não uma licença para remover controles determinísticos.
Como desenhar uma camada portátil entre OpenAI, Claude e Gemini
A forma mais estável é criar uma representação interna independente do fornecedor. Em vez de pensar primeiro em system, developer ou user, pense em categorias semânticas: política do aplicativo, instruções operacionais, pedido do usuário, contexto não confiável e histórico.
Na integração OpenAI, política e instruções operacionais são mapeadas para Developer ou para o mecanismo de instructions adequado; o pedido vai para User; o histórico mantém seus papéis. Na integração Claude, política e instruções operacionais vão para system; o pedido vai para user; o histórico alterna user e assistant. Na integração Gemini, política e instruções operacionais vão para system_instruction; o pedido entra como input ou user; o histórico usa user e model.
Essa arquitetura permite trocar de fornecedor sem fingir que as APIs são iguais. Também facilita testes, porque a mesma regra interna pode ser renderizada de maneiras diferentes e comparada em cenários equivalentes.
O teste mínimo antes de declarar um prompt portável
Primeiro, provoque um conflito direto entre a regra do aplicativo e o pedido do usuário. O comportamento esperado precisa permanecer estável em cada provedor.
Depois, coloque uma instrução maliciosa dentro de um documento ou retorno de ferramenta e confirme que ela é interpretada como dado. Esse teste verifica se o adaptador não elevou conteúdo externo para a camada errada.
Por fim, mude uma regra no meio de uma conversa longa. O teste deve confirmar que a regra nova é a efetivamente aplicada e que o histórico antigo não continua mandando por acidente. No Claude, isso também exige verificar se o modelo escolhido suporta system no meio da conversa; no OpenAI e no Gemini, exige atenção a como o estado e as instruções são reenviados em cada chamada.
A regra de bolso para não confundir os três
Se você estiver usando OpenAI, pense Developer para regras do aplicativo e User para o pedido final, lembrando que a plataforma tem níveis superiores que o usuário não controla. Se estiver usando Claude, pense system para regras persistentes e user para a solicitação, com assistant como histórico e system no meio da conversa apenas quando a superfície e o modelo suportarem. Se estiver usando Gemini, pense system_instruction para regras definidas pelo desenvolvedor e user ou input para o pedido, com model representando respostas anteriores.
A semelhança entre os provedores está na separação de responsabilidades. A diferença está no contrato concreto da API. É essa diferença que precisa ser preservada numa migração.
O que vale revisar em projetos existentes
Projetos que nasceram antes da consolidação de developer messages na OpenAI podem ainda concentrar tudo em system. Integrações do Claude podem carregar regras críticas repetidas em mensagens user porque foram adaptadas de exemplos genéricos. Integrações do Gemini podem tratar system_instruction como se fosse um terceiro turno da conversa, quando ele é um campo de configuração separado.
Revisar esses pontos costuma trazer mais previsibilidade do que simplesmente aumentar o tamanho do prompt. Uma arquitetura curta, com cada instrução no nível certo, é mais fácil de testar e de portar.
Também é importante registrar a data da implementação. As APIs evoluem rapidamente. As diferenças descritas aqui refletem a documentação oficial consultada em 24 de agosto de 2026. Antes de implantar uma migração, confirme a referência atual do endpoint, do modelo e do SDK escolhido, principalmente para recursos dependentes de modelo como mensagens system no meio da conversa no Claude.
Conceito comum não significa implementação igual
OpenAI, Claude e Gemini permitem ao desenvolvedor separar regras estáveis da solicitação imediata, mas não oferecem três versões do mesmo esquema. OpenAI formaliza uma camada Developer e uma cadeia de autoridade explícita. Claude concentra as regras de aplicação em system e mantém a conversa em user e assistant, com extensões de system no meio da conversa em modelos compatíveis. Gemini usa system_instruction e restringe os papéis de conteúdo a user e model no GenerateContent.
A melhor prática, portanto, não é decorar uma tabela de equivalências, e sim modelar a intenção de cada instrução no seu próprio código. Depois, cada adaptador envia essa intenção para o campo correto do provedor. É assim que a hierarquia deixa de ser um detalhe de prompt e vira parte da arquitetura da aplicação.
