System prompts: como dar um papel persistente à IA

Um system prompt é a camada de instrução que roda antes de qualquer interação com o usuário. Ele define tom, escopo, persona e restrições. Para quem está colocando um produto de IA em produção, é o que separa um modelo genérico de uma ferramenta com comportamento intencional. O que a maioria das explicações sobre o assunto ignora é justamente a parte que importa em ambiente real: a autoridade do system prompt é probabilística, não aplicada, e ela se degrada de forma previsível sob as condições certas.

O que esse artigo cobre: como system prompts funcionam tecnicamente, como escrevê-los para que o papel realmente se sustente, e onde esse papel quebra mesmo quando você fez tudo certo.

System prompts ficam no topo da hierarquia de instrução, mas essa hierarquia não é hermética

Um artigo do arxiv de fevereiro de 2026 intitulado "Who Controls the Conversation?" descreve a ordem de instrução com clareza: mensagens de sistema têm o maior privilégio, mensagens do usuário ficam abaixo, outputs do modelo ficam abaixo ainda, e outputs de ferramentas ficam no fundo. A OpenAI chama isso de "chain of command". Esse enquadramento implica que a autoridade flui de cima para baixo de forma limpa e determinística.

Na prática, o enquadramento está correto para a ordem de prioridade, mas é enganoso sobre a aplicação. Modelos não fazem parsing de instruções como um motor de regras. Tudo no context window é ponderado probabilisticamente. System prompts têm uma vantagem estrutural porque aparecem primeiro e porque modelos com instruction tuning são treinados para tratá-los como autoritativos, mas essa vantagem não é absoluta. Ela se degrada conforme a conversa cresce e conforme as mensagens do usuário acumulam momentum em outra direção.

A documentação da Anthropic sobre system prompts enquadra a separação corretamente: coloque o papel no parâmetro de sistema, coloque a tarefa no turno do usuário. Um prompt como "Você é um cientista de dados experiente em uma grande varejista brasileira" molda o output de maneiras que uma instrução genérica como "seja útil" não consegue. A documentação nota que até uma única frase faz diferença para focar o comportamento e o tom do Claude, o que se confirma na prática.

O que essa documentação não endereça em detalhe é o que acontece depois do turno 10.

Como escrever um system prompt que se sustenta sob pressão do usuário

Estrutura importa mais do que tamanho. Um system prompt que lista 40 regras performa pior do que um que estabelece uma identidade coerente com um número pequeno de restrições inegociáveis. Sem contexto suficiente, o modelo não consegue derivar o comportamento correto a partir de primeiros princípios quando um caso de borda aparece que você não antecipou explicitamente.

Três coisas que melhoram a estabilidade do papel:

• Estabeleça a identidade antes de listar as restrições. "Você é um agente de suporte da empresa X" seguido de "nunca discuta preços de concorrentes" dá ao modelo um frame para ancorar a restrição. Começar com uma lista de proibições não dá ao modelo nada para se apoiar.
• Use restrições negativas de forma explícita. O guia de prompting da Shopify faz esse ponto diretamente: especificar o que a ferramenta não deve fazer produz outputs mais confiáveis do que depender apenas de instruções positivas. Na prática isso significa "não especule sobre prazos de entrega que você não pode confirmar" em vez de "discuta apenas informações confirmadas".
• Declare o raciocínio por trás das restrições-chave quando o motivo não for óbvio. Um modelo que entende por que uma restrição existe vai generalizá-la corretamente para casos de borda. Um que só tem a regra vai às vezes perder casos adjacentes.

Especificidade de persona aparece muito como dúvida. Mais especificidade é geralmente melhor, até certo ponto. "Você é uma especialista em análise de dados de clientes no varejo" vai produzir outputs diferentes de "você é uma analista de dados", que por sua vez difere de "você é uma analista". Cada dimensão adicionada foca a distribuição de probabilidade das respostas prováveis. Especificação excessiva em território que conflita internamente cria seus próprios problemas, mas esse limiar é mais alto do que a maioria dos profissionais atinge.

Uma coisa que um system prompt não consegue fazer: sobrescrever o treinamento constitucional de segurança do Claude. Como a Constituição da Anthropic deixa claro, a camada de segurança é arquitetura, não configuração. Um system prompt instruindo o Claude a produzir conteúdo que seu treinamento classificou como fora dos limites não vai funcionar, independente de como a instrução é enquadrada. Para quem está construindo produtos na API, entender as camadas de autoridade operador/usuário/Anthropic antes do deploy evita muito tempo de depuração depois. O artigo sobre Constitutional AI cobre essa estrutura em mais detalhe.

A autoridade do system prompt degrada no meio da conversa, e ninguém avisa sobre o turno 15

Aqui está a parte que quebra suposições em produtos em produção. Um bot de atendimento instruído a "nunca discutir preços de concorrentes" vai manter esse limite com confiança no turno 3. Já no turno 15 a 20 de uma conversa estendida, especialmente se os usuários enquadram seus pedidos de forma conversacional em vez de comandos diretos, a conformidade se suaviza de forma mensurável. Nenhum momento óbvio de "jailbreak" dispara isso. O papel simplesmente vai cedendo gradualmente ao peso acumulado do contexto conversacional.

A pesquisa do artigo do arxiv de fevereiro de 2026 confirma que o privilégio da mensagem de sistema opera em probabilidade, não em aplicação. Em uma conversa curta, o system prompt representa uma grande fatia do contexto, então seu peso é alto. Conforme a contagem de turnos do usuário cresce, a proporção muda. O momentum conversacional recente começa a importar mais do que o frame de instrução inicial. Um usuário que passou 12 turnos construindo rapport com um bot e então faz uma pergunta limítrofe está aplicando pressão social implícita que o treinamento do modelo trata como sinal relevante, mesmo quando o system prompt diz o contrário.

Essa dinâmica tem consequências reais em contextos de vendas e suporte. Os casos em que suas restrições são testadas são quase sempre conversas longas com usuários engajados, que são precisamente os casos em que a autoridade do system prompt é mais fraca.

As mitigações práticas são limitadas, mas existem. Injetar uma versão condensada das suas restrições principais em intervalos, prática muitas vezes chamada de "prompt injection refresh", estende a estabilidade em threads longas, ainda que consuma tokens. Desenhar fluxos de conversa que limitam o tamanho do thread por meio de checkpoints naturais, como resets de sessão ou cortes por conclusão de tarefa, evita o problema arquiteturalmente. Para restrições de alto risco, fazer red-team dos seus system prompts antes do deploy contra cenários adversariais de contexto longo deve ser parte do processo de revisão, não uma reflexão tardia.

Na prática

Uso system prompts para dar ao Claude um papel consistente em grandes volumes de tarefas similares: escrever descrições de produtos em formato específico, sinalizar valores de atributos fora do padrão, ou gerar textos de e-mail em um tom definido. Para esses casos, o papel se sustenta bem porque as conversas são curtas e estruturadas, tipicamente um ou dois turnos por tarefa. A degradação praticamente não existe quando você roda muitas sessões curtas em vez de uma longa.

A fragilidade apareceu quando testei um assistente interno mais aberto, com menos fronteiras de tarefa definidas. Sessões mais longas derivavam visivelmente em tom e às vezes em escopo, o que bateu com o que a pesquisa descreve. A correção foi estrutural: quebrar o caso de uso em sessões menores e com propósito definido em vez de tentar manter um papel amplo ao longo de um thread estendido. Não foi questão de prompt melhor, foi questão de arquitetura diferente.

Se você usa Claude em contexto parecido, com tarefas repetitivas e bem delimitadas no GA4, Snowflake, ou qualquer ferramenta de analytics, a estratégia de sessões curtas é o caminho mais confiável. O artigo sobre chain-of-thought prompting toca em pontos complementares sobre quando vale a pena investir em estrutura de prompt versus quando o problema é arquitetural.

Perguntas frequentes

Qual a diferença entre system prompt e user prompt?

Um system prompt roda antes de qualquer interação do usuário e define o contexto persistente para toda a conversa. Ele determina o papel do modelo, as restrições e o tom. Um user prompt é a mensagem enviada durante a conversa. A Anthropic recomenda colocar o papel no parâmetro de sistema e a tarefa específica no turno do usuário, mantendo as duas responsabilidades separadas.

Um system prompt pode impedir o modelo de responder certos tópicos completamente?

Parcialmente. Um system prompt pode reduzir de forma confiável a probabilidade de o modelo engajar com tópicos fora do escopo, e vai manter esse limite bem em conversas curtas. Aplicação absoluta não está disponível, especialmente em threads longos. Tópicos que caem dentro dos limites de segurança constitucional do modelo podem ser bloqueados de forma confiável via restrições de treinamento, mas restrições de lógica de negócio, como "não discuta preços de concorrentes", são probabilísticas, não garantidas.

O tamanho do system prompt importa?

Sim, mas não da forma que a maioria espera. Mais longo não é necessariamente melhor. Um prompt curto, coerente e bem estruturado frequentemente supera uma lista longa de regras, porque o modelo consegue generalizar a partir de uma identidade clara para lidar com casos de borda que não foram explicitamente instruídos. System prompts muito longos também podem fragmentar a atenção no conjunto de instruções, o que pode fazer com que algumas restrições recebam menos peso do que o pretendido.

Os usuários conseguem ver o system prompt?

Não pelo uso normal da API. Passado em um campo separado da conversa do usuário, o system prompt não é exibido para os usuários finais por padrão. Algumas implementações o ofuscam ainda mais, posto que os modelos às vezes possam revelar que um system prompt existe quando perguntados diretamente. O conteúdo do prompt geralmente não é exposto a menos que o modelo seja especificamente instruído a compartilhá-lo.

System prompts são a ferramenta certa para dar a um modelo um papel persistente, e funcionam bem dentro do seu intervalo operacional real: sessões curtas a médias, fronteiras de tarefa bem definidas, e restrições que não precisam se sustentar sob pressão adversarial prolongada. Os casos em que falham não são aleatórios. São previsíveis, e a maioria deles envolve assumir que a hierarquia de instrução opera como controle de acesso quando na verdade opera como uma distribuição de probabilidade ponderada.