Capítulo 33 — Segurança de IA e aprendizado de máquina: segurança física e resiliência | Engenharia Segurança de IA e aprendizado de máquina

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

Mapa da aula

Aula 33 publicada. Mapa, exemplo, EX097.

flowchart TD
  N0["33.1 Falha segura"]
  N1["33.2 Resiliência"]
  N2["33.3 Supervisão humana efetiva"]
  N3["33.4 Uso indevido de capacidades generativas"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX097"]

Desenho lógico

flowchart LR
  N0["33.1 Falha segura"]
  N1["33.2 Resiliência"]
  N2["33.3 Supervisão humana efetiva"]
  N3["33.4 Uso indevido de capacidades generativas"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX097"]

[33.1 Falha segura]
    |
    v
[33.2 Resiliência]
    |
    v
[33.3 Supervisão humana efetiva]
    |
    v
[33.4 Uso indevido de capacidades generativas]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX097]

Objetivos de aprendizagem

Você vai (1) projetar sistemas de IA que permaneçam seguros quando componentes falham ou são atacados; (2) aplicar conceitos de resiliência (antecipar, resistir, recuperar, adaptar); (3) definir uma supervisão humana efetiva, e não apenas nominal; e (4) planejar para o uso indevido de capacidades generativas.

33.1 Falha segura

Todo caminho de decisão de IA precisa de um estado seguro definido: inspeção manual, um padrão conservador, recusar uma ação ou escalar para um humano. Casos de segurança argumentam, com evidências, que os perigos estão controlados em níveis aceitáveis — inclusive perigos causados por adversários. Para o TrackEye, o estado seguro é a inspeção manual do trecho afetado; para o Wrench, é recusar a ação de ferramenta e dizer ao técnico por quê. Escolher estados seguros é uma decisão de projeto com custos: a inspeção manual consome tempo da equipe, e as recusas atrasam o trabalho. O caso de segurança declara esses custos e mostra que são aceitáveis, o que também deixa claro o que aconteceria se um atacante forçasse deliberadamente o sistema a entrar repetidamente em seu estado seguro.

33.2 Resiliência

Resiliência é a capacidade de antecipar condições adversas, resistir a elas, recuperar-se delas e adaptar-se a elas. Para a IA: antecipar com modelos de ameaças e monitoramento; resistir com controles em camadas; recuperar com rollback, retreinamento a partir de dados verificados e revogação de credenciais; adaptar atualizando testes e controles após incidentes. O NIST AI RMF lista seguro e resiliente como uma característica da IA confiável. A recuperação depende de uma preparação feita antes. Retreinar a partir de dados verificados só é possível se as versões e os hashes dos dados foram guardados. Revogar credenciais rapidamente exige um procedimento testado e credenciais estreitas que possam ser revogadas sem parar tudo. Adaptar significa que cada incidente deixa um rastro no sistema: um novo teste no conjunto, um limiar alterado ou um runbook atualizado, para que a mesma falha seja menos provável da próxima vez.

33.3 Supervisão humana efetiva

A supervisão falha quando os humanos aprovam por hábito ("viés de automação") ou não têm informação. Uma supervisão efetiva mostra a evidência por trás de uma proposta (fontes, confiança, o que é incomum), limita o volume para que os revisores possam se concentrar e acompanha a qualidade das aprovações (por exemplo, inserindo propostas de teste sabidamente ruins para medir as taxas de detecção, com o consentimento dos revisores e uma política clara). O EU AI Act exige que sistemas de alto risco sejam projetados para uma supervisão humana efetiva (Artigo 14). As propostas sabidamente ruins precisam ser claramente identificáveis depois, para que nunca sejam executadas. Os resultados são compartilhados com os revisores como grupo e nunca usados para classificar indivíduos.

33.4 Uso indevido de capacidades generativas

Sistemas generativos podem ser usados indevidamente para produzir conteúdo nocivo ou para auxiliar ataques. O NIST AI 600-1 discute riscos que incluem segurança da informação e conteúdo perigoso, com ações sugeridas. As respostas de engenharia incluem políticas de uso, monitoramento de abuso, treinamento para recusa, limites de taxa e restrição de capacidades de alto risco a usuários autenticados e responsabilizáveis. Restringir capacidades a usuários autenticados torna o uso indevido atribuível, o que o desestimula e apoia a investigação. Para o Wrench, o risco é modesto, já que suas ferramentas são estreitas, mas um gerador de texto genérico conectado a documentos internos poderia ser solicitado a redigir um phishing convincente usando nomes reais de fornecedores. O monitoramento de abuso procura esses padrões, e as políticas de uso dizem à equipe o que é aceitável antes que alguém precise aplicá-las.

33.5 Exemplo resolvido (caso sintético da NRS)

Sam mediu que os técnicos aprovavam 97% das propostas de ordens de serviço do Wrench em uma mediana de 4 segundos. Com a concordância dos técnicos, um exercício mensal inseriu propostas de teste sintéticas, claramente marcadas, com ativos errados; apenas 60% foram rejeitadas. A equipe redesenhou a tela de aprovação para destacar ativos fora das rotas habituais do técnico e qualquer texto de origem com cara de instrução; a taxa de detecção no exercício seguinte subiu para 88%. A alta taxa de aprovação e a mediana de quatro segundos eram os sinais de alerta, já que ninguém lê um documento de origem em quatro segundos. Uma taxa de detecção de 60% significava que duas em cada cinco propostas erradas teriam sido aprovadas. O redesenho tornou visível a informação importante em vez de pedir às pessoas que se esforçassem mais, e o exercício seguinte mediu o efeito em vez de presumi-lo.

33.6 Erros e limites

Três erros são comuns: revisão humana como mera formalidade; nenhum estado seguro definido; e planos de recuperação que supõem haver dados limpos disponíveis sem que tenham sido guardados. Uma revisão de mera formalidade cria a aparência de controle enquanto aprova quase tudo. Sem um estado seguro definido, um componente com falha pode continuar em um modo inseguro ou parar de um modo não planejado. Planos de recuperação falham no dia em que são necessários se os dados limpos, os modelos assinados ou as credenciais de que dependem nunca foram guardados. Cada um desses pontos é verificado por exercício, e não pela leitura do plano, porque os planos muitas vezes supõem coisas que ninguém testou.

Exercícios

EX097 — Estados seguros. Defina estados seguros para o TrackEye, o Wrench e o Pulse. Rubrica: 3 = inspeção manual, nenhuma ação/escalar, alerta conservador/verificação manual; 2 = dois; 1 = um; 0 = nenhum.
EX098 — Resiliência. Dê uma ação para cada um de antecipar, resistir, recuperar e adaptar para o Wrench. Rubrica: 3 = quatro adequadas; 2 = três; 1 = uma ou duas; 0 = nenhuma.
EX099 — Supervisão. Por que inserir propostas de teste revelou um problema, e o que melhorou a supervisão? Rubrica: 3 = mediu a taxa real de detecção (60%) vs a presumida; destacar o que é incomum e as informações de origem; 2 = parcial; 1 = vago; 0 = nenhum.

Síntese

Segurança física e resiliência partem do princípio de que os controles às vezes vão falhar. Estados seguros, planos de recuperação e uma supervisão humana medida e bem projetada mantêm as falhas limitadas.

Continue estudando — capítulo 33 de 50

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