Nos últimos meses, governos de todo o mundo começaram a convergir em torno de uma solução para gerir os riscos da IA ​​generativa: red teaming.

No final de outubro, a administração Biden divulgou a sua abrangente ordem executiva sobre IA. Entre seus requisitos mais importantes está que certos modelos de IA generativos de alto risco sejam submetidos a “red teaming”, que define vagamente como “um esforço de teste estruturado para encontrar falhas e vulnerabilidades em um sistema de IA”. Isso aconteceu alguns meses depois que o governo organizou um evento formal de equipe vermelha de IA que atraiu milhares de hackers.

O foco na equipe vermelha é um desenvolvimento positivo. A equipe vermelha é uma das maneiras mais eficazes de descobrir e gerenciar os riscos da IA ​​generativa. Existem, no entanto, uma série de barreiras importantes à implementação do red teaming na prática, incluindo a clarificação do que realmente constitui um red team, a padronização do que essa equipa faz enquanto testa o modelo e a especificação de como os resultados são codificados e divulgados quando os testes terminam.

Cada modelo tem uma superfície de ataque, vulnerabilidades e ambientes de implantação diferentes, o que significa que não há dois esforços de red teaming exatamente iguais. Por esse motivo, a formação de equipes vermelhas consistente e transparente tornou-se um desafio central na implantação de IA generativa, tanto para os fornecedores que desenvolvem modelos fundamentais quanto para as empresas que ajustam e colocam esses modelos em uso.

Este artigo tem como objetivo abordar essas barreiras e resumir minha experiência em red teaming de vários sistemas generativos de IA diferentes. Meu escritório de advocacia, Luminos.Law, formado em conjunto por advogados e cientistas de dados, concentra-se exclusivamente no gerenciamento de riscos de IA. Depois de contratarmos para a equipe vermelha alguns dos modelos de IA generativa de maior perfil e amplamente adotados, descobrimos o que funciona e o que não funciona quando a equipe vermelha forma IA generativa. Aqui está o que aprendemos.

O que é IA generativa de equipe vermelha?

Apesar do crescente entusiasmo pela atividade, não há um consenso claro sobre o que a IA generativa de red teaming significa na prática. Isto apesar do facto de algumas das maiores empresas de tecnologia terem começado a abraçar publicamente o método como um componente central da criação de IA generativa confiável.

O próprio termo foi popularizado durante a Guerra Fria e começou a ser formalmente integrado nos esforços de planeamento de guerra pelo Departamento de Defesa dos EUA. Nos exercícios de simulação, as chamadas equipas vermelhas foram encarregadas de agir como adversários soviéticos (daí o termo “vermelho”), enquanto as equipas azuis foram incumbidas de agir como os Estados Unidos ou os seus aliados. À medida que os esforços de segurança da informação amadureceram ao longo dos anos, a comunidade de segurança cibernética adoptou a mesma linguagem, aplicando o conceito de red teaming aos testes de segurança para sistemas de software tradicionais.

A IA generativa de red teaming é muito diferente da red teaming de outros sistemas de software, incluindo outros tipos de IA. Ao contrário de outros sistemas de IA, que normalmente são usados ​​para tomar uma decisão – como quem contratar ou que classificação de crédito alguém deveria ter – os sistemas de IA generativos produzem conteúdo para seus usuários. A interação de qualquer usuário com um sistema generativo de IA pode criar um enorme volume de texto, imagens ou áudio.

Os danos criados pelos sistemas de IA generativa são, em muitos casos, diferentes de outras formas de IA, tanto no âmbito como na escala. A IA generativa da equipe vermelha é projetada especificamente para gerar conteúdo prejudicial que não tem análogo claro nos sistemas de software tradicionais – desde a geração de estereótipos humilhantes e imagens gráficas até mentiras descaradas. Na verdade, os danos que as equipes vermelhas tentam gerar estão mais comumente associados a humanos do que a software.

Na prática, isso significa que as formas como as equipes vermelhas interagem com os próprios sistemas de IA generativa são únicas: elas devem se concentrar na geração de prompts maliciosos, ou entradas no modelo, além de testes usando código mais tradicional, a fim de testar a capacidade do sistema de produzir comportamento prejudicial ou inadequado. Existem várias maneiras de gerar esses tipos de prompts maliciosos – desde alterar sutilmente os prompts até simplesmente pressionar o modelo para gerar resultados problemáticos. A lista de maneiras de atacar efetivamente a IA generativa é longa e cresce a cada dia.

