Capítulo 25 — Ateliê de projeto I
Mapa da aula
Aula 25 publicada. Mapa, exemplo, EX073.
flowchart TD
N0["25.1 Formato do ateliê"]
N1["25.2 O briefing sintético"]
N2["25.3 O pacote de projeto"]
N3["25.4 Crítica"]
N4["25.4b Tabelas de trade-offs"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX073"]
Desenho lógico
flowchart LR
N0["25.1 Formato do ateliê"]
N1["25.2 O briefing sintético"]
N2["25.3 O pacote de projeto"]
N3["25.4 Crítica"]
N4["25.4b Tabelas de trade-offs"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX073"]
[25.1 Formato do ateliê]
|
v
[25.2 O briefing sintético]
|
v
[25.3 O pacote de projeto]
|
v
[25.4 Crítica]
|
v
[25.4b Tabelas de trade-offs]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX073]
Objetivos de aprendizagem
Você vai (1) trabalhar em equipe para projetar um subsistema com IA com requisitos de segurança; (2) apresentar alternativas de projeto e seus trade-offs; (3) receber críticas ao projeto e responder a elas; e (4) produzir um pacote de projeto (requisitos, arquitetura, modelo de ameaças, plano de verificação).
25.1 Formato do ateliê
Equipes de três a cinco pessoas recebem um briefing, produzem um projeto em duas semanas, apresentam-no a uma banca e o revisam. A banca desempenha papéis: operador, atacante, avaliador de segurança física e dono do orçamento. O objetivo é praticar como fazer e defender trade-offs, e não encontrar um projeto perfeito. Os papéis puxam em direções diferentes de propósito. Um operador quer rapidez e poucos cliques, um atacante quer qualquer caminho até o impacto, um avaliador de segurança física quer que as falhas sejam seguras e um dono do orçamento quer o custo justificado. Um projeto que satisfaz completamente um papel costuma falhar com outro, e as perguntas da banca expõem isso antes que qualquer código seja escrito.
25.2 O briefing (sintético)
Projete um assistente baseado em LLM que ajude os planejadores dos depósitos da NRS a programar inspeções usando o histórico de manutenção, previsões do tempo e boletins de fornecedores. Ele pode propor mudanças na programação; um planejador precisa aprová-las. O briefing é pequeno, mas contém a tensão central do curso. O histórico de manutenção é interno, as previsões do tempo vêm de um feed externo e os boletins de fornecedores são escritos por terceiros, de modo que três níveis de confiança se encontram em um único assistente. O assistente só pode propor, mas propostas de adiar inspeções afetam a segurança ferroviária. As equipes precisam decidir até onde cada fonte pode influenciar uma proposta e o que um planejador precisa ver antes de aprová-la.
25.3 O pacote de projeto
- Contexto e partes interessadas. 2. Requisitos (funcionais, de segurança, estatísticos, operacionais) com métodos de verificação. 3. Arquitetura com fronteiras de confiança e um ponto de política externo. 4. Modelo de ameaças classificado e mapeado para OWASP/ATLAS. 5. Plano de verificação: conjuntos de avaliação, tamanhos de amostra, portões. 6. Riscos residuais e questões em aberto. A ordem espelha o modo como um revisor lê: para quem é o sistema, o que ele precisa fazer, como é construído, o que pode dar errado, como isso será verificado e o que resta. Cada item faz referência aos anteriores, de modo que uma ameaça aponta para o requisito que ela coloca em risco e para o teste que vai verificar o controle. Um pacote sem plano de verificação é devolvido sem ser lido, porque sem ele nada mais pode ser verificado.
25.4 Crítica
Cada papel da banca faz perguntas a partir de sua perspectiva. O papel do atacante é especialmente valioso: "Eu controlo um espelho do feed meteorológico. O que posso fazer?" As equipes precisam responder com sua arquitetura, e não com promessas sobre o modelo. Uma resposta como "o modelo vai ignorar instruções maliciosas" falha, porque depende de um comportamento que ninguém pode garantir. Uma resposta aceitável aponta para a arquitetura: os valores do feed meteorológico passam por um validador que só aceita números dentro dos limites físicos, e qualquer mudança na programação ainda precisa da aprovação de um planejador, com a fonte exibida. As equipes aprendem a receber bem as perguntas difíceis, já que cada uma encontrada no ateliê é uma a menos encontrada em serviço.
25.4b Tabelas de trade-offs
Apresente as alternativas em uma tabela com colunas para efeito na segurança, efeito na segurança física, atrito para o usuário, custo e risco residual. Assim a banca consegue ver por que uma opção foi rejeitada, em vez de adivinhar. Por exemplo, "sem acesso a ferramentas" tem o menor risco, mas perde a maior parte do benefício; "acesso livre a ferramentas" tem o maior benefício e risco inaceitável; "proposta mais aprovação" fica no meio. Ser explícito sobre o que cada opção sacrifica convence mais do que afirmar que alguma opção não custa nada.
A revisão do assistente de planejamento de Sam cabe em uma tabela assim: "boletins lidos diretamente no prompt" foi rejeitada por seu risco residual, enquanto "resumidos por um modelo de baixo privilégio, mais duas aprovações para mudanças críticas para a segurança" aceitou algum atrito extra para o planejador em troca de um pior caso limitado.
25.5 Exemplo resolvido (caso sintético da NRS)
A equipe de Sam propôs ler os boletins de fornecedores diretamente no prompt do planejador. O membro da banca no papel de atacante mostrou (em termos de projeto) que um boletim poderia pedir ao modelo que adiasse as inspeções de uma rota. A equipe revisou: os boletins são resumidos por um modelo separado de baixo privilégio cuja saída é rotulada como não confiável; mudanças na programação que afetam inspeções críticas para a segurança exigem duas aprovações; e toda mudança proposta mostra os documentos de origem que a influenciaram. A revisão mostra o padrão que o ateliê quer ensinar: o ataque foi respondido mudando a estrutura, e não melhorando o prompt.
25.6 Erros e limites
Três erros são comuns: projetos que dependem de o modelo "ignorar" texto malicioso; pacotes sem planos de verificação; e respostas defensivas à crítica. Depender de o modelo ignorar texto malicioso é uma promessa, não um controle. Um pacote sem plano de verificação não consegue mostrar que algum requisito é atendido. Respostas defensivas, como argumentar que um atacante nunca tentaria algo, desperdiçam o feedback mais útil da banca. A equipe de Sam adotou uma regra para o ateliê: toda crítica recebe uma resposta escrita dizendo aceita, rejeitada com motivo, ou adiada com um responsável e uma data.
Exercícios
- EX073 — Pacote. Liste as seis partes do pacote de projeto. Rubrica: 3 = as seis; 2 = quatro; 1 = duas; 0 = nenhuma.
- EX074 — Pergunta do atacante. Responda à pergunta do espelho do feed meteorológico para o seu projeto. Rubrica: 3 = identifica o caminho de influência e o limite arquitetural; 2 = parcial; 1 = depende do modelo; 0 = nenhuma.
- EX075 — Duas aprovações. Por que exigir duas aprovações apenas para mudanças críticas para a segurança? Rubrica: 3 = controle proporcional, limita o atrito enquanto restringe o risco de alto impacto; 2 = parcial; 1 = vago; 0 = errado.
Síntese
O ateliê pratica a habilidade central da engenharia: fazer trade-offs explícitos e defendê-los diante de operadores, atacantes, avaliadores de segurança física e donos do orçamento.
Continue estudando — capítulo 25 de 50
← Capítulo 24 (rascunho) · Índice de capítulos do curso · Capítulo 26 (rascunho) →