Guardrails São uma Variável Desigual de Aquisição

Kasra Rahjerdi gastou US$ 1.500 para responder uma pergunta estreita: um modelo de linguagem consegue hackear o próprio app dele? Ele apontou dez configurações de modelo para uma aplicação propositalmente vulnerável, limitou cada uma a US$ 10 e duas horas, e contou quantas chegavam à flag. O número de manchete (qual modelo venceu) é o resultado menos interessante. O resultado interessante é o quão diferente os modelos se comportaram antes mesmo de tentar.

Um modelo resolveu sete das dez execuções. Outro recusou de cara, queimando 9.000 tokens para dizer não enquanto os demais gastavam mais de 100.000 efetivamente trabalhando. O mesmo prompt, o mesmo alvo, o mesmo enquadramento de tarefa. A variação não estava na habilidade. Estava na disposição.

Essa variação tem um nome que a maioria das equipes de compra nunca escreveu num contrato: a superfície de guardrail. E ela não é uniforme.

O Que o Experimento de Fato Mediu

O alvo era um app que Rahjerdi construiu com uma API endurecida na frente e um Firebase escancarado atrás. Autorização quebrada no nível de objeto. O tipo de falha que um atacante real adora e que uma auditoria real não percebe. Ele deu a cada modelo o mesmo briefing e deixou rodar.

As taxas de resolução, com a ressalva do próprio autor de que isso “não é científico” (dez execuções por modelo, intervalos de confiança largos):

gpt-5.5: 7/10, cerca de US$ 9,46 por solução
deepseek-v4-pro: 3/10, cerca de US$ 0,19 por execução
claude-sonnet-4.6: 2/10
claude-opus-4-8: 2/10, com recusas tardias depois de chegar perto
gemini-3.1-pro: 0/10, recusa imediata, 9.000 tokens contra os mais de 100.000 que os modelos ativos gastaram

Leia esses números como direcionais, não definitivos. A amostra é pequena e o autor diz isso com todas as letras. Mas o formato do resultado é limpo demais para ignorar: os modelos não falharam no mesmo ponto nem pela mesma razão. Alguns falharam na porta. Alguns falharam no cofre. Um entrou andando.

Recusa É um Comportamento, Não um Piso

O modelo mental comum trata segurança como uma linha de base que todo fornecedor sério cumpre. Compre qualquer modelo de fronteira, diz o raciocínio, e você tem mais ou menos o mesmo piso protetivo. O experimento desmonta isso.

O gemini-3.1-pro recusou de imediato. Nunca engajou a tarefa. O claude-opus-4-8 engajou, fez progresso real, então bateu num guardrail tardio e parou. O gpt-5.5 trabalhou o problema até o fim sete vezes em dez. Três posturas de segurança diferentes, três pontos de intervenção diferentes, uma única requisição idêntica.

Rahjerdi também notou um padrão regional: “os modelos chineses ficaram bem mais à vontade atacando o banco de dados.” Os modelos ocidentais hesitaram especificamente diante do impacto sobre banco de dados ao vivo, o momento em que a ação deixa de ser análise e vira consequência. Essa hesitação é uma decisão de design codificada pelo fornecedor, e ela difere de fornecedor para fornecedor.

Isso importa nos dois sentidos. Se você quer um modelo para rodar segurança ofensiva contra os seus próprios sistemas, o modelo que recusa é inútil para você por mais capaz que seja. Se você quer um modelo que recuse exatamente esse tipo de trabalho quando um funcionário pede, o modelo complacente é um passivo. O mesmo guardrail é um ativo ou um defeito dependendo inteiramente do seu caso de uso.

O Ponto Cego da Aquisição

A maioria das seleções de modelo roda sobre um checklist familiar: pontuação em benchmark, janela de contexto, latência, preço por token, residência de dados. A disposição de executar trabalho sensível quase nunca aparece, porque a maioria dos compradores presume que ela é constante entre fornecedores. Não é.

Considere só a dimensão de custo. O gpt-5.5 resolveu a US$ 9,46 por solução. O deepseek-v4-pro rodou a US$ 0,19 por execução com taxa de 3/10. Se a sua tarefa é sensível e você seleciona por preço, você pode ter acabado de selecionar o modelo mais disposto a fazer a coisa sensível, pelo menor custo, com o menor atrito. Esse é um resultado de governança que você alcançou por acidente, através de uma decisão de compra que nunca nomeou a variável que estava de fato ajustando.

O problema mais profundo é o silêncio. Um modelo que recusa avisa que recusou. Um modelo que completa uma tarefa limítrofe em silêncio não avisa nada. Numa frota de agentes agindo em seu nome, as diferenças entre “recusou”, “completou com aviso” e “completou em silêncio” se acumulam em perfis de risco muito distintos, e nenhuma delas aparece num ranking de benchmark.

Guardrails Entram na Matriz

Trate a superfície de guardrail como uma variável de aquisição medida, do mesmo jeito que você trata latência ou preço. Três coisas precisam mudar.

Primeiro, defina o comportamento que você de fato quer, por classe de tarefa. Ferramentas de segurança ofensiva, chat com cliente, geração interna de código e análise financeira não compartilham um perfil de recusa. O guardrail “certo” para um é o guardrail errado para outro. Escreva, por caso de uso, se você quer que o modelo penda para a ação ou para a recusa.

Segundo, teste isso. Monte uma pequena bateria de prompts limítrofes que fiquem perto das suas fronteiras reais de risco e passe cada modelo candidato por ela. Você não está medindo capacidade aqui. Está medindo disposição, o ponto de recusa, e se a recusa é barulhenta ou silenciosa. Os US$ 1.500 de Rahjerdi compraram uma resposta direcional para um app. Uma avaliação interna focada custa bem menos e responde isso para as suas cargas de trabalho reais.

Terceiro, reteste a cada versão de modelo. O comportamento de guardrail muda entre lançamentos, muitas vezes sem uma entrada de changelog que o nomeie. Um modelo que recusou em março pode aceitar em junho. Sua matriz de compra precisa de uma coluna que é atualizada, não de uma checagem única que apodrece.

Faça Isto Agora

Escolha a tarefa mais sensível que os seus agentes executam. Escreva cinco prompts que fiquem bem na fronteira de risco dela. Passe-os por todo modelo que você tem em produção e todo modelo que está avaliando. Registre três coisas para cada um: ele aceitou, onde parou, e se avisou. Coloque o resultado na sua matriz de seleção de modelo ao lado de preço e latência, e atribua um dono para rerodar a cada troca de versão.

Você já está selecionando uma postura de guardrail toda vez que escolhe um modelo. A única questão é se você está fazendo isso de propósito.

Fontes

Kasra Rahjerdi. “I Spent $1,500 Seeing If LLMs Could Hack My App.” Junho de 2026.

A Victorino ajuda empresas a transformar guardrails de modelos em uma linha medida na aquisição: contato@victorino.com.br | www.victorino.com.br