Capítulo 29 — Segurança de IA e aprendizado de máquina: operações
Mapa da aula
Aula 29 publicada. Mapa, exemplo, EX085.
flowchart TD
N0["29.1 Monitoramento"]
N1["29.2 Resposta a incidentes"]
N2["29.3 Gestão de mudanças"]
N3["29.4 Acesso e contas"]
N4["29.5 Relatórios"]
N5["29.5b Exercícios e simulações"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX085"]
Desenho lógico
flowchart LR
N0["29.1 Monitoramento"]
N1["29.2 Resposta a incidentes"]
N2["29.3 Gestão de mudanças"]
N3["29.4 Acesso e contas"]
N4["29.5 Relatórios"]
N5["29.5b Exercícios e simulações"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX085"]
[29.1 Monitoramento]
|
v
[29.2 Resposta a incidentes]
|
v
[29.3 Gestão de mudanças]
|
v
[29.4 Acesso e contas]
|
v
[29.5 Relatórios]
|
v
[29.5b Exercícios e simulações]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX085]
Objetivos de aprendizagem
Você vai (1) operar sistemas de IA com segurança no dia a dia; (2) monitorar sinais específicos de IA; (3) conduzir a resposta a incidentes de IA; e (4) gerenciar mudanças em modelos, prompts e dados.
29.1 Monitoramento
Acompanhe sinais que revelem ataques ou falhas: sinalizações do classificador de injeção, negações de política, taxas incomuns de chamadas de ferramentas, volume de consultas por usuário, custo por conversa, falhas de embasamento das respostas e deriva nas distribuições de entradas ou saídas. Envie-os à equipe de operações de segurança, com responsáveis claros. Na LCH, a contagem de negações de política se mostrou o sinal precoce mais útil: uma alta súbita de marcações negadas costumava significar que alguém tentava manipular o chatbot, mesmo quando nenhuma marcação era bem-sucedida. Cada sinal do painel tem um responsável na equipe de operações de segurança, e os alertas vão para o engenheiro de plantão fora do horário de expediente.
29.2 Resposta a incidentes
Prepare runbooks. Para suspeita de injeção com impacto: conter (desativar a ferramenta afetada ou revogar suas credenciais), investigar (rastrear a conversa, os documentos recuperados e os logs das ferramentas), recuperar (desfazer ações, remover conteúdo malicioso), aprender (acrescentar testes, corrigir o processo). Para suspeita de envenenamento: interromper o retreinamento, identificar pela linhagem os dados e modelos afetados, reverter. Para suspeita de extração: restringir a taxa, preservar os logs, envolver o jurídico. A etapa de contenção vem primeiro porque pode ser feita em minutos, sem entender a causa. Na LCH, desativar a ferramenta de agendamento ainda deixa o Ask Lumen responder a perguntas, então os pacientes perdem apenas a marcação por conta própria enquanto os funcionários investigam, e podem telefonar para a clínica.
29.3 Gestão de mudanças
Trate modelos, prompts, fontes de recuperação e ferramentas como itens de configuração. As mudanças passam por testes de segurança, são implantadas gradualmente e podem ser revertidas. Modelos hospedados podem mudar sem aviso; reexecute as suítes de avaliação segundo um calendário. Na LCH, o prompt de sistema fica no mesmo repositório que o código, então uma edição de prompt passa pelo mesmo pipeline de revisão e testes. O modelo do provedor pode mudar sob o mesmo nome, então a suíte de avaliação de Rina roda semanalmente contra o modelo em produção, e uma queda em qualquer métrica abre um chamado mesmo quando a LCH não mudou nada.
29.4 Acesso e contas
Revise quem pode alterar prompts, enviar documentos, rotular dados e administrar os serviços de IA. Remova contas obsoletas; exija autenticação multifator para administradores. A revisão trimestral da LCH encontrou dois ex-terceirizados que ainda podiam rotular cartas do DocSort e uma conta de estagiário com direito de editar o prompt do Ask Lumen. As três foram removidas. As contas de envio dos parceiros agora estão ligadas a pessoas nomeadas, e não a logins compartilhados, de modo que um documento hostil pode ser rastreado até um envio individual e suspenso isoladamente, sem atrapalhar os demais parceiros.
29.5 Relatórios
Relatórios mensais: incidentes, negações, sinalizações, resultados de avaliação e riscos em aberto, com tendências. O relatório mensal da LCH mostra quatro números na primeira página: incidentes, negações de política, falhas de embasamento e a taxa de aprovação da avaliação mais recente, cada um com os três meses anteriores para comparação. Uma tendência de alta nas negações, mesmo sem incidentes, motiva um exame mais atento. Os riscos em aberto listam um responsável e uma data-alvo, então o relatório também acompanha se as correções estão sendo feitas no prazo, e os itens atrasados aparecem separadamente.
29.5b Exercícios e simulações
Faça simulações curtas: um documento injetado simulado na homologação, um lote envenenado simulado, um vazamento de chave simulado. Meça o tempo para detectar e conter e atualize os runbooks com o que aprender. A primeira simulação de documento injetado da LCH levou 40 minutos para conter porque o runbook indicava o interruptor de ferramenta errado; o runbook corrigido foi o usado no incidente real. Simulações são baratas comparadas a aprender a mesma lição durante um ataque, e cada uma terminou com uma pequena lista de edições no runbook, feitas na mesma semana e verificadas na simulação seguinte.
29.6 Exemplo resolvido (caso sintético da LCH)
Numa manhã de segunda-feira, o monitoramento mostrou cancelamentos de consultas pelo Ask Lumen a cinco vezes a taxa habitual. O runbook levou o engenheiro de plantão a desativar a ferramenta de cancelamento, rastrear os cancelamentos até conversas que haviam recuperado um documento de parceiro recém-enviado e restaurar as consultas canceladas. A conta que enviou o documento foi suspensa até a revisão. Tempo para conter: 18 minutos. Restaurar as consultas foi possível porque o log de marcações ligava cada cancelamento à sua conversa. Sem essa ligação, os funcionários teriam precisado perguntar a cada paciente se havia cancelado.
29.7 Erros e limites
Três erros são comuns: sinais de IA que ninguém monitora; nenhum runbook para incidentes específicos de IA; e mudanças de prompt feitas diretamente em produção. Sinais que ninguém observa não dão proteção: o incidente do falso fechamento durou uma noite, ao longo de 23 respostas falsas, porque não havia sinal de embasamento e ninguém observava as respostas até que uma recepcionista as relatou. Sem runbooks, um engenheiro de plantão precisa inventar uma resposta sob pressão. Editar prompts diretamente em produção contorna os testes que pegariam uma instrução enfraquecida ou uma salvaguarda removida e não deixa registro do que mudou quando algo dá errado em produção.
Exercícios
- EX085 — Sinais. Liste cinco sinais de IA a monitorar no Ask Lumen. Rubrica: 3 = cinco pertinentes; 2 = quatro; 1 = dois; 0 = nenhum.
- EX086 — Runbook. Escreva os passos de conter/investigar/recuperar/aprender para o incidente de cancelamentos. Rubrica: 3 = os quatro concretos; 2 = três; 1 = vagos; 0 = nenhum.
- EX087 — Mudanças em modelos hospedados. Por que reexecutar avaliações segundo um calendário no caso de modelos hospedados? Rubrica: 3 = atualizações do provedor podem mudar o comportamento sem aviso; detectar regressões; 2 = parcial; 1 = vago; 0 = errado.
Síntese
As operações mantêm a segurança de IA funcionando depois do lançamento: sinais de IA monitorados, runbooks praticados, mudanças controladas e relatórios regulares.
Continue estudando — capítulo 29 de 40
← Capítulo 28 (rascunho) · Índice de capítulos do curso · Capítulo 30 (rascunho) →