Unidade 6 / 11

Gerenciamento de risco de modelo e equipe vermelha

Ganhos:

  • Capacidade de classificar cenários de uso em níveis de risco baixo/médio/alto de acordo com o impacto
  • Capacidade de testar sistematicamente o modelo antes da produção com red-teaming
  • Capacidade de tomar decisões de produção com cartão modelo e porta de aceitação (passar/não passar)

Nem todo uso de IA acarreta o mesmo risco. Um assistente resumindo uma nota de reunião e um assistente avaliando um pedido de empréstimo produzem resultados muito diferentes. A base da governança corporativa é classificar os usos de acordo com o nível de risco e aplicar o controle adequado a cada nível. Nesta unidade, aprenderemos a estrutura de gerenciamento de risco de modelo (a disciplina de gerenciamento do risco causado por um modelo ser incorreto, tendencioso ou explorável), como testar o modelo antes da produção com red-teaming e o cartão de modelo e critérios de aceitação.

Classificação por Risco

O primeiro passo é sempre o mesmo: “O que acontece se esse uso der errado?” Três níveis aproximados de acordo com potência e reversibilidade:

  • Baixo risco: O erro é facilmente detectado e desfeito; Sem consequências pessoais/financeiras. Exemplo: resumo da reunião interna, geração de rascunhos de ideias.
  • Risco médio: O erro afeta o processo de negócios, mas passa pelo olho humano. Exemplo: rascunho da resposta ao cliente, resumo do relatório preliminar.
  • Alto risco: A decisão afeta diretamente uma pessoa/dinheiro, difícil de reverter. Exemplo: decisão de crédito/seguro, triagem de saúde, triagem de emprego.

A intensidade do controle aumenta com o nível de risco: em risco baixo, controles leves são suficientes; Em alto risco, a supervisão humana, a verificação rigorosa, a formação de equipes vermelhas e o monitoramento constante são obrigatórios.

Atenção: Faça classificação de risco de acordo com o efeito do uso e não com o nome. O chamado sistema “apenas um chatbot” é de alto risco se puder iniciar pagamentos.

Equipe Vermelha (Equipe Vermelha)

A equipe vermelha está tentando deliberadamente quebrar um sistema fingindo ser um invasor mal-intencionado. Isso está na IA; Inclui jailbreak (ignorando as regras de segurança do modelo), injeção imediata, exfiltração de dados, geração de resultados tendenciosos/maliciosos e teste de cenários de borda. O objetivo é encontrar vulnerabilidades antes do verdadeiro invasor.

Passo a passo:

  1. Liste cenários de ameaças. Como esse sistema pode ser abusado?
  2. Prepare o conjunto de ataque. Escreva exemplos concretos de entrada para cada ameaça.
  3. Tente sistematicamente. Execute cada cenário e registre o resultado.
  4. Priorize as descobertas. Classifique por impacto × probabilidade.
  5. Corrija e teste novamente. Após o patch, tente novamente com o mesmo conjunto (regressão).

Cartão Modelo e Critérios de Aceitação

Um cartão de modelo é um documento que resume para que um modelo é adequado, suas limitações, riscos conhecidos e desempenho. Antes de colocá-lo em produção, você deve ter critérios para uma decisão de aceitação: limite de precisão, taxa de aprovação da equipe vermelha, latência, custo e testes de viés.

Quatro modelos copiáveis

Solicitação de classificação de risco:

Considere o seguinte caso de uso: {{ cenário }}Perguntas:- Quem/o que o bug afeta? (pessoa, dinheiro, reputação, harmonia)- É reversível? (sim/não) - Os humanos podem intervir? Resultado: “Risco Baixo/Médio/Alto” ​​+ lista de verificações obrigatórias.

Gerador de conjunto de ataque da equipe vermelha:

Você é um especialista da equipe vermelha. Gere 15 cenários de ataque para o seguinte assistente: 5 jailbreaks, 5 injeções imediatas (3 das quais indiretas), 5 tentativas de exfiltração de dados. Para cada cenário: escreva o propósito, o texto de introdução completo e os "critérios de sucesso" (tudo o que vejo conta o ataque como bem-sucedido).

Esqueleto da placa modelo:

Cartão modelo: - Uso pretendido/uso não intencional - Limites de treinamento/dados e vulnerabilidades conhecidas - Desempenho: precisão, latência, custo (no conjunto de teste) - Segurança: taxa de aprovação da equipe vermelha, jailbreaks conhecidos - Resultados de testes tendenciosos - Decisão de aceitação: APROVAÇÃO / CONDICIONAL / REJEIÇÃO + justificativa

