◇ OpenCyber Academy
Engenharia · Capítulo 41 · Português

Capítulo 41 — Segurança de IA e aprendizado de máquina: otimização do sistema

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 41 — Segurança de IA e aprendizado de máquina: otimização do sistema

Mapa da aula

Aula 41 publicada. Mapa, exemplo, EX121.

flowchart TD
  N0["41.2 Ajuste de limiares"]
  N1["41.3 Posicionando controles"]
  N2["41.4 Lei de Goodhart"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX121"]

Desenho lógico

flowchart LR
  N0["41.2 Ajuste de limiares"]
  N1["41.3 Posicionando controles"]
  N2["41.4 Lei de Goodhart"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX121"]

[41.2 Ajuste de limiares]
    |
    v
[41.3 Posicionando controles]
    |
    v
[41.4 Lei de Goodhart]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX121]

Objetivos de aprendizagem

Você vai (1) otimizar um sistema de IA considerando segurança, segurança física, utilidade e custo; (2) usar raciocínio multiobjetivo (fronteiras de Pareto) em vez de métricas únicas; (3) ajustar limiares e a posição dos controles com base em dados; e (4) evitar otimizar as métricas de segurança até que percam o sentido.

41.1 Otimização multiobjetivo

Melhorias de segurança costumam custar utilidade, latência ou dinheiro. Plote as alternativas em dois ou mais eixos (por exemplo, sucesso de ataque versus sucesso na tarefa) e identifique a fronteira de Pareto: as opções para as quais nenhuma outra é melhor em todos os eixos. Quem decide escolhe então um ponto na fronteira usando prioridades explícitas. Uma opção é dominada quando outra é pelo menos tão boa em todos os eixos e melhor em um; opções dominadas podem ser descartadas sem debate. A própria fronteira costuma conter várias opções, cada uma abrindo mão de algo diferente. A engenharia pode mostrar a fronteira com clareza, mas escolher entre seus pontos é um julgamento de prioridades, então cabe aos responsáveis.

41.2 Ajuste de limiares

Detectores e modelos de anomalia têm limiares. Escolha-os com um modelo de custo: custo de um ataque não detectado × sua probabilidade versus custo de um alarme falso × sua probabilidade, a taxas de base realistas. Ajuste em dados de validação, nunca no conjunto de teste final, e reveja à medida que as taxas de base mudam. Os dados de validação precisam refletir a taxa de base esperada em operação, ou o limiar escolhido estará errado em serviço. Um limiar definido quando os ataques eram raros pode produzir enxurradas de alertas durante uma campanha, ou deixar passar demais se os atacantes se adaptarem. Sam registra as premissas de custo com cada limiar, de modo que uma mudança posterior na taxa de base ou no custo de uma omissão provoque um reajuste deliberado.

41.3 Posicionando controles

O lugar onde um controle fica muda seu custo e seu efeito. Rodar um classificador de injeção apenas sobre o conteúdo recuperado não confiável (em vez de sobre todas as mensagens) corta o custo e mantém a cobertura do caminho arriscado. Colocar confirmação apenas em ações de alto impacto reduz o atrito. Otimizar significa colocar controles fortes nos caminhos de alto risco e controles leves no restante. O princípio decorre da análise de fluxo de dados: o risco se concentra onde a entrada não confiável encontra uma ação privilegiada. Aplicar controles pesados em toda parte desperdiça orçamento e irrita os usuários sem acrescentar muita proteção, enquanto controles leves no caminho arriscado o deixam aberto. Mover o classificador para o conteúdo recuperado, no capítulo sobre desempenho, é um exemplo: o custo caiu bastante e a cobertura do caminho não confiável continuou a mesma.

41.4 Lei de Goodhart

Quando uma medida se torna uma meta, deixa de ser uma boa medida. Equipes que otimizam um benchmark fixo de jailbreak podem se sobreajustar a ele enquanto a robustez real não melhora. Mantenha conjuntos reservados e renovados, faça red teaming periodicamente e acompanhe várias métricas. Uma equipe recompensada por um número decrescente de sucesso de ataque em um único benchmark pode acrescentar filtros para suas frases exatas, melhorando a pontuação sem tornar o sistema mais difícil de atacar. Conjuntos reservados e renovados quebram esse vínculo, já que a equipe não consegue se ajustar a testes que não viu. Acompanhar várias métricas também ajuda, porque manipular uma costuma piorar outra, como as recusas indevidas ou o sucesso na tarefa.

41.5 Exemplo resolvido (caso sintético da NRS)

Sam avaliou cinco configurações do Wrench quanto ao sucesso de ataque (conjunto de injeção) e ao sucesso na tarefa (conjunto de planejamento): A (sem controles) 31%/95%; B (classificador bloqueando) 9%/86%; C (política + confirmação) 0,0% de execuções/93%; D (C + classificador sinalizando) 0,0%/93%, com melhor foco dos revisores; E (modelo duplo + C) 0,0%/90%. B é dominada por C. D foi escolhida: o mesmo sucesso na tarefa que C, mais sinalizações que melhoraram as taxas de detecção dos revisores. B bloqueia alguns ataques, mas é a que mais custa em sucesso na tarefa, o que explica por que C a domina: nenhuma execução e sucesso na tarefa maior. O modelo duplo de E acrescenta uma proteção já fornecida por C, a um custo adicional de três pontos. D acrescenta sinalizações sobre C sem custo em sucesso na tarefa, e é por isso que vence.

41.6 Erros e limites

Três erros são comuns: otimizar um único número; ajustar limiares nos dados de teste; e benchmarks que nunca mudam. Otimizar um único número o melhora às custas de tudo o que não é medido. Limiares ajustados nos dados de teste parecem perfeitos no relatório e decepcionam em serviço. Benchmarks que nunca mudam são aprendidos pelo sistema e por seus desenvolvedores, até que uma pontuação alta mostre familiaridade, e não robustez. Sam exige que todo relatório de otimização mostre pelo menos uma métrica de segurança e uma métrica de custo em um conjunto reservado. As duas aparecem em um único gráfico.

Exercícios

Síntese

A otimização em segurança de IA é multiobjetivo: encontre a fronteira de Pareto, ajuste limiares com modelos de custo, posicione controles conforme o risco e proteja-se contra a manipulação das suas próprias métricas.

Continue estudando — capítulo 41 de 50

← Capítulo 40 (rascunho) · Índice de capítulos do curso · Capítulo 42 (rascunho) →