Red Teaming de IA Explicado: O que uma Equipe Vermelha Testa e o que Ela Deixa Para Trás

A maioria dos engajamentos de red teaming de IA é julgada pelo artefato errado. Uma semana de trabalho produz uma apresentação de slides, a apresentação diz que é possível convencer o assistente a escrever um e-mail de phishing, e ninguém consegue dizer depois se o comportamento era reproduzível, qual era a gravidade ou qual controle teria impedido isso. A disciplina tem um resultado real, e não é uma apresentação: é um conjunto de achados que resistem a novas execuções, cada um atrelado a uma fronteira que foi cruzada e à evidência que a cruzou. Esse também é o formato do registro que o AI incident archive mantém — 400 entradas que cobrem de dezembro de 2024 a outubro de 2026, extraídas de 743 fontes distintas, e um veredito sobre cada uma a respeito de se alguém foi de fato prejudicado.

A confusão é compreensível, porque o "red teaming" é usado para duas tarefas que compartilham vocabulário e pouco mais. Este é um guia para as duas, para as evidências que cada uma deve produzir e para os quatro pontos em que o red teaming de IA se afasta de verdade da versão de rede que a maioria das equipes de segurança já sabe executar.

A questão do framework: a quem pertence o teste

Antes do escopo, há a questão de quem está conduzindo o exercício e contra o quê. A Microsoft publica uma das posições públicas mais completas sobre isso, e vale a pena lê-la como um mapa, não como uma página de produto. Seu hub AI Red Team separa o conceito de red teaming de IA da execução prática, e então organiza a prática em uma ordem que é, ela própria, um argumento: visão geral, depois um guia para montar uma equipe de red team de LLM, depois o material de referência — uma barra de bugs para triagem de ataques a sistemas de aprendizado de máquina, uma taxonomia de falhas de aprendizado de máquina, um modelo de responsabilidade compartilhada e orientação de modelagem de ameaças para desenvolvedores.

Leia a sequência e a metodologia surge. Uma taxonomia decide o que conta como falha. Um limiar de bugs decide quais dessas falhas vale a pena corrigir. Um modelo de responsabilidade compartilhada decide quem é responsável por ela depois que é encontrada. A modelagem de ameaças decide onde olhar a seguir. Sem esses quatro, uma equipe de red team está gerando anedotas com uma coluna de gravidade acoplada à força, e a coluna de gravidade é o que o testador sentiu naquela tarde.

O framework de automação aberto da Microsoft, PyRIT, está arquivado na mesma prateleira, e esse posicionamento é a parte útil. Um kit de orquestração não é uma metodologia; é aquilo para o qual você aponta um alvo depois que a taxonomia e o critério de bugs existem. Equipes que começam pelo framework tendem a terminar com um grande corpus de prompts e nenhuma forma de classificar os resultados.

Duas equipes de red team, duas perguntas diferentes

A distinção mais útil neste campo é aquela que quase ninguém registra por escrito: uma equipe de red team que testa um modelo e uma equipe de red team que testa um sistema estão respondendo a perguntas diferentes, com unidades sob teste diferentes, resultados diferentes e responsáveis diferentes. Misturá-las é o que faz um jailbreak ser reportado como uma descoberta de segurança, e um bug genuíno de escalonamento de privilégios ser registrado como uma reclamação de qualidade do modelo.

Avaliação de segurança no nível do modelo é um problema de medição. Você está perguntando se um modelo produzirá uma categoria de conteúdo, e a maneira honesta de responder é uma amostra grande o suficiente para dizer algo sobre uma taxa. A unidade em teste é o modelo por trás de uma API fina, o método é o prompting adversário — jailbreaks, ataques de persona, pressão em múltiplos turnos — e o que sai é uma transcrição mais um julgamento de dano. Quando os pesos mudam ou a camada de segurança do fornecedor se altera, todo o resultado fica desatualizado. É por isso que esse tipo de teste costuma ser executado pelo criador do modelo ou por um avaliador independente, e por que suas descobertas raramente se mapeiam para uma correção específica no seu aplicativo.

Emulação de adversários em nível de sistema é um problema de engenharia. A questão é se um atacante consegue fazer com que o sistema implantado aja — leia um ficheiro que não devia, chame uma ferramenta que não devia, gaste dinheiro que não devia. A unidade em teste é o agente com as suas ferramentas, a recuperação de dados e as credenciais associadas. Os métodos são os habituais, reorientados: injeção através de conteúdo recuperado em vez de através do turno do utilizador, abuso de ferramentas, cadeias de privilégios montadas a partir de permissões individualmente razoáveis, percursos de dados que extravasam uma fronteira entre inquilinos. O resultado é uma constatação com uma reprodução, uma fronteira cruzada e um responsável capaz de alterar a configuração amanhã.

Os dois produzem artefactos incompatíveis, e essa incompatibilidade é reveladora e não apenas irritante. Um resultado ao nível do modelo não pode ser "corrigido" pela sua equipa, exceto mudando de modelo. Um resultado ao nível do sistema não pode ser corrigido pelo fornecedor de forma alguma. Se um relatório não indicar qual dos dois é, não é possível atribuir nenhum dos seus itens.

O que a superfície de ataque se torna quando o modelo tem ferramentas

A superfície que a maioria das equipes ainda testa é o prompt. Também é a menos interessante, porque é aquela em que o fornecedor do modelo despendeu o maior esforço para fortalecer e sobre a qual um atacante tem menos alavancagem. As superfícies que realmente compensam são as que o aplicativo adicionou: as ferramentas que o agente pode chamar, o índice de recuperação que ele lê, a memória que ele carrega entre turnos e o próprio canal de saída.

Ferramentas são onde um modelo de linguagem se torna um ator, e a pergunta interessante nunca é "ele consegue chamar a ferramenta", mas "qual é o menor privilégio que essa ferramenta poderia ter tido". Uma ferramenta de consulta de tickets que aceita uma consulta em texto livre geralmente pode ser convencida a aceitar o identificador de outro cliente. Recuperação é um canal de conteúdo para o contexto do modelo, o que significa que qualquer pessoa que possa escrever no corpus — um drive compartilhado, uma macro de suporte, uma página web que o fetcher alcança — está escrevendo no prompt. Memória transforma um único turno em persistência: uma instrução plantada no turno dois ainda está lá no turno quarenta. Saída é onde o texto do modelo chega a algum lugar que o interpreta, e renderização, markdown, pré-visualizações de links e pipelines adjacentes ao shell todos interpretam texto.

Um engajamento que testa apenas o prompt reportará um resultado limpo e estará certo a respeito da coisa errada.

Por que uma transcrição não é um achado

Uma descoberta precisa de três propriedades que uma captura de tela de uma janela de chat não tem. A primeira é a reprodutibilidade: execute-a novamente a partir de um estado limpo e ela volta a acontecer. Os modelos são não determinísticos, portanto a reprodutibilidade é uma taxa, e não um booleano — "nove em cada dez tentativas" é uma descoberta, "aconteceu uma vez" é um boato. A segunda é uma fronteira cruzada: nomeie a coisa que não deveria ter acontecido nos próprios termos da aplicação, não nos do modelo. Não "o modelo foi grosseiro", mas "o agente leu um documento pertencente ao tenant B". A terceira é uma severidade que remonta ao impacto em vez de à intuição do testador, e é para isso que serve um bug bar.

Todo o resto — a transcrição, o prompt, o raciocínio do modelo — é evidência que sustenta esses três. Não é o achado em si, e é por isso que um corpus de dois mil prompts de jailbreak vale menos do que cinco achados de sistema reproduzíveis com controles nomeados anexados.

Quatro pontos em que o red teaming de IA diverge do red teaming de redes

