Jailbreak: quando o alinhamento encontra seus limites

Esse é mais um post da série em que procuro destrinchar as entranhas dos LLMs↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI →. Um dos assuntos que mais desperta curiosidade é o chamado jailbreak. De tempos em tempos surgem demonstrações mostrando que alguém conseguiu induzir um modelo a produzir uma resposta que suas políticas deveriam impedir.

Isso leva muita gente a imaginar que existe uma “falha de segurança” simples ou um prompt mágico capaz de quebrar qualquer modelo. Mas, a realidade não é bem assim.

Para entender por que jailbreaks podem funcionar, precisamos abandonar a ideia de que existe um único mecanismo responsável pelo comportamento de um LLM. Durante sua construção, o modelo passa por diferentes etapas, com objetivos distintos.

Tudo começa pelo pré-treinamento. É principalmente nessa etapa que o modelo desenvolve suas capacidades gerais de linguagem a partir das regularidades presentes nos dados: idiomas, programação, literatura, ciência, história, estilos de escrita e inúmeras relações entre tokens e representações internas. É também, de longe, a etapa mais intensiva em dados e computação.

Depois podem ocorrer etapas de pós-treinamento, como Supervised Fine-Tuning (SFT) e técnicas de otimização por preferências. RLHF é uma delas, mas os sistemas atuais podem combinar diferentes abordagens, como DPO, RLAIF, rejection sampling e outras.

Aqui existe uma confusão frequente: imaginar que o RLHF “ensina” ao modelo todo o conhecimento necessário ou que seja responsável sozinho pela segurança. Não é assim.

O pré-treinamento responde pela maior parte das capacidades gerais do modelo. O pós-treinamento procura modificar o comportamento observado pelo usuário, aprimorando aspectos como seguimento de instruções, utilidade, estilo, preferências e determinados comportamentos de segurança.

Mas existe ainda outra dimensão: a inferência. Quando enviamos um prompt, não estamos alterando os parâmetros do modelo. Estamos fornecendo contexto que influencia aquela geração específica.

A resposta resulta da interação entre parâmetros aprendidos, contexto, instruções aplicáveis, histórico da conversa e, nos sistemas modernos, ferramentas, memória e componentes externos. É nesse espaço que alguns jailbreaks procuram explorar fragilidades.

Uma técnica pode explorar ambiguidades ou conflitos entre instruções. Outra pode criar um contexto que induza o modelo a interpretar a solicitação de maneira diferente. Outra pode explorar limitações de generalização dos mecanismos de segurança.

E algumas vulnerabilidades sequer estão no modelo: podem estar na aplicação, nas ferramentas, nas permissões ou na forma como diferentes componentes foram integrados. Por isso, jailbreak, prompt injection e vulnerabilidade de aplicação não são exatamente a mesma coisa, embora possam interagir.

Isso também explica por que um jailbreak pode funcionar em uma versão e deixar de funcionar em outra. Os desenvolvedores podem modificar dados de pós-treinamento, políticas, avaliações, filtros, classificadores e mecanismos de proteção. Alterações em qualquer dessas camadas podem mudar a robustez do sistema.

Existe ainda uma limitação fundamental: alinhamento não significa segurança perfeita. Um modelo pode apresentar excelente desempenho em avaliações de segurança e ainda falhar diante de uma formulação não contemplada durante o desenvolvimento. O espaço de possíveis entradas é enorme, enquanto os conjuntos de treinamento e avaliação são necessariamente finitos.

Por isso, sistemas de produção adicionam outras camadas: classificação de entradas e saídas, filtros, políticas, controle de ferramentas, isolamento de execução, monitoramento, limites de permissão e mecanismos de detecção.

Isso é especialmente importante em sistemas agentivos. Um modelo que apenas gera texto pode produzir uma resposta inadequada. Um agente conectado a ferramentas pode, dependendo das permissões concedidas, transformar uma interpretação inadequada em uma ação.

O risco deixa então de ser apenas: “O que o modelo pode dizer?” e passa a incluir: “O que o modelo está autorizado a fazer?”

É aqui que o jailbreak revela algo importante sobre os LLMs. Eles não são sistemas tradicionais baseados exclusivamente em regras explícitas do tipo “se X acontecer, faça Y”. Seu comportamento resulta da interação entre parâmetros aprendidos, contexto, instruções e componentes adicionais do sistema.

Isso torna o alinhamento um problema de engenharia particularmente difícil. Não basta ensinar o modelo a recusar determinadas solicitações em exemplos conhecidos. É necessário que esse comportamento generalize para uma enorme variedade de formulações, contextos e combinações de instruções.

Por isso, eu evitaria pensar em jailbreak simplesmente como um “prompt que desliga a segurança”. Às vezes ele explora uma fragilidade do próprio modelo. Em outras, uma falha de generalização do pós-treinamento. Em outras ainda, uma vulnerabilidade na arquitetura que envolve o modelo.

Na prática, não existe uma linha mágica de código chamada “segurança” dentro de um LLM. A segurança é uma propriedade do sistema como um todo: modelo, pós-treinamento, políticas, contexto, ferramentas, permissões, filtros, avaliações e arquitetura da aplicação.

E quanto maior a autonomia concedida ao modelo, mais perigoso se torna acreditar que alinhar o modelo é o mesmo que proteger o sistema.

Um modelo pode ser muito bem alinhado e ainda estar inserido em uma arquitetura vulnerável.

É por isso que jailbreak não é apenas uma curiosidade sobre prompts. É um teste de estresse da nossa própria engenharia de segurança para sistemas probabilísticos.