Capítulo 31 — Segurança de IA e aprendizado de máquina: implementação II
Mapa da aula
Aula 31 publicada. Mapa, exemplo, EX091.
flowchart TD
N0["31.1 Monitoramento e detecção de abuso"]
N1["31.2 Integridade do pipeline de dados"]
N2["31.3 Carregamento e atualização seguros de modelos"]
N3["31.4 Logging e alertas"]
N4["31.6b Testando alertas de ponta a ponta"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX091"]
Desenho lógico
flowchart LR
N0["31.1 Monitoramento e detecção de abuso"]
N1["31.2 Integridade do pipeline de dados"]
N2["31.3 Carregamento e atualização seguros de modelos"]
N3["31.4 Logging e alertas"]
N4["31.6b Testando alertas de ponta a ponta"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX091"]
[31.1 Monitoramento e detecção de abuso]
|
v
[31.2 Integridade do pipeline de dados]
|
v
[31.3 Carregamento e atualização seguros de modelos]
|
v
[31.4 Logging e alertas]
|
v
[31.6b Testando alertas de ponta a ponta]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX091]
Objetivos de aprendizagem
Você vai (1) implementar monitoramento e detecção de abuso para serviços de modelos; (2) implementar controles de integridade no pipeline de dados; (3) implementar carregamento e atualização seguros de modelos; e (4) integrar os controles a logging e alertas.
31.1 Monitoramento e detecção de abuso
Registre em log, por cliente, os volumes de consultas, a diversidade das entradas, as contagens de tokens, as recusas e as propostas de chamadas de ferramenta. Estatísticas robustas (mediana e desvio absoluto mediano) encontram valores atípicos sem serem distorcidas pelos próprios valores atípicos. O laboratório sinaliza um raspador sintético que envia uma varredura de entradas em forma de grade, típica de tentativas de extração.
"""Lab A: spotting extraction-style abuse in a synthetic API log.
Flags clients whose query volume or input diversity is anomalous."""
import random, statistics
rng = random.Random(21)
log = []
for c in range(12):
for _ in range(rng.randint(40, 90)):
log.append((f"client{c:02d}", round(rng.gauss(0, 1), 1)))
for i in range(600): # synthetic scraper: many, grid-like inputs
log.append(("client99", round(-3 + 6*(i % 61)/60, 1)))
by = {}
for c, x in log: by.setdefault(c, []).append(x)
vol = {c: len(v) for c, v in by.items()}
med = statistics.median(vol.values()); mad = statistics.median(abs(v-med) for v in vol.values())
for c in sorted(by):
z = (vol[c]-med)/(1.4826*mad); uniq = len(set(by[c]))/len(by[c])
flag = "FLAG" if z > 3.5 else "ok"
print(f"{c} queries={vol[c]:3d} robust_z={z:6.2f} distinct_ratio={uniq:.2f} {flag}")
Saída esperada:
client00 queries= 50 robust_z= -0.34 distinct_ratio=0.56 ok
client01 queries= 64 robust_z= 0.45 distinct_ratio=0.52 ok
client02 queries= 81 robust_z= 1.41 distinct_ratio=0.44 ok
client03 queries= 46 robust_z= -0.56 distinct_ratio=0.52 ok
client04 queries= 52 robust_z= -0.22 distinct_ratio=0.48 ok
client05 queries= 40 robust_z= -0.90 distinct_ratio=0.57 ok
client06 queries= 42 robust_z= -0.79 distinct_ratio=0.57 ok
client07 queries= 87 robust_z= 1.74 distinct_ratio=0.48 ok
client08 queries= 56 robust_z= 0.00 distinct_ratio=0.52 ok
client09 queries= 50 robust_z= -0.34 distinct_ratio=0.62 ok
client10 queries= 68 robust_z= 0.67 distinct_ratio=0.50 ok
client11 queries= 89 robust_z= 1.85 distinct_ratio=0.42 ok
client99 queries=600 robust_z= 30.58 distinct_ratio=0.10 FLAG
O raspador se destaca nas duas medidas: 600 consultas dão um z robusto acima de 30, e uma razão de entradas distintas perto de uma em dez mostra que ele repete uma grade fixa de 61 valores. Os clientes comuns ficam entre 40 e 89 consultas, com razões em torno de metade. Usar a mediana e o MAD impede que o próprio volume do raspador eleve o limiar contra o qual ele é julgado.
31.2 Integridade do pipeline de dados
Calcule hashes dos dados na ingestão; mantenha versões imutáveis; exija merges revisados para mudanças de rótulos; execute verificações automáticas de duplicatas, mudanças no equilíbrio entre classes e correlações suspeitas entre característica e rótulo (possíveis gatilhos); coloque novas fontes em quarentena até serem revisadas. Cada verificação mira uma via de envenenamento. Hashes e versões imutáveis impedem edições silenciosas. Merges de rótulos revisados pegam uma terceirizada invertendo rótulos. Verificações de equilíbrio e de correlação procuram a assinatura de um backdoor, como uma característica que prevê uma classe quase perfeitamente nos dados novos, mas não nos antigos. A quarentena dá aos revisores tempo para amostrar uma nova fonte antes que qualquer modelo aprenda com ela, o que é muito mais barato do que retreinar depois.
31.3 Carregamento e atualização seguros de modelos
Carregue apenas artefatos assinados cujos resumos no manifesto confiram; use formatos que contenham apenas tensores; verifique no dispositivo de destino; mantenha a versão anterior para rollback; registre qual versão atendeu cada requisição. A sequência é verificada em ordem no dispositivo: assinatura, depois resumos, depois formato. O carregamento falha de forma segura se qualquer etapa falhar, e o dispositivo continua executando a versão anterior verificada. Registrar a versão de cada requisição permite que os investigadores liguem uma saída estranha ao modelo exato que a produziu, o que importa quando um fornecedor relata depois uma versão defeituosa e a NRS precisa saber quais inspeções ela afetou.
31.4 Logging e alertas
Correlacione os IDs de requisição entre os serviços de modelo, de política e de ferramentas. Os alertas devem ser específicos ("client99 robust z = 30.6; distinct-input ratio 0.10") e encaminhados a um responsável com um runbook. Evite registrar em log o conteúdo sensível dos prompts por inteiro; registre hashes ou formas mascaradas quando possível, em linha com as obrigações de proteção de dados. Um alerta específico permite que o engenheiro de plantão avalie a gravidade de imediato; "atividade incomum" o obriga a repetir a análise. Os runbooks declaram as primeiras verificações, como confirmar se o cliente é um parceiro conhecido, e quando escalar.
31.5 Exemplo resolvido (caso sintético da NRS)
A NRS abriu uma API limitada do TrackEye a um parceiro. Sam implantou as regras de monitoramento: um z-score robusto acima de 3,5 no volume diário, ou uma razão de entradas distintas abaixo de 0,2 com volume alto, dispara uma revisão. No primeiro mês, um script de parceiro foi sinalizado; era um laço de novas tentativas mal configurado, não um ataque, e o parceiro o corrigiu. Sam manteve a regra e documentou o falso positivo. Um laço de novas tentativas e uma varredura de extração produzem ambos volume alto, então a segunda regra, uma razão baixa de entradas distintas, ajuda a distingui-los: um laço de novas tentativas reenvia as mesmas poucas entradas, enquanto a extração espalha as consultas de forma sistemática. Documentar o falso positivo dá ao próximo revisor um padrão conhecido para verificar primeiro.
31.6 Erros e limites
Três erros são comuns: limiares de média e desvio padrão que o próprio valor atípico infla; registrar prompts completos com dados pessoais indefinidamente; e atualizações carregadas sem verificação de assinatura. Um limiar baseado na média sobe a cada usuário intenso, de modo que um raspador grande pode erguer a barra acima de seu próprio volume e escapar da sinalização. Prompts completos guardados indefinidamente se tornam um repositório de dados pessoais que é, ele mesmo, um alvo e pode violar regras de retenção. Atualizações não assinadas permitem que qualquer pessoa que alcance o dispositivo substitua o modelo. Cada um desses pontos aparece na revisão de monitoramento de Sam como uma pergunta de sim ou não com evidência anexada.
31.6b Testando alertas de ponta a ponta
Cada regra de monitoramento do Wrench e do TrackEye é testada injetando um evento sintético em homologação e verificando se o alerta chega ao engenheiro de plantão com contexto suficiente para agir. Regras que nunca dispararam em um teste são tratadas como não verificadas. As duas regras de Sam para a API do TrackEye foram testadas assim antes de o parceiro entrar em produção: um cliente sintético enviando 600 consultas em forma de grade em homologação precisava disparar a regra da razão de entradas distintas e acionar o engenheiro de plantão. O primeiro alerta real do mês, o laço de novas tentativas mal configurado do parceiro, chegou então por um caminho que já se sabia funcionar, com o volume do cliente e o z-score robusto na mensagem.
Exercícios
- EX091 — Leitura do laboratório. Que z-score robusto e que razão de entradas distintas o client99 teve, e por que usar mediana/MAD? Rubrica: 3 = 30.58 e 0.10; robusto à influência do valor atípico; 2 = só os números; 1 = vago; 0 = errado.
- EX092 — Verificação de gatilhos. Descreva uma verificação automática de possíveis gatilhos de backdoor em novos dados de treinamento. Rubrica: 3 = procurar características raras fortemente correlacionadas com um rótulo, comparar com versões anteriores, sinalizar para revisão; 2 = parcial; 1 = vago; 0 = nenhuma.
- EX093 — Privacidade nos logs. Como manter os logs úteis e ao mesmo tempo preservar a privacidade? Rubrica: 3 = mascarar/aplicar hash ao conteúdo, limites de retenção, controle de acesso, manter metadados; 2 = dois; 1 = um; 0 = nenhum.
Síntese
A implementação II acrescenta os controles detectivos e de integridade: monitoramento robusto, verificações de integridade de dados e de modelos e logging correlacionado e atento à privacidade.
Continue estudando — capítulo 31 de 50
← Capítulo 30 (rascunho) · Índice de capítulos do curso · Capítulo 32 (rascunho) →