◇ OpenCyber Academy
Engenharia · Capítulo 39 · Português

Capítulo 39 — Segurança de IA e aprendizado de máquina: manutenibilidade

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

Capítulo 39 — Segurança de IA e aprendizado de máquina: manutenibilidade

Mapa da aula

Aula 39 publicada. Mapa, exemplo, EX115.

flowchart TD
  N0["39.1 A mudança é constante"]
  N1["39.2 Estratégia de atualização"]
  N2["39.3 Mantendo o conhecimento atualizado"]
  N3["39.4 Dívida técnica em segurança de IA"]
  N4["39.5 Desativação"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX115"]

Desenho lógico

flowchart LR
  N0["39.1 A mudança é constante"]
  N1["39.2 Estratégia de atualização"]
  N2["39.3 Mantendo o conhecimento atualizado"]
  N3["39.4 Dívida técnica em segurança de IA"]
  N4["39.5 Desativação"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX115"]

[39.1 A mudança é constante]
    |
    v
[39.2 Estratégia de atualização]
    |
    v
[39.3 Mantendo o conhecimento atualizado]
    |
    v
[39.4 Dívida técnica em segurança de IA]
    |
    v
[39.5 Desativação]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX115]

Objetivos de aprendizagem

Você vai (1) projetar sistemas de IA cuja segurança possa ser mantida à medida que modelos, dados e ameaças mudam; (2) gerenciar atualizações de modelos e dependências; (3) manter atualizados os conjuntos de avaliação, os modelos de ameaças e a documentação; e (4) planejar a desativação e o descarte de dados.

39.1 A mudança é constante

Modelos hospedados são atualizados; modelos abertos ganham novas versões; bibliotecas corrigem vulnerabilidades; atacantes publicam novas técnicas; processos de negócio mudam. Um projeto seguro que não pode ser atualizado com segurança vai se tornar inseguro. Cada fonte de mudança afeta a segurança de um jeito. Uma atualização de modelo pode alterar a facilidade com que ele segue texto injetado; uma correção de biblioteca pode mudar o comportamento de análise; uma nova técnica de ataque pode derrotar um filtro que funcionava no mês passado. Manutenibilidade é a capacidade de absorver essas mudanças sem perder os controles que importam, o que exige testes, responsáveis e um processo previsível de atualização.

39.2 Estratégia de atualização

Fixe as versões e atualize de forma deliberada: cada atualização de modelo ou de dependência dispara o portão de avaliação de segurança, uma implantação canário e um plano de rollback. Para modelos hospedados que mudam sem aviso, rode o conjunto de avaliação em um cronograma e alerte sobre regressões. Mantenha camadas de abstração para que um modelo possa ser trocado sem reescrever a aplicação de políticas. A camada de abstração faz com que a aplicação de políticas não dependa do comportamento de nenhum modelo específico. Trocar um modelo passa então a exigir apenas o portão e o canário, e não um redesenho dos controles ao redor dele.

39.3 Mantendo o conhecimento atualizado

Atribua responsáveis pelo modelo de ameaças, pelos conjuntos de avaliação, pelos model cards e pelos runbooks, com datas de revisão. Acrescente cada incidente e cada achado de red team ao conjunto de regressão. Acompanhe as fontes externas (atualizações do OWASP, acréscimos ao MITRE ATLAS, publicações do NIST) e registre se cada mudança afeta o seu sistema. Um responsável com data de revisão transforma "alguém deveria atualizar o modelo de ameaças" em uma tarefa com um nome associado. Acrescentar cada achado ao conjunto de regressão faz os testes do sistema crescerem a partir da experiência real, e não de suposições. O acompanhamento externo é registrado de forma breve, por exemplo "nova técnica do ATLAS sobre injeção via descrição de ferramenta: aplica-se aos conectores, teste acrescentado", para que revisores posteriores possam ver que as mudanças foram consideradas.

39.4 Dívida técnica em segurança de IA

A dívida se acumula na forma de filtros pontuais, exceções e ajustes de prompt não documentados. Refatore periodicamente: remova controles que não servem mais a nenhuma ameaça, consolide os filtros no ponto de aplicação e documente as exceções restantes com datas de expiração. Um filtro acrescentado durante um incidente e nunca removido pode agora bloquear pedidos legítimos ou duplicar um controle do ponto de aplicação. Ajustes de prompt não documentados são especialmente arriscados, já que ninguém sabe qual deles está segurando uma fraqueza conhecida. A refatoração é feita com o conjunto de regressão rodando, de modo que remover um controle que ainda importa aparece como um teste falhando, e não como um incidente.

39.5 Desativação

Desativar um modelo inclui revogar suas credenciais, remover os caminhos de acesso, decidir o que fazer com os pesos (eles podem codificar dados de treinamento), excluir ou arquivar dados de acordo com as regras de retenção e atualizar os inventários. A ISO/IEC 42001 espera processos de ciclo de vida de sistemas de IA que incluam a desativação. Modelos esquecidos são um risco real: um endpoint antigo ainda rodando com credenciais válidas pode ser encontrado e abusado muito depois de todos terem parado de usá-lo. Os pesos podem permitir inferência de pertencimento ou vazar dados de treinamento, então são tratados sob as mesmas regras que os próprios dados. A atualização do inventário fecha o ciclo, de modo que o monitoramento e as auditorias deixam de esperar um sistema que não existe mais e percebem qualquer um que não deveria continuar rodando.

39.6 Exemplo resolvido (caso sintético da NRS)

Um modelo de embeddings hospedado, usado na recuperação do Wrench, foi atualizado em silêncio pelo provedor. A avaliação programada descobriu que a recuperação agora classificava documentos de RH mais acima em algumas consultas; o filtro de controle de acesso continuava a bloqueá-los, mas a equipe foi alertada. Sam acrescentou a "versão do modelo de embeddings" ao monitoramento e passou a usar uma versão fixa, com atualizações programadas. A defesa em profundidade se sustentou: a mudança de classificação só foi inofensiva porque o controle de acesso era aplicado separadamente da recuperação. O episódio também revelou uma dependência oculta, já que ninguém tinha listado o modelo de embeddings como algo que poderia mudar.

39.7 Erros e limites

Três erros são comuns: nenhum responsável pelo modelo de ameaças ou pelo conjunto de avaliação; exceções sem datas de expiração; e uma desativação que esquece pesos e credenciais. Sem responsáveis, os modelos de ameaças e os conjuntos param de mudar enquanto o sistema continua mudando, e a distância cresce sem ser vista. Exceções sem expiração se acumulam até que ninguém saiba quais ainda são necessárias. Uma desativação que remove a interface, mas deixa pesos e credenciais para trás, cria um sistema sem monitoramento guardando material sensível. A revisão trimestral de Sam confere os nomes dos responsáveis, as datas das exceções e o inventário contra o que de fato está rodando.

Exercícios

Síntese

Uma segurança de IA manutenível parte do princípio da mudança: atualizações fixadas e com portão, conhecimento com dono e atualizado, dívida gerenciada e desativação deliberada.

Continue estudando — capítulo 39 de 50

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