Capítulo 37 — Segurança de IA e aprendizado de máquina: operações
Mapa da aula
Aula 37 publicada. Mapa, exemplo, EX109.
flowchart TD
N0["37.1 Operações de segurança para IA"]
N1["37.2 Runbooks de incidentes de IA"]
N2["37.3 Gestão de vulnerabilidades"]
N3["37.4 Gestão de mudanças"]
N4["37.5 Métricas operacionais"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX109"]
Desenho lógico
flowchart LR
N0["37.1 Operações de segurança para IA"]
N1["37.2 Runbooks de incidentes de IA"]
N2["37.3 Gestão de vulnerabilidades"]
N3["37.4 Gestão de mudanças"]
N4["37.5 Métricas operacionais"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX109"]
[37.1 Operações de segurança para IA]
|
v
[37.2 Runbooks de incidentes de IA]
|
v
[37.3 Gestão de vulnerabilidades]
|
v
[37.4 Gestão de mudanças]
|
v
[37.5 Métricas operacionais]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX109]
Objetivos de aprendizagem
Você vai (1) operar sistemas de IA em produção com operações de segurança (monitoramento, resposta a incidentes, gestão de vulnerabilidades); (2) escrever runbooks para incidentes específicos de IA; (3) gerenciar operacionalmente as mudanças de modelos e prompts; e (4) relatar métricas operacionais.
37.1 Operações de segurança para IA
Envie a telemetria de IA para o centro de operações de segurança: sinalizações do classificador de injeção, negações de política, taxas incomuns de chamadas de ferramenta, padrões de consulta semelhantes a extração, falhas de verificação no carregamento de modelos e alarmes de deriva. Defina gravidades e responsáveis. Os analistas do centro de operações de segurança já observam sinais de identidade, rede e endpoints, então os eventos de IA se tornam muito mais úteis ao lado deles: uma rajada de negações de política vinda de uma conta pode coincidir com um login suspeito. Cada sinal de IA recebe uma gravidade, um responsável e um runbook antes de ser ativado, porque um alerta que ninguém entende logo passa a ser ignorado. Sam começa com poucos sinais de alto valor e acrescenta outros depois que os primeiros estão ajustados e são confiáveis.
37.2 Runbooks de incidentes de IA
Os runbooks dão etapas para: suspeita de injeção de prompt com ação executada (conter: revogar credenciais de ferramentas, desativar a ferramenta; investigar: rastrear os IDs de requisição até o documento de origem; recuperar: desfazer ações, expurgar documentos envenenados; aprender: acrescentar aos testes); suspeita de envenenamento de dados (congelar o treinamento, identificar as versões afetadas pela linhagem, fazer rollback para um modelo verificado); suspeita de extração (limitar o cliente, preservar os logs, notificar o jurídico); falha de integridade do modelo (parar de carregar, verificar a cadeia de suprimentos). A contenção vem primeiro em cada runbook porque é rápida e reversível. A investigação vem depois que o dano parou.
37.3 Gestão de vulnerabilidades
Acompanhe as vulnerabilidades em softwares de serviço de modelos, bibliotecas e conectores como em qualquer software. Acompanhe as fraquezas no nível do modelo (novas técnicas de jailbreak, ataques recém-publicados) monitorando fontes como os estudos de caso do MITRE ATLAS, avisos de fornecedores e pesquisas. Teste novamente após atualizações de modelo ou de prompt. Fraquezas no nível do modelo diferem de bugs de software: muitas vezes não há correção, apenas uma mitigação, como um novo teste, um filtro ou uma permissão de ferramenta mais restrita. Cada técnica recém-publicada é avaliada contra o próprio modelo de ameaças do sistema e registrada como não aplicável, mitigada ou em aberto. Testar de novo após as atualizações importa porque uma nova versão do modelo pode ser mais fraca contra um ataque antigo a que a versão anterior resistia.
37.4 Gestão de mudanças
Mudanças em modelos, prompts, ferramentas e fontes de recuperação passam pelo processo de liberação com portões de segurança, implantação canário e rollback. Mudanças emergenciais (por exemplo, desativar uma ferramenta) são pré-aprovadas nos runbooks. Uma edição de prompt ou uma nova fonte de recuperação pode mudar o comportamento de segurança tanto quanto um código novo, então todas passam pelo mesmo portão. Mudanças emergenciais pré-aprovadas permitem que o engenheiro de plantão desative uma ferramenta à noite sem esperar por uma reunião, enquanto a mudança continua registrada e é revisada no dia seguinte. O objetivo é rapidez para a contenção e cuidado para todo o resto.
37.5 Métricas operacionais
Relate mensalmente: negações e confirmações de política, sinalizações de injeção, incidentes por tipo e tempo até a contenção, resultados do conjunto de avaliação por versão, violações de cota e riscos em aberto. As tendências importam mais que números isolados. Um número crescente de confirmações pode significar mais trabalho legítimo ou uma nova campanha de injeção, e a tendência ao lado das sinalizações e dos incidentes ajuda a saber qual. O tempo até a contenção mostra se os runbooks funcionam na prática. Os resultados de avaliação por versão mostram se a segurança está melhorando ou piorando à medida que o sistema muda. Os riscos em aberto mantêm visíveis os problemas aceitos, para que sejam revisitados em vez de esquecidos.
37.6 Exemplo resolvido (caso sintético da NRS)
Às 02:10, o SOC viu uma rajada de propostas do Wrench para criar ordens de serviço em uma linha, todas confirmadas por uma única conta do turno da noite em questão de segundos. O runbook levou o engenheiro de plantão a suspender o acesso dessa conta às ferramentas do Wrench, rastrear as propostas até um boletim enviado às 01:55 e descobrir que ele continha texto com cara de instrução. O dono da conta tinha aprovado sem ler. As ordens foram canceladas; a fonte do boletim foi bloqueada; a interface de aprovação ganhou um limite de aprovações por minuto. Cada confirmação levou segundos, um padrão que nenhum revisor cuidadoso produz.
37.7 Erros e limites
Três erros são comuns: telemetria de IA que não chega ao SOC; nenhum runbook para incidentes específicos de modelos; e mudanças emergenciais sem pré-aprovação, causando atraso. Se a telemetria de IA fica em um painel de engenharia, ninguém a observa às 02:10. Sem runbooks específicos de modelos, os respondentes improvisam, muitas vezes desligando o serviço inteiro quando bastaria desativar uma ferramenta. Mudanças emergenciais que precisam de um comitê perdem horas enquanto um ataque continua. O incidente acima deu certo porque os três estavam em vigor: o alerta chegou ao SOC, havia um runbook e a suspensão do acesso estava pré-aprovada.
Exercícios
- EX109 — Runbook. Escreva as quatro fases de um runbook para suspeita de envenenamento. Rubrica: 3 = conter, investigar, recuperar, aprender, com etapas concretas; 2 = três; 1 = vago; 0 = nenhuma.
- EX110 — Telemetria. Liste cinco sinais de IA que o SOC deve receber. Rubrica: 3 = cinco pertinentes; 2 = quatro; 1 = dois; 0 = nenhum.
- EX111 — Lição do incidente. Que controle teria reduzido mais cedo o impacto do incidente das 02:10? Rubrica: 3 = limites de taxa de aprovação/alertas de anomalia nas aprovações, confiança da fonte, destaque; 2 = um genérico; 1 = vago; 0 = nenhum.
Síntese
As operações mantêm viva a segurança de IA após a liberação: telemetria no SOC, runbooks específicos de IA, gestão de vulnerabilidades e de mudanças e relatórios de tendências.
Continue estudando — capítulo 37 de 50
← Capítulo 36 (rascunho) · Índice de capítulos do curso · Capítulo 38 (rascunho) →