O termo "red teaming" vem de exercícios militares da Guerra Fria onde uma equipe adversária designada (vermelha) atacava os planos da equipe defensora (azul). Em cibersegurança, evoluiu para a prática de contratar hackers éticos para encontrar vulnerabilidades antes que os maliciosos o façam. Red teaming de IA aplica a mesma filosofia: assuma que o modelo tem fraquezas, e então encontre-as sistematicamente. A diferença-chave do pen testing tradicional é que modelos de IA falham de formas difusas e probabilísticas — não existe um único exploit que "rooteia" um modelo de linguagem, mas sim um panorama de prompts e contextos onde o modelo se comporta inesperadamente ou prejudicialmente.
O red teaming moderno de IA tipicamente cobre várias categorias de falha. Testes de segurança investigam geração de conteúdo prejudicial — você consegue fazer o modelo produzir instruções para armas, conteúdo detalhado de automutilação ou material de exploração infantil? Testes de viés e justiça verificam se o modelo trata grupos demográficos diferentemente ou reforça estereótipos. Testes de factualidade procuram alucinações confiantes, especialmente em domínios de alto risco como medicina e direito. Testes de privacidade verificam se o modelo regurgita informações pessoais de seus dados de treinamento (pesquisadores extraíram dados de treinamento literais do GPT-3, incluindo números de telefone e endereços de e-mail). E avaliações de capacidade avaliam se o modelo poderia auxiliar em tarefas genuinamente perigosas como design de bioarmas ou ciberataques — essas são as avaliações que informam se um modelo é seguro para ser implantado.
A prática se profissionalizou rapidamente. Anthropic, OpenAI, Google DeepMind e Meta todos rodam red teams internos antes de grandes lançamentos, e cada vez mais trazem especialistas externos. A Anthropic fez parceria com especialistas em domínio de biossegurança e cibersegurança para as avaliações pré-lançamento do Claude. A OpenAI conduziu um exercício de red teaming externo em larga escala para o GPT-4 com mais de 50 especialistas. Startups como HackerOne e Scale AI construíram plataformas de red-teaming-as-a-service. Há também uma comunidade crescente de red teamers independentes de IA — o evento de Red Teaming de IA Generativa da DEF CON em 2023 teve milhares de participantes testando modelos de múltiplos provedores simultaneamente, e revelou vulnerabilidades reais que as empresas subsequentemente corrigiram.
Red teaming automatizado é um complemento cada vez mais importante aos testes humanos. A ideia é usar um modelo de IA para gerar prompts adversários que testam as defesas de outro modelo. Técnicas incluem ataques baseados em gradiente (Greedy Coordinate Gradient, ou GCG, que encontra sufixos adversários sem sentido mas eficazes), abordagens de LLM-como-atacante (onde um modelo "vermelho" refina iterativamente prompts de jailbreak com base nas respostas do alvo) e fuzzing (mutando sistematicamente ataques conhecidos bem-sucedidos para encontrar novas variantes). Anthropic e outros laboratórios usam esses métodos automatizados para testar em escala — um red teamer humano pode tentar centenas de ataques em uma sessão, enquanto um sistema automatizado pode tentar milhões. O porém é que métodos automatizados tendem a encontrar falhas "estranhas" (respostas a tokens sem sentido) enquanto humanos são melhores em encontrar vetores de ataque socialmente realistas (do tipo que usuários reais tentariam).
Uma pegadinha prática para quem faz red teaming: os resultados são altamente sensíveis a como você enquadra o exercício. Se você só testa as falhas que espera, só encontrará essas. O red teaming mais valioso frequentemente vem de pessoas com expertise de domínio não relacionada a IA — um assistente social pode identificar padrões de manipulação que um pesquisador de segurança não pensaria em testar, enquanto um químico saberia quais instruções de síntese são realmente perigosas versus quais são conhecimento de livro-texto. É por isso que red teams diversos consistentemente encontram mais vulnerabilidades e diferentes daquelas encontradas por equipes homogêneas. É também por que red teaming nunca está "terminado" — cada novo caso de uso, cada nova integração, cada atualização de modelo potencialmente introduz modos de falha que testes anteriores não cobriram.