Capítulo 44 — Projeto final de engenharia I
Mapa da aula
Aula 44 publicada. Mapa, exemplo, EX130.
flowchart TD
N0["44.1 Escolhendo o projeto"]
N1["44.2 Plano do projeto"]
N2["44.3 Aprovação da linha de base"]
N3["44.4 Trabalho em equipe"]
N4["44.4b Ética e autorização no projeto final"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX130"]
Desenho lógico
flowchart LR
N0["44.1 Escolhendo o projeto"]
N1["44.2 Plano do projeto"]
N2["44.3 Aprovação da linha de base"]
N3["44.4 Trabalho em equipe"]
N4["44.4b Ética e autorização no projeto final"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX130"]
[44.1 Escolhendo o projeto]
|
v
[44.2 Plano do projeto]
|
v
[44.3 Aprovação da linha de base]
|
v
[44.4 Trabalho em equipe]
|
v
[44.4b Ética e autorização no projeto final]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX130]
Objetivos de aprendizagem
Você vai (1) definir um projeto final de engenharia de segurança de IA com um cliente, requisitos e restrições; (2) planejá-lo com marcos, riscos e verificação; (3) produzir os requisitos do sistema e a linha de base da arquitetura; e (4) obter a aprovação para construir.
44.1 Escolhendo o projeto
Um bom projeto final tem um cliente real (ou sintético e realista), um componente de IA com risco de segurança significativo, uma entrega que possa ser construída e verificada em dois semestres e uma avaliação clara. Exemplos: um assistente RAG protegido, com aplicação de políticas e uma estrutura de avaliação; um pipeline de dados resistente a envenenamento; um serviço de monitoramento de extração e abuso. Dois semestres passam depressa, então um projeto que precisa de meses de coleta de dados antes de qualquer coisa poder ser construída costuma ser grande demais. Os exemplos compartilham um padrão: uma ameaça clara, um componente que a equipe consegue construir e controlar e uma medição que vai mostrar se ele funciona. Um cliente dá ao projeto requisitos reais e um revisor de fora da universidade.
44.2 Plano do projeto
Inclua: declaração do problema; partes interessadas; escopo e exclusões; requisitos (funcionais, de segurança, estatísticos, operacionais) com métodos de verificação; arquitetura com fronteiras de confiança; modelo de ameaças; plano de verificação; registro de riscos do próprio projeto (acesso a dados, computação, disponibilidade da equipe); marcos e entregas; ética e autorização. O registro de riscos do plano cobre o projeto, não o sistema: um acordo de dados atrasado, um orçamento de nuvem que acaba ou um membro da equipe que adoece. Cada risco tem uma mitigação, como dados sintéticos preparados com antecedência. Os marcos são espaçados de modo que cada um produza algo que a banca possa inspecionar, o que mantém o progresso visível e os problemas, precoces.
44.3 Aprovação da linha de base
Uma banca de revisão aprova a linha de base: requisitos, arquitetura e plano. Após a aprovação, as mudanças passam pelo controle de mudanças, de modo que o aumento de escopo fica visível e justificado. O controle de mudanças não proíbe mudanças. Ele pede que cada mudança declare o que acrescenta, o que custa e quais requisitos ou testes afeta, e que a banca ou o cliente concordem. Uma equipe que acrescenta anexos de imagem ao Bulletin Gate no meio do caminho precisa mostrar que o cronograma ainda funciona e que as novas ameaças estão cobertas, ou adiar a funcionalidade, como planejado originalmente.
44.4 Trabalho em equipe
Atribua papéis (líder, arquiteto de segurança, engenheiro de ML, líder de testes), mas faça rodízio das tarefas de revisão para que todos entendam o todo. Registre as decisões em ADRs e mantenha as reuniões curtas, com ações registradas. Papéis fixos deixam a responsabilidade clara, mas o rodízio das revisões espalha o entendimento, de modo que o projeto sobrevive se um membro faltar. Um arquiteto de segurança que revisa o pipeline de dados do engenheiro de ML, e o inverso, pega problemas que nenhum dos dois veria sozinho. Reuniões curtas com ações escritas evitam decisões que só existem na memória de alguém, e os registros de decisão explicam as escolhas à banca depois.
44.4b Ética e autorização no projeto final
Mesmo projetos sintéticos precisam de uma nota de autorização: quais ambientes, dados e contas a equipe pode usar, e o que é proibido (sistemas de produção, dados pessoais reais, serviços públicos de IA além de seus termos). Se um cliente fornecer dados reais, combine por escrito os termos de proteção de dados antes de recebê-los. Para o Bulletin Gate, a nota nomeou as cópias de homologação do Wrench e do repositório de boletins, apenas boletins sintéticos ou liberados pelos fornecedores e nenhuma conexão com o sistema de ordens de serviço de produção. Ela também cobriu a condição da banca: a outra equipe, que escrevia ataques adaptativos, estava autorizada a atacar apenas a instância de homologação do Bulletin Gate, e suas strings de ataque foram guardadas com as evidências, em vez de compartilhadas fora do curso.
44.5 Exemplo resolvido (caso sintético da NRS)
A equipe de Sam escolheu o "Bulletin Gate": um serviço que ingere os boletins de fornecedores, extrai fatos estruturados de manutenção com um modelo em quarentena, sinaliza conteúdo com cara de instrução e passa apenas registros estruturados ao Wrench. Os requisitos incluíam: acurácia de extração ≥ 95% em 500 boletins reservados; zero texto de instrução nos registros de saída (garantido pelo esquema); latência mediana ≤ 2 s; proveniência completa. Exclusões: anexos de imagem (adiados). A banca aprovou com uma condição: acrescentar um conjunto de testes de ataques adaptativos escrito por outra equipe. O requisito garantido pelo esquema é notável porque é absoluto, e não estatístico: o formato de saída não tem nenhum campo que possa conter texto livre de instrução.
44.6 Erros e limites
Três erros são comuns: projetos finais grandes demais para serem verificados; requisitos sem métodos de verificação; e nenhum controle de mudanças após a aprovação. Um projeto final superdimensionado termina com um sistema parcialmente construído e mal testado, o que resulta em um dossiê fraco. Requisitos sem métodos de verificação não podem ser demonstrados como aprovados e convidam a discussões na revisão final. Sem controle de mudanças, o escopo deriva em silêncio, os prazos escorregam e a banca não consegue dizer o que foi aprovado. A equipe de Sam revisou o escopo contra o esforço de verificação a cada marco. Cortar escopo cedo custou menos do que cortar testes tarde.
Exercícios
- EX130 — Escopo. Escreva o escopo e as exclusões de um projeto final que protege um assistente RAG. Rubrica: 3 = itens no escopo claros e exclusões justificadas; 2 = um lado fraco; 1 = vago; 0 = nenhum.
- EX131 — Registro de riscos. Liste três riscos do projeto e suas mitigações. Rubrica: 3 = três pertinentes, com mitigações; 2 = dois; 1 = um; 0 = nenhum.
- EX132 — Condição da banca. Por que a banca exigiu que outra equipe escrevesse os ataques adaptativos? Rubrica: 3 = independência; quem constrói não enxerga as próprias premissas; 2 = parcial; 1 = vago; 0 = errado.
Síntese
O projeto final I estabelece uma linha de base verificável: um problema realista, requisitos mensuráveis, uma arquitetura defensável, um plano de projeto com riscos e testes adversariais independentes incorporados.
Continue estudando — capítulo 44 de 50
← Capítulo 43 (rascunho) · Índice de capítulos do curso · Capítulo 45 (rascunho) →