Grok 4.7: o que muda nas recusas e na resistência a jailbreak?

Fala aí, beleza? A xAI acabou de publicar a página oficial do Grok 4.7, e a Reuters já registrou o lançamento

Mas aqui o recorte é outro

Não vou falar de benchmark de código, nem de SWE-bench, nem de quem ganha de quem em matemática

O assunto é a parte chata e que quase ninguém lê: salvaguardas, recusas e resistência a jailbreak

Ou seja, o que acontece quando um usuário mal intencionado senta na frente do seu produto e começa a tentar torcer o modelo

E já adianto uma coisa, pra ser honesto com você desde o começo: até o momento em que escrevo, não existe model card público confirmado do 4.7 com números de segurança. Então tudo que for número aqui vem das versões anteriores, devidamente marcado

Como o Grok 4.7 chegou até aqui

Antes de falar de salvaguarda, vale entender que esse lançamento não foi uma linha reta

O flagship anterior é o Grok 4.6, listado na documentação da xAI como lançado em 12/08/2026, com janela de 500 mil tokens de contexto, entrada de texto e imagem e saída somente em texto

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Aí veio a novela

Em 11/09/2026 Musk disse publicamente que o modelo precisava de "a few more days to cook", citando dois problemas: penalização excessiva do tamanho de resposta no aprendizado por reforço e falhas de autoverificação

Esse segundo ponto é interessante porque autoverificação é exatamente o que virou o destaque do Grok 4.6 checando o próprio trabalho em tarefas longas

Dois dias depois, em 13/09, ele anunciou o Grok 4.8, de 2,5 trilhões de parâmetros, sem data de envio

Ou seja, o 4.7 chegou a ser preterido publicamente em favor de um modelo que ainda nem tinha prazo 😅

No mesmo dia, Musk posicionou o modelo assim: "Grok 4.7 should be roughly on par with Opus 5.0, not 5.1. Better in some ways, worse in others. We need to fix multimodal performance."

E agora, 21/09, a página do anúncio está no ar

Tome cuidado com as specs que você vai ver circulando. Os 2,1 trilhões de parâmetros atribuídos ao 4.7 (contra 1,5 trilhão do 4.6), o "melhor que o 4.6 em tudo, exceto um pouco mais lento para servir", a melhor eficiência de tokens e o treino suplementar com dados internos da SpaceX: tudo isso veio de declaração do Musk, não de documentação técnica da xAI

Declaração de CEO no timeline não é spec sheet, beleza?

Como a xAI constrói as salvaguardas do Grok na prática

Aqui dá pra ser bem concreto, porque a xAI documenta o mecanismo nos model cards das versões anteriores

E o mecanismo é mais simples (e mais frágil) do que a maioria das pessoas imagina

A política de recusa mora no prompt de sistema

A ideia central documentada pela xAI é essa: em vez de tentar enfiar "não faça X" só no treino, eles colocam a política de recusa dentro do prompt de sistema e deixam o modelo raciocinar sobre a política antes de responder

O efeito relatado é duplo: cai muito a taxa de resposta a pedidos nocivos, e a recusa fica mais precisa

Precisão aqui é a palavra chave. Não adianta recusar tudo que tem a palavra "vírus" no meio

Se você conhece guardrails de aplicação, é quase a mesma lógica: a regra fica explícita, legível, no contexto, e não escondida dentro dos pesos

O aviso anti-jailbreak como vacina

A outra peça documentada é engraçada de tão direta: avisar o modelo, no próprio prompt, que vão tentar dar jailbreak nele

A xAI descreve isso como inoculação

É tipo contar pro seu estagiário que vai chegar um cara muito simpático tentando convencê-lo a liberar acesso ao banco de produção. Ele já entra desconfiado

No model card do Grok 4.1, o modelo é descrito como recusando quase todos os pedidos nocivos em modo chat, mesmo sob ataque adversarial

Filtros que não são o modelo

Além do prompt, os model cards da família Grok 4 descrevem filtros baseados em modelo que rejeitam classes inteiras de pedido, incluindo armas biológicas e químicas e automutilação

E descrevem avaliação de robustez a jailbreaks e a injeção de prompt

Ou seja, tem uma camada fora do modelo principal. Isso importa muito pra próxima seção

Onde isso fica visível

O detalhe que eu acho mais massa: a xAI mantém um repositório público com esses prompts

É o xai-org/grok-prompts no GitHub, com arquivos como grok_4_safety_prompt.txt e grok4_system_turn_prompt_v8.j2

Dá pra ler o texto da política com os próprios olhos, em vez de confiar no parágrafo de marketing

E os model cards, como o Model Card: Grok 4.6 (datado de 12/08/2026, com revisão de 17/08/2026), trazem seções específicas de avaliação de recusa e de robustez a jailbreak, medidas sobre o checkpoint final implantado

Esse "checkpoint final implantado" não é detalhe burocrático: é a diferença entre medir o modelo que foi pra produção e medir um modelo de laboratório que ninguém usa

O que muda para quem coloca o Grok na frente do usuário final

Agora a parte que interessa se você tá construindo produto

Se boa parte da segurança mora no prompt de sistema, o que acontece quando você chama a API direto, sem prompt de sistema nenhum?

Acontece exatamente o que a SplxAI reportou

No teste de segurança da SplxAI com o Grok 4, o modelo falhou de forma ampla sem prompt de sistema, e chegou a pontuações quase perfeitas depois da aplicação de um prompt de sistema endurecido

Mesmo modelo. Resultado completamente diferente

Isso deveria estar tatuado na testa de todo mundo que integra LLM: o modelo que você chama cru não é o modelo do app oficial

E tem o outro lado. Em 14/07/2026 a Axios reportou que um jailbreak que atingiu o ChatGPT gerando imagens sexuais e violentas também funcionou no Grok

Ou seja, "mais forte em recusa" nunca significa blindagem

Significa que a barra subiu, não que a porta sumiu

Checklist mínimo de quem integra

1. Escreva o seu próprio prompt de sistema e trate ele como código. Versionado, revisado, com diff. O erro comum aqui é o dev de aplicação achar que "o modelo já vem seguro de fábrica" e mandar a chamada pelada pra API

2. Mantenha uma camada de filtro fora do modelo. Entrada e saída. A própria xAI descreve filtros baseados em modelo além do prompt, e eles fazem isso por um motivo. O erro comum é confiar só no julgamento do mesmo modelo que o atacante está tentando convencer: você deu o cadeado e a chave pra mesma pessoa

3. Logue as recusas, não só os erros. Recusa não é exceção, é sinal de produto. O erro comum é jogar a recusa no mesmo balde do 500 e nunca mais olhar, aí você não faz ideia se o modelo tá recusando ataque real ou o seu usuário legítimo

E cuidado com a troca de versão silenciosa. Se sua aplicação aponta pra um alias genérico, um upgrade de modelo muda o comportamento de recusa da noite pro dia sem ninguém aprovar nada

O preço de um modelo que recusa mais

Aqui mora o trade-off que quase nunca aparece no anúncio

Recusa mais precisa é o objetivo declarado. Ótimo

Mas todo aperto de política aumenta a chance de falso positivo: o pedido legítimo que leva não

E olha os domínios que sofrem primeiro:

• Segurança ofensiva e red team interno (o cara tá te pagando pra pedir exatamente aquilo)
• Saúde mental, onde o usuário precisa falar de tema pesado e leva um bloqueio na cara
• Ficção, roteiro, RPG, qualquer coisa com conflito e violência narrativa
• Área médica e jurídica, onde a resposta correta é técnica e desconfortável

Num chat de consumidor, uma recusa errada é um usuário irritado

No seu produto, uma recusa errada em cima do fluxo principal é churn

É um problema parecido com o que aparece quando se discute as salvaguardas do Claude Fable 5 em trabalho autônomo longo: quanto mais a política aperta, mais o modelo trava no caso limite legítimo, e quem paga a conta é o usuário certo, não o atacante

Por isso a recomendação prática é banal e quase ninguém faz: monte um conjunto de prompts do seu domínio, com casos nocivos de verdade E casos legítimos que parecem nocivos, e rode antes de trocar de versão

Sem isso, você tá descobrindo a política nova pelo ticket de suporte

O que dá e o que não dá pra afirmar hoje

Enquanto a linha do model card estiver vazia, qualquer comparação de segurança entre o 4.7 e o 4.6 é chute

E chute com número é a pior espécie de chute

Conteúdo relacionado

Pra começar do zero no assunto de modelos de fronteira e o que eles mudam no dia a dia dentro da ferramenta, este vídeo do canal mostra as novidades do Claude Opus 4.7 dentro do Claude Code:

Conclusão

O Grok 4.7 saiu, tá anunciado na página oficial da xAI e registrado pela Reuters

A promessa de salvaguardas mais fortes é do anúncio, e anúncio não é evidência

O que valida isso é o model card, do jeito que a xAI fez com o 4.6: seção de recusa, seção de robustez a jailbreak, medidas sobre o checkpoint que foi pra produção de verdade

Até lá, o que você tem de sólido é o mecanismo já documentado (política no prompt de sistema, inoculação contra jailbreak, filtros fora do modelo) e duas evidências públicas de que isso é forte mas não é escudo: o teste da SplxAI e o caso reportado pela Axios

Então o próximo passo prático é bem simples

Monta hoje o seu conjunto de prompts de teste, com os casos nocivos do seu domínio e, principalmente, com os casos-limite legítimos que o seu usuário real manda

Roda antes de promover qualquer versão nova pra produção

Modelo troca rápido, o estrago na confiança do usuário demora pra consertar…

Até o próximo post! 😀