Um artigo intitulado The Fragility of Jailbreak Robustness Across Operational States, aceito para EMNLP 2026 Findings, defende uma tese estreita e incômoda: a robustez de um modelo é uma propriedade da configuração em que foi medida, e não do modelo. Mantendo o ataque fixo e alterando apenas um system prompt comum — sem relação com segurança —, a taxa de sucesso do ataque passou, em um caso, de 2% para 58%, uma variação de 56 pontos. O resultado abrange sete modelos alinhados e três ataques representativos.

O mecanismo proposto

Os autores relacionam o efeito à posição de representações ocultas ao longo do que chamam de eixo de recusa. Uma projeção nesse eixo prevê se um determinado jailbreak será bem-sucedido — o que enquadra um system prompt operacional como algo que desloca discretamente o modelo ao longo de uma direção relevante para a segurança, sem qualquer intenção adversária de quem o escreveu.

O que o artigo não diz

Ele não afirma que os modelos ficaram menos seguros, e manchetes do tipo "os modelos são fáceis de jailbreaking" invertem o argumento. A descoberta diz respeito à medição: relatar a robustez como um único valor de ASR em uma configuração padrão gera uma falsa confiança, porque o número não se sustenta quando confrontado com um prompt operacional. Trata-se de uma crítica a uma metodologia usada em fichas de segurança de fornecedores e benchmarks públicos, e não de um novo ataque.

Dois detalhes que vale não confundir

A aceitação é para Findings, e não para a trilha principal do EMNLP — uma distinção que resumos de imprensa costumam omitir. E a data no arXiv se refere ao envio de uma versão específica: esta é a v1, submetida em 31 de agosto, sem revisão posterior, portanto não se trata de um trabalho mais antigo reaparecendo sob uma data de listagem nova.

Por que profissionais devem se importar

Em produção, o system prompt é escrito pelo integrador, e não pelo laboratório. Se a robustez medida com o prompt padrão do laboratório não se transfere, então todo número de segurança mostrado a um comprador descreve uma configuração que não existirá no produto dele. A implicação prática é que o red-teaming precisa ser executado contra o prompt real de produção e repetido sempre que esse prompt mudar — algo que hoje é tratado como uma simples revisão de texto.