Capítulo 14 — Engenharia de software | Engenharia Segurança de IA e aprendizado de máquina

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX040.

flowchart TD
  N0["14.1 Um ciclo de vida para software de IA"]
  N1["14.2 Gerência de configuração de modelos e prompts"]
  N2["14.3 Revisão e integração contínua"]
  N3["14.4 Liberação e reversão"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX040"]

Desenho lógico

flowchart LR
  N0["14.1 Um ciclo de vida para software de IA"]
  N1["14.2 Gerência de configuração de modelos e prompts"]
  N2["14.3 Revisão e integração contínua"]
  N3["14.4 Liberação e reversão"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]

[14.1 Um ciclo de vida para software de IA]
    |
    v
[14.2 Gerência de configuração de modelos e prompts]
    |
    v
[14.3 Revisão e integração contínua]
    |
    v
[14.4 Liberação e reversão]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX040]

Objetivos de aprendizagem

Você vai (1) aplicar um ciclo de vida de desenvolvimento seguro a software com IA; (2) gerenciar requisitos, versões e mudanças de modelos e prompts, além do código; (3) conduzir revisão de código e integração contínua com portões de segurança e de avaliação; e (4) planejar liberações e reversões de componentes de IA.

14.1 Um ciclo de vida para software de IA

Um ciclo de vida de desenvolvimento seguro acrescenta atividades de segurança a cada fase: requisitos (casos de abuso), projeto (modelagem de ameaças), implementação (codificação segura, controle de dependências), verificação (testes, avaliações, red teaming) e liberação (aprovação, monitoramento). Na IA, os artefatos se multiplicam: código, pesos do modelo, dados de treinamento, prompts, índices de recuperação e conjuntos de avaliação. Cada um precisa ser versionado e revisado; um prompt de sistema alterado pode mudar o comportamento de segurança tanto quanto uma mudança de código. Os casos de abuso são escritos junto com os requisitos normais, por exemplo 'um boletim de fornecedor tenta fazer o Wrench criar uma ordem de serviço'.

14.2 Gerência de configuração de modelos e prompts

Guarde os prompts no controle de versão, não num console web. Dê a cada modelo uma entrada no registro com seu hash, a versão dos dados de treinamento, os resultados de avaliação e o estado de aprovação. Implante por referência a uma versão do registro, para que a produção sempre possa ser rastreada e revertida. Um prompt editado num console web não tem revisão, nem histórico, nem vínculo com a avaliação que o aprovou. No controle de versão, toda mudança tem um autor e um diff, e o portão de CI roda sobre ela como sobre qualquer mudança de código. A entrada do registro vincula um modelo implantado aos dados e testes por trás dele, então um auditor pode perguntar o que está rodando e obter uma resposta exata.

14.3 Revisão e integração contínua

A revisão de código pega erros de projeto e de lógica; em componentes de IA, revise também as mudanças de prompt e de dados. A integração contínua deve executar testes unitários, verificações de dependências e um portão de avaliação de segurança: um conjunto fixo de testes de injeção, jailbreak e uso indevido, com limiares que bloqueiam a liberação se forem excedidos. O portão precisa usar testes reservados, não os exemplos contra os quais os desenvolvedores fizeram ajustes. Os testes reservados ficam com um responsável separado e são renovados com novos padrões de ataque, para que o portão meça generalização e não memória.

14.4 Liberação e reversão

Libere de forma gradual (implantação canário para uma pequena fatia do tráfego), observe as métricas e mantenha a versão anterior pronta. Para modelos, reverter significa trocar a referência no registro — algo fácil só se você tiver planejado para isso. Um canário expõe uma nova versão a uma pequena fatia do tráfego real enquanto a versão antiga atende o resto. As métricas observadas incluem sinais de segurança, como propostas de ferramenta rejeitadas e alertas de detectores, e não só latência e erros. A reversão precisa ser praticada: a equipe de Sam volta todo mês, em homologação, à versão anterior do registro para confirmar que isso ainda funciona, já que uma reversão nunca testada pode falhar no dia em que for necessária.

14.5 Exemplo resolvido (caso sintético da NRS)

Um desenvolvedor mudou o prompt de sistema do Wrench para deixar as respostas mais simpáticas. O portão de segurança da CI executou 300 casos reservados de injeção e encontrou as propostas de chamadas de ferramenta não autorizadas subindo de 1.0% para 4.3% (a camada de políticas ainda as bloqueava, mas o limiar do portão para propostas era de 2%). A liberação foi bloqueada; a equipe descobriu que uma frase nova, "sempre tente concluir o objetivo do usuário", incentivava seguir instruções presentes no texto recuperado. Eles a reescreveram e a taxa voltou a 1.1%. A camada de políticas garantiu que nenhum dano chegasse à produção, mas o portão pegou um enfraquecimento numa camada anterior antes da liberação.

14.6 Erros e limites

Três erros são comuns: prompts editados diretamente na produção; testes de segurança que os desenvolvedores já viram e contra os quais fizeram ajustes; e nenhum caminho de reversão para modelos. Edições de prompt na produção contornam a revisão e não deixam registro de por que o comportamento mudou. Testes contra os quais os desenvolvedores fizeram ajustes mostram que o sistema consegue passar nesses testes, não que resiste a ataques novos. Modelos sem caminho de reversão obrigam as equipes a corrigir os problemas para a frente, sob pressão. Cada lacuna tem um remédio direto: prompts no controle de versão, um portão reservado com responsável separado e uma volta praticada à última versão aprovada do registro.

Exercícios

EX040 — Artefatos. Liste seis artefatos de uma aplicação de LLM que precisam de controle de versão. Rubrica: 3 = código, pesos/ID do modelo, prompts, índice/dados de recuperação, conjuntos de avaliação, configurações/políticas; 2 = quatro; 1 = dois; 0 = nenhuma.
EX041 — Portão de segurança. Projete um portão de CI para o Wrench (testes, métrica, limiar, ação). Rubrica: 3 = conjunto reservado, métrica de taxa com limiar, bloqueia a liberação; 2 = falta um; 1 = vago; 0 = nenhuma.
EX042 — Mudança de prompt. Por que uma mudança de simpatia afetou a segurança? Rubrica: 3 = a redação do prompt muda as prioridades de seguir instruções, inclusive em direção a textos injetados; 2 = parcial; 1 = vago; 0 = errado.

Síntese

A engenharia de software de IA trata modelos, prompts e dados como artefatos versionados e revisados, controlados por avaliações de segurança reservadas e liberados com um caminho de reversão.

Continue estudando — capítulo 14 de 50

← Capítulo 13 (rascunho) · Índice de capítulos do curso · Capítulo 15 (rascunho) →