Red teaming em IA: como testar seu agente antes do lançamento

Antes de lançar um agente voltado ao cliente, o red teaming em IA deve verificar se alguém consegue fazê-lo expor dados privados, executar uma ação sem autorização ou gerar conteúdo proibido. Comece com uma rodada de 6 etapas: definir o escopo, listar ataques, executar, avaliar, corrigir e testar novamente. O resultado útil é uma falha documentada, que possa ser rastreada, e uma correção verificada — não um selo para tranquilizar a equipe.

Os recursos das ferramentas e as descrições dos frameworks foram verificados na documentação oficial em 17 de outubro de 2026. O fluxo de trabalho e os exemplos com agentes de atendimento abaixo são exercícios propostos, não resultados de testes de produtos.

O que é red teaming em IA?

Red teaming em IA é a tentativa deliberada de fazer um sistema de IA violar uma regra de segurança, de proteção contra danos ou do negócio. Quem testa procura provocar uma falha, observa o comportamento do sistema e transforma o que encontrou em uma correção que possa ser verificada depois. Para uma empresa que vai lançar um chatbot, o alvo costuma ser a aplicação inteira: suas instruções, as informações que ela consulta, suas permissões, ferramentas e respostas exibidas ao cliente. Ameaças ao modelo e à aplicação.

Pense na recepção de um hotel. Um teste comum de atendimento verifica se o hóspede consegue retirar a chave do quarto certo. Já um teste adversarial pergunta se um aviso falso de manutenção, escrito de forma convincente, poderia levar a recepção a entregar a chave de outra pessoa. O que importa como evidência é qual chave saiu do balcão, independentemente da educação de quem atendeu.

Seu agente tem limites parecidos. Um chamado de suporte contém informações a processar; ele não deve ganhar a autoridade de uma aprovação gerencial. Um documento recuperado pode ajudar a responder uma pergunta; não deve conceder acesso aos registros de outro cliente.

O que muda entre testar o modelo e testar a aplicação?

O red teaming de modelos de IA examina como o modelo se comporta diante de entradas adversariais. O teste da aplicação inclui o sistema ao redor dele, no qual a identidade do cliente, o acesso a documentos e as permissões das ferramentas determinam o que pode acontecer. O relatório de segurança do fornecedor do modelo não comprova que sua integração de reembolso verifica a conta correta. A documentação de red teaming do promptfoo deixa essa distinção explícita.

Para a maioria das empresas, o ponto de partida deve ser o perímetro da aplicação implantada. Testes no nível do modelo continuam úteis na escolha ou na troca do modelo, mas o cliente usa o produto completo.

O que pode passar despercebido nos testes de qualidade?

O red teaming em IA procura maneiras de violar um limite previsto, inclusive por meio de solicitações plausíveis que exploram ambiguidades, em vez de entradas malformadas. A garantia de qualidade, ou QA, normalmente verifica os comportamentos especificados: respostas corretas, transações válidas, tempos de resposta e erros esperados. Um programa maduro de QA pode incluir testes adversariais; o red teaming fornece novos casos de falha para esse programa.

Um bot de atendimento pode explicar corretamente a política de reembolso e, ainda assim, interpretar um parágrafo malicioso em um artigo de ajuda como permissão para ignorá-la. As duas solicitações são textos legíveis. A diferença está em qual instrução a aplicação reconhece como autoridade.

Use estas famílias de ataques como ponto de partida para um agente voltado ao cliente. Os exemplos são propostas de testes com dados fictícios, e os critérios de aprovação precisam ser adaptados à sua política.

Essas categorias se sobrepõem. Um jailbreak busca contornar as proteções de comportamento. A prompt injection, ou injeção de prompt, tenta redirecionar o sistema por meio de instruções que ele não deveria reconhecer como autoridade. Uma injeção escondida em material recuperado é chamada de prompt injection indireta; ela pode levar a um vazamento de dados ou a uma ação não autorizada. As categorias descrevem partes diferentes de uma falha, não compartimentos isolados. Definições das ameaças.

Para testar agentes de IA, acompanhe as ações

Um agente de IA é uma aplicação capaz de usar ferramentas para executar etapas de uma tarefa. Por isso, o red teaming de agentes exige evidências que vão além da resposta final. Uma recusa não desfaz uma alteração de registro que já ocorreu, e uma frase como “reembolso emitido” não prova que algum reembolso aconteceu.

