Capítulo 28 — Segurança de IA e aprendizado de máquina: análise de falhas
Mapa da aula
Aula 28 publicada. Mapa, exemplo, EX082.
flowchart TD
N0["28.1 Tipos de causa"]
N1["28.2 Evidências e linhas do tempo"]
N2["28.3 Métodos de causa-raiz"]
N3["28.4 Revisões sem culpados"]
N4["28.5 Deriva ou ataque?"]
N5["28.7b Transformar causas em correções"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX082"]
Desenho lógico
flowchart LR
N0["28.1 Tipos de causa"]
N1["28.2 Evidências e linhas do tempo"]
N2["28.3 Métodos de causa-raiz"]
N3["28.4 Revisões sem culpados"]
N4["28.5 Deriva ou ataque?"]
N5["28.7b Transformar causas em correções"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX082"]
[28.1 Tipos de causa]
|
v
[28.2 Evidências e linhas do tempo]
|
v
[28.3 Métodos de causa-raiz]
|
v
[28.4 Revisões sem culpados]
|
v
[28.5 Deriva ou ataque?]
|
v
[28.7b Transformar causas em correções]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX082]
Objetivos de aprendizagem
Você vai (1) analisar falhas e incidentes de IA para encontrar as causas-raiz; (2) distinguir causas de modelo, de dados, de integração e de processo; (3) usar linhas do tempo e evidências; e (4) escrever revisões pós-incidente sem culpados, com ações.
28.1 Tipos de causa
Falhas de IA podem vir do modelo (comportamento), dos dados (envenenados, deslocados ou vazados), da integração (ferramentas, permissões, análise sintática) ou do processo (revisão, gestão de mudanças, treinamento). A maioria dos incidentes tem várias causas contribuintes. O incidente do falso fechamento, no exemplo resolvido abaixo, mostra isso: uma causa de processo (nenhuma revisão dos envios), uma causa de integração (fontes misturadas na recuperação) e uma causa de projeto (nenhuma verificação de embasamento) precisaram estar todas presentes. Remover qualquer uma delas teria evitado ou limitado o dano, e é por isso que as ações trataram as três, e não apenas a mais visível.
28.2 Evidências e linhas do tempo
Colete logs da aplicação, do gateway do modelo, do serviço de políticas e das ferramentas; registre as versões de modelo, prompt e dados; construa uma linha do tempo desde a primeira causa até a detecção e a resolução. Preserve as evidências antes de alterar os sistemas. No incidente do fechamento, o primeiro passo foi exportar os logs de recuperação e a cópia indexada do folheto antes que alguém o apagasse, porque o folheto era a principal evidência. A linha do tempo foi então do envio à indexação noturna, à primeira resposta falsa e ao relato da recepcionista, o que mostrou quanto tempo durou a exposição.
28.3 Métodos de causa-raiz
Pergunte "por quê" repetidamente até chegar a causas sobre as quais se possa agir; use árvores de falhas para falhas complexas. Evite parar em "o modelo fez algo errado": pergunte por que esse comportamento teve impacto (permissões excessivas, falta de confirmação). No incidente do fechamento, a cadeia foi: por que os pacientes ouviram falar do fechamento? O modelo repetiu um folheto. Por que ele leu o folheto? Os envios de parceiros eram indexados sem revisão. Por quê? O processo de envio era anterior ao chatbot, e ninguém o atualizou quando o Ask Lumen começou a ler o mesmo repositório. Essa última resposta apontou para a gestão de mudanças, uma ação que a LCH podia tomar.
28.4 Revisões sem culpados
Concentre-se em sistemas e condições, não em indivíduos. Registre o que aconteceu, o impacto, as causas, o que deu certo e as ações, com responsáveis e datas. Compartilhe amplamente as lições. O parceiro que enviou o folheto havia seguido o processo que lhe fora dado, e a recepcionista que percebeu o problema recebeu crédito na revisão. Tratar o incidente como falha de sistema manteve os funcionários dispostos a relatar respostas estranhas do chatbot, que foi justamente como o problema foi encontrado. A culpa teria ensinado os funcionários a ficar calados.
28.5 Deriva ou ataque?
Mudanças nas taxas de erro podem ser deriva (novos padrões nos dados) ou ataque. Procure agrupamentos por origem, momento e correlação com entradas específicas. O laboratório de monitoramento sinaliza um cliente sintético cujo padrão de consultas difere bruscamente dos outros.
"""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
No laboratório, o client99 enviou 600 consultas com uma razão de distintas de 0.10, enquanto os clientes normais enviaram de 40 a 89, com razões perto de 0.5; essa combinação de volume e padrão repetitivo sugere sondagem sistemática, e não deriva. A deriva normalmente desloca um pouco muitos clientes, e não muito um único cliente, e não reduziria a variedade das consultas.
28.6 Exemplo resolvido (caso sintético da LCH)
Vários pacientes ouviram que uma clínica havia fechado. Linha do tempo: um parceiro enviou um folheto com texto oculto; ele foi indexado durante a noite; o Ask Lumen repetiu o fechamento 23 vezes antes que uma recepcionista o relatasse. Causas: envios de parceiros indexados sem revisão (processo), recuperação que misturava fontes de parceiros e da LCH (integração), nenhuma verificação contra os dados estruturados das clínicas (projeto). Ações: fila de revisão para envios de parceiros, rotulagem das fontes, verificação de embasamento. As 23 respostas falsas foram contadas nos logs de conversas, e os funcionários das clínicas telefonaram para cada paciente afetado para confirmar sua consulta.
28.7 Erros e limites
Três erros são comuns: culpar o modelo ou uma pessoa e parar aí; alterar os sistemas antes de preservar os logs; e ações sem responsáveis. Parar em "o modelo alucinou" teria deixado o processo de envio inalterado, e o próximo folheto hostil teria produzido o mesmo resultado. Apagar o folheto antes de copiá-lo teria destruído a evidência de como o texto oculto foi escrito. Ações sem responsáveis e sem datas tendem a ficar abertas indefinidamente; cada uma das três ações do fechamento tinha um responsável nomeado e um prazo.
28.7b Transformar causas em correções
Cada causa encontrada numa revisão do Ask Lumen vira uma mudança específica com um responsável: uma verificação de saída ausente vira um validador, um passo confuso do runbook é reescrito, uma reversão nunca testada é ensaiada. A revisão só é encerrada quando cada mudança foi feita e verificada, não quando a reunião termina. No incidente do fechamento, a revisão ficou aberta até que a verificação de embasamento fosse testada contra o folheto original. O teste mostrou que o Ask Lumen agora respondia com o horário real, tirado do arquivo estruturado, e sinalizava o conflito para revisão; depois disso, a revisão foi encerrada e o teste do folheto foi acrescentado à suíte de regressão.
Exercícios
- EX082 — Causas. Classifique as causas do incidente do folheto em modelo, dados, integração e processo. Rubrica: 3 = classificação correta; 2 = a maioria; 1 = vago; 0 = nenhuma.
- EX083 — Leitura do laboratório. Qual cliente é sinalizado e com base em que evidência? Rubrica: 3 = client99, 600 consultas, z robusto 30.58, distintas 0.10; 2 = o nome; 1 = vago; 0 = errado.
- EX084 — Ações da revisão. Escreva duas ações da revisão do folheto, com responsáveis e datas. Rubrica: 3 = específicas, com responsável e data; 2 = uma; 1 = vagas; 0 = nenhuma.
Síntese
A análise de falhas transforma incidentes em aprendizado: linhas do tempo baseadas em evidências, causas em camadas e revisões sem culpados com ações que têm responsáveis.
Continue estudando — capítulo 28 de 40
← Capítulo 27 (rascunho) · Índice de capítulos do curso · Capítulo 29 (rascunho) →