O essencial
- O red teaming deixou de ser facultativo na Europa a 2 de agosto de 2025, quando o
artigo 55.ºdo regulamento da IA passou a aplicar-se aos prestadores de modelos de finalidade geral com risco sistémico. - A aplicação já é efetiva: o Serviço para a IA dispõe dos seus poderes sancionatórios desde 2 de agosto de 2026, com coimas até 15 milhões de euros ou 3 por cento do volume de negócios mundial anual.
- O regime de risco elevado moveu-se em sentido inverso. O ómnibus digital aprovado a 16 de junho de 2026 adia as obrigações do anexo III para 2 de dezembro de 2027.
- A maioria das organizações não é prestadora destes modelos: a exposição chega por via contratual, através da diligência sobre fornecedores e dos pedidos de garantia dos clientes.
- Um exercício não documentado nada prova. O que um avaliador lê é o processo: âmbito, modelo de ameaças, registo de testes, criticidade, responsáveis pela correção e novo teste.
O que é realmente o red teaming, e o que não é
O red teaming consiste em sujeitar um sistema de IA a um ataque estruturado, conduzido por pessoas cuja missão, enquanto dura o exercício, é fazê-lo falhar. A equipa redige instruções concebidas para contornar as salvaguardas, contamina um índice documental, encadeia chamadas a ferramentas que o projetista não previu, e regista o comportamento obtido. O objetivo não é uma pontuação. O objetivo é a lista de comportamentos que ninguém pretendeu.
Quem ler a primeira página de resultados sobre este tema concluirá que se trata de uma disciplina de segurança e nada mais. Cada página bem posicionada descreve vetores de ataque, fases de método e ferramentas. A descrição é correta e incompleta, porque omite aquilo que hoje decide o orçamento: na União Europeia esta atividade constitui uma obrigação jurídica documentada para uma categoria de prestadores e uma expectativa documentada para várias outras.
Convém fixar duas fronteiras antes de prosseguir.
Red teaming, testes comparativos e avaliações são três coisas distintas
Os testes comparativos medem capacidades conhecidas sobre um conjunto fixo de perguntas. As avaliações pontuam um sistema face a critérios definidos à partida. Ambos respondem à pergunta sobre se o sistema faz bem aquilo que lhe foi pedido. Nenhum responde à pergunta sobre o que mais faz.
O red teaming existe para essa segunda pergunta. A investigação da IBM formula-o sem rodeios: o exercício serve para tratar aquilo que não se sabe que se ignora. Uma bateria de testes comparativos não consegue revelar um modo de falha para o qual ninguém escreveu um teste, e é precisamente essa categoria que produz incidentes.
Consequência prática: as abordagens completam-se, não se substituem. Ter medido uma capacidade não equivale a ter sondado um dano.
Também não é um teste de intrusão com outro nome
Um teste de intrusão ataca a infraestrutura: a rede, o gateway de API, a camada de identidade. Esse trabalho continua a ser necessário. O red teaming ataca o modelo e o seu comportamento, que falha de outra maneira. Para um modelo que se deixa convencer não existe correção de software. A correção assume a forma de novo treino, filtragem, políticas de recusa, redução de privilégios ou monitorização, nunca de um salto de versão.
A obrigação de que os resultados de pesquisa não falam
O artigo 55.º, n.º 1, alínea a) do regulamento da IA obriga os prestadores de modelos de IA de finalidade geral com risco sistémico a efetuar a avaliação do modelo segundo protocolos e ferramentas normalizados que reflitam o estado da arte, o que inclui realizar e documentar testes adversos destinados a identificar e atenuar os riscos sistémicos. O texto acrescenta que os testes devem ser proporcionados ao nível de risco e ao estado da arte, e que podem envolver peritos externos independentes.
Três termos suportam todo o peso. A realização torna o exercício obrigatório. A documentação torna o rasto obrigatório. A proporcionalidade significa que um prestador de pequena dimensão não será medido pelo programa de um laboratório de fronteira e, simetricamente, que um laboratório de fronteira não cumpre a sua obrigação com um fim de semana de testes de instruções.
Um modelo entra na categoria de risco sistémico quando a potência de cálculo acumulada de treino ultrapassa os 10^25 FLOPs, ou quando o Serviço para a IA o designa com base noutros critérios. O limiar é deliberadamente elevado: abrange os criadores de modelos de fronteira, não a empresa mediana.
Os prazos são o elemento pior compreendido. As obrigações relativas a modelos de finalidade geral aplicam-se desde 2 de agosto de 2025 aos modelos colocados no mercado depois dessa data. Os modelos já existentes dispõem de prazo até 2 de agosto de 2027. E desde 2 de agosto de 2026 o Serviço para a IA da Comissão dispõe dos seus poderes de execução, com coimas até 15 milhões de euros ou 3 por cento do volume de negócios mundial anual, consoante o montante mais elevado.
Entretanto, o regime que todos preparavam há dois anos recuou. O Parlamento Europeu aprovou a 16 de junho de 2026 as alterações do ómnibus digital, deslocando as obrigações dos sistemas de risco elevado autónomos do anexo III de 2 de agosto de 2026 para 2 de dezembro de 2027, e as dos sistemas integrados em produtos para 2 de agosto de 2028. O ómnibus não mexeu nos prazos aplicáveis aos modelos de finalidade geral.
A situação é, portanto, o inverso do que a maioria dos calendários de conformidade pressupõe. A obrigação de teste do regulamento que hoje é exigível é a que abrange os modelos de finalidade geral, e os testes adversos constituem o seu núcleo.
A via operacional passa pelo código de boas práticas para modelos de finalidade geral. O seu capítulo de segurança e proteção, publicado a 10 de julho de 2025, define o dispositivo esperado: avaliações de modelos, red teaming, vigilância pós-comercialização, medidas de cibersegurança, comunicação de incidentes e responsabilidade sobre o modelo. A subscrição continua a ser voluntária, mas o Serviço para a IA declarou que os signatários são tratados como agindo de boa-fé e que os seus compromissos pesam no cálculo de uma sanção. É o mais próximo de um porto seguro que o regulamento oferece, e assenta em provas de teste.
Quem tem mesmo de fazer red teaming
Para a maioria dos leitores a resposta honesta é: não é o seu caso, pelo menos não diretamente. Convém dizê-lo com clareza, porque os conteúdos publicados pelos fabricantes de segurança sobre esta pesquisa deixam supor uma obrigação universal.
Os prestadores de modelos de finalidade geral com risco sistémico. Vinculados pelo artigo 55.º, exigível desde já, com sanção associada. A lista é curta e os visados sabem-no.
Os prestadores de sistemas de risco elevado. O artigo 9.º exige um sistema de gestão de riscos com testes ao longo de todo o ciclo de vida, e o artigo 15.º exige sistemas que funcionem de forma fiável e resistam a erros, falhas e tentativas de alterar a sua utilização ou o seu desempenho. Nenhum dos dois emprega a expressão red teaming. Ambos exigem testes em condições que pressionem o funcionamento previsto, com método e resultados documentados. Aplicável a partir de 2 de dezembro de 2027 aos sistemas autónomos do anexo III.
Os responsáveis pela implantação. Nenhuma obrigação legal direta de teste. A obrigação chega pelo contrato: questionários de compra, anexos de garantia, direitos de auditoria, cláusulas de indemnização. Na prática é por esta via que o red teaming atinge a maioria das organizações, e apresenta-se quase sempre como uma pergunta a responder em trinta dias. Estruturar essa resposta é antes uma questão de governação do que técnica, como mostra a nossa análise dos desafios da governação da IA.
Todos os restantes. Voluntário, e cada vez mais esperado. As seguradoras perguntam. Os grandes clientes também. Os conselhos de administração interessam-se depois do primeiro incidente público do seu setor.
Merece referência um último grupo: as organizações cujo parque de IA não é integralmente conhecido. Não se faz red teaming sobre aquilo que não foi inventariado, e as utilizações não declaradas explicam que muitos programas cubram apenas uma fração da superfície real. O recrutamento oferece um exemplo nítido, como mostra a nossa análise sobre a inteligência artificial no recrutamento.
O que cada referencial exige na realidade
Os referenciais convergem na atividade e divergem claramente na força vinculativa.
| Referencial | O que exige | Termo utilizado | Vinculativo? |
|---|---|---|---|
Regulamento da IA art. 55.º, n.º 1, al. a) | Avaliação do modelo com testes adversos documentados e proporcionados ao risco | Testes adversos | Sim, para modelos com risco sistémico, exigível desde 2 de agosto de 2026 |
Regulamento da IA art. 9.º e art. 15.º | Testes ao longo do ciclo de vida em condições exigentes, método e resultados documentados | Testes | Sim, para risco elevado, a partir de 2 de dezembro de 2027 |
| Código de boas práticas, capítulo de segurança e proteção | Avaliações de modelos, red teaming, vigilância pós-comercialização, comunicação de incidentes | Red teaming | Voluntário, mas relevante em sede sancionatória |
| NIST AI RMF, Measure 1.1 | Equipas adversas e testes adversos para revelar capacidades perigosas e propriedades emergentes | Red teaming | Voluntário |
| NIST AI 600-1, perfil de IA generativa | Red teaming antes e depois da implantação, sobre doze categorias de risco | Red teaming | Voluntário |
ISO/IEC 42001 | Nenhuma cláusula dedicada; os registos de teste sustentam o sistema de gestão | Teste e avaliação | Certificável |
| Guia OWASP GenAI Red Teaming | Testes por fases: modelo, implementação, sistema, execução | Red teaming | Norma de prática |
| Guia CSA e OWASP sobre IA agêntica | Doze categorias de ameaças agênticas sobre o modelo MAESTRO | Red teaming | Norma de prática |
Da tabela decorrem duas observações.
Primeira, a ISO/IEC 42001 nunca pronuncia o termo, o que surpreende quem chega à procura de uma cláusula. A norma exige a prova de que os riscos foram identificados, os tratamentos testados e os resultados revistos. Um relatório de red teaming com rasto de correção satisfaz esse requisito; um simples teste comparativo de desempenho não.
Segunda, os instrumentos americanos e europeus descrevem a mesma prática com força distinta. O perfil de Berkeley para modelos de finalidade geral coloca o red teaming sob Measure 1.1 do NIST AI RMF, para revelar capacidades perigosas, vulnerabilidades e propriedades emergentes, e repete-o como controlo de ciclo de vida sob Manage 1.3, 2.3 e 2.4. O NIST AI 600-1 recomenda praticá-lo antes e depois da implantação sobre doze categorias de risco. Nenhum prevê coimas. Ambos são o que um avaliador europeu aceitará como estado da arte quando o artigo 55.º perguntar face a que norma se testou.
No plano nacional, a CNPD mantém a sua competência sempre que haja tratamento de dados pessoais envolvido, e a estrutura designada para a supervisão da IA é o interlocutor para o restante. Não criam uma obrigação nova de red teaming, mas fixam a instância perante a qual a diligência terá de ser demonstrada.
Delimitar o âmbito para que as conclusões se sustentem
A maioria dos relatórios falha no âmbito, não no teste. O exercício localiza problemas reais e depois ninguém sabe dizer a que versão do sistema se referiam.
Nomear o alvo com precisão. Modelo de base, variante especializada, camada de recuperação documental, superfície de ferramentas e agentes, aplicação implantada. Indique o que entra no âmbito, o que fica de fora e porquê. Testar o modelo de base não cobre o produto construído por cima.
Fixar todas as versões. Compilação do modelo, versão da instrução de sistema, instantâneo do índice documental, configuração das salvaguardas, permissões das ferramentas. Uma conclusão referida a uma compilação sem nome não pode ser reverificada, e uma conclusão não verificável não é prova.
Definir os danos a partir da taxonomia própria. As listas genéricas produzem conclusões genéricas. Se o registo de riscos aponta o compromisso financeiro não autorizado e a divulgação de dados de clientes como exposições principais, são essas a entrar primeiro no âmbito, e o relatório deve explicar porque as restantes ficaram adiadas. Esse raciocínio torna visível o seu apetite ao risco perante um avaliador.
Decidir a independência de forma deliberada. O artigo 55.º contempla expressamente o recurso a peritos externos independentes. As equipas internas conhecem melhor o sistema e custam menos. As equipas externas são mais difíceis de afastar e pesam mais no plano probatório. A escolha deve ficar por escrito e fundamentada, porque será discutida.
Alargar o âmbito aos sistemas agênticos. Os testes de um único turno tornam-se insuficientes assim que um sistema dispõe de autonomia, memória e ferramentas. O guia da Cloud Security Alliance e da OWASP organiza este trabalho em torno do modelo de ameaças MAESTRO e de doze categorias, entre elas a apropriação das autorizações e do controlo do agente, a contornagem do ponto de controlo humano, a manipulação de objetivos, a manipulação de memória e contexto, a exploração multiagente, o raio de impacto e a rastreabilidade do agente. Este último ponto pesa mais do que parece: se as ações de um agente não puderem ser imputadas a posteriori, a falha é antes uma falha de responsabilidade do que um problema de segurança.
As provas que o red teaming tem de deixar
É a parte que os resultados de pesquisa ignoram por completo, e é a que decide se a despesa se justificou. Imagine o processo que um avaliador abrirá daqui a dezoito meses.
A nota de âmbito. Datada, com versão, com as exclusões e a respetiva justificação.
O modelo de ameaças. O referencial adotado nomeado de forma explícita: MITRE ATLAS, MAESTRO, a taxonomia OWASP GenAI, ou o próprio, mapeado sobre um deles.
O registo de testes. O que foi tentado, por quem, com que ferramentas, em que data, contra que compilação. Das campanhas automatizadas regista-se a configuração, e não apenas o resultado.
As conclusões com criticidade e fundamentação. A fundamentação pesa mais do que a classificação. Um avaliador pode contestar um nível elevado e aceitar ainda assim o processo, se o raciocínio for legível.
As decisões de correção com responsável e prazo. Cada conclusão recebe um estado: corrigida, atenuada, aceite, ou adiada com data de revisão.
O risco residual aceite ao nível adequado. Uma pessoa com autoridade suficiente assina que a exposição remanescente é tolerável face a um limiar escrito.
A prova do novo teste. A demonstração de que a correção funciona, no mesmo teste, contra a compilação nomeada. Sem ela, a coluna da correção é uma afirmação.
Duas situações merecem ser nomeadas. Um red teaming não documentado nada prova, por melhores que tenham sido os testes. E um relatório com conclusões sem rasto de correção é pior do que nenhum relatório, porque estabelece de forma duradoura que sabia. As autoridades e os queixosos leem-no da mesma maneira.
Onde o red teaming encaixa no resto do processo de governação
Um red teaming que termina num PDF falhou, quaisquer que tenham sido as conclusões. Quatro ligações tornam-no operacional.
O registo de riscos. As conclusões passam a entradas com responsável e data de revisão, no mesmo sistema de qualquer outro risco. Se viverem num acompanhamento de segurança à parte, o processo de governação apresenta um vazio no ponto da ligação.
A comunicação de incidentes. Uma conclusão que depois se materializa em produção passa a ser uma questão do artigo 73.º, e a primeira pergunta será se tinha conhecimento.
A vigilância pós-comercialização. O red teaming é uma sondagem pontual. A vigilância é a metade contínua, e o código de boas práticas nomeia ambas. Um programa com apenas uma metade é meio programa.
O relato de transparência. O perfil de Berkeley encaminha os resultados para as fichas de modelo e de sistema, omitindo de forma responsável os detalhes que aumentariam o potencial de utilização abusiva. Essa reserva não é opcional: publicar uma contornagem funcional é uma falha de divulgação, não transparência.
Cinco defeitos que anulam a prova
Testar uma compilação e implantar outra. O defeito mais comum. O relatório descreve um sistema que já não existe.
Limitar o âmbito à injeção de instruções. A injeção de instruções é o modo de falha famoso, não o mais caro. São as permissões sobre ferramentas e a autonomia dos agentes que produzem os incidentes com consequências financeiras.
Não ter escala de criticidade. Quando tudo é médio, nada é priorizado, e a fundamentação que um avaliador quer ler não existe.
Conclusões sem responsável. Uma conclusão não atribuída é um apontamento. Continuará aberta na revisão seguinte, e as datas hão de demonstrá-lo.
Nenhum novo teste. A correção é afirmada em vez de demonstrada. É a lacuna mais frequente em programas de red teaming de resto sérios, e a mais barata de fechar.
Perguntas frequentes
O red teaming é obrigatório por lei?
Na União Europeia sim, para um grupo preciso. O artigo 55.º, n.º 1, alínea a) do regulamento da IA obriga os prestadores de modelos de finalidade geral com risco sistémico a realizar e documentar testes adversos, obrigações exigíveis desde 2 de agosto de 2026. Para os prestadores de sistemas de risco elevado, os artigos 9.º e 15.º exigem testes documentados em condições exigentes a partir de 2 de dezembro de 2027, sem empregar o termo. Para os restantes, a obrigação é contratual antes de ser legal.
Quem fica abrangido pelo regulamento da IA?
Os prestadores de modelos de finalidade geral cuja potência de cálculo acumulada de treino ultrapasse os 10^25 FLOPs, ou que o Serviço para a IA designe como portadores de risco sistémico. Trata-se de uma população reduzida de criadores de modelos de fronteira. Quem implanta esses modelos herda as expectativas por contrato, e é assim que o requisito chega à maioria das organizações.
Qual é a diferença face a um teste de intrusão?
Um teste de intrusão ataca a infraestrutura e produz vulnerabilidades com a respetiva correção de software. O red teaming ataca o comportamento do modelo e produz modos de falha sem correção de software. A remediação consiste em novo treino, filtragem, política de recusa, redução de privilégios ou monitorização. Ambos são necessários e nenhum substitui o outro.
Com que frequência deve ser feito?
Ligue a cadência à mudança e não ao calendário. Um novo modelo de base, uma especialização, uma ferramenta ou integração nova, uma alteração substancial da instrução de sistema ou um novo contexto de implantação justificam cada um deles um exercício. Acrescente uma linha de referência periódica, anual para a maioria dos sistemas, e trate os testes posteriores à implantação separadamente dos anteriores.
O red teaming pode ser automatizado?
Em parte, e a repartição conta para a prova. As sondas automatizadas dão amplitude, repetibilidade e o mecanismo do novo teste, exatamente aquilo de que a documentação precisa. Os operadores humanos encontram o caminho inédito que nenhuma biblioteca de sondas contém. Um programa inteiramente automatizado produzirá um processo limpo com um ponto cego previsível.
O que pede um auditor depois do exercício?
A nota de âmbito com as versões, o modelo de ameaças e o seu referencial, o registo de testes, as conclusões com criticidade e fundamentação, responsáveis e prazos de correção, a aceitação do risco residual e a respetiva assinatura, e a prova do novo teste. O auditor avalia a cadeia documental, não o exercício, porque é a única parte que sobrevive.
Conclusão
Os resultados de pesquisa tratam o red teaming como um serviço de segurança; nessa leitura a decisão reduz-se a uma linha de orçamento de uma equipa técnica. A posição regulatória diz outra coisa. Os testes adversos são a obrigação do regulamento da IA exigível hoje, ao passo que o regime de risco elevado que todos preparavam fica a mais de um ano de distância, e o que cumpre a obrigação não é o exercício mas o rasto que deixa.
Esse deslocamento muda o dono do assunto. Os testes continuam nas mãos de quem sabe partir sistemas. A nota de âmbito, a fundamentação das criticidades, o registo de correção e a assinatura do risco residual pertencem à governação, porque são os únicos documentos que alguém lerá. Comece pelo processo que teria de apresentar e encomende depois o red teaming que o preenche. A nossa plataforma de governação da IA mostra como estas peças ficam no mesmo sítio.