Planejando o red teaming de IA

O processo de red teaming é uma boa prática no desenvolvimento responsável de aplicações e sistemas que utilizam Large Language Models (LLMs). O Red Teaming complementa o trabalho sistemático de medição e mitigação feito pelos desenvolvedores e ajuda a descobrir e identificar danos. As equipes vermelhas também ajudam a habilitar estratégias de medição para validar a eficácia das mitigações.

Ao planear a sua abordagem para red teaming de LLMs e aplicações habilitadas com IA, considere os seguintes objetivos:

• Certifique-se de que os protocolos adequados de segurança de software são seguidos para a aplicação — a IA não o isenta das práticas tradicionais de segurança
• Teste o modelo base do LLM e determine se existem lacunas nos sistemas de segurança existentes, tendo em conta o contexto da sua aplicação
• Fornecer feedback sobre falhas que os testes revelam para impulsionar melhorias

O processo de red teaming da IA tem quatro fases: recrutar a equipa, desenhar testes adversariais, realizar testes e reportar resultados.

Recrute a equipa vermelha

O sucesso do red teaming da IA depende das pessoas que contratares. Ao selecionar membros da equipa vermelha, siga estes princípios:

• Selecione para experiência e especialização diversificadas: Procure membros da equipa vermelha com diferentes formações, áreas de especialização e casos de uso para o sistema-alvo. Por exemplo, ao sondar um chatbot de saúde, um enfermeiro tem uma abordagem diferente do administrador de sistemas que gere a infraestrutura do chatbot.
• Incluir mentalidades adversariais e benignas: Ao contrário das equipas vermelhas tradicionais compostas apenas por profissionais de segurança, as equipas vermelhas de IA também devem incluir utilizadores comuns. Os utilizadores habituais podem descobrir comportamentos prejudiciais através de padrões naturais de interação que os profissionais de segurança podem não pensar em testar. Por exemplo, um enfermeiro pode convencer um chatbot a divulgar dados confidenciais de pacientes de uma forma que não passaria pela cabeça de um profissional de segurança.
• Atribuir membros da equipa a riscos e funcionalidades específicas: Atribuir membros com expertise específica para analisar tipos específicos de riscos — por exemplo, especialistas em segurança analisam jailbreaks e extração por metaprompt. Para várias rondas, considere rodar as tarefas para trazer novas perspetivas e permitir tempo para adaptação.
• Forneça objetivos claros: Dê a cada membro da equipa instruções claras sobre o objetivo, as funcionalidades do produto a testar, os tipos de questões a investigar, expectativas temporais e como registar resultados.

Forneça uma forma consistente de registar resultados, incluindo a data, um identificador único de reprodutibilidade, o prompt de entrada e uma descrição ou captura de ecrã da saída.

Testes Adversariais de Design

Como uma aplicação é construída usando um modelo base, teste em ambas as camadas:

• O modelo base do LLM com o seu sistema de segurança implementado, normalmente através de um endpoint API, para identificar lacunas que precisam de ser resolvidas no contexto da sua aplicação
• A aplicação habilitada por IA através da sua interface de utilizador, para testar todo o sistema, incluindo mecanismos de segurança ao nível da aplicação

Os jogadores da equipa vermelha devem testar ambas as camadas antes e depois de as mitigações estarem implementadas.

Realizar testes

Comece por testar o modelo base para compreender a superfície de risco e orientar o desenvolvimento da mitigação. Teste iterativamente, com e sem mitigantes, para avaliar a sua eficácia. Utilize tanto a abordagem de equipas vermelhas manuais como medições sistemáticas, e teste tanto quanto possível na interface de produção para replicar o uso em condições reais.

Estrutura os teus testes em torno destas atividades:

Determinar a extensão do dano

Comece com políticas organizacionais sobre confiança e segurança ou IA responsável, juntamente com regulamentos de conformidade. Trabalhe com as suas equipas jurídicas e de políticas para identificar os prejuízos mais importantes desta aplicação. O resultado é uma lista prioritária de danos com exemplos.

Os membros criativos da equipa vermelha frequentemente encontram danos que não foram previstos pelas políticas organizacionais. Várias organizações sofreram danos reputacionais quando o público descobriu resultados problemáticos em IA que não foram testados. Uma equipa vermelha criativa tem mais probabilidade de descobrir estes problemas antes do lançamento.

Estenda a lista através de testes abertos

Complemente a lista orientada por políticas com os danos encontrados através da exploração criativa. Priorize os danos para testes iterativos com base na gravidade e no contexto em que provavelmente irão aparecer. Adicione cada dano recém-descoberto à lista principal para futuras rondas de teste.

Teste novamente após a aplicação de mitigações

Teste a lista completa de danos conhecidos com medidas de mitigação em vigor. Pode descobrir novos danos ou descobrir que as medidas de mitigação existentes são insuficientes. Atualize a lista de danos e esteja aberto a mudanças de prioridades com base nos resultados.

Automatizar em escala

O red teaming manual é essencial, mas difícil de ampliar. Complemente-o com ferramentas automatizadas de red teaming — estruturas que automatizam a análise adversarial de modelos e aplicações de IA. Por exemplo, a ferramenta de código aberto Python Risk Identification Tool (PyRIT) fornece:

1. Varreduras automáticas: Simula sondagens adversariais usando prompts iniciais selecionados por categoria de risco, com estratégias de ataque que evitam alinhamentos de segurança
2. Pontuação: Gera uma Taxa de Sucesso de Ataque (ASR) — a percentagem de ataques bem-sucedidos — dando-lhe uma postura de risco quantificável
3. Relatórios: Produz scorecards de técnicas de ataque e categorias de risco, monitorizados ao longo do tempo para cumprimento e monitorização contínua

Para agentes de IA, especificamente, as ferramentas automatizadas podem testar categorias de risco difíceis de alcançar apenas através de testes manuais de prompt, incluindo ações proibidas, vazamento de dados sensíveis em chamadas de ferramentas e cumprimento de tarefas.

Executar ferramentas automatizadas num ambiente não de produção configurado com recursos semelhantes à produção. Utilize-os como complemento aos testes manuais — a automação revela riscos em grande escala, enquanto especialistas humanos fornecem análises mais profundas.

Comunicar resultados

Adote uma abordagem estratégica na recolha de dados para evitar sobrecarregar os red teamers captando as informações essenciais. Para exercícios mais pequenos, uma folha de cálculo partilhada funciona bem. Para testes sistemáticos em escala, ferramentas automatizadas fornecem recolha estruturada de resultados e métricas.

Partilhe relatórios regulares com as principais partes interessadas, incluindo:

• As principais questões identificadas
• Um link para os dados brutos
• O plano de testes para as próximas rondas
• Reconhecimento dos jogadores da equipa vermelha

Esclareça que o red teaming expõe e aumenta a compreensão da superfície de risco — não substitui a medição sistemática e o trabalho rigoroso de mitigação. Os leitores não devem interpretar exemplos específicos como uma métrica da presença generalizada desse dano.