Capítulo 21 — Segurança de IA e aprendizado de máquina: requisitos | 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 21 publicada. Mapa, exemplo, EX061.

flowchart TD
  N0["21.1 De casos de abuso a requisitos"]
  N1["21.2 Tipos de requisito"]
  N2["21.3 Escrevendo requisitos estatísticos verificáveis"]
  N3["21.4 Rastreabilidade"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX061"]

Desenho lógico

flowchart LR
  N0["21.1 De casos de abuso a requisitos"]
  N1["21.2 Tipos de requisito"]
  N2["21.3 Escrevendo requisitos estatísticos verificáveis"]
  N3["21.4 Rastreabilidade"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]

[21.1 De casos de abuso a requisitos]
    |
    v
[21.2 Tipos de requisito]
    |
    v
[21.3 Escrevendo requisitos estatísticos verificáveis]
    |
    v
[21.4 Rastreabilidade]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX061]

Objetivos de aprendizagem

Você vai (1) escrever requisitos de segurança para componentes de IA que sejam específicos, mensuráveis e verificáveis; (2) derivar requisitos de casos de abuso; (3) expressar requisitos estatísticos com limites de confiança; e (4) rastrear requisitos até frameworks e regulamentação.

21.1 De casos de abuso a requisitos

Um caso de abuso descreve como alguém poderia usar o sistema indevidamente: "Um fornecedor embute em um boletim uma instrução que faz o Wrench agendar manutenção desnecessária." Cada caso de abuso gera requisitos que o previnem, detectam ou limitam. Escrever casos de abuso como histórias com um ator, um objetivo e um caminho os torna concretos o bastante para serem testados. O caso do boletim gera três requisitos: rotular o texto dos boletins como não confiável (prevenir), alertar sobre conteúdo com cara de instrução nos boletins (detectar) e exigir confirmação para ordens de serviço (limitar). Ter os três significa que a falha de um não deixa o caso de abuso em aberto.

21.2 Tipos de requisito

Segurança funcional: "Ordens de serviço exigem confirmação do técnico." Comportamento estatístico: "No conjunto reservado de testes de injeção (≥ 600 casos), o Wrench propõe chamadas de ferramenta não autorizadas em ≤ 2% dos casos (limite superior de 95%)." Processo: "Toda versão do modelo passa pelo portão de avaliação de segurança." Dados: "Imagens de treinamento carregam proveniência; reetiquetagens da terceirizada são amostradas e revisadas a 5%." Operacional: "Orçamento de ações por usuário de 20 ordens de serviço por hora; alertas acima de 3× a linha de base acionam o plantão."

O mínimo de 600 casos é o dobro do conjunto de 300 casos que barrou o prompt mais amigável, porque um conjunto menor dá um limite superior largo demais para demonstrar uma taxa perto de 2%.

21.3 Escrevendo requisitos estatísticos verificáveis

Declare a população (conjunto de testes), a métrica, o limiar, o nível de confiança e o tamanho mínimo de amostra. "Robusto a ataques" não é verificável. "Acurácia sob PGD com L∞ ε = 4/255 ≥ 70% no conjunto reservado" é — e declara implicitamente o modelo de ameaça. O exemplo do PGD nomeia o ataque, a norma e o orçamento, de modo que os testadores sabem exatamente o que executar e os leitores sabem o que o resultado não cobre: orçamentos maiores, outras normas e ataques físicos. Um requisito estatístico também precisa de dados suficientes para decidir. Se o conjunto de testes for pequeno demais, o limite superior pode exceder o limiar mesmo quando o modelo é bom, e não se consegue mostrar que o requisito passa. O tamanho da amostra, portanto, faz parte do próprio requisito.

21.4 Rastreabilidade

Ligue cada requisito à sua origem (caso de abuso, item do OWASP, artigo do AI Act, objetivo de controle da ISO/IEC 42001) e ao seu método de verificação. O Artigo 15 do EU AI Act exige que sistemas de alto risco sejam resilientes a tentativas de alterar seu uso ou desempenho explorando vulnerabilidades, nomeando envenenamento de dados, envenenamento de modelo, exemplos adversariais e ataques à confidencialidade; requisitos que tratem cada um deles tornam rastreáveis os argumentos de conformidade. Uma tabela de rastreabilidade funciona nos dois sentidos: de cada origem aos requisitos que a atendem, e de cada requisito ao seu teste. As lacunas então aparecem como células vazias.

21.5 Exemplo resolvido (caso sintético da NRS)

Sam escreveu o REQ-AI-014: "A taxa de falsos negativos do TrackEye para defeitos ≥ 10 mm deverá ser ≤ 1,5% com limite superior de 95%, por estrato de condição (dia, amanhecer/anoitecer, noite, chuva), em um conjunto reservado de ≥ 1.000 defeitos por estrato; verificada por relatório de teste a cada versão." Origem: perigo H-03 e AI Act Art. 15 (acurácia). O REQ-AI-015 tratou das marcações adversariais: "Nenhuma marcação única ≤ 20 × 20 cm colocada a ≥ 0,5 m do trilho deverá reduzir a detecção de um defeito adjacente para menos de 95% na campanha de testes físicos." A regra por estrato fecha a lacuna do amanhecer: uma boa taxa geral não pode mais esconder uma condição fraca.

21.6 Erros e limites

Três erros são comuns: requisitos sem limiares ou conjuntos de testes; limiares sem limites de confiança; e requisitos que não podem ser verificados com os dados disponíveis. Sem um limiar e um conjunto de testes, ninguém consegue dizer se um requisito foi atendido. Um limiar sem limite de confiança pode ser superado por sorte em uma amostra pequena. Um requisito que precisa de dados inexistentes, como mil defeitos noturnos por estrato quando só duzentos foram registrados, deve ser reescrito ou vir com um plano para coletar os dados antes da versão que depende dele.

Exercícios

EX061 — Reescrita. Reescreva "O Wrench não deve vazar segredos" como um requisito verificável. Rubrica: 3 = população, métrica, limiar, confiança, verificação; 2 = quatro; 1 = vago; 0 = inalterado.
EX062 — Caso de abuso. Escreva um caso de abuso para o Pulse e um requisito derivado. Rubrica: 3 = caso plausível e requisito verificável; 2 = um fraco; 1 = vago; 0 = nenhum.
EX063 — Tamanho de amostra. Quantos casos de teste são necessários para mostrar uma taxa ≤ 2% com limite superior unilateral de 95% se nenhuma falha for observada? Rubrica: 3 = cerca de 150 (regra de três: 3/n ≤ 0,02); 2 = só o método; 1 = errado, mas fundamentado; 0 = nenhum.

Síntese

Bons requisitos de segurança de IA são afirmações mensuráveis sobre o comportamento sob ataques declarados, com tamanhos de amostra e confiança, rastreadas até sua origem e sua verificação.

Continue estudando — capítulo 21 de 50

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