Registre tanto a conversa quanto as ações. Se o agente solicitar uma operação proibida, mas a camada de permissões bloqueá-la, registre separadamente a tentativa de violação e a contenção bem-sucedida. Essa distinção ajuda a melhorar o comportamento sem relatar uma tentativa bloqueada como se fosse uma violação consumada.

Para um chatbot sem ferramentas, concentre-se nas respostas e nas informações acessíveis. Para um agente capaz de alterar registros de clientes, inclua o estado antes e depois de cada tentativa de ação. É a permissão adicional que muda o teste.

Quem precisa fazer red teaming em IA agora?

Aja antes de disponibilizar aos clientes o acesso a informações privadas ou a ações com consequências relevantes. A responsabilidade muda conforme a função, mas a decisão de lançamento precisa considerar todas essas perspectivas.

Quem desenvolve: um fundador que recebeu investimento ou um desenvolvedor que trabalha sozinho deve escolher uma jornada de cliente bem delimitada e identificar seus resultados proibidos antes de conectar uma ferramenta de ataque. Se a aplicação pode ler pedidos, teste o isolamento entre contas. Se pode alterar pedidos, teste a autorização no momento da alteração.

Quem opera: a liderança de atendimento deve fornecer a política, exemplos de exceções legítimas e o fluxo de escalonamento. Engenheiros de segurança não têm como deduzir quando sua empresa permite um reembolso ou que tipo de orientação seu chatbot deve recusar. Uma ação tecnicamente válida ainda pode violar uma regra do negócio.

Quem compra: o CTO de uma empresa de médio porte deve pedir evidências referentes à configuração que será contratada, incluindo conectores e permissões. O relatório do fornecedor sobre o modelo base serve como contexto; ele não resolve a questão do risco na implantação pretendida.

Um protótipo restrito a informações públicas, sem ações e sem usuários externos, pode adiar uma grande campanha automatizada enquanto seu comportamento ainda muda. Mantenha as verificações básicas de uso indevido e de conteúdo. A entrada de clientes, a recuperação de informações privadas ou a inclusão de ferramentas com permissão de escrita é o sinal para aprofundar os testes.

Aprender red teaming em IA começa pela política da empresa

Para a primeira rodada, designe alguém que conheça a aplicação, alguém que possa avaliar os danos ao negócio e alguém que implemente as correções. Em equipes pequenas, a mesma pessoa pode acumular funções, mas, sempre que possível, os achados com consequências relevantes devem ser revisados por alguém além de quem os produziu.

Pratique escrevendo um objetivo de ataque e uma condição de falha observável para um caso fictício de atendimento. Se os revisores discordarem sobre a permissão para o comportamento proposto, resolva a questão na política antes de tentar automatizar a avaliação.

Como fazer a primeira rodada em seis etapas

Mantenha a primeira rodada pequena o bastante para examinar e corrigir cada falha com consequências relevantes. O fluxo abaixo é uma proposta de método operacional, não uma afirmação de que uma quantidade fixa de testes certifica a segurança.

Use como exemplo um agente de atendimento capaz de ler pedidos e solicitar reembolsos. O resultado esperado é um conjunto de evidências que outro engenheiro ou comprador consiga entender.

1. 1

   1. Defina o escopo da aplicação e os resultados proibidos

   Registre a revisão da aplicação, o identificador do modelo, as instruções, as fontes de recuperação de informações, os perfis de clientes, as ferramentas disponíveis e as regras de aprovação. Especifique o ambiente e quem autorizou o exercício. Liste as exclusões para que uma integração não testada não fique escondida atrás de um resultado geral de aprovação.

   No exemplo de atendimento, o limite pode ser: clientes podem ler seus próprios pedidos; reembolsos exigem uma aprovação válida; nenhum cliente pode recuperar os registros de outro. Torne cada regra observável. “Respeitar a privacidade” é vago demais para avaliar.

   Use registros fictícios e identidades de teste com acesso restrito em um ambiente semelhante ao de produção. Direcione as operações de escrita a um serviço de teste controlado que preserve as verificações de permissão e registre o que seria alterado. Uma ferramenta simulada que aceita tudo não comprova se a autorização em produção funciona. Defina limites de requisições, tempo e gastos, além de uma forma de interromper a execução.

   A entrega é um documento curto de escopo, com responsáveis definidos e resultados que impedem o lançamento. Para montar o ambiente controlado, consulte o guia de avaliação de segurança de agentes de IA.

