Capítulo 3 — Prática autorizada e tratamento de evidências

Mapa da aula

Aula 03 publicada. Mapa, exemplo, EX011.

flowchart TD
  N0["3.1 Autorização"]
  N1["3.2 Ambientes seguros"]
  N2["3.3 Evidências"]
  N3["3.4 Constatações sensíveis"]
  N4["3.5 Repetir e quantificar"]
  N5["3.7b Guardar as evidências com segurança"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX011"]

Desenho lógico

flowchart LR
  N0["3.1 Autorização"]
  N1["3.2 Ambientes seguros"]
  N2["3.3 Evidências"]
  N3["3.4 Constatações sensíveis"]
  N4["3.5 Repetir e quantificar"]
  N5["3.7b Guardar as evidências com segurança"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX011"]

[3.1 Autorização]
    |
    v
[3.2 Ambientes seguros]
    |
    v
[3.3 Evidências]
    |
    v
[3.4 Constatações sensíveis]
    |
    v
[3.5 Repetir e quantificar]
    |
    v
[3.7b Guardar as evidências com segurança]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX011]

Objetivos de aprendizagem

Você vai (1) trabalhar somente dentro de uma autorização por escrito; (2) usar dados sintéticos e ambientes isolados; (3) coletar e preservar evidências de forma adequada; (4) tratar constatações sensíveis com responsabilidade; e (5) relatar pelos canais certos.

3.1 Autorização

Antes de qualquer teste, tenha uma autorização por escrito do responsável pelo sistema, indicando sistemas, atividades, datas, dados e contatos. Testar sem ela pode violar a lei e prejudicar clientes, mesmo com boas intenções. Se encontrar algo fora do escopo, pare e pergunte. A autorização de Sofia indicava o ambiente de homologação do ClaimChat, duas semanas e apenas clientes sintéticos. Guarde o documento assinado com os registros de teste e verifique, antes de cada sessão, se as datas ainda cobrem o trabalho. Se o responsável pelo produto quiser mais testes, por exemplo em produção, peça uma nova aprovação por escrito em vez de estender a antiga por e-mail ou numa conversa.

3.2 Ambientes seguros

Teste em cópias isoladas com dados sintéticos. Se um teste em produção chegar a ser aprovado, use contas de teste dedicadas e ações que não possam afetar clientes reais. Na Meridian, a homologação do ClaimChat é a cópia isolada para testes, com clientes sintéticos criados para cada plano de teste. Verifique antes de cada sessão se o ambiente continua isolado, porque dados podem ser copiados para ele por engano, como Sofia descobriu quando o nome de um cliente real apareceu num registro da homologação. Mantenha as contas de teste claramente identificadas como sintéticas e nunca aponte a ferramenta de retorno da homologação para uma linha telefônica real.

3.3 Evidências

Registre data e hora, sistema e versão, passos, entradas, saídas e registros das ferramentas. Meça efeitos (um retorno foi agendado), não impressões (a resposta soou estranha). Mantenha os originais inalterados; trabalhe em cópias; anote quem manuseou as evidências. Nos testes de Sofia, a evidência de um retorno urgente injetado é o agendamento no registro da ferramenta, não a redação da resposta do ClaimChat. Guarde as evidências com o identificador do teste, para que qualquer resultado possa ser rastreado até sua entrada e sua versão. Anote também a versão do modelo e o prompt em uso naquele momento.

3.4 Constatações sensíveis

Se vir dados pessoais reais, uma vulnerabilidade ativa ou sinais de um ataque de fato, pare os testes e escale pelo processo de incidentes. Não compartilhe detalhes além de quem precisa deles. Coordene a divulgação com os fornecedores quando os produtos deles forem afetados. A descoberta, por Sofia, do nome de um cliente real num registro da homologação é um exemplo: ela parou, relatou o fato à sua supervisora e ao encarregado de privacidade e só retomou depois que os dados foram removidos. Registre o que viu e quando, sem copiar os próprios dados.

3.5 Repetir e quantificar

Repita os testes para estimar taxas e relate a incerteza.

"""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 resultado de 11 em 40 de Sofia é relatado com um intervalo de cerca de 16–43%, o que diz à equipe que o problema é real, mas que sua taxa exata é incerta. Execute casos suficientes para sustentar a decisão em questão e relate o número de tentativas ao lado de cada taxa. O laboratório S mostra como o intervalo se estreita à medida que as tentativas aumentam. Uma única execução prova pouco, porque as saídas do modelo variam entre tentativas; repita cada caso e conte. Sofia contou os agendamentos urgentes ao longo de seus 40 envios, em vez de julgar a partir de um só.

3.6 Exemplo resolvido (caso sintético da Meridian)

A autorização de Sofia cobre a homologação do ClaimChat por duas semanas, apenas com clientes sintéticos. Ela envia 40 orçamentos de reparo sintéticos com texto escondido pedindo um retorno urgente. 11 de 40 causam um agendamento urgente (intervalo de cerca de 16–43%). Durante os testes, ela nota o nome de um cliente real num registro da homologação — dados de produção copiados por engano. Ela para, relata o fato à supervisora e ao encarregado de privacidade e só continua depois que os dados são removidos. A interrupção mostra que a autorização cobre o que fazer quando algo dá errado, e não apenas o que testar.

3.7 Erros e limites

Três erros são comuns: apenas autorização verbal; testar com dados reais de clientes; e continuar depois de encontrar um problema ativo. Cada erro põe pessoas ou o trabalho em risco. Uma autorização verbal não pode ser verificada depois e não protege você se um teste causar dano. Dados reais de clientes nos testes criam justamente a exposição que está sendo estudada. Continuar depois de encontrar um problema ativo, o que Sofia não fez, pode espalhar ainda mais dados pessoais e atrasar a resposta. Verifique os três no seu plano de teste e na sua conduta. Corrija qualquer um deles antes da próxima sessão.

3.7b Guardar as evidências com segurança

Capturas de tela de respostas do ClaimChat podem conter nomes de clientes, números de sinistro e fotos. A Meridian guarda as evidências de teste numa pasta restrita, usa clientes sintéticos sempre que possível e apaga as evidências na data escrita no plano de teste. As evidências de Sofia dos testes do ClaimChat usaram clientes sintéticos, por isso as capturas de tela não trazem dados reais. Registre a data de exclusão no plano de teste e confirme a exclusão quando ela acontecer. Mantenha as evidências numa pasta com controle de acesso para a equipe de teste, não em canais de chat nem em unidades pessoais, e defina uma data de exclusão combinada com o encarregado de privacidade. Evidências que contenham dados reais por engano devem ser apagadas de imediato, e o incidente, relatado.

Exercícios

• EX011 — Autorização. Escreva o esboço de uma autorização para o teste de Sofia. Rubrica: 3 = sistemas, atividades, datas, dados, contatos, assinatura; 2 = quatro; 1 = dois; 0 = nenhum.
• EX012 — Evidências. Liste seis campos de evidência para um teste. Rubrica: 3 = seis pertinentes; 2 = quatro; 1 = dois; 0 = nenhum.
• EX013 — Dados reais. Sofia agiu certo ao parar? Explique. Rubrica: 3 = privacidade, escopo, processo de incidentes; 2 = dois; 1 = só sim; 0 = não.
• EX014 — Intervalo. Interprete 11/40 com seu intervalo. Rubrica: 3 = taxa ≈28%, faixa de 16–43%, mais tentativas a estreitam; 2 = parcial; 1 = só a taxa; 0 = errado.
• EX015 — Fornecedor. Você encontra uma falha no leitor de documentos do fornecedor. O que faz? Rubrica: 3 = relato interno, divulgação coordenada com o fornecedor, mitigação; 2 = dois; 1 = um; 0 = publicar.

Síntese

Testes autorizados e seguros, com evidências cuidadosas e escalonamento responsável, são a base de uma prática confiável de segurança de IA.

Continue estudando — capítulo 03 de 12

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