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
- EX026 — Fluxo de trabalho. Desenhe o fluxo de trabalho para o pedido de uma nova funcionalidade de IA. Rubrica: 3 = as oito etapas, com responsáveis; 2 = seis; 1 = três; 0 = nenhuma.
- EX027 — Gravidade. Classifique as três constatações, com justificativas. Rubrica: 3 = três classificações com justificativas de impacto/probabilidade; 2 = duas; 1 = só as classificações; 0 = nenhuma.
- EX028 — Controle de pendências. Escreva uma entrada no controle para a constatação 2. Rubrica: 3 = responsável, prazo, correção, teste, encerramento; 2 = quatro; 1 = dois; 0 = nenhum.
- EX029 — Regressão. Por que a constatação 1 voltou, e qual é a correção duradoura? Rubrica: 3 = controle baseado no prompt foi removido; impor na ferramenta; 2 = parcial; 1 = vago; 0 = nenhum.
- EX030 — Laboratório de monitoramento. Como você usaria a abordagem do laboratório de monitoramento no ClaimChat? Rubrica: 3 = valores atípicos de volume por conta, z robusto, alerta para triagem; 2 = parcial; 1 = vago; 0 = nenhum.
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) →