Quem deve formar a equipe vermelha da IA?

Assim como a própria definição de red teaming, não há um consenso claro sobre como cada red team deve ser construída. Por isso, uma das primeiras questões que as empresas devem abordar é se a equipe vermelha deve ser interna ou externa à empresa.

Empresas, incluindo o Google, que criaram suas próprias equipes vermelhas de IA agora defendem equipes vermelhas internas , nas quais funcionários com vários tipos de experiência simulam ataques ao modelo de IA. Outros, como a OpenAI, adotaram o conceito de red teaming externo, chegando ao ponto de criar uma rede externa para incentivar a adesão de membros externos. Determinar como devem ser constituídas as equipas vermelhas de IA é uma das tarefas que a administração Biden confiou aos chefes das agências federais, que deverão responder à questão no próximo ano num próximo relatório.

Então, o que dizemos aos nossos clientes? Para começar, não existe uma abordagem única para a criação de equipes vermelhas para IA generativa. Aqui estão algumas diretrizes gerais.

Devido à grande escala dos sistemas de IA que muitas empresas estão adotando, seria impossível formar uma equipe totalmente vermelha para cada uma delas. Por esse motivo, a chave para uma equipe vermelha eficaz reside na triagem de riscos de cada sistema. Pedimos aos nossos clientes para atribuir diferentes níveis de risco a diferentes modelos – com base, por exemplo, na probabilidade de o dano ocorrer, na gravidade do dano, caso ocorra, ou na capacidade de retificar o dano assim que for detectado. (Essas são métricas comumente aceitas para definição de risco.) Diferentes níveis de risco podem então ser usados ​​para orientar a intensidade de cada esforço da equipe vermelha: o tamanho da equipe vermelha, por exemplo, ou o grau em que o sistema é testado, ou mesmo se for testado.

Utilizando esta abordagem, os modelos de menor risco devem ser sujeitos a testes menos exaustivos. Outros modelos podem exigir testes internos, mas nenhuma revisão de especialistas externos, enquanto os sistemas de maior risco normalmente exigem equipes vermelhas externas. As partes externas focadas na IA generativa de red teaming provavelmente terão níveis mais elevados de experiência em red teaming e, portanto, serão capazes de descobrir mais vulnerabilidades. As análises externas podem demonstrar um padrão razoável de cuidado e também reduzir a responsabilidade, documentando que partes externas aprovaram o sistema de IA generativo.

Objetivos de Degradação

Compreender quais danos as equipes vermelhas devem visar é extremamente importante. Selecionamos o que chamamos de “objetivos de degradação” para orientar nossos esforços e iniciamos nossa equipe vermelha avaliando quais tipos de comportamento modelo prejudicial gerarão a maior responsabilidade.

Os objectivos de degradação são tão críticos porque, a menos que sejam claramente definidos e mapeados para as responsabilidades mais significativas que cada sistema representa, o red teaming é quase sempre mal sucedido ou, na melhor das hipóteses, incompleto. Na verdade, sem uma organização adequada, as red teaming são muitas vezes conduzidas sem um plano coordenado para gerar danos específicos, o que leva a ataques ao sistema e a nenhuma conclusão estratégica clara e exequível. Embora este tipo de red teaming possa criar a aparência de testes abrangentes, uma investigação desorganizada deste tipo pode ser contraproducente, criando a impressão de que o sistema foi totalmente testado quando ainda existem grandes lacunas.

Juntamente com uma avaliação clara dos riscos e responsabilidades, também é uma boa prática alinhar os objetivos de degradação com incidentes conhecidos de sistemas de IA generativos semelhantes. Embora existam várias maneiras diferentes de rastrear e comparar incidentes passados, o banco de dados de incidentes de IA é um excelente recurso (e no qual confiamos fortemente).

Aqui estão alguns objetivos comuns de degradação de nossos esforços anteriores de red teaming:

Ajudar os usuários a se envolverem em atividades ilícitas

Os utilizadores podem tirar partido dos sistemas generativos de IA para ajudar a realizar uma série de atividades prejudiciais e, em muitos casos, gerar responsabilidades significativas para as empresas que implementam o sistema de IA no processo. Se não existirem salvaguardas suficientes contra este tipo de comportamento modelo, as empresas podem acabar por partilhar a responsabilidade pelos danos finais. No passado, testamos danos que vão desde instruções para a fabricação de armas e drogas até o desempenho de contabilidade fraudulenta e o modelo que realiza campanhas de hackers automatizadas.

