Capítulo 32 — Segurança de IA e aprendizado de máquina: confiabilidade
Mapa da aula
Aula 32 publicada. Mapa, exemplo, EX094.
flowchart TD
N0["32.1 Confiabilidade para IA"]
N1["32.2 Calibração"]
N2["32.3 Redundância e degradação"]
N3["32.4 Confiabilidade ou ataque?"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX094"]
Desenho lógico
flowchart LR
N0["32.1 Confiabilidade para IA"]
N1["32.2 Calibração"]
N2["32.3 Redundância e degradação"]
N3["32.4 Confiabilidade ou ataque?"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX094"]
[32.1 Confiabilidade para IA]
|
v
[32.2 Calibração]
|
v
[32.3 Redundância e degradação]
|
v
[32.4 Confiabilidade ou ataque?]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX094]
Objetivos de aprendizagem
Você vai (1) definir confiabilidade para componentes de IA (comportamento correto e consistente ao longo do tempo e das condições); (2) quantificar a confiabilidade com taxas de erro estratificadas, calibração e disponibilidade; (3) projetar redundância e degradação controlada; e (4) distinguir falhas de confiabilidade de ataques na análise de incidentes.
32.1 Confiabilidade para IA
A confiabilidade clássica pergunta com que frequência um componente falha. Para a IA, "falha" inclui saídas erradas que parecem normais. A confiabilidade, portanto, inclui a acurácia em diferentes condições (taxas de erro estratificadas), a calibração (90% de confiança significa 90% de acerto?), a estabilidade entre versões e a disponibilidade do serviço. Um serviço que caiu é notado de imediato; um modelo que, em silêncio, deixa passar mais defeitos ao amanhecer, não. As medidas de confiabilidade para IA precisam, portanto, olhar as saídas ao longo do tempo e por condição, e não apenas o tempo de atividade. A estabilidade entre versões importa porque uma atualização do modelo pode mudar decisões em casos que antes estavam certos, e operadores que aprenderam a confiar no comportamento antigo podem não perceber.
32.2 Calibração
A confiança de um modelo calibrado corresponde à sua acurácia. Modelos superconfiantes tornam frágil a automação a jusante: se o TrackEye diz 99% "sem defeito", mas acerta apenas 95% das vezes com essa confiança, os operadores confiam demais nele. Meça a calibração com diagramas de confiabilidade ou com o erro de calibração esperado; recalibre com métodos simples, como o temperature scaling em dados reservados. O temperature scaling divide as pontuações brutas do modelo por um único número ajustado antes de convertê-las em probabilidades. Ele não muda qual classe vence, então a acurácia continua a mesma, mas as confianças se aproximam da acurácia observada. A calibração também precisa ser verificada por estrato de condição, porque um modelo pode estar bem calibrado no geral e muito superconfiante ao amanhecer.
32.3 Redundância e degradação
A redundância pode ser diversa (um modelo diferente ou uma verificação baseada em regras) ou repetida (uma segunda inferência). A redundância diversa ajuda contra modos de falha compartilhados e contra alguns ataques, porque uma entrada adversarial criada para um modelo pode não se transferir perfeitamente. A degradação controlada define o que acontece quando um componente falha ou está incerto: o TrackEye sinaliza trechos para revisão manual em vez de marcá-los como livres. A inferência repetida no mesmo modelo só ajuda contra falhas aleatórias, como um erro transitório de hardware, já que a mesma entrada dá o mesmo erro.
32.4 Confiabilidade ou ataque?
Quando as taxas de erro mudam, pergunte: as entradas mudaram (deriva), o modelo mudou (versão) ou alguém agiu (ataque)? Observe o momento, os estratos afetados, a correlação com fontes específicas e os logs. Muitos ataques aparentes são deriva; alguma deriva aparente é ataque. Quem decide é a evidência, não o instinto. Uma deriva costuma começar gradualmente ou em uma mudança conhecida, afeta muitas entradas de uma condição e se correlaciona com o ambiente ou a versão. Um ataque muitas vezes começa de forma abrupta, concentra-se em fontes ou alvos específicos e pode evitar as condições que o tornariam óbvio. O checklist de triagem de Sam registra cada observação, para que um revisor posterior possa ver por que um incidente foi classificado de um jeito e revisitá-lo se surgir nova evidência.
32.5 Exemplo resolvido (caso sintético da NRS)
A taxa de falsos negativos do Pulse subiu em uma rota. Os logs mostraram que a alta coincidiu com uma atualização de firmware dos sensores que mudou as unidades em dois eixos — uma falha de confiabilidade, não um ataque. Sam acrescentou verificações de unidade na ingestão e uma verificação de limiar diversa, baseada em regras, que teria pegado as leituras extremas independentemente do modelo. O momento apontava para a atualização de firmware, e apenas os dois eixos afetados mudaram, o que se encaixa em uma mudança de configuração, e não em um atacante. As correções tratam tanto a causa quanto a classe de falha: as verificações de unidade rejeitam de imediato valores impossíveis, e a verificação baseada em regras não depende do modelo em nada.
32.6 Erros e limites
Três erros são comuns: tratar pontuações de confiança como probabilidades sem calibração; redundância com modelos idênticos (falha compartilhada); e concluir "ataque" sem verificar deriva e mudanças. Pontuações não calibradas enganam qualquer pessoa que defina limiares ou explique decisões com elas. Modelos redundantes idênticos falham juntos, então acrescentam custo sem acrescentar segurança. Chamar toda mudança de ataque desperdiça esforço de investigação e pode prejudicar a confiança de fornecedores e parceiros, enquanto chamar toda mudança de deriva pode deixar um ataque real continuar. O hábito que Sam ensina é reunir evidências para as duas explicações antes de decidir.
Exercícios
- EX094 — Calibração. Um modelo tem 80% de acurácia nas previsões em que relata 95% de confiança. O que está errado e qual é uma correção? Rubrica: 3 = superconfiante; recalibrar (temperature scaling) e verificar; 2 = só o diagnóstico; 1 = vago; 0 = errado.
- EX095 — Redundância diversa. Por que uma verificação baseada em regras é útil ao lado do Pulse? Rubrica: 3 = modos de falha diferentes; efeitos adversariais/de deriva têm menos chance de afetar ambos; 2 = parcial; 1 = vago; 0 = errado.
- EX096 — Triagem. Liste três perguntas para separar deriva de ataque. Rubrica: 3 = o que mudou (entradas, versões), quais estratos/fontes, momento e correlação com os logs; 2 = duas; 1 = uma; 0 = nenhuma.
Síntese
Uma IA confiável é calibrada, estratificada, redundante de formas diversas e se degrada com segurança; a análise de incidentes separa deriva de ataque usando evidências.
Continue estudando — capítulo 32 de 50
← Capítulo 31 (rascunho) · Índice de capítulos do curso · Capítulo 33 (rascunho) →