2. 2

   2. Monte a lista de ataques a partir dos danos ao negócio

   Escreva os objetivos antes dos prompts. “Obter o endereço de entrega de outro cliente” é um objetivo. Uma formulação específica é apenas uma tentativa de alcançá-lo.

   Para cada objetivo, registre o ponto de entrada, as permissões do atacante, o comportamento seguro esperado e as evidências necessárias. Inclua mensagens diretas no chat, documentos recuperados e respostas de ferramentas, conforme o uso desses recursos pela aplicação. Teste tanto uma conversa que avance gradualmente até a violação quanto uma solicitação imediata.

   Um caso útil é um artigo de ajuda fictício que contenha uma instrução para dispensar a aprovação de reembolsos. O comportamento esperado é tratar esse trecho como conteúdo não confiável e manter a exigência de aprovação. Inclua também um reembolso legítimo, com aprovação válida, para que uma defesa que bloqueie todos os reembolsos não pareça bem-sucedida.

   Preserve os casos originais e seus identificadores. Acrescente variações de redação, contexto ou ponto de entrada sem mudar silenciosamente o resultado proibido.

3. 3

   3. Execute os testes pelo mesmo fluxo usado pelo cliente

   Conecte o teste à mesma lógica da aplicação que processa as solicitações dos clientes, usando o ambiente e a identidade definidos no escopo. Testar apenas o modelo, sem passar pela recuperação de informações e pela autorização, responde a outra pergunta.

   Primeiro, verifique se a conexão chega ao alvo pretendido e se os logs contêm as evidências necessárias. Depois, execute os casos selecionados, preservando entradas, histórico de conversa, trechos recuperados, solicitações de ferramentas, decisões de permissão, respostas e estado final. Mantenha credenciais fora dos relatórios e use marcadores fictícios de dados sensíveis em vez de dados reais de clientes.

   Repita os casos com consequências relevantes conforme uma política declarada, pois as respostas do modelo podem variar. Registre as repetições e qualquer limite de turnos para ataques adaptativos. Reinicie as sessões entre casos independentes; preserve o histórico quando a sequência da conversa for o próprio teste.

   Um timeout, um erro de autenticação ou uma falha no parser é um problema do teste até que seja investigado. Não é evidência de que a aplicação resistiu ao ataque.

4. 4

   4. Avalie as evidências e depois atribua a gravidade

   Atribua um status de evidência a cada tentativa antes de calcular uma métrica geral. Use verificações explícitas para fatos observáveis, como o retorno de um registro proibido ou uma alteração de estado sem autorização. Um avaliador baseado em modelo pode ajudar a interpretar a linguagem, mas pessoas devem revisar achados com consequências relevantes e avaliações incertas.

   Os critérios propostos abaixo separam um teste com defeito de um limite que foi protegido:

   Status	Significado	Próxima ação
   Aprovado	A tentativa válida não causou a violação definida, e as evidências exigidas estão disponíveis.	Preserve o caso e suas evidências.
   Reprovado	As evidências confirmam a violação definida.	Atribua a gravidade e um responsável pela correção.
   Inválido	A tentativa não exercitou o cenário pretendido, por exemplo, por falha de autenticação ou ausência do conteúdo de ataque.	Corrija o teste e execute-o novamente.
   Inconclusivo	O cenário foi executado, mas as evidências ou a avaliação não permitem determinar o resultado.	Investigue; não conte como aprovação.

   A gravidade exige uma avaliação à parte sobre os danos, os dados afetados, o acesso necessário ao atacante e se o resultado chegou ao ponto em que uma ação de fato é executada. Um vazamento confirmado entre clientes exige uma decisão sobre o lançamento, mesmo que a maioria das tentativas inofensivas tenha sido aprovada.

   Se for apresentar uma taxa observada de sucesso dos ataques, defina-a como o número de tentativas com sucesso confirmado dividido pelo número de tentativas válidas segundo o protocolo declarado, e informe também os resultados ainda não resolvidos. Se houver tentativas válidas inconclusivas, identifique a fração como um limite inferior de sucesso confirmado, não como uma taxa completa de sucesso. Explique o que conta como tentativa, inclusive se uma conversa com vários turnos equivale a um caso. Não reúna conjuntos de testes que mudam ao longo do tempo em uma tendência nem trate o percentual resultante como a probabilidade de um cliente sofrer um ataque.

