Capítulo 38 — Segurança de IA e aprendizado de máquina: validação
Mapa da aula
Aula 38 publicada. Mapa, exemplo, EX112.
flowchart TD
N0["38.1 Verificação versus validação"]
N1["38.2 Validação operacional"]
N2["38.3 Red teaming como validação"]
N3["38.4 Adequação ao propósito"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX112"]
Desenho lógico
flowchart LR
N0["38.1 Verificação versus validação"]
N1["38.2 Validação operacional"]
N2["38.3 Red teaming como validação"]
N3["38.4 Adequação ao propósito"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX112"]
[38.1 Verificação versus validação]
|
v
[38.2 Validação operacional]
|
v
[38.3 Red teaming como validação]
|
v
[38.4 Adequação ao propósito]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX112]
Objetivos de aprendizagem
Você vai (1) distinguir verificação (construído do jeito certo) de validação (construída a coisa certa); (2) validar a segurança de IA com usuários e operadores em condições realistas; (3) conduzir exercícios de red team como validação; e (4) decidir sobre a adequação ao propósito com evidências documentadas.
38.1 Verificação versus validação
A verificação confere se o sistema atende aos requisitos especificados. A validação confere se os requisitos e o sistema atendem às necessidades reais das partes interessadas no ambiente real. Um sistema pode passar em todos os requisitos e ainda assim ser inseguro se os requisitos deixaram passar uma ameaça ou se os usuários se comportam de modo diferente do suposto. Para o Wrench, a verificação mostrou que o ponto de aplicação bloqueia chamadas não autorizadas. A validação pergunta se os técnicos conseguem fazer seu trabalho com ele, se leem as telas de confirmação e se as ameaças do modelo são as que de fato aparecem. As duas são necessárias: verificação sem validação pode aprovar um sistema que ninguém usa com segurança, e validação sem verificação se apoia em impressões.
38.2 Validação operacional
Conduza pilotos em condições realistas: cargas de trabalho reais (autorizadas), usuários reais, conteúdo adversarial realista. Observe como os usuários interagem com os controles — eles leem as telas de aprovação, contornam as restrições? Meça juntos o sucesso nas tarefas e os resultados de segurança. A observação revela comportamentos que nenhum requisito previu, como um técnico que aprova propostas em lote no fim do turno, ou outro que copia o texto de boletins para o chat para ganhar tempo. Medir o sucesso nas tarefas junto com os resultados de segurança impede que um piloto declare sucesso quando o trabalho ficou mais rápido só porque as pessoas estavam contornando os controles. O feedback dos usuários do piloto é coletado por escrito, com a permissão deles, e devolvido aos requisitos.
38.3 Red teaming como validação
Um red team com escopo e autorização definidos tenta atingir objetivos de atacante contra o sistema integrado, usando qualquer técnica dentro das regras. Diferentemente de um conjunto de testes, red teams encontram caminhos não previstos. O NIST AI 600-1 lista o red teaming entre as ações sugeridas para IA generativa. Relate os achados com gravidade e correções, e converta os caminhos bem-sucedidos em testes de regressão. Red teams funcionam melhor quando são independentes dos desenvolvedores. Os desenvolvedores conhecem os caminhos pretendidos e tendem a testá-los; uma equipe externa parte do objetivo do atacante, como um pedido de peças não autorizado, e trabalha de trás para frente por tudo o que o sistema expõe. Cada achado é testado de novo após sua correção.
38.4 Adequação ao propósito
O relatório de validação declara: o uso pretendido, as condições testadas, os resultados em relação às necessidades das partes interessadas, os achados do red team e seu status, os riscos residuais e uma recomendação (implantar, implantar com condições, não implantar) assinada pelos responsáveis. Os responsáveis assinam porque a implantação é uma decisão de negócio informada por evidências de engenharia, e não apenas uma decisão de engenharia. As condições associadas a um resultado de "implantar com condições" têm, cada uma, um responsável e uma data, e o sistema é verificado contra elas antes que sejam consideradas cumpridas. O relatório também declara quando a validação precisa ser repetida, como após uma grande mudança de modelo ou uma nova integração.
38.5 Exemplo resolvido (caso sintético da NRS)
O Wrench passou na verificação. Durante um piloto de quatro semanas em dois depósitos, os técnicos pediam ao Wrench que "fizesse tudo o que o boletim diz" — um padrão de uso não previsto, que aumentou a parcela de propostas derivadas de texto não confiável. Um red team interno autorizado conseguiu então um pedido de peças não autorizado encadeando um resultado de busca em um e-mail para um fornecedor da lista de permissões com um número de peça modificado. Resultado da validação: implantar com condições — os números de peça nos e-mails precisam corresponder a uma ordem de serviço aberta, e os técnicos recebem treinamento sobre pedidos guiados por boletins.
38.6 Erros e limites
Três erros são comuns: tratar a verificação como validação; red teams sem escopo ou com os desenvolvedores avaliando a si mesmos; e recomendações sem a assinatura de responsáveis. Um sistema que atende à sua especificação ainda pode falhar com seus usuários se a especificação não captou como eles trabalham, como mostraram os pedidos de boletins no piloto. Red teams que se reportam aos desenvolvedores que testam, ou que trabalham sem escopo por escrito, produzem achados fáceis de descartar ou perigosos de obter. Uma recomendação que ninguém assina deixa a decisão de implantação sem dono quando algo der errado depois.
Exercícios
- EX112 — V&V. Dê um exemplo em que o Wrench passa na verificação, mas falha na validação. Rubrica: 3 = exemplo plausível (uso não previsto, lacuna de requisito); 2 = parcial; 1 = vago; 0 = nenhum.
- EX113 — Achado do red team. Transforme a cadeia do red team em um teste de regressão. Rubrica: 3 = cenário, entrada, resultado de política esperado, critério de aprovação; 2 = parcial; 1 = vago; 0 = nenhum.
- EX114 — Recomendação. Escreva a frase de recomendação da validação para o Wrench. Rubrica: 3 = implantar com as condições listadas, responsáveis, data de revisão; 2 = falta um; 1 = vago; 0 = nenhuma.
Síntese
A validação pergunta se o sistema protegido funciona para pessoas reais sob pressão real. Pilotos e red teams encontram o que os requisitos deixaram passar, e os responsáveis decidem sobre a adequação ao propósito.
Continue estudando — capítulo 38 de 50
← Capítulo 37 (rascunho) · Índice de capítulos do curso · Capítulo 39 (rascunho) →