OpenCyber Academy
Profissionalizante · Capítulo 6 · Português
Código do curso: OCA-043Capítulo 06: OCA-043-C006

Capítulo 6 — Segurança de IA e aprendizado de máquina: fluxo de trabalho operacional

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 06 publicada. Mapa, exemplo, EX026.

flowchart TD
  N0["6.1 Fluxo de trabalho"]
  N1["6.2 Triagem"]
  N2["6.3 Acompanhamento da remediação"]
  N3["6.4 Gestão de mudanças"]
  N4["6.5 Trabalho com a operação"]
  N5["6.7b Dar retorno a quem relatou"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX026"]

Desenho lógico

flowchart LR
  N0["6.1 Fluxo de trabalho"]
  N1["6.2 Triagem"]
  N2["6.3 Acompanhamento da remediação"]
  N3["6.4 Gestão de mudanças"]
  N4["6.5 Trabalho com a operação"]
  N5["6.7b Dar retorno a quem relatou"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX026"]
[6.1 Fluxo de trabalho]
    |
    v
[6.2 Triagem]
    |
    v
[6.3 Acompanhamento da remediação]
    |
    v
[6.4 Gestão de mudanças]
    |
    v
[6.5 Trabalho com a operação]
    |
    v
[6.7b Dar retorno a quem relatou]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX026]

Objetivos de aprendizagem

Você vai (1) seguir um fluxo de trabalho de segurança de IA da entrada ao encerramento; (2) fazer a triagem das constatações por gravidade; (3) acompanhar a remediação; (4) gerenciar mudanças em sistemas de IA; e (5) trabalhar com as equipes de operação.

6.1 Fluxo de trabalho

Entrada (um novo serviço de IA, uma mudança ou uma preocupação) → contexto e fluxo de dados → cenários de risco → testes → constatações → remediação → verificação → encerramento e registros. Cada etapa tem um responsável e um registro. Na Meridian, uma edição de prompt é uma entrada tanto quanto um novo serviço, como o novo teste de Sofia mostrou. Registre o resultado de cada etapa no controle de pendências. O controle de Sofia tem uma linha por etapa. Um novo serviço de IA, uma edição de prompt ou uma preocupação de um analista começam todos pela entrada, e nada pula a verificação antes do encerramento. Os registros de cada etapa permitem que um auditor acompanhe uma constatação desde a primeira preocupação até sua nota de encerramento.

6.2 Triagem

A gravidade considera o impacto (dinheiro, dados, pessoas afetadas, aspectos legais), a probabilidade (quão fácil, quão exposto) e a detectabilidade. Constatações que permitem a pessoas de fora executar ações nas contas de outros ou ver os dados deles costumam ser altas ou críticas. Sofia classificou como altos os retornos urgentes por envios com injeção e a divulgação do andamento de sinistros, e como média a enxurrada de mensagens longas. Escreva uma justificativa para cada classificação, para que o responsável veja como o impacto e a probabilidade foram julgados. As classificações usam a escala de impacto e probabilidade combinada com o negócio, para que uma classificação alta signifique a mesma coisa em todas as equipes.

6.3 Acompanhamento da remediação

Cada constatação recebe um responsável, um prazo conforme a gravidade, uma correção, um teste de verificação e uma nota de encerramento. Riscos aceitos precisam de um aprovador nomeado e de uma data de revisão. Na Meridian, cada uma das três constatações de Sofia tem responsável e prazo. Revise semanalmente as constatações em aberto e escale as que estiverem vencidas. Encerre uma constatação somente depois que o teste de verificação passar e a nota de encerramento disser o que mudou. Constatações altas vencidas vão para o gestor do responsável pelo produto. O controle mostra de relance a situação de cada constatação para o responsável pelo produto.

6.4 Gestão de mudanças

Atualizações de modelo, edições de prompt, novas fontes de documentos, novas ferramentas e mudanças de configuração alteram o comportamento. Faça-as passar pela gestão de mudanças, com um novo teste antes da liberação. Na Meridian, uma edição de prompt um mês depois dos testes trouxe de volta a constatação 1, que só um novo teste detectou. Escreva quais testes devem ser repetidos para cada tipo de mudança e guarde os resultados com o registro da mudança. Uma atualização de modelo normalmente exige a bateria completa, enquanto uma nova fonte de documentos exige pelo menos os testes de recuperação e de injeção sobre essa fonte.

6.5 Trabalho com a operação

Combine como os alertas chegam até você, como você aciona o plantão e quem pode desativar uma ferramenta numa emergência. Compartilhe os runbooks.

"""Lab A: spotting extraction-style abuse in a synthetic API log.
Flags clients whose query volume or input diversity is anomalous."""
import random, statistics
rng = random.Random(21)
log = []
for c in range(12):
    for _ in range(rng.randint(40, 90)):
        log.append((f"client{c:02d}", round(rng.gauss(0, 1), 1)))
for i in range(600):                      # synthetic scraper: many, grid-like inputs
    log.append(("client99", round(-3 + 6*(i % 61)/60, 1)))
by = {}
for c, x in log: by.setdefault(c, []).append(x)
vol = {c: len(v) for c, v in by.items()}
med = statistics.median(vol.values()); mad = statistics.median(abs(v-med) for v in vol.values())
for c in sorted(by):
    z = (vol[c]-med)/(1.4826*mad); uniq = len(set(by[c]))/len(by[c])
    flag = "FLAG" if z > 3.5 else "ok"
    print(f"{c} queries={vol[c]:3d} robust_z={z:6.2f} distinct_ratio={uniq:.2f} {flag}")

Saída esperada:

client00 queries= 50 robust_z= -0.34 distinct_ratio=0.56 ok
client01 queries= 64 robust_z=  0.45 distinct_ratio=0.52 ok
client02 queries= 81 robust_z=  1.41 distinct_ratio=0.44 ok
client03 queries= 46 robust_z= -0.56 distinct_ratio=0.52 ok
client04 queries= 52 robust_z= -0.22 distinct_ratio=0.48 ok
client05 queries= 40 robust_z= -0.90 distinct_ratio=0.57 ok
client06 queries= 42 robust_z= -0.79 distinct_ratio=0.57 ok
client07 queries= 87 robust_z=  1.74 distinct_ratio=0.48 ok
client08 queries= 56 robust_z=  0.00 distinct_ratio=0.52 ok
client09 queries= 50 robust_z= -0.34 distinct_ratio=0.62 ok
client10 queries= 68 robust_z=  0.67 distinct_ratio=0.50 ok
client11 queries= 89 robust_z=  1.85 distinct_ratio=0.42 ok
client99 queries=600 robust_z= 30.58 distinct_ratio=0.10 FLAG

Na Meridian, Sofia combina com a operação quem pode desativar a ferramenta de retorno do ClaimChat se os agendamentos urgentes dispararem. Teste o procedimento num exercício simulado antes que ele seja necessário e registre quanto tempo levou. Os runbooks devem dizer como desativar a ferramenta de retorno, quem decide, como os clientes são informados e como reativá-la depois que uma correção for verificada. Pratique a desativação na homologação. Nomeie um contato substituto para o caso de o plantão não ser encontrado.

6.6 Exemplo resolvido (caso sintético da Meridian)

As três constatações de Sofia: (1) retornos urgentes por envios com injeção — alta; (2) o ClaimChat revela o andamento de qualquer sinistro a partir do número e de um CEP — alta; (3) enxurradas de mensagens longas — média. Responsáveis e prazos são definidos. Um mês depois, a equipe de produto edita o prompt de sistema; a gestão de mudanças dispara um novo teste, que mostra que a constatação 1 voltou porque a edição removeu uma instrução da qual a equipe dependia. Sofia usa isso para defender que a regra dos retornos urgentes passe para dentro da própria ferramenta de retorno.

A regressão mostra por que os controles precisam ficar nas ferramentas.

6.7 Erros e limites

Três erros são comuns: constatações sem responsáveis ou prazos; edições de prompt fora da gestão de mudanças; e controles que existem apenas no prompt. Cada erro deixa os problemas voltarem. Uma constatação sem responsável ou prazo fica à deriva. Uma edição de prompt fora da gestão de mudanças pode desfazer uma correção sem que ninguém perceba, como a edição da Meridian fez com a constatação 1. Um controle que existe apenas no prompt pode ser removido pela próxima edição ou sobreposto por texto injetado. Verifique os três no seu controle de pendências e no seu processo de mudanças.

6.7b Dar retorno a quem relatou

Quando um analista de sinistros relata um comportamento estranho do ClaimChat, a equipe de segurança diz a ele o que foi encontrado e o que mudou. As pessoas só continuam relatando quando os relatos visivelmente levam a algum lugar, por isso o retorno é parte do fluxo de trabalho, não uma cortesia. Registre o retorno na constatação, com a data. A nota de Sofia ao analista que primeiro levantou os retornos urgentes nomeava a constatação, a regra na ferramenta e o resultado do novo teste, em linguagem simples, sem detalhes técnicos de que o analista não precisava. Uma nota curta como essa leva minutos e mantém os relatos chegando.

Exercícios

Síntese

Um fluxo de trabalho claro — da entrada ao encerramento, com triagem, acompanhamento e gestão de mudanças — mantém o trabalho de segurança de IA em movimento e evita regressões.

Continue estudando — capítulo 06 de 12

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

Respostas comentadas

EX026. Entrada (responsável pelo produto) → contexto e fluxos (profissional) → cenários (profissional e responsável) → testes (profissional) → constatações (profissional) → remediação (engenharia) → verificação (profissional) → encerramento (líder de segurança).

EX027. 1. Alta: pessoas de fora podem perturbar os analistas e atrasar clientes legítimos, e é fácil de fazer. 2. Alta: dados pessoais são expostos, e basta um CEP. 3. Média: impacto em custo e disponibilidade, mitigado pelas cotas do fornecedor.

EX028. - Constatação 2. Responsável: líder de engenharia do ClaimChat. Prazo: 14 dias (alta). - Correção: a ferramenta de andamento verifica se o sinistro pertence ao cliente autenticado. - Teste: DIS-01 a DIS-20 devem dar 0 divulgações. - Encerramento: verificado na homologação v2.3, com a data.

EX029. O controle era uma instrução no prompt de sistema, e a edição a removeu. A correção duradoura é impor a regra dos retornos urgentes na ferramenta de retorno, independentemente do prompt.

EX030. Calcule as requisições por conta por hora e depois escores z robustos, usando a mediana e o MAD. Alerte para valores muito atípicos (por exemplo, z > 10) e envie-os para a triagem, como com client99 no laboratório.