Regra de controle do portão de admissão:

TODAS as condições devem ser atendidas para passar para a produção: - >= limite alvo no conjunto de testes de precisão - Contagem de descobertas críticas da equipe vermelha = 0 - Se alto risco: inspeção humana e painel de monitoramento Se nenhum for atendido: "NÃO-GO" + item faltante.

Alerta Fraco/Prompt Forte

abordagem pobre

Abordagem forte

Processando cada uso com o mesmo controle

Classifique por risco e controle de escala

"Nós testamos, funciona" (maneira feliz)

Tentativa de ruptura deliberada com o time vermelho

Colocar o modelo em produção sem justificativa

Modelo de cartão + portão de aceitação (go/no-go)

Não testar novamente após o patch

Teste de regressão após correção

Três Mini Estojos

Caso 1 — A classificação incorreta custou caro. Uma empresa considerou a pré-seleção de recrutamento “apenas um complemento” e considerou-a de baixo risco. O modelo eliminou sistematicamente os formandos de determinadas escolas; isso se transformou em uma queixa de discriminação. O uso foi reclassificado como “alto risco” e foram adicionados testes de viés e monitoramento humano.

Caso 2 — A equipe vermelha encontrou 3 vulnerabilidades críticas. Um assistente de cliente foi designado para a equipe vermelha antes de entrar em produção. 3 dos 15 cenários foram bem-sucedidos: as informações do pedido de outro cliente poderiam vazar por meio de injeção indireta. As lacunas foram fechadas e testadas novamente com o mesmo conjunto; A produção foi retomada somente quando a descoberta crítica foi redefinida.

Caso 3 — A modelo esclareceu a decisão de aceitar o cartão. Escolhendo entre dois modelos, uma equipe colocou cartões de modelo lado a lado. O modelo mais barato atingiu o alvo em precisão, mas foi vulnerável a 2 jailbreaks críticos no time vermelho. A equipe escolheu o modelo caro, mas seguro, devido à regra do portão de aceitação “descoberta crítica = 0” e documentou a decisão.

Dica: o time vermelho não é um evento único. Execute novamente o conjunto de ataques sempre que o modelo, o prompt ou as ferramentas mudarem; A segurança não é um estado, mas uma prática contínua.

Erros comuns

  • Classifique o uso por nome (em vez de efeito); confundindo alto risco com baixo.
  • Apenas testando o “caminho feliz” e não tentando o abuso.
  • Fazer o time vermelho uma vez e não repetir após trocas.
  • Colocar o modelo em produção sem cartão de modelo e critérios de aceitação.
  • Ignorar testes de preconceito/discriminação (especialmente em decisões humanas de alto risco).
  • Significa "fechado" sem fazer testes de regressão pós-correção.

Em resumo

  • O primeiro passo é classificar os usos como de baixo/médio/alto risco de acordo com o impacto; A intensidade do controle aumenta com o risco.
  • A equipe vermelha está tentando deliberadamente quebrar o sistema como um invasor; encontra a vulnerabilidade antes do verdadeiro invasor.
  • O cartão modelo documenta a finalidade, as limitações e os riscos do modelo; é a base para a decisão de admissão.
  • A transição para a produção deve estar vinculada a uma decisão de avançar/não avançar: precisão, resultado crítico zero, monitoramento necessário.
  • A segurança é contínua: red teaming e testes de regressão são repetidos a cada mudança.

Tarefa de aplicativo

Escolha o uso de uma IA, determine o nível de risco com base no impacto e escreva a justificativa. Em seguida, gere pelo menos 10 cenários de ataque para esse uso (jailbreak, injeção, exfiltração de dados) e experimente-os manualmente. Para cada ataque bem-sucedido, proponha uma solução. Por fim, preencha um modelo de cartão e tome uma decisão "GO/NO-GO" com os motivos.

lista de verificação

  • [ ] Classifiquei o uso de acordo com o nível de risco de acordo com o efeito.
  • [ ] Combinei a intensidade do controle com o nível de risco.
  • [] Preparei um conjunto de ataque do time vermelho e tentei sistematicamente.
  • [] Corrigi as descobertas críticas e as verifiquei com testes de regressão.
  • [ ] Preparei um cartão modelo (finalidade, limite, desempenho, segurança).
  • [] Eu vinculei a decisão de produção a um sim/não.