Capítulo 19 — Segurança de IA e aprendizado de máquina: monitoramento
Mapa da aula
Aula 19 publicada. Mapa, exemplo, EX055.
flowchart TD
N0["19.1 Sinais"]
N1["19.2 Detecção de anomalias"]
N2["19.3 Volume de alertas"]
N3["19.4 Runbooks"]
N4["19.4b Revisando o monitoramento"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX055"]
Desenho lógico
flowchart LR
N0["19.1 Sinais"]
N1["19.2 Detecção de anomalias"]
N2["19.3 Volume de alertas"]
N3["19.4 Runbooks"]
N4["19.4b Revisando o monitoramento"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX055"]
[19.1 Sinais]
|
v
[19.2 Detecção de anomalias]
|
v
[19.3 Volume de alertas]
|
v
[19.4 Runbooks]
|
v
[19.4b Revisando o monitoramento]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX055]
Objetivos de aprendizagem
Você vai (1) escolher sinais para monitorar sistemas de IA; (2) construir uma detecção de anomalias simples; (3) gerenciar o volume de alertas usando taxas de base; e (4) escrever runbooks de alertas.
19.1 Sinais
Sinais úteis: volume de requisições e de tokens por usuário ou por chave; negações do serviço de políticas; chamadas de ferramentas por conversa; strings-canário nas saídas; saídas contendo links; picos de recusas ou de reclamações; distribuições das pontuações de classificadores (deriva); custo por hora. Escolha sinais ligados aos seus cenários de risco, para que cada alerta tenha uma razão de existir. No Ask Brightwell, Jonas liga cada sinal a um cenário: as negações de política à fraude de reembolso, as strings-canário à divulgação e o volume de tokens às inundações de custo. Os sinais do ReturnGuard são as chamadas de pontuação por chave, que detectaram uma integração de parceiro comprometida, e a distribuição das pontuações ao longo do tempo.
19.2 Detecção de anomalias
Estatísticas simples levam longe. Um escore z robusto, que usa a mediana e o desvio absoluto mediano (MAD), resiste melhor a valores atípicos do que a média e o desvio-padrão. Sinalize usuários cujo volume ou cuja razão de consultas distintas esteja muito longe dos demais — um padrão de raspagem ou de extração de modelo.
"""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
Os painéis da Brightwell usam esse método nas chamadas de pontuação do ReturnGuard por conta. Uma chave de parceiro muito distante das demais, com consultas que variavam um atributo por vez, correspondeu ao padrão de extração do laboratório. O método não exige nenhum modelo e roda na mesma consulta agendada que alimenta os painéis.
19.3 Volume de alertas
Todo alerta custa tempo de analista. Com ataques raros, até detectores precisos produzem sobretudo alarmes falsos (efeito da taxa de base), então defina os limiares medindo o volume de alertas no tráfego normal e encaminhe os sinais de baixa confiança para painéis, e não para o pager. O alerta de volume de transferências do Gift Card Help, o projeto final de Jonas (capítulos 29–30), mostrou esse efeito: sua precisão no tráfego reproduzido foi de 0,5, por isso Jonas o encaminhou para um painel. Já os valores atípicos nas chamadas de pontuação do ReturnGuard são tratados com limitação automática de taxa e um aviso ao plantão, e não com um acionamento. Medir primeiro o volume no tráfego normal é o que permite à equipe escolher entre esses caminhos.
19.4 Runbooks
Cada alerta precisa de um runbook: o que ele significa, como conferi-lo, como contê-lo (limitar a taxa, desativar uma ferramenta, reverter um prompt), a quem notificar e quando encerrá-lo. Os runbooks permitem que um engenheiro de plantão aja à noite sem adivinhar. O alerta da chave de parceiro seguiu seu runbook: limitar a taxa da chave, contatar o parceiro, revisar os registros. Como cada etapa estava escrita, o engenheiro de plantão não precisou decidir o que fazer primeiro. O mesmo runbook nomeia quem encerra o alerta e que evidências são guardadas, para que o caso possa ser revisado depois.
19.4b Revisando o monitoramento
Todo mês, revise quais alertas dispararam, quantos eram reais e quais incidentes foram descobertos de outra forma. Ajuste ou aposente os alertas ruidosos; acrescente sinais para os incidentes que o monitoramento deixou passar. Na Brightwell, a revisão mensal conta os casos reais e falsos de cada alerta. O problema do prazo de devolução de 60 dias foi descoberto pelos clientes, e não pelo monitoramento, e levou a um teste de regressão e a uma nova verificação da validade dos documentos recuperados. A revisão mensal também confere se o runbook de cada alerta foi seguido e o atualiza quando uma etapa foi pulada ou estava pouco clara.
19.5 Exemplo resolvido (caso sintético da Brightwell)
Jonas acrescenta painéis por conta. Numa semana, uma chave de API de parceiro mostra z robusto ≈ 30 nas chamadas de pontuação do ReturnGuard, semelhante ao cliente atípico client99 do laboratório; as consultas da chave variam um atributo por vez — o que é compatível com extração. O runbook: limitar a taxa da chave, contatar o parceiro, revisar os registros. A integração do parceiro tinha sido comprometida; a chave foi rotacionada. O runbook transformou um sinal estatístico numa sequência curta de ações. Rotacionar a chave encerrou a extração; contatar o parceiro revelou a causa. O painel continuou acompanhando a chave substituta, que desde então mostra volumes normais de chamadas.
19.6 Erros e limites
Três erros são comuns: alertas sem runbooks; acionar o pager a cada negação; e monitorar apenas a infraestrutura, e não o comportamento da IA. O monitoramento da Brightwell evita esses erros. Cada alerta tem um runbook, as negações vão para painéis, a menos que deem um pico, e o comportamento da IA é acompanhado junto com os servidores. O alerta da chave de parceiro não teria significado nada se ninguém soubesse o que fazer com ele. Sem sinais de comportamento, a injeção que um serviço de políticas nega nunca seria vista. O painel de negações cobre o segundo erro, e o alerta de chamadas de pontuação cobre o terceiro.
Exercícios
- EX055 — Sinais. Escolha cinco sinais para o Ask Brightwell e ligue cada um a um cenário de risco. Rubrica: 3 = cinco ligados; 2 = quatro; 1 = dois; 0 = nenhum.
- EX056 — Z robusto. Por que usar a mediana e o MAD em vez da média e do desvio-padrão? Rubrica: 3 = valores atípicos inflam o desvio-padrão e se mascaram; 2 = parcial; 1 = vago; 0 = errado.
- EX057 — Runbook. Escreva o runbook do alerta de extração. Rubrica: 3 = significado, verificações, contenção, notificação, encerramento; 2 = quatro; 1 = dois; 0 = nenhum.
Síntese
O monitoramento acompanha sinais específicos de IA, usa estatísticas robustas, respeita as taxas de base e liga cada alerta a um runbook.
Continue estudando — capítulo 19 de 30
← Capítulo 18 (rascunho) · Índice de capítulos do curso · Capítulo 20 (rascunho) →