Red team de IA e avaliação de modelos: testar antes do incidente

Quase toda empresa que colocou um assistente em produção fez algum teste antes de abrir para o usuário. Quase nenhuma consegue responder, três meses depois, se o sistema continua resistindo ao que resistia no dia do lançamento. O motivo é que o teste foi um evento, e não um ativo: alguém tentou alguns prompts maliciosos, o resultado foi um print no chat da equipe, e o modelo, o prompt de sistema e as ferramentas mudaram desde então.

Este artigo trata do que transforma esse esforço em controle: a diferença entre avaliar e atacar, o conjunto adversarial que fica versionado no repositório, o juiz que pontua sem pessoa no meio, e o portão que impede a regressão de chegar à produção. O pano de fundo, com as classes de risco, está em segurança de LLM e GenAI.

Avaliação e red team respondem a perguntas diferentes

Avaliação, ou eval, mede se o sistema faz bem o que deveria fazer: responde ao que foi perguntado, cita a fonte certa, respeita o formato, erra pouco no conjunto de referência. É teste de qualidade, com entrada representativa do uso esperado.

Red team mede o oposto: procura a entrada que quebra o comportamento pretendido. Não interessa a média, interessa o caso. Um sistema com 98% de acerto na avaliação pode ser inaceitável se os 2% incluírem revelar o prompt de sistema ou executar uma ferramenta em nome de quem não deveria.

As duas práticas precisam coexistir, e por motivos diferentes. A avaliação impede que a correção de segurança destrua a utilidade; o red team impede que a busca por utilidade abra o sistema. Quem só faz avaliação entrega um produto bom que falha sob ataque; quem só faz red team endurece o sistema até ele parar de servir.

O que testar, pelas classes que aparecem em produção

Teste adversarial sem taxonomia vira criatividade dispersa. A lista que organiza o esforço é a do OWASP, cuja edição vigente está comentada em o que mudou no Top 10 de 2026. Traduzida para casos de teste, ela gera cinco famílias:

• Injeção direta: o usuário instrui o modelo a ignorar a instrução de sistema, por pedido explícito, por troca de papel ou por formatação que confunde a fronteira entre instrução e conteúdo.
• Injeção indireta: a instrução maliciosa chega escondida em material que o sistema lê sozinho, como página recuperada pelo RAG, documento anexado, campo de ticket ou descrição de ferramenta.
• Exposição de contexto: o teste tenta extrair o que está na janela sem estar na resposta pretendida, do prompt de sistema ao trecho recuperado de outro usuário.
• Excesso de ação: o teste verifica se dá para fazer o agente chamar ferramenta fora do escopo, encadear chamadas até um efeito não previsto ou agir com credencial de terceiro. É a área tratada em MCP e agentic AI security.
• Saída perigosa: o teste força o modelo a produzir conteúdo que o sistema a jusante executa, como marcação que vira script, consulta que vira comando ou caminho que vira leitura de arquivo.

Cada família vira um conjunto de casos com resultado esperado explícito. Sem o esperado escrito, não existe falha: existe conversa sobre se aquilo foi grave.

O conjunto adversarial versionado, o ativo que sobra

O que sobra de um exercício de red team não é o relatório, é o conjunto de casos. Ele fica no repositório, ao lado do código da aplicação, com uma linha por caso: a entrada, a condição que caracteriza falha, a família, a severidade e a data em que entrou.

Três regras mantêm esse conjunto útil ao longo do tempo. Todo incidente real vira caso, inclusive o quase incidente que alguém notou e corrigiu na conversa. Todo caso que passa a falhar depois de uma mudança fica marcado como regressão, que é a métrica que o portão observa. E o conjunto nunca é publicado inteiro, porque um conjunto adversarial divulgado deixa de medir o sistema e passa a medir quem decorou os casos.

O tamanho importa menos do que a cobertura. Um conjunto de 200 casos bem distribuídos entre as cinco famílias informa mais que 5.000 variações do mesmo pedido de jailbreak.

O juiz automático e onde ele erra

Avaliar centenas de respostas à mão não escala, e a saída usada no mercado é o juiz automático: um modelo recebe a resposta, o caso e o critério, e decide se houve falha. Funciona bem para o que é objetivo, como presença de um segredo conhecido no texto, chamada de ferramenta que não deveria ter ocorrido ou formato violado.

Ele erra onde o julgamento é sutil: recusa parcial, resposta que entrega metade do que foi pedido, conteúdo tecnicamente correto mas inadequado ao contexto do negócio. Por isso o juiz precisa ser calibrado: um lote de casos recebe rótulo humano, mede-se a concordância entre o juiz e a pessoa, e só então ele passa a rodar sozinho. Concordância baixa não invalida o método, mas define onde a revisão humana continua obrigatória, com o critério descrito em human-in-the-loop.

Onde isso entra na esteira de entrega

Três cadências resolvem a maior parte do problema, e elas não competem:

• A cada mudança: o subconjunto rápido do catálogo roda no pipeline, junto dos testes da aplicação. Mudou prompt de sistema, modelo, versão de biblioteca, política de ferramenta ou base do RAG, roda.
• Periodicamente, em profundidade: um exercício trimestral com gente criativa, que busca o caminho novo em vez de repetir o catálogo. O que ele achar vira caso e passa a rodar a cada mudança.
• Em produção: amostragem contínua do tráfego real contra os mesmos critérios, porque o usuário produz entrada que ninguém imaginou.

O portão de merge usa a métrica mais simples que existe: taxa de regressão no conjunto adversarial. Caso que passava e passou a falhar bloqueia a entrega, do mesmo jeito que um teste unitário quebrado bloqueia. É essa decisão, e não o relatório trimestral, que muda o comportamento da equipe.

Ferramentas, e para que serve cada uma

O ferramental amadureceu e se dividiu por função:

• Catálogo de sondas conhecidas, como o garak, que roda uma bateria fixa de ataques já documentados. É rápido e repetível, perfil certo para regressão diária.
• Orquestração de ataque, como o PyRIT, que gera e encadeia tentativas em vez de só repetir um catálogo, inclusive em outras modalidades além de texto. Perfil de exercício profundo.
• Avaliação em pipeline, como o promptfoo, voltado a rodar conjunto versionado e comparar versões dentro da integração contínua.
• Avaliação de agente, como o Giskard, e arcabouços de eval como o Inspect AI, para quem precisa medir comportamento de sistema que usa ferramenta e mantém estado.

Nenhuma delas decide o que é falha no seu contexto. Todas executam e pontuam contra o critério que você escreveu, e a qualidade do resultado é a qualidade desse critério.

A evidência que sobra para auditoria e regulador

Teste adversarial deixou de ser boa prática opcional para quem opera em ambiente regulado. O perfil de IA generativa do NIST, o AI 600-1, que acompanha o AI Risk Management Framework, lista o red team entre as ações sugeridas para avaliar resiliência a injeção e a entrada adversarial. No regulamento europeu de IA, o provedor de modelo de propósito geral com risco sistêmico precisa avaliar o modelo, incluindo teste adversarial conduzido e documentado.

O que isso cobra na prática é previsível: qual conjunto rodou, em que versão do sistema, com que resultado, o que foi corrigido e em quanto tempo. Um conjunto versionado com histórico de execução responde a isso sozinho; um print de conversa não responde. A ponte dessa evidência para a instância que decide está em governança de IA no conselho.

O que a automação não cobre

Ferramenta encontra o que já foi descrito. Ela não inventa o ataque de cinco passos que combina uma página envenenada, uma ferramenta mal escopada e um comportamento específico do seu negócio. Esse caminho continua sendo trabalho humano, e é a mesma lógica da segurança ofensiva tradicional, discutida em red team, blue team e purple team e na prática de purple teaming.

O segundo limite é de julgamento. Decidir se uma resposta causa dano exige contexto de negócio, de contrato e, às vezes, jurídico. O juiz automático classifica; a decisão sobre o que é aceitável pertence a quem responde pelo processo.

E há o limite de escopo: testar o modelo não testa a aplicação. Controle de acesso, isolamento de dado por usuário, limite de custo e registro de contexto são propriedades do sistema em volta, e falham mesmo com um modelo que resiste a tudo que o catálogo tentou.

Perguntas Frequentes

Conclusão

Testar modelo de IA não é um evento antes do lançamento, é uma rotina com ativo próprio. O ativo é o conjunto adversarial versionado, com resultado esperado por caso e histórico de execução; o resto, do juiz automático ao painel, existe para manter esse conjunto rodando barato e com frequência.

A pergunta que separa quem tem o controle de quem tem a intenção é simples, e vale fazer à equipe hoje: se o modelo for trocado de versão amanhã, quanto tempo leva para saber se alguma proteção regrediu? Se a resposta depender de alguém lembrar de testar, ainda não é controle.

E vale guardar o limite junto com a prática. Resistir ao catálogo não torna o sistema seguro, porque controle de acesso, isolamento de dado, limite de custo e registro de contexto são propriedades da aplicação em volta do modelo, não do modelo.