Capítulo 11 — Segurança de IA e aprendizado de máquina: verificação
Mapa da aula
Aula 11 publicada. Mapa, exemplo, EX041.
flowchart TD
N0["11.1 Verifique, não suponha"]
N1["11.2 O que verificar"]
N2["11.3 Testando de novo depois de mudanças"]
N3["11.4 Relatando com incerteza"]
N4["11.5 Registros"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX041"]
Desenho lógico
flowchart LR
N0["11.1 Verifique, não suponha"]
N1["11.2 O que verificar"]
N2["11.3 Testando de novo depois de mudanças"]
N3["11.4 Relatando com incerteza"]
N4["11.5 Registros"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX041"]
[11.1 Verifique, não suponha]
|
v
[11.2 O que verificar]
|
v
[11.3 Testando de novo depois de mudanças]
|
v
[11.4 Relatando com incerteza]
|
v
[11.5 Registros]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX041]
Objetivos de aprendizagem
Você vai (1) verificar se os controles configurados funcionam; (2) testar de novo depois de mudanças; (3) relatar os resultados da verificação com sua incerteza; (4) manter registros de verificação.
11.1 Verifique, não suponha
Um controle configurado pode não funcionar: uma regra pode ter um erro de digitação, uma configuração pode não ter sido implantada, uma ferramenta nova pode contornar a verificação. Verificar significa rodar testes que falhariam se o controle não funcionasse. Um controle que nunca foi visto bloqueando algo é um controle que você espera que funcione. Na Kestrel, a verificação de titularidade passou pela revisão de código, mas chegou à homologação com a comparação invertida para um tipo de roteador, então permitia exatamente as reinicializações que deveria bloquear nesses roteadores. Só um teste negativo pegou o problema. A ferramenta de senha do Wi-Fi é o outro exemplo: acrescentada duas semanas depois da configuração de Ana, ela chamava diretamente o serviço de gerenciamento de roteadores e, assim, contornava por completo a verificação da ferramenta de reinicialização. A verificação é a etapa que encontra esses problemas antes dos clientes.
11.2 O que verificar
Para cada controle, pelo menos um teste positivo (o uso normal continua funcionando) e um teste negativo (a ação ruim é bloqueada). Exemplo: a verificação de reinicialização permite que um cliente reinicie o próprio roteador e bloqueia reinicializações de roteadores de outras pessoas. Use testes de injeção reservados, que não foram usados para ajustar a configuração. Na ferramenta de chamados, o teste positivo é um cliente sintético abrindo um chamado de prioridade normal sobre a própria linha; os testes negativos são um pedido injetado de chamado urgente e um chamado aberto contra outra conta. Ambos devem ser avaliados pelo registro de chamados. O conjunto reservado importa porque Ana ajustou a configuração com seus 40 testes de injeção; só os 20 testes reservados, rodados uma vez, mostram se a correção se generaliza.
11.3 Testando de novo depois de mudanças
Rode a bateria de novo quando mudarem a versão do modelo, o prompt, as fontes de recuperação, as ferramentas ou a configuração. Automatize isso no pipeline de implantação, para que não possa ser esquecido. O pipeline da Kestrel roda a bateria completa do HelpBot na homologação a cada mudança na versão do modelo, no prompt de sistema, nas coleções de recuperação, nas ferramentas ou na configuração de políticas, e bloqueia a implantação diante de qualquer ação entre clientes ou vazamento de canário. Foi assim que a falta de verificação de titularidade na ferramenta de senha do Wi-Fi foi detectada antes do lançamento. As atualizações do modelo do fornecedor contam como mudanças, embora a Kestrel não as tenha escrito; a versão fica fixada até a bateria passar na nova.
11.4 Relatando com incerteza
Relate contagens e intervalos: 0 falhas em 60 testes significa que a taxa real de falhas provavelmente está abaixo de cerca de 5%, não que é zero. Mais testes estreitam o intervalo.
"""Lab S: reporting attack-success rates honestly: Wilson intervals,
seed variation and a paired bootstrap. Synthetic trial outcomes only."""
import math, random
def wilson(k, n, z=1.96):
p = k/n; d = 1 + z*z/n
c = (p + z*z/(2*n))/d; h = z*math.sqrt(p*(1-p)/n + z*z/(4*n*n))/d
return c - h, c + h
for k, n in ((3, 20), (30, 200), (300, 2000)):
lo, hi = wilson(k, n); print(f"successes={k}/{n} rate={k/n:.3f} wilson95=[{lo:.3f}, {hi:.3f}]")
# five seeds of a synthetic defence evaluation: per-seed attack success rate
rates = []
for seed in range(5):
r = random.Random(seed); rates.append(sum(r.random() < 0.12 for _ in range(200))/200)
m = sum(rates)/5; sd = math.sqrt(sum((x-m)**2 for x in rates)/4)
print("per-seed rates:", " ".join(f"{x:.3f}" for x in rates), f"mean={m:.3f} sd={sd:.3f}")
# paired bootstrap: baseline vs defence on the same 300 synthetic prompts
r = random.Random(42)
base = [r.random() < 0.30 for _ in range(300)]
defn = [b and r.random() < 0.6 for b in base] # defence blocks ~40% of successes
diffs = []
for _ in range(2000):
idx = [r.randrange(300) for _ in range(300)]
diffs.append(sum(base[i] for i in idx)/300 - sum(defn[i] for i in idx)/300)
diffs.sort()
print(f"baseline_asr={sum(base)/300:.3f} defended_asr={sum(defn)/300:.3f} "
f"reduction_ci95=[{diffs[50]:.3f}, {diffs[1949]:.3f}]")
Saída esperada:
successes=3/20 rate=0.150 wilson95=[0.052, 0.360]
successes=30/200 rate=0.150 wilson95=[0.107, 0.206]
successes=300/2000 rate=0.150 wilson95=[0.135, 0.166]
per-seed rates: 0.110 0.130 0.135 0.105 0.145 mean=0.125 sd=0.017
baseline_asr=0.350 defended_asr=0.190 reduction_ci95=[0.120, 0.203]
O laboratório mostra por que os intervalos importam. Três sucessos em 20 tentativas dão um intervalo entre 5,2% e 36%; a mesma taxa em 2.000 tentativas se estreita para 13,5%–16,6%. A variação de semente acrescenta sua própria dispersão: cinco sementes da mesma avaliação sintética deram taxas entre 0,105 e 0,145. O bootstrap pareado estima a redução proporcionada pela defesa entre 0,120 e 0,203. Por isso os relatórios de Ana dizem "0 de 60 (limite superior de cerca de 6%)" em vez de "corrigido". Para 0 de 30, o limite fica em cerca de 10%.
11.5 Registros
Mantenha um registro de verificação: controle, IDs dos testes, versões, data, resultados, quem os executou. Auditores e futuros técnicos dependem desses registros. O registro de Ana para a verificação de titularidade das reinicializações diz: controle, regra de titularidade no serviço de ferramentas; testes, 60 tentativas de reinicialização entre contas mais testes positivos com o próprio roteador; versões do orquestrador, do serviço de ferramentas e do modelo fixado; data; resultado, 0 de 60 tiveram sucesso e todas as reinicializações do próprio roteador funcionaram; responsável pelo teste, Ana, com revisão do líder da equipe. Quando a ferramenta de Wi-Fi foi acrescentada, esse registro mostrou ao auditor exatamente quais testes faltavam à nova ferramenta. O registro fica ao lado de RST-N01–N30 no controle de versão, para que os testes e suas evidências mudem juntos.
11.6 Exemplo resolvido (caso sintético da Kestrel)
Duas semanas depois da configuração de Ana, um desenvolvedor acrescenta uma ferramenta de "mudar a senha do Wi-Fi". O pipeline roda a bateria de novo: os testes positivos passam, mas um teste negativo mostra que a nova ferramenta não tem a verificação de titularidade — um cliente consegue mudar a senha do Wi-Fi de outro cliente. A implantação é bloqueada; a verificação é acrescentada; a bateria passa, com 0 de 30 tentativas entre clientes (limite superior de cerca de 10%). Ana acrescenta mais 60 testes para estreitá-lo. O registro desta execução entrou no histórico de verificações ao lado do da verificação de reinicialização. O pipeline cumpriu seu papel porque a bateria incluía testes negativos para todas as ferramentas que mexem num roteador; uma bateria só de testes positivos teria aprovado a nova ferramenta, já que os clientes conseguiam mudar as próprias senhas do Wi-Fi. Com 90 tentativas e 0 sucessos, o limite se estreita para cerca de 4%.
11.7 Erros e limites
Três erros são comuns: tratar a configuração como prova; ter só testes negativos (bloquear tudo passa); e não testar de novo depois de acrescentar ferramentas. Cada erro corresponde a algo que Ana viu. Tratar a configuração como prova teria levado à produção a verificação de titularidade com a comparação invertida. Uma bateria só de testes negativos aprova um sistema que recusa tudo, inclusive as 50 tarefas normais de que os clientes realmente precisam. Não testar de novo depois de acrescentar uma ferramenta é a forma como a ferramenta de senha do Wi-Fi quase chegou aos clientes sem verificação de titularidade. Cada erro deixa um registro que diz "verificado" enquanto o controle não funciona.
Exercícios
- EX041 — Par de testes. Escreva um teste positivo e um negativo para a regra de prioridade dos chamados. Rubrica: 3 = os dois com resultados esperados; 2 = um; 1 = vago; 0 = nenhum.
- EX042 — Gatilhos. Liste cinco mudanças que devem disparar novos testes. Rubrica: 3 = cinco pertinentes; 2 = quatro; 1 = duas; 0 = nenhuma.
- EX043 — Incerteza. O que se pode afirmar a partir de 0 falhas em 30 testes, e como reforçar essa afirmação? Rubrica: 3 = limite de ≈10%, mais testes; 2 = um; 1 = "é seguro"; 0 = nada.
- EX044 — Registro. Escreva uma entrada de registro de verificação para a verificação da ferramenta de Wi-Fi. Rubrica: 3 = controle, testes, versões, data, resultados, responsável pelo teste; 2 = quatro; 1 = dois; 0 = nenhum.
Síntese
A verificação transforma a configuração em evidência: testes positivos e negativos, repetidos a cada mudança, relatados com sua incerteza e registrados.
Continue estudando — capítulo 11 de 18
← Capítulo 10 (rascunho) · Índice de capítulos do curso · Capítulo 12 (rascunho) →