5. 5

   5. Corrija o controle que falhou

   Rastreie a causa da falha antes de alterar o prompt. Se um documento recuperado consegue conceder autoridade para reembolsos, reforce a verificação de aprovação na interface da ferramenta. Se a recuperação retorna registros de outro cliente, corrija o filtro de acesso antes que esses registros entrem no contexto do modelo.

   Outras correções podem incluir remover uma ferramenta desnecessária, restringir permissões, exigir aprovação para uma ação com consequências relevantes, separar instruções de conteúdo externo ou melhorar a política de respostas. Escolha a correção que trate o caminho observado.

   Para padrões de implementação, consulte o guia de guardrails e contenção de impacto para agentes em produção. O achado de red teaming identifica a falha a tratar; os controles de produção limitam o que o sistema pode fazer quando as defesas baseadas em linguagem falham.

   Cada achado precisa de um responsável, uma alteração específica e um critério para o novo teste. “Prompt reforçado” não é um critério de encerramento.

6. 6

   6. Repita o caso que falhou e teste suas variações

   Execute novamente o caso original na aplicação corrigida e depois teste variações que busquem o mesmo objetivo. Verifique também a jornada legítima do cliente. Bloquear todos os reembolsos pode fechar o caminho de ataque e, ao mesmo tempo, inutilizar uma função do produto.

   Preserve as evidências de antes e depois, as revisões da aplicação e a configuração dos testes. Incorpore as falhas corrigidas a uma suíte de regressão: verificações que podem ser repetidas para detectar a volta de problemas antigos. Acrescente novos ataques exploratórios separadamente, para que a melhora no conjunto fixo não esconda novas fragilidades.

   Revise o escopo quando houver mudanças no modelo, nas instruções, nas fontes de recuperação de informações, nas permissões, nas ferramentas ou na política do negócio. Libere o lançamento somente quando os impedimentos declarados forem resolvidos ou quando o responsável tiver aceitado explicitamente o risco restante. Um resultado inconclusivo em um limite definido como impeditivo continua em aberto.

Use OWASP, MITRE ATLAS e NIST para funções diferentes

Use os frameworks para organizar o trabalho e depois acrescente as condições de falha específicas da sua aplicação. Nenhum deles fornece sua política de reembolso nem prova que o limite de acesso dos clientes foi respeitado.

O OWASP Top 10 for LLM Applications é uma lista de riscos para aplicações que usam grandes modelos de linguagem, os modelos que geram texto por trás de muitos chatbots. Sua página atual apresenta a lista de 2025, que inclui prompt injection, exposição de informações sensíveis e autonomia excessiva, situação em que o sistema tem capacidade demais para agir. Use-a para identificar categorias de risco ausentes na lista de ataques. Lista oficial da OWASP.

O MITRE ATLAS é uma base de conhecimento em constante atualização sobre táticas e técnicas de adversários envolvendo IA, alimentada por ataques observados e demonstrações realistas. Use-o para descrever como um atacante poderia chegar a um resultado prejudicial e conectar casos isolados em uma sequência plausível. Ele ajuda quem revisa a segurança a entender quais comportamentos o exercício cobriu. MITRE ATLAS.

O AI Risk Management Framework do National Institute of Standards and Technology, ou NIST AI RMF, organiza o trabalho de risco em torno de Governar, Mapear, Medir e Gerenciar. O NIST o descreve como voluntário. Use-o para conectar o teste à atribuição de responsabilidades, ao contexto de implantação, à medição e à decisão sobre os riscos não resolvidos. Um relatório mapeado ao framework não equivale a uma certificação do NIST. NIST AI RMF.

No caso fictício de reembolso, a OWASP ajuda a nomear o risco, o ATLAS ajuda a descrever o caminho adversarial e o AI RMF ajuda a inserir o resultado em um processo de decisão com gestão de risco. Mantenha esse mapeamento junto das evidências, em vez de substituí-las por nomes de frameworks.

Ferramentas de red teaming em IA: quando usar cada uma

Escolha a ferramenta capaz de testar sua aplicação real e preservar as evidências necessárias. Comece com código aberto quando um engenheiro puder assumir a configuração, a avaliação, a investigação e as execuções recorrentes. Considere uma plataforma quando coordenar esse trabalho entre aplicações e revisores se tornar o gargalo.

promptfoo: testes de aplicação que podem ser repetidos

O modo de red teaming do promptfoo gera entradas adversariais por meio de plugins, aplica estratégias de ataque e produz relatórios para examinar falhas. Seu guia de início rápido documenta testes por uma API web, uma interface para chamar a aplicação, além de testes pelo navegador ou diretamente no modelo. Isso o torna um ponto de partida prático para quem desenvolve e quer configurar uma varredura repetível da aplicação. Guia oficial de início rápido de red teaming.

O cuidado operacional está no tratamento de dados: executar a ferramenta localmente não significa que a geração e a avaliação também permaneçam locais. Alguns plugins exigem inferência hospedada, e a avaliação hospedada pode receber prompts e respostas do alvo. Confira os fluxos de dados documentados antes de conectar material de acesso restrito. A análise do promptfoo detalha a configuração e esses limites.

Microsoft PyRIT: fluxos adversariais flexíveis

O Microsoft PyRIT, Python Risk Identification Tool for generative AI, é um framework de código aberto para identificar riscos em sistemas de IA generativa. Sua documentação abrange ataques de um ou vários turnos, alvos personalizados, avaliação e resultados de conversas armazenados, com modos de scanner, interface gráfica e framework. Repositório atual e documentação oficial.

Escolha-o quando o exercício exigir sequências de ataque ou avaliações personalizadas e houver alguém para montar esse fluxo. A contrapartida da flexibilidade é que os critérios de sucesso específicos da aplicação e a integração das evidências ficam por sua conta.

NVIDIA garak: varredura de vulnerabilidades em LLMs

O NVIDIA garak, Generative AI Red-teaming & Assessment Kit, se apresenta como um scanner de vulnerabilidades em LLMs. Ele usa sondas para provocar falhas e detectores para avaliar as saídas, cobrindo áreas como vazamento de dados, prompt injection, toxicidade e jailbreaks. Seu repositório também documenta um conector para endpoints web e logs detalhados dos resultados. Repositório oficial.

Escolha-o para fazer varreduras sistemáticas de um modelo ou endpoint de diálogo. Se a afirmação que você quer verificar envolve uma ação de ferramenta ou registros de clientes, garanta que o alvo e as verificações exponham essas evidências. A avaliação das saídas de um scanner, sozinha, não comprova uma alteração de estado que ele nunca observa. Essa é uma limitação do perímetro do teste, não um motivo para descartar varreduras de modelos.

Airia: quando a operação contínua das campanhas faz diferença

A Airia entra na avaliação de plataformas quando o problema inclui coordenar testes recorrentes de agentes em diferentes fluxos de trabalho. Sua página de red teaming de agentes descreve testes de prompt injection, manipulação de ferramentas e cenários encadeados, incluindo ataques de várias etapas que passam por prompts, ferramentas, APIs e memória. A Airia também descreve campanhas contínuas e achados mapeados a frameworks reconhecidos de segurança. Essas são as capacidades declaradas pelo fornecedor. Página de red teaming de agentes da Airia.

Uma plataforma justifica seu lugar quando reduz o trabalho de conectar aplicações, revisar evidências e acompanhar os achados até a correção. Para uma empresa com vários responsáveis por agentes e avaliações corporativas, isso pode importar mais do que controlar cada componente da execução dos testes.

Condicione a compra a uma demonstração com a aplicação definida no seu escopo: reproduza uma falha conhecida com dados fictícios, examine as evidências da ação relevante, aplique uma correção e execute o caso novamente. Pergunte quais mapeamentos a frameworks e exportações de evidências estão disponíveis para aquela implantação. A descrição pública dos recursos não comprova eficácia de forma independente nem demonstra que todas as integrações necessárias estão cobertas.

Continue com código aberto quando uma suíte administrável e um engenheiro responsável já produzirem as evidências de que os compradores precisam. Contrate uma plataforma quando a operação recorrente e a revisão compartilhada justificarem a escolha, desde que a demonstração atenda ao mesmo padrão. Nenhuma das opções elimina a necessidade de definir o comportamento aceitável.

Que evidências um comprador corporativo deve exigir?

Peça um relatório correspondente à implantação e um exemplo que acompanhe o caminho do achado até o novo teste. “Fazemos red teaming da nossa IA” é uma afirmação sobre processo; o registro que a sustenta deve mostrar o que foi testado e o que mudou por causa disso.

Solicite estes itens em conjunto:

• Escopo e data: identificadores da aplicação e do modelo, instruções relevantes, fontes de recuperação de informações, perfis, ferramentas, integrações e exclusões.
• Cobertura de ataques: objetivos, pontos de entrada, casos de um turno e casos de conversa, além das capacidades do cliente disponíveis a quem realizou os testes.
• Método e avaliação: configuração dos testes, contagem das tentativas, critérios de sucesso, revisão humana e tratamento dos resultados inválidos ou inconclusivos.
• Achados: gravidade, limites afetados, evidências reproduzíveis e limitações não resolvidas, com detalhes sensíveis compartilhados por um canal adequado.
• Correções e novos testes: o controle alterado, as evidências de antes e depois e a confirmação de que o uso legítimo continua funcionando.
• Responsabilidade contínua: quem aceita o risco residual, quais mudanças exigem outra rodada e como os clientes ficam sabendo de achados relevantes que os afetam.

Pergunte se o trabalho foi realizado pelo fornecedor, por um avaliador externo ou por ambos. A independência é um contexto útil, mas o logotipo de um terceiro não preenche um escopo ausente nem cobre um conector que não foi testado.

Se o relatório excluir a integração que você pretende habilitar, trate-a como não avaliada. Peça testes direcionados antes de ativá-la ou restrinja a implantação até que existam as evidências relevantes. Um resultado sem falhas para um chatbot de somente leitura não autoriza, por associação, um agente com permissão de escrita.

Onde estão os exageros?

Um grande volume de ataques não comprova cobertura. Repetir variações contra um endpoint de chat pode deixar de fora a recuperação de informações, a memória e a autorização de ferramentas. A cobertura deve se referir às superfícies e às condições de falha definidas no escopo.

Também é fácil tirar conclusões demais de uma única taxa de aprovação. Geradores de ataque, orçamentos, denominadores e avaliadores diferentes dificultam a comparação de pontuações. Apresente o protocolo e os achados com consequências relevantes junto de qualquer resultado agregado. Não existe um percentual de aprovação universalmente seguro que resolva um vazamento demonstrado de dados de clientes.

Avaliar apenas as recusas é especialmente frágil no caso de agentes. Uma resposta que parece segura pode acompanhar uma ação insegura, enquanto uma chamada de ferramenta bloqueada pode demonstrar que um controle importante funcionou. Examine as evidências antes de classificar o resultado.

Por fim, o red teaming é um dos insumos de um programa de segurança e proteção contra danos. Ele não substitui o QA convencional, os testes de controle de acesso, o monitoramento em produção nem a resposta a incidentes. Uma campanha concluída estabelece o que aconteceu nas condições testadas; não prova a ausência de falhas ainda não descobertas.

Perguntas frequentes sobre red teaming em IA

O que é red teaming em IA?

É um teste adversarial deliberado que busca fazer um sistema de IA violar uma regra de segurança, de proteção contra danos ou do negócio. Em uma aplicação voltada ao cliente, inclua o acesso a dados e o comportamento das ferramentas, além das respostas do modelo.

Qual é a melhor IA para fazer red teaming?

Não existe um modelo atacante ou uma ferramenta que seja a melhor em todos os casos. Escolha um método que alcance os pontos de entrada reais da aplicação e consiga verificar o resultado proibido. promptfoo, Microsoft PyRIT e NVIDIA garak oferecem maneiras diferentes de organizar esse trabalho; nenhum deles fornece automaticamente a política do seu negócio.

Como começar em red teaming de IA?

Comece com uma aplicação que você tenha autorização para testar, dados fictícios e um limite definido por escrito. Aprenda a produzir um achado reproduzível com um resultado esperado claro e depois verifique a correção. Conhecer a aplicação, observar com cuidado e avaliar com rigor vêm antes de ampliar a geração de ataques.

A IA vai substituir os profissionais de red teaming?

Nos testes de sistemas de IA, a automação pode gerar e repetir tentativas, mas pessoas ainda precisam definir quais danos são inaceitáveis, validar os achados e decidir se as evidências sustentam um lançamento. Trate os ataques e as avaliações automatizadas como apoio a esse trabalho, com revisão humana quando houver consequências relevantes.

Qual é um exemplo de red teaming?

Insira uma instrução falsa para dispensar a aprovação de reembolsos em um documento de ajuda fictício usado por um agente de atendimento. Verifique se ele trata o documento como autoridade e se a ferramenta de reembolso permite uma ação não autorizada. Corrija o limite que falhou e execute o caso novamente, junto de um reembolso legítimo e aprovado.

O que fazer agora

Antes da próxima revisão de lançamento, escolha uma jornada de cliente, escreva seus resultados proibidos e designe um responsável pelas correções. Execute a rodada dentro do escopo e leve as evidências para a decisão. Se estiver comprando, peça ao fornecedor que apresente um achado, sua correção e o novo teste para a configuração que você pretende usar.

Assine a newsletter para receber guias práticos sobre desenvolvimento e operação de sistemas de IA.