O que mudou no system prompt do Opus 4.7 é referência de governança

TV
Thiago Victorino
5 min de leitura
O que mudou no system prompt do Opus 4.7 é referência de governança
Ouvir este artigo

Simon Willison publicou em 18 de abril o diff completo entre os system prompts do Claude Opus 4.6 e 4.7. É o tipo de post que passa despercebido para quem está fora da bolha, mas que merece atenção de qualquer time que opera agentes em produção. Não pelo conteúdo específico das mudanças. Pelo fato de existir um diff público, legível, auditável, da camada de prompt de um fornecedor de ponta.

Isso é governança tornada visível. E vale como referência, não como template.

O que mudou, em números

Cinco pontos saltam do diff:

  • 23 ferramentas declaradas no system prompt, contra um conjunto menor na 4.6.
  • Bloco de child-safety expandido, com instrução explícita sobre o efeito de cascata: “uma vez que o Claude recuse uma solicitação por razões de segurança infantil, todas as solicitações seguintes devem ser tratadas com extrema cautela”.
  • Verbosidade reduzida: o prompt ficou mais enxuto, com menos floreios e menos instruções redundantes.
  • Remoção da linguagem anti-”genuinely”: a Anthropic tinha adicionado instruções para o modelo evitar a palavra “genuinely”, que vinha sendo super-representada nas respostas. Em 4.7, essa camada foi removida.
  • Knowledge cutoff atualizado para janeiro de 2026.

Nada disso é revolucionário isoladamente. O conjunto, porém, mostra uma camada de produto sendo versionada como qualquer outro componente de engenharia.

Por que isso importa para quem constrói

A maioria dos times que coloca agentes em produção hoje monta guardrails em três lugares: no system prompt, em hooks de ferramentas e em checagens pós-hoc. A camada de prompt costuma ser a mais frágil. Ela é editada sem revisão, sem histórico, sem dono claro. Cresce por acréscimo até virar um artefato impossível de entender.

O diff do Opus 4.7 mostra o inverso. Há instruções específicas para:

  • Ferramentas declaradas de forma estruturada, com nome e contrato.
  • Um bloco de segurança com lógica de estado. O modelo deve mudar de postura após certos gatilhos.
  • Ajuste fino de tom. A palavra “genuinely” foi literalmente caçada por um patch anterior e agora removida.
  • Uma data de cutoff tratada como metadado, não como prosa solta no meio do texto.

Se o seu system prompt não tem essa nitidez, você não tem governança. Você tem um documento de Word versionado.

O que não importar

Há um risco óbvio em publicar esse tipo de análise: times copiando trechos inteiros do prompt da Anthropic para dentro dos próprios agentes. Isso é um antipadrão.

O prompt do Opus foi escrito para um modelo treinado com constituição específica, RLHF específico, avaliações específicas. As instruções que funcionam lá não transferem linearmente. A instrução de child-safety, por exemplo, só faz sentido dentro de um modelo que já foi alinhado para reconhecer e recusar certos padrões. Colada em um modelo open-source sem esse alinhamento, ela vira teatro.

Como discuti em Constituição do Claude como governança corporativa, a constituição do modelo é a camada que dá peso ao prompt. Sem ela, o prompt vira um post-it colado na frente de um motor que não combinou as regras.

O que transferir, então? A forma, não o conteúdo. Ter um prompt versionado, com diff público interno, com owner claro, com seções estruturadas (ferramentas, segurança, tom, metadados). Isso é o que importa.

A camada externa virou auditável

O ponto meta do post do Willison é mais importante que o diff em si. Até agora, o system prompt de um fornecedor de modelos era uma caixa-preta. O cliente corporativo que comprava acesso à API não tinha como saber o que o fornecedor estava injetando antes das suas próprias instruções.

Com posts como o do Willison, essa camada fica parcialmente visível. Analistas externos conseguem acompanhar mudanças, comparar versões, identificar padrões. A Anthropic não publica o prompt oficialmente, mas ele é extraível com perguntas certas. O fornecedor sabe disso e, implicitamente, aceita o escrutínio.

Para o time de risco e compliance de uma empresa que usa Claude em fluxos regulados, isso muda algo concreto: há uma fonte secundária confiável para entender o que o fornecedor faz na camada de prompt. Não é auditoria completa. Você não vê o treinamento, não vê a infraestrutura, não vê os classificadores internos. Mas é mais do que tinha antes.

Como explorei em Modo auto do Claude Code como governança, a Anthropic vem empurrando decisões de governança para dentro do modelo, não para fora. O system prompt é a interface visível desse movimento. Cada mudança no prompt é uma decisão de produto que antes ficaria escondida e agora pode ser lida.

O que fazer com isso na sua operação

Três ações práticas para quem opera agentes:

Primeiro, trate seu system prompt como código. Versão em git. Revisão obrigatória. Changelog legível. Se alguém pergunta “por que essa instrução está aqui?”, o histórico responde. Se o prompt não cabe em uma revisão de PR, ele está grande demais.

Segundo, separe camadas. Ferramentas em um bloco. Segurança em outro. Tom em outro. Metadados (cutoff, versão, ambiente) em outro. Texto corrido misturando as quatro coisas é dívida técnica mal disfarçada.

Terceiro, audite o prompt do fornecedor quando possível. Posts como o do Willison são insumo. Leia, entenda o que o fornecedor está assumindo sobre o modelo, e verifique se essas premissas se aplicam ao seu caso. Se você usa o mesmo modelo em um contexto diferente, como um agente de suporte jurídico, o bloco de child-safety pode ser irrelevante, mas o padrão de “estado após recusa” provavelmente é útil.

O limite honesto

Nada disso substitui as camadas que você não vê. O prompt é a ponta visível. Abaixo dele há treinamento, RLHF, constituição, classificadores, hooks de API, filtros de saída. O diff do Willison cobre uma fatia fina. Um time de governança que lê o prompt e acha que entendeu a máquina está se iludindo.

Mas o inverso também vale. Um time que ignora o prompt porque “é só uma camada” está ignorando o único ponto de contato documentado entre o fornecedor e a aplicação.

O Opus 4.7 não é um marco técnico. É um marco de legibilidade. O produto ficou um pouco mais auditável do lado de fora. Quem constrói por cima pode, e deve, fazer o mesmo por dentro.


Fontes

Ajudamos equipes a desenhar governança auditável de camada de prompt para agentes em produção: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa