Capítulo 25 — Ateliê de projeto em equipe
Mapa da aula
Aula 25 publicada. Mapa, exemplo, EX073.
flowchart TD
N0["25.1 O enunciado do ateliê"]
N1["25.2 Papéis"]
N2["25.3 Revisão por pares"]
N3["25.4 Apresentação às partes interessadas"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX073"]
Desenho lógico
flowchart LR
N0["25.1 O enunciado do ateliê"]
N1["25.2 Papéis"]
N2["25.3 Revisão por pares"]
N3["25.4 Apresentação às partes interessadas"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]
[25.1 O enunciado do ateliê]
|
v
[25.2 Papéis]
|
v
[25.3 Revisão por pares]
|
v
[25.4 Apresentação às partes interessadas]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX073]
Objetivos de aprendizagem
Você vai (1) trabalhar em equipe para proteger um recurso de IA de ponta a ponta; (2) dividir papéis e coordenar o trabalho; (3) revisar o trabalho de segurança dos colegas; e (4) apresentar os resultados às partes interessadas.
25.1 O enunciado do ateliê
Equipes de quatro pessoas recebem um recurso de IA sintético num ambiente de homologação — por exemplo, um assistente de devoluções com duas ferramentas — e seis semanas. Entregas: modelo de ameaças, controles, harness de avaliação e resultados, runbooks e uma apresentação. Cada equipe mantém um registro de decisões compartilhado, para que as razões das escolhas sobrevivam ao projeto. A equipe de Jonas recebeu como enunciado um assistente de reagendamento de entregas, na mesma plataforma de homologação do Ask Brightwell. Seu registro de decisões anotou, por exemplo, por que as regras de reagendamento foram colocadas num serviço de políticas, e não no prompt.
25.2 Papéis
Faça rodízio dos papéis toda semana, para que todos pratiquem cada um: arquiteto (diagramas, decisões de projeto), construtor (controles e código), testador (conjuntos e harness, independente do construtor), operador (monitoramento, runbooks). Quem está no papel de testador não pode testar o próprio código naquela semana; a independência é o objetivo. Na equipe de Jonas, Mei era a testadora na semana em que encontrou a lacuna do prazo de cancelamento, e não tinha escrito o código de política. Essa independência é a razão de ela ter procurado maneiras de contornar as regras, em vez de confirmar que elas funcionavam como pretendido.
25.3 Revisão por pares
Todo controle é revisado por alguém que não o escreveu. As revisões conferem: o código impõe o que o modelo de ameaças diz? Há testes? Os padrões são seguros? Há um jeito de contorná-lo? Os revisores escrevem comentários que nomeiam o problema, por que ele importa e uma correção sugerida. Na equipe de Jonas, as regras de reagendamento foram revisadas por um colega que não as tinha escrito. A revisão perguntou se as regras correspondiam ao cenário do modelo de ameaças sobre o bloqueio do cancelamento, e foi assim que a verificação de data ausente se tornou um problema nomeado, com uma correção sugerida.
25.4 Apresentação às partes interessadas
Dez minutos: o que o recurso faz, os principais riscos, os controles, as evidências (com intervalos), o risco residual e a decisão que você recomenda. Espere perguntas de um dono de produto (valor), de um líder de suporte (usabilidade) e de um líder de segurança (evidências). A apresentação do assistente de reagendamento pela equipe de Jonas terminou com um slide de risco residual: mudanças feitas por telefone contornam as regras do assistente. O líder de suporte perguntou como a equipe saberia disso, o que levou a uma nota no runbook do suporte. O líder de segurança perguntou como o resultado de 0 em 60 foi avaliado, e a equipe mostrou o avaliador baseado nos registros das ferramentas.
25.5 Exemplo resolvido (caso sintético da Brightwell)
A equipe de Jonas protege um assistente de "reagendamento de entregas". A testadora daquela semana, Mei, escreve casos adaptativos sem ver o código de política e descobre que um cliente pode reagendar uma entrega para uma data posterior ao prazo de cancelamento do pedido, o que na prática bloqueia o cancelamento. O construtor acrescenta a regra; o harness confirma que, depois disso, 0 de 60 casos adaptativos têm sucesso. A equipe apresenta com um slide de risco residual: mudanças pelo canal telefônico contornam as regras do assistente. O achado veio de uma testadora independente, e a correção foi confirmada pelo harness, e não pela palavra do construtor.
25.6 Erros e limites
Três erros são comuns: uma única pessoa fazendo todo o trabalho de segurança; testadores revisando o próprio código; e apresentações sem risco residual. A equipe de Jonas evitou esses erros fazendo rodízio de papéis, mantendo a testadora independente do código daquela semana e apresentando o contorno pelo canal telefônico como risco residual. Uma única pessoa fazendo todo o trabalho teria testado apenas o que ela mesma construiu. Uma apresentação sem risco residual teria deixado os donos supor que as mudanças por telefone estavam cobertas. O rodízio semanal de papéis é o que impede cada um desses erros, porque ninguém ocupa o mesmo papel duas semanas seguidas.
Exercícios
- EX073 — Papéis. Explique por que o papel de testador deve ser independente. Rubrica: 3 = pontos cegos, premissas compartilhadas com o construtor, credibilidade das evidências; 2 = dois; 1 = um; 0 = nenhum.
- EX074 — Comentário de revisão. Escreva um comentário de revisão sobre uma regra de política sem negação por padrão. Rubrica: 3 = problema, impacto, correção; 2 = dois; 1 = vago; 0 = nenhum.
- EX075 — Apresentação. Esboce a apresentação de dez minutos da equipe de Mei. Rubrica: 3 = recurso, riscos, controles, evidências, risco residual, decisão; 2 = quatro ou cinco; 1 = dois; 0 = nenhum.
Síntese
Os ateliês em equipe ensinam a segurança como uma prática compartilhada: rodízio de papéis, testes independentes, revisão por pares e apresentação honesta.
Continue estudando — capítulo 25 de 30
← Capítulo 24 (rascunho) · Índice de capítulos do curso · Capítulo 26 (rascunho) →