Capítulo 13 — Segurança de IA e aprendizado de máquina: cenários de risco
Mapa da aula
Aula 13 publicada. Mapa, exemplo, EX037.
flowchart TD
N0["13.1 Formato do cenário"]
N1["13.2 Probabilidade e impacto"]
N2["13.3 Priorizando"]
N3["13.4 Ligando a controles e testes"]
N4["13.4b Fontes de cenários"]
N5["13.7 Revisando cenários ao longo do tempo"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX037"]
Desenho lógico
flowchart LR
N0["13.1 Formato do cenário"]
N1["13.2 Probabilidade e impacto"]
N2["13.3 Priorizando"]
N3["13.4 Ligando a controles e testes"]
N4["13.4b Fontes de cenários"]
N5["13.7 Revisando cenários ao longo do tempo"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX037"]
[13.1 Formato do cenário]
|
v
[13.2 Probabilidade e impacto]
|
v
[13.3 Priorizando]
|
v
[13.4 Ligando a controles e testes]
|
v
[13.4b Fontes de cenários]
|
v
[13.7 Revisando cenários ao longo do tempo]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX037]
Objetivos de aprendizagem
Você vai (1) escrever cenários de risco concretos para sistemas de IA; (2) estimar probabilidade e impacto; (3) priorizar cenários; e (4) ligar cada um deles a controles e testes.
13.1 Formato do cenário
Um cenário nomeia: ator, ponto de entrada, técnica, ativo afetado, efeito e controles existentes. Exemplo: "Um fraudador (ator) publica uma avaliação de produto (entrada) contendo instruções (injeção de prompt indireta) que fazem o Ask Brightwell (ativo) iniciar reembolsos integrais sem devolução (efeito); controles atuais: nenhum na ferramenta de devoluções." Cenários concretos podem ser testados; cenários vagos ("a IA pode ser hackeada") não podem. Os seis cenários da Brightwell escritos por Jonas seguem esse formato, e é por isso que cada um pôde depois ser ligado a um teste na homologação. Cada cenário da Brightwell também nomeia seu controle existente, ou a ausência dele.
13.2 Probabilidade e impacto
Probabilidade: quão fácil é, quão motivados estão os atacantes, se já aconteceu em outro lugar (os estudos de caso do MITRE ATLAS ajudam). Impacto: dinheiro, pessoas afetadas, exposição jurídica, reputação. Use escalas simples (1–5) e escreva as justificativas. No Ask Brightwell, a fraude de reembolso por meio de uma avaliação injetada recebeu probabilidade 4, porque escrever uma avaliação exige apenas uma conta e a técnica é publicada, e impacto 4, porque reembolsos custam dinheiro diretamente. A consulta entre clientes recebeu impacto 4 por envolver dados pessoais. Escrever essas justificativas permite que outras pessoas contestem a pontuação. Quando a ferramenta de devoluções foi acrescentada, as justificativas escritas mostraram exatamente qual parte da pontuação da fraude de reembolso precisava ser reavaliada.
13.3 Priorizando
Ordene por impacto × probabilidade e depois ajuste pela detectabilidade e pela reversibilidade: um dano que você vai perceber e pode desfazer rapidamente fica abaixo de um dano silencioso e permanente. A evasão do ReturnGuard pela divisão de devoluções ficou mais abaixo em parte porque aparece nos relatórios semanais e pode ser revertida recuperando os reembolsos. A fraude de reembolso por avaliações injetadas ficou mais acima porque poderia ocorrer em silêncio, e o dinheiro é difícil de recuperar depois de pago. A detectabilidade e a reversibilidade mudaram a ordem mais do que as pontuações brutas.
13.4 Ligando a controles e testes
Para cada cenário de alta prioridade, liste o controle que o limita e o teste que mostra que o controle funciona. Isso transforma o registro de riscos num backlog de engenharia. O principal cenário da Brightwell, a fraude de reembolso por avaliação injetada, liga-se ao serviço de políticas como controle e ao conjunto reservado de injeções como teste. A consulta entre clientes liga-se à verificação de titularidade e ao seu teste de unidade entre usuários. Quando um teste falha, o cenário mostra qual risco foi reaberto. Cada ligação cenário-controle-teste é uma linha no registro de riscos.
13.4b Fontes de cenários
Tire cenários das entradas do OWASP LLM Top 10, das técnicas e dos estudos de caso do MITRE ATLAS, de incidentes passados na sua organização e dos caminhos de contaminação do diagrama de fluxo de dados. Pergunte às pessoas que operam o sistema o que as preocupa: a equipe de atendimento ao cliente muitas vezes conhece os padrões de abuso antes da segurança. Revise os cenários após cada incidente e cada mudança importante. Os cenários da Brightwell vieram de várias dessas fontes: o OWASP LLM01 para a avaliação injetada, o caminho de contaminação do DFD para a ferramenta de devoluções e a equipe de atendimento, que mencionou as devoluções divididas como um truque de fraude conhecido.
13.5 Exemplo resolvido (caso sintético da Brightwell)
Jonas escreve seis cenários. Os três principais: fraude de reembolso por avaliação injetada (impacto 4, probabilidade 4); consulta de pedidos entre clientes (impacto 4, probabilidade 3, já corrigida e testada); ataque de custo por inundação de tokens (impacto 3, probabilidade 3). Mais abaixo: evasão do ReturnGuard pela divisão de devoluções (impacto 2, probabilidade 3) — detectável nos relatórios semanais. A consulta entre clientes tem impacto alto, mas seu teste já passa, então a atenção vai para a fraude de reembolso. A divisão de devoluções fica mais abaixo em parte porque os relatórios semanais a mostrariam, o que segue a regra de colocar danos silenciosos acima dos visíveis. Cada pontuação tem uma justificativa escrita no registro.
13.6 Erros e limites
Três erros são comuns: cenários vagos; pontuações sem justificativas; e cenários sem teste vinculado. Os seis cenários de Jonas evitam esses erros: cada um nomeia um ator, um ponto de entrada e um efeito, cada pontuação tem uma justificativa escrita, e os três principais estão ligados a um controle e a um teste. Um cenário que não pode ser testado não consegue avisar ninguém quando o risco diminuiu. A revisão trimestral confere essas três propriedades em todos os cenários ainda abertos. Cada propriedade é uma única coluna no registro de cenários da Brightwell, de modo que uma lacuna fica visível para quem o lê.
13.7 Revisando cenários ao longo do tempo
A Brightwell revisa seus cenários de risco de IA a cada trimestre e após qualquer incidente. Um cenário cuja probabilidade mudou — por exemplo, porque o Ask Brightwell ganhou uma nova ferramenta para emitir reembolsos — é reavaliado, e seus testes vinculados são atualizados na mesma revisão. A mesma revisão confere se o conjunto reservado ainda contém casos para o caminho dos reembolsos e acrescenta novos se os parâmetros da ferramenta mudaram. Os resultados vão para o dono do cenário de fraude de reembolso, que decide se a reavaliação muda o plano de lançamento.
Exercícios
- EX037 — Cenário. Escreva um cenário completo para o CodePilot sugerindo um pacote malicioso. Rubrica: 3 = os seis elementos; 2 = quatro ou cinco; 1 = dois ou três; 0 = nenhum.
- EX038 — Pontuação. Pontue seu cenário com justificativas. Rubrica: 3 = as duas pontuações com justificativas e ajuste; 2 = pontuações com justificativas; 1 = só pontuações; 0 = nenhuma.
- EX039 — Ligação. Ligue o principal cenário da Brightwell a um controle e a um teste. Rubrica: 3 = controle e teste específicos, com critério de aprovação; 2 = sem critério; 1 = vago; 0 = nenhum.
Síntese
Cenários concretos e pontuados, ligados a controles e testes, transformam o risco de IA em trabalho de engenharia.
Continue estudando — capítulo 13 de 30
← Capítulo 12 (rascunho) · Índice de capítulos do curso · Capítulo 14 (rascunho) →