Red teaming é testar adversarialmente o próprio sistema — atacá-lo deliberadamente para descobrir onde ele quebra antes que outra pessoa descubra. O nome vem da tradição militar e de segurança da informação, e em IA significa provocar o modelo a produzir o que não deveria: conteúdo nocivo, vazamento de instruções internas, comportamento fora de política. Deixou de ser boa prática opcional e virou exigência regulatória: o AI Act europeu determina, no artigo 55, que fornecedores de modelos de risco sistêmico realizem avaliação conforme protocolos padronizados, “incluindo a condução e documentação de teste adversarial do modelo” para identificar e mitigar riscos sistêmicos. Uma precisão de vocabulário: o texto legal diz “teste adversarial”; “red teaming” aparece no anexo como exemplo de forma de cumpri-lo. A distinção importa em documento de conformidade — e vale saber que o teste do fabricante não cobre o sistema que você monta em cima do modelo.
Como isso é feito na prática
Há metodologia publicada com números. Um estudo liberou publicamente um conjunto de 38.961 ataques de red team, aplicados a quatro tipos de modelo em três tamanhos diferentes.
O achado relatado: modelos treinados com aprendizado por reforço a partir de feedback humano ficam progressivamente mais difíceis de atacar conforme aumentam de escala, enquanto os demais tipos apresentaram comportamento estável com o crescimento.
Uma ressalva necessária: esse estudo é de um fornecedor de modelos, avaliando os próprios modelos — e o método que sai melhor é o que a empresa usa. O dado é público e o conjunto de ataques foi aberto, o que é meritório; mas o resultado deve ser lido com essa lente.
⚠️ Red teaming do fabricante não cobre o seu sistema
O erro conceitual mais caro é supor que, porque o fornecedor testou o modelo, o seu produto está testado. São coisas diferentes.
O fabricante testa o modelo isolado. Você opera um sistema: modelo mais prompt de sistema, mais ferramentas conectadas, mais dados do seu CRM, mais integrações que executam ações. As vulnerabilidades que importam para você surgem na composição — e o fabricante não tem como testá-las.
Os números dos verbetes vizinhos mostram por quê: ataques de jailbreak em múltiplos turnos seguem acima de 50% de sucesso mesmo nos modelos recentes, e defesas contra injeção de prompt reduzem o ataque a 8%, nunca a zero.
O que isso muda na prática
Red teaming de um assistente de marketing não exige equipe de segurança. Exige uma tarde e método:
- Tente extrair as instruções. Peça ao bot que repita o que foi instruído a fazer, de várias formas. Se ele entregar a política de desconto, o problema é de arquitetura, não de prompt.
- Tente obter promessa fora de política. Insista por desconto, prazo ou condição que a empresa não oferece. Veja se ele cede depois de três tentativas.
- Plante instrução em conteúdo externo. Se o agente lê e-mails ou páginas, coloque uma instrução no texto e veja se ele obedece.
- Registre e repita. Guarde os ataques que funcionaram e rode-os de novo a cada mudança de prompt ou de modelo. Vira um conjunto de regressão de segurança.
O objetivo não é blindar — nenhum dos verbetes deste glossário sustenta que isso seja possível. É saber onde quebra antes de descobrir por uma captura de tela circulando.
Fontes
- Regulamento (UE) 2024/1689 — AI Act, artigo 55
- Red Teaming Language Models to Reduce Harms — 38.961 ataques; pesquisa de fornecedor sobre os próprios modelos
Leitura das fontes em 17/08/2026.