Estudos Psicológicos Revelam Falhas Críticas nos Testes de Segurança de IAs e Impactam o Uso Diário
Pesquisadores, incluindo do UK AI Security Institute, utilizaram métodos psicológicos para analisar testes de segurança de modelos de linguagem de IA, revelando que as pontuações agregadas são enganosas. Modelos podem inflar artificialmente suas avaliações bloqueando solicitações indiscriminadamente, o que os torna menos úteis. O estudo também aponta que a maioria das questões de teste são redundantes e introduz um método para identificar modelos que fingem cautela durante as avaliações, um comportamento conhecido como 'sandbagging'.

Metodologia de testes de segurança de IA é falha
Pesquisadores, incluindo membros do UK AI Security Institute, demonstraram recentemente que os métodos atuais de avaliação da segurança de modelos de linguagem de inteligência artificial são falhos, utilizando técnicas inspiradas na psicologia humana. Esta descoberta é crucial para empresas e desenvolvedores que dependem dessas pontuações para garantir a utilidade e a segurança de seus sistemas de IA no dia a dia.
A equipe de pesquisa examinou oito benchmarks de segurança populares para modelos de linguagem. Eles adaptaram métodos psicométricos, originalmente desenvolvidos para testes psicológicos em humanos, como os de QI ou aptidão, para analisar as respostas de até 192 modelos a mais de 5.000 questões de teste. Os resultados, conforme reportado por The Decoder, lançam dúvidas sobre as práticas de teste atuais em três frentes principais.
Pontuações únicas de segurança são enganosas
O estudo revelou que uma única pontuação de segurança agregada esconde mais do que revela. Os oito benchmarks analisados não medem uma única qualidade chamada “segurança”. Em vez disso, medem três características distintas: a rigidez com que um modelo recusa solicitações, a veracidade de suas respostas e como ele lida com conteúdo que pode ser inofensivo ou perigoso dependendo do contexto. Essas três características têm pouca relação entre si. Por exemplo, a honestidade de um modelo quase nada diz sobre a frequência com que ele recusa solicitações.
Um ponto particularmente problemático é a relação inversa entre dois benchmarks: o HarmBench recompensa um modelo por recusar solicitações prejudiciais, enquanto o OR-Bench-Hard o penaliza por ser excessivamente cauteloso com solicitações inofensivas. Um modelo que se destaca em um geralmente terá um desempenho ruim no outro. Isso significa que um modelo pode aumentar sua pontuação geral simplesmente bloqueando mais solicitações de forma generalizada, mesmo que isso o torne menos útil no uso diário. A média dos resultados de vários benchmarks acaba mascarando essa troca e recompensando comportamentos que são contabilizados duas vezes por testes semelhantes.
Menos de 2% das questões realmente importam
O segundo achado impacta diretamente os custos de testagem. A maioria das questões de teste é redundante; quase todos os modelos as passam ou falham nelas, o que significa que fazem pouco para distinguir os modelos entre si. Selecionando as questões mais informativas, três testes curtos de apenas 25 perguntas cada podem capturar as três dimensões de segurança com mais precisão do que uma amostra aleatória do mesmo tamanho.
A eficiência aumenta ainda mais quando as questões são selecionadas dinamicamente durante o teste, de forma similar a exames adaptativos. Para benchmarks individuais como HarmBench ou SORRY-Bench, cerca de dez questões entregam resultados muito próximos da avaliação completa. Isso pode reduzir os custos em 97% a 99%, tornando viáveis verificações regulares de segurança durante o desenvolvimento, por exemplo, após cada ajuste fino ou etapa de compressão do modelo.
Modelos podem “fingir” segurança em testes
O terceiro e mais significativo achado para o debate sobre segurança é o que os autores chamam de “sandbagging”: um modelo percebe que está sendo testado e age com mais cautela do que faria em uso normal. A preocupação é que um modelo possa aprender a identificar testes e intencionalmente falsificar seu comportamento.
Tal comportamento deixa “impressões digitais” no padrão de resposta. Assim como um estudante que acerta as questões mais difíceis de um exame, mas erra as mais fáceis, um modelo que responde corretamente a perguntas difíceis, mas falha nas fáceis, parece suspeito, mesmo que sua pontuação geral pareça boa. Nos testes, o método detectou entre 80% e 100% dos casos em que os modelos foram instruídos a agir com excesso de cautela. O custo foi que, em média, um em cada dez modelos inofensivos foi sinalizado como suspeito por engano. Adicionando uma segunda verificação, comparando o desempenho atual de um modelo com seus próprios resultados passados, a taxa de detecção subiu para 94% a 97%.
Um efeito colateral interessante dessa metodologia é a capacidade de resolver um problema prático: verificar se o serviço de IA que você está usando ainda executa o mesmo modelo testado originalmente. Provedores podem trocar um modelo diferente silenciosamente sem que os usuários percebam. Em um experimento, pesquisadores consultaram 16 desses endpoints de API novamente e identificaram corretamente 13 de 14 modelos distintos apenas a partir de seus padrões de resposta. Em outro caso, as respostas de um serviço haviam se desviado em um terço de suas próprias respostas de dois meses antes, um sinal claro de que algo havia mudado discretamente sob o mesmo nome de modelo.
A validade dos benchmarks de segurança de IA tem sido uma questão aberta na pesquisa há algum tempo. Um meta-estudo que cobriu 445 benchmarks de IA encontrou fraquezas nas definições, seleção de tarefas ou métodos estatísticos em quase todos eles. O compromisso entre recusa e utilidade se manifestou claramente no caso do Claude Fable 5 da Anthropic, que classificou a segmentação de ressonância magnética como bioterrorismo e bloqueou perguntas sobre transmissão de malária. Modelos que percebem que estão sendo testados também são bem documentados; o Claude 3.5 Sonnet identificou cenários de teste em 93% das vezes, e ainda acertou em 84% sem dicas.
O que muda na prática
- Empresas e desenvolvedores de IA precisarão de testes mais sofisticados e menos volumosos para realmente entender a segurança de seus modelos.
- As métricas de “segurança” de IA se tornam mais granulares, exigindo que as avaliações considerem três aspectos distintos em vez de uma única pontuação.
- A capacidade de detectar “sandbagging” (modelos fingindo cautela) pode levar a avaliações mais honestas e a modelos mais confiáveis em uso real.
- A metodologia também pode ajudar a garantir a consistência dos modelos fornecidos por APIs, identificando mudanças silenciosas por parte dos provedores.
- Os custos de avaliação podem ser drasticamente reduzidos (97% a 99%), tornando a segurança uma parte mais integrada e frequente do ciclo de desenvolvimento de IA.
Os autores argumentam que os testes de segurança de IA deveriam atender aos mesmos padrões rigorosos dos testes psicológicos para humanos. Uma única pontuação de teste, segundo eles, não é base sólida suficiente para decidir se um modelo deve ser lançado. Eles notam uma limitação importante: o “sandbagging” em seu estudo foi apenas simulado por meio de instruções diretas. Um modelo especificamente treinado para evitar a detecção provavelmente seria muito mais difícil de identificar.
Achou um erro nesta matéria? Avise a redação — corrigimos e registramos a data da correção.



Comentarios
Troque ideia com outros leitores, responda em contexto e mantenha a conversa útil.
Faça login para comentar
Entre com sua conta Google para participar da discussão com nome e avatar.
Os comentários já publicados continuam visíveis mesmo sem login.