Viés no modelo

A IA em geral pode gerar ou perpetuar todos os tipos de preconceitos, como já escrevi aqui antes, o que, por sua vez, pode levar a muitos tipos diferentes de responsabilidades ao abrigo da lei anti-discriminação. A Comissão Federal de Comércio dos EUA tem dedicado muita atenção à questão da injustiça na IA ao longo dos últimos anos, tal como os legisladores, sinalizando que está a surgir mais responsabilidade nesta área. Podem surgir preconceitos no resultado do modelo, como a representação injusta de diferentes grupos demográficos no conteúdo gerado pela IA, bem como no próprio desempenho do modelo, como o desempenho diferente para membros de grupos diferentes (falantes nativos de inglês vs. falantes não nativos, por exemplo). exemplo).

Toxicidade

A toxicidade na IA generativa surge com a criação de conteúdo ofensivo ou impróprio. Este problema tem uma longa história na IA generativa, como quando o chatbot Tay começou a gerar publicamente resultados racistas e sexistas. Como os modelos de IA generativa são moldados por grandes quantidades de dados extraídos da Internet – um lugar não conhecido pelo seu decoro – o conteúdo tóxico assola muitos sistemas de IA generativa. Na verdade, a toxicidade é um problema tão grande que deu origem a todo um novo campo de estudo na investigação da IA, conhecido como “ desintoxicação ”.

Danos à privacidade

Existem várias maneiras pelas quais os modelos generativos de IA podem criar danos à privacidade. Às vezes, informações de identificação pessoal estão contidas nos próprios dados de treinamento, que podem ser hackeados por usuários adversários. Outras vezes, informações confidenciais de outros usuários podem ser vazadas pela modelo de forma não intencional, como ocorreu com o chatbot sul-coreano Lee Luda . Os modelos de IA generativa podem até violar diretamente as políticas de privacidade da empresa, como dizer falsamente aos utilizadores que têm acesso limitado aos seus dados e, assim, envolver-se em fraudes.

A lista de objectivos de degradação é muitas vezes longa, variando desde os objectivos descritos acima até danos como violação de propriedade intelectual, violações contratuais e muito mais. À medida que os sistemas generativos de IA são implantados num número crescente de ambientes, desde os cuidados de saúde até ao jurídico e financeiro, essa lista provavelmente crescerá ainda mais.

Ataques à IA generativa

Depois de determinarmos a composição da equipe vermelha, as responsabilidades e os objetivos de degradação associados para orientar os testes, começa a parte divertida: atacar o modelo.

Há uma grande variedade de métodos que as equipes vermelhas podem usar. Na Luminos.Law, dividimos nossos planos de ataque em duas categorias: manual e automatizado. Vamos nos concentrar principalmente nos ataques manuais aqui, mas vale a pena notar que um grande conjunto de pesquisas e ferramentas emergentes tornam os ataques automatizados uma parte cada vez mais importante do red teaming. Existem também muitos conjuntos de dados de código aberto diferentes que podem ser usados ​​para testar esses sistemas. ( Aqui está um artigo que fornece uma visão geral de muitos desses conjuntos de dados.)

Uma estratégia de ataque eficaz envolve mapear cada objetivo para os ataques que acreditamos terem maior probabilidade de sucesso, bem como os vetores de ataque através dos quais planejamos testar o sistema. Os vetores de ataque podem ser “diretos”, consistindo em interações diretas e relativamente curtas com o modelo, enquanto outros envolvem ataques mais complexos, chamados de injeção indireta imediata, nos quais códigos ou instruções maliciosas podem estar contidos em sites ou outros arquivos que o sistema possa ter. acesso a.

Embora a lista a seguir não inclua todas as técnicas que usamos, ela fornece um exemplo de como gostamos de abordar os ataques durante o red teaming:

• Injeção de código.  Usamos código de computador, ou prompts de entrada que se assemelham a código de computador, para fazer com que o modelo gere resultados prejudiciais. Este método é um dos nossos favoritos precisamente porque tem uma taxa de sucesso surpreendentemente elevada, como demonstrou recentemente um grupo de investigadores .
• Esgotamento de conteúdo.  Usamos grandes volumes de informações para sobrecarregar o modelo.
• Hipoteticamente.  Instruímos o modelo a criar resultados com base em instruções hipotéticas que, de outra forma, acionariam controles de conteúdo.
• Prós e contras.  Perguntamos sobre os prós e os contras de temas polêmicos para gerar respostas prejudiciais.
• Interpretação de papéis.  Direcionamos o modelo para assumir o papel de uma entidade normalmente associada a declarações negativas ou controversas e, em seguida, incitamos o modelo a criar conteúdo prejudicial.

Existem, é claro, dezenas de estratégias de ataque para sistemas generativos de IA — muitas das quais, na verdade, já existem há anos . A metodologia de ataque de crowdsourcing, sempre que possível, também é uma prática recomendada quando se forma red teaming, e há vários recursos on-line diferentes que os red teamers podem usar para se inspirar, como repositórios específicos do Github onde os testadores refinam e compartilham ataques bem-sucedidos. A chave para testes eficazes reside no mapeamento de cada estratégia para o objetivo de degradação, vetor de ataque e, claro, tomar notas abundantes para que ataques bem-sucedidos possam ser capturados e estudados posteriormente.

Juntando tudo

A IA generativa de equipes vermelhas é complicada – geralmente envolvendo equipes diferentes, cronogramas concorrentes e muitos tipos diferentes de experiência. Mas as dificuldades que as empresas enfrentam não estão apenas relacionadas com a formação da equipa vermelha, com o alinhamento das principais responsabilidades, com a definição de objetivos claros de degradação e com a implementação das estratégias de ataque corretas. Vemos vários outros problemas que muitas vezes atrapalham as empresas.

Documentação

O red teaming bem-sucedido muitas vezes envolve testar centenas de estratégias de ataque. Se ataques automatizados forem usados, esse número pode chegar a milhares. Com tantas variáveis, estratégias de teste, membros da equipe vermelha e muito mais, pode ser difícil acompanhar as informações geradas e garantir que os resultados dos testes sejam digeríveis. Ter uma orientação clara não apenas sobre como testar, mas também sobre como documentar cada teste é uma parte crítica, embora muitas vezes esquecida, do processo de red teaming.

Embora cada organização e equipe vermelha sejam diferentes, resolvemos esse problema para nosso escritório de advocacia criando nossos próprios modelos personalizados para orientar nossos testes e apresentar nossa análise final aos nossos clientes. Saber que a documentação final está alinhada com as informações capturadas durante os testes em tempo real torna o processo de red teaming significativamente mais eficiente.

Privilégio legal

Com tantas informações confidenciais sendo geradas entre testadores e equipes, entender onde e quando reivindicar privilégio legal é outra questão frequentemente esquecida, mas uma consideração importante. Muitas vezes vemos responsabilidades potenciais sendo discutidas abertamente em lugares como o Slack, o que torna essas informações detectáveis ​​por partes adversárias se ocorrer supervisão externa, como uma investigação regulatória ou ação judicial.

A última coisa que as empresas querem é aumentar os seus riscos porque estavam a red teaming nos seus modelos. Envolver advogados e determinar cuidadosamente onde as informações sobre os resultados dos testes podem ser comunicadas e como é uma consideração importante.

O que fazer com vulnerabilidades

Ter planos claros para abordar as vulnerabilidades que os esforços de red teaming descobrem é outra parte central, mas muitas vezes esquecida, do processo de red teaming. Quem das equipes de produto ou de ciência de dados é responsável por agir? Eles se reúnem diretamente com a equipe vermelha ou por meio de um intermediário? Eles tentam corrigir as vulnerabilidades enquanto o red teaming está ocorrendo ou devem esperar até o final do processo?

Essas questões, e muitas outras, precisam ser abordadas antes que ocorra o red teaming; caso contrário, a detecção de vulnerabilidades no modelo provavelmente criará muita confusão.

Este artigo fornece apenas uma visão geral de alto nível de todas as considerações necessárias para tornar a IA generativa de red teaming bem-sucedida. É uma das formas mais eficazes de gerir os riscos complexos da tecnologia e, por esse motivo, os governos estão apenas a começar a perceber os benefícios do red teaming. As empresas que apostam alto na IA generativa devem estar igualmente comprometidas com o red teaming.