Red teaming de IA: como simular ataques antes do invasor

Red teaming de IA é a simulação controlada de ataques contra um sistema de inteligência artificial em produção — prompt injection, jailbreak, extração de dados de treinamento — feita por uma equipe que assume o papel de invasor real, antes que um invasor de verdade encontre a mesma brecha. Diferente de um teste de qualidade, que confirma se o modelo funciona como projetado, o red team pergunta o oposto: o que acontece quando alguém tenta deliberadamente fazer o sistema falhar? Este guia é para quem decide como e quando testar sistemas de IA já em produção — CISO, diretoria de tecnologia, jurídico e compliance.

O que é red teaming de IA, e por que "parece seguro" não basta

Red teaming de IA é a prática de atacar deliberadamente um sistema de inteligência artificial — com as mesmas técnicas que um adversário real usaria — para encontrar e documentar falhas antes que elas virem incidente. A equipe da Microsoft que testou mais de 100 produtos de IA generativa descreve o processo em três etapas: mapear os riscos possíveis, medir a exposição real testando ataques específicos e gerenciar o que foi encontrado com mitigação e reteste, segundo o relato publicado pela Microsoft Source LATAM. A equipe usa personas e fala coletivamente 17 idiomas para testar como o sistema se comporta em contextos culturais diferentes, combinando isso com ferramentas de ataque automatizado como PyRIT e Counterfit, ambas de código aberto.

A diferença central para um pentest tradicional é o alvo. Pentest ataca infraestrutura, rede e código — a superfície que qualquer aplicação tem. Red teaming de IA ataca o comportamento do modelo em linguagem natural: instrução, contexto, memória de conversa, ferramentas conectadas. É possível — e recomendado — rodar as duas coisas ao mesmo tempo, porque cobrem superfícies diferentes do mesmo sistema.

Vale a mesma distinção que já existe entre auditoria e red teaming: a auditoria de IA é a avaliação periódica e ampla de um sistema — viés, drift, explicabilidade, qualidade de dados e segurança —, e trata segurança adversarial como uma de cinco frentes que verifica. Red teaming é a execução profunda dessa única frente. Uma auditoria pode incluir um red team como evidência; um red team sozinho não substitui a auditoria completa.

Os três vetores que todo red team de IA precisa cobrir

Três categorias de ataque dominam o trabalho de red teaming em sistemas de IA generativa hoje, e cada uma exige técnica própria.

Prompt injection

É o ataque que ocupa o topo do OWASP Top 10 for LLM Applications 2025 pela segunda edição consecutiva, classificado como LLM01, segundo o OWASP Gen AI Security Project. Acontece quando um invasor manipula a entrada do modelo para sobrepor, contornar ou alterar as instruções que o desenvolvedor definiu. Pode ser direto — o próprio usuário digita a instrução maliciosa no chat — ou indireto, quando o modelo lê conteúdo não confiável de um e-mail, site ou documento e interpreta esse conteúdo como instrução nova em vez de dado a processar. O modelo não distingue os dois porque processa instrução e dado no mesmo canal — nem RAG nem fine-tuning eliminam essa classe de risco por conta própria, segundo o mesmo relatório da OWASP.

Jailbreak

Enquanto o prompt injection explora a ambiguidade entre instrução e dado, o jailbreak ataca diretamente as camadas de segurança do modelo — as restrições que o fornecedor configurou para recusar determinados pedidos. A técnica típica usa personas fictícias, encadeamento de instruções em várias etapas ou reformulação incremental do pedido até o modelo produzir uma saída que a instrução original recusaria diretamente. Diferente do prompt injection, que geralmente mira uma aplicação específica, jailbreak costuma mirar o modelo em si — e por isso um jailbreak encontrado em um produto pode se repetir em qualquer outra aplicação construída sobre o mesmo modelo.

Extração de dados de treinamento (model inversion)

É a categoria mais técnica das três: reconstruir, a partir das respostas do modelo, dado que fez parte do seu treinamento — nome, e-mail, trecho de código, documento interno — mesmo que nunca devesse ser reproduzido. Pesquisadores associados ao Google DeepMind demonstraram essa classe de ataque contra o ChatGPT em 2023 com uma técnica deliberadamente simples: pedir ao modelo para repetir uma palavra "para sempre". O comando desalinhou o modelo do treinamento de segurança e o fez divergir para reproduzir trechos memorizados do corpus original — extraindo vários megabytes de dado real (e-mail, telefone, código) por cerca de US$ 200, com mais de 5% da saída composta por sequências de 50 tokens copiadas verbatim do treinamento, quase 150 vezes acima da taxa que métodos de detecção padrão identificavam antes, segundo o estudo publicado pelos pesquisadores. O achado central: alinhamento de segurança pode mascarar uma vulnerabilidade sem eliminá-la — o tipo de lacuna que um red team estruturado é desenhado para encontrar antes de alguém de fora.

Metodologia recomendada: equipe, cadência e frameworks

Quem monta o red team

Três formatos coexistem, e a maioria dos programas maduros combina mais de um:

Formato	Quando faz sentido	Limitação
Time interno dedicado	Múltiplos sistemas de IA em produção, volume que justifica estrutura própria	Expertise rara — segurança ofensiva e comportamento de modelo de linguagem
Terceiro especializado	Validação independente para due diligence, certificação ou exigência regulatória	Menos contexto de negócio que o time interno
Híbrido com ferramenta automatizada	Cobertura contínua entre ciclos de teste manual mais profundos	Encontra padrão conhecido, não substitui julgamento humano

Um achado consistente do trabalho da Microsoft ao testar mais de 100 produtos de IA generativa: a automação ajuda a gerar e pontuar tentativas de ataque em escala, mas não substitui especialista humano em domínios sensíveis — medicina, segurança nacional, dano psicológico — nem o julgamento sobre contexto cultural, segundo o relatório da Microsoft Security, que defende ciclos de "break-fix": testar, corrigir, testar de novo.

Cadência: não é evento único

Red teaming de IA não é um teste que se roda uma vez e arquiva. A recomendação predominante é testar antes do lançamento e depois de cada atualização relevante do modelo — cada mudança expande a superfície de ataque de novo —, com testes contínuos entre esses marcos, segundo o guia da Mindgard sobre red teaming de IA. O NIST AI 600-1 (perfil de IA generativa do AI RMF) recomenda formalmente red teaming antes e depois do deployment, cobrindo doze categorias de risco — o mesmo documento cita o prazo de 2 de agosto de 2025, quando provedores de modelos de propósito geral na União Europeia passaram a ter obrigação equivalente sob o AI Act, segundo a mesma fonte. Os gatilhos que devem disparar um novo ciclo, além do calendário:

1. Antes do primeiro acesso em produção de qualquer sistema de IA voltado a público externo.
2. Após atualização de modelo, troca de fornecedor ou mudança relevante no prompt de sistema.
3. Após qualquer incidente ou tentativa de manipulação identificada em produção.
4. Antes de expandir o sistema para um novo caso de uso ou público.

Frameworks: OWASP LLM Top 10 e MITRE ATLAS

Dois frameworks estruturam a maioria dos programas de red teaming de IA hoje, com papéis diferentes:

• OWASP Top 10 for LLM Applications — cataloga as dez classes de risco mais críticas de aplicações construídas sobre modelos de linguagem: prompt injection, divulgação de informação sensível, cadeia de suprimento, envenenamento de dado e modelo, tratamento inadequado de saída, agência excessiva, vazamento do prompt de sistema, fragilidade de embeddings, desinformação e consumo desregulado de recursos, segundo o OWASP Gen AI Security Project. Referência para decidir o que testar.
• MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) — base de conhecimento viva, no modelo do MITRE ATT&CK, que cataloga táticas e técnicas reais de ataque contra sistemas de IA: 16 táticas, 84 técnicas, 56 subtécnicas, 32 mitigações e 42 estudos de caso reais, na versão de fevereiro de 2026, segundo a Vectra AI. Referência para como simular o ataque com realismo — cada técnica mapeia para um caso documentado, não hipotético.

O que virou exigência regulatória

Red teaming deixou de ser boa prática discricionária em dois pontos específicos:

• NIST AI RMF, função Measure. O framework organiza sua estrutura em quatro funções — Govern, Map, Measure, Manage — e coloca teste adversarial e red teaming dentro de Measure, junto com auditoria de viés e validação de acurácia, como as avaliações técnicas que geram o dado que sustenta as outras três funções, segundo o glossário da Scrut.io sobre a função Measure. Comparação completa com ISO/IEC 42001 e OCDE em framework de governança de IA: guia de implementação.
• Artigo 15 do AI Act europeu. Exige que sistemas de IA de alto risco tenham "medidas para prevenir, detectar, responder, resolver e controlar ataques que tentem manipular o conjunto de dados de treinamento (envenenamento de dado), componentes pré-treinados usados no treinamento (envenenamento de modelo) e entradas desenhadas para causar erro do modelo (exemplos adversariais ou evasão de modelo)" ao longo de todo o ciclo de vida do sistema, segundo o texto consolidado do AI Act, Artigo 15. Isso não é uma recomendação — é requisito de conformidade para colocar um sistema de alto risco no mercado europeu, com alcance extraterritorial que já afeta empresas brasileiras que vendem ou operam na UE. O cronograma completo, incluindo o que o Digital Omnibus on AI adiou, está em AI Act europeu e empresas brasileiras.

No Brasil, o PL 2338 ainda tramita sem exigência explícita de red teaming, mas já prevê avaliação de impacto algorítmico para sistemas de alto risco — detalhamento em Marco Legal da IA no Brasil (PL 2338). Empresas que já testam hoje estão construindo a evidência que qualquer uma dessas exigências vai pedir depois.

Da simulação ao gerenciamento: o que fazer com o que o red team encontra

Um relatório de red teaming sem plano de correção é, na prática, um registro de risco conhecido e ignorado — pior evidência possível do que nunca ter testado. Achados de red teaming se conectam a três outras práticas de governança:

• Gestão de risco de modelo. Um jailbreak ou uma extração de dado bem-sucedida é sinal de vulnerabilidade no modelo, não só no prompt de aplicação — informação que entra na classificação de criticidade descrita em gestão de risco de modelo de IA.
• Resposta a incidente. Um achado crítico, especialmente se já foi explorado fora do teste controlado, deve acionar o processo formal descrito em plano de resposta a incidentes de IA — red teaming e resposta a incidente são processos irmãos, não o mesmo processo.
• Contenção de agente. Quando o achado envolve ação autônoma, o mecanismo de contenção imediata é o kill switch para agentes de IA, e o controle que evita escalada de privilégio é o assunto de gestão de identidade para agentes de IA.

Há também um efeito colateral financeiro que poucas empresas antecipam: evidência de red teaming recorrente é o tipo de documentação que uma seguradora pede antes de precificar uma apólice de risco cibernético para IA — o que cobre e o que fica de fora está em seguro cibernético para riscos de IA.

Por que red teaming de IA exige time capacitado, não só ferramenta

O ponto que o relatório da Microsoft deixa mais claro depois de testar mais de 100 produtos: ferramenta automatizada escala tentativas de ataque, mas não substitui alguém que entende o domínio, reconhece dano sutil e sabe quando escalar. Comprar plataforma de red teaming sem formar quem vai interpretar o resultado é o mesmo erro que já aparece em outras frentes de governança de IA: instalar controle sem instalar capacidade.

Dentro do método Flight Plan (quatro estágios, cerca de duas semanas por área), o Launchpad mapeia quais sistemas de IA já estão em produção e nunca passaram por teste adversarial; o Flight Plan desenha a cadência proporcional ao risco de cada sistema; o Booster capacita o time de segurança e os donos de produto a reconhecer sinais de prompt injection e jailbreak no dia a dia; e o Mission Control acompanha se os achados viraram correção, não só relatório arquivado. Como parceira oficial da Replit no Brasil, a Jetpacks já aplicou essa abordagem em empresas como Hypera Pharma, Volvo, BMR Medical e C12 Brasil.

FAQ

O que é red teaming de IA?

É a simulação controlada de ataques contra um sistema de inteligência artificial em produção — prompt injection, jailbreak, extração de dado de treinamento — feita por uma equipe que assume o papel de invasor, para encontrar e corrigir falhas antes que alguém de fora as explore.

Qual a diferença entre red teaming de IA e um pentest tradicional?

Pentest ataca infraestrutura, rede e código-fonte. Red teaming de IA ataca o comportamento do modelo em linguagem natural — instrução, contexto, memória de conversa, ferramentas conectadas. As duas práticas cobrem superfícies diferentes do mesmo sistema e, idealmente, rodam em paralelo.

Qual a diferença entre red teaming de IA e auditoria de IA?

Auditoria de IA é a avaliação ampla e periódica de um sistema — viés, drift, explicabilidade, qualidade de dado e segurança — que trata teste adversarial como uma de cinco frentes. Red teaming é a execução profunda e contínua dessa frente específica: simular ativamente o ataque, não só verificar se ele já foi mitigado.

Com que frequência uma empresa deve fazer red teaming de IA?

Antes de qualquer sistema entrar em produção e depois de toda atualização relevante de modelo, prompt de sistema ou fornecedor. Entre esses marcos, a prática recomendada é monitoramento e teste contínuo, não um evento isolado uma vez por ano.

O AI Act europeu exige red teaming de sistemas de IA?

O Artigo 15 exige que sistemas de alto risco tenham medidas para prevenir, detectar e responder a ataques de envenenamento de dado e modelo e a exemplos adversariais ao longo do ciclo de vida — o red teaming é o mecanismo prático que produz essa evidência. Provedores de modelos de propósito geral já têm obrigação equivalente desde agosto de 2025.

Ferramentas automatizadas substituem um time humano de red teaming?

Não. Elas escalam a geração e a pontuação de tentativas de ataque, mas não substituem especialista humano em domínios sensíveis nem o julgamento sobre dano sutil e contexto cultural — achado consistente do programa de red teaming da Microsoft após testar mais de 100 produtos.

Conclusão: testar como um invasor testaria é o que separa "parece seguro" de "é seguro"

Um sistema de IA que nunca foi atacado de propósito não é um sistema seguro — é um sistema não testado. A diferença entre as duas coisas só aparece quando alguém, de forma deliberada e metodológica, tenta fazer o modelo falhar antes que um adversário real o faça. É isso que red teaming de IA produz: evidência de que prompt injection, jailbreak e extração de dado foram tentados e mitigados, não apenas presumidos ausentes.

Se sua empresa já tem sistemas de IA em produção e ainda não tem um programa formal de red teaming — com cadência definida, framework de referência e time capacitado para interpretar o resultado —, o diagnóstico gratuito da Jetpacks mapeia, em 30 a 45 minutos, quais sistemas precisam de teste adversarial com mais urgência, e o método Flight Plan desenha a cadência junto com a capacitação de quem vai conduzi-la. Para a estrutura mais ampla de governança em que o red teaming se encaixa, comece pelo pilar governança de IA na prática.