Equipes que vêm da segurança de rede ou de aplicações trazem bons instintos e quatro suposições erradas.

• Não há perímetro a manter. Um engajamento de rede tem uma lista de alvos; um engajamento de agente tem uma janela de contexto montada no momento da solicitação a partir de fontes que você pode não ter inventariado. O escopo precisa ser expresso como fontes de dados e permissões de ferramentas, não nomes de host.

• O alvo é não determinístico. A mesma entrada pode ter sucesso na terça-feira e falhar na quarta-feira. Isso quebra o padrão de evidência de "uma reprodução limpa" e obriga você a relatar taxas.

• O exploit é a linguagem, e a linguagem não tem patch. Você pode corrigir uma verificação de autorização ausente. Você não pode aplicar um patch em "o modelo pode ser persuadido". A mitigação para uma fraqueza no nível da linguagem é um controle em outro lugar — um filtro, um limite de escopo, uma fronteira de permissão — e é por isso que os achados precisam nomear o controle, não apenas o comportamento.

• O fornecedor está dentro do ciclo. Seu alvo muda quando outra pessoa lança uma versão. Um resultado no nível do modelo só é válido para a build que você testou, e se você não registrou a versão e a data, você não tem um resultado.

Como definir o escopo de um primeiro engajamento

As intervenções que correm mal são quase sempre definidas como "testar a IA". Um âmbito que sobrevive ao contacto com um cronograma assemelha-se mais a isto: um agente, num ambiente de pré-produção, com dados e permissões semelhantes aos de produção; uma lista das cinco fronteiras que importam (isolamento de inquilinos, acesso a credenciais, gastos, saída de dados, âmbito das ferramentas); regras de atuação que especifiquem o que está fora dos limites; condições de paragem que indiquem quem pode interromper a execução; e um formato de evidência definido e acordado antes da primeira tentativa, para que o relatório seja montado a partir de artefactos em vez de reconstruído a partir da memória.

A autorização merece uma frase própria, porque é o item que as equipes pulam quando o alvo é o próprio produto e as ferramentas são de outra pessoa. Testar um modelo que você não opera, em uma infraestrutura que não é sua, com prompts concebidos para derrotar uma camada de segurança, é uma atividade diferente de testar a sua própria implantação — e o escopo escrito é o que separa as duas. O portão de verificação pelo qual a nossa própria camada de cibersegurança passa existe pelo mesmo motivo: trabalho de segurança autorizado no nível do modelo exige uma parte nomeada e responsável dos dois lados.

O que o registro do incidente acrescenta

Uma execução de red team informa o que seu alvo faz. Ela não consegue informar o que acontece em campo, e é em campo que o argumento a favor de um controle realmente se constrói. É essa lacuna que um registro de incidentes preenche — e a disciplina que ele impõe é a parte útil: um registro sem pelo menos uma fonte não existe, e um registro sem um veredito de dano não é um incidente.

Leia os dois artefatos em conjunto e o ciclo se fecha. A equipe de red team produz um achado reproduzível e nomeia o controle que o teria bloqueado. O registro informa se alguém em campo já atingiu esse limite, qual foi o dano e se o controle funcionou em qualquer outro lugar. Um achado sem precedente em campo é uma hipótese que vale a pena corrigir; um incidente em campo sem achado reproduzível é um bug que você ainda não consegue encerrar. As equipes que acertam isso param de tratar "fizemos red team ao modelo" como um entregável e passam a tratá-lo como uma entrada para um livro-razão próprio.

O que resta é a nota final honesta. O red teaming de IA não produz uma garantia de segurança, e qualquer trabalho vendido como tal está a vender a coisa errada. Produz um conjunto de fronteiras que agora sabe que são atravessadas, com evidências que pode voltar a executar, ordenadas pelo que acontece quando o são. Isso é suficiente para tomar decisões — e consideravelmente mais do que um deck.