Capítulo 16 — Engenharia de sistemas
Mapa da aula
Aula 16 publicada. Mapa, exemplo, EX046.
flowchart TD
N0["16.1 O modelo em V"]
N1["16.2 Decomposição de requisitos"]
N2["16.3 Interfaces e emergência"]
N3["16.4 Análise de perigos"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX046"]
Desenho lógico
flowchart LR
N0["16.1 O modelo em V"]
N1["16.2 Decomposição de requisitos"]
N2["16.3 Interfaces e emergência"]
N3["16.4 Análise de perigos"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]
[16.1 O modelo em V]
|
v
[16.2 Decomposição de requisitos]
|
v
[16.3 Interfaces e emergência]
|
v
[16.4 Análise de perigos]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX046]
Objetivos de aprendizagem
Você vai (1) aplicar o modelo em V da engenharia de sistemas a sistemas com IA; (2) decompor requisitos de sistema em requisitos de componentes com métodos de verificação; (3) gerenciar interfaces e comportamento emergente; e (4) usar análise de perigos que inclua modos de falha de IA.
16.1 O modelo em V
A engenharia de sistemas desce das necessidades das partes interessadas para os requisitos de sistema, a arquitetura, o projeto de componentes e a implementação, e depois sobe pela verificação de componentes, pelos testes de integração, pela verificação do sistema e pela validação contra as necessidades. Todo requisito do lado esquerdo tem uma atividade de verificação do lado direito. Componentes de IA se encaixam nisso, mas precisam de métodos de verificação estatísticos (taxas com intervalos) em vez de testes únicos de aprovado/reprovado. Uma aprovação do TrackEye é uma taxa declarada com um intervalo, medida em um conjunto de teste nomeado, e não uma única saída correta.
16.2 Decomposição de requisitos
Um requisito de sistema como "defeitos de trilho maiores que 10 mm são detectados com probabilidade ≥ 0,98 em todas as condições de operação" se decompõe em requisitos de câmera, iluminação, modelo, alerta e revisão humana. A parcela do modelo poderia ser "taxa de falsos negativos ≤ 1,5% em cada estrato de condição, com limite superior de 95%", deixando margem para os outros componentes. A divisão é um orçamento. Se o modelo pode deixar passar 1,5%, a etapa de revisão humana e a cadeia de alertas precisam manter suas próprias perdas pequenas o bastante para que a cadeia inteira ainda atinja 0,98. O requisito de cada componente nomeia sua parcela e como será verificado, de modo que uma falta em um ponto fica visível e pode ser compensada em outro, em vez de ser descoberta no fim.
16.3 Interfaces e emergência
Interfaces carregam premissas: o modelo pressupõe imagens com certa resolução e exposição; o sistema de alertas pressupõe que a confiança do modelo está calibrada. O comportamento emergente surge quando componentes interagem — por exemplo, um agente LLM que combina duas ferramentas inofensivas para produzir um efeito danoso. Documentos de controle de interface devem declarar formatos de dados, níveis de confiança e comportamento em falha. Quando o fornecedor da câmera troca um sensor, o documento de interface diz à equipe quais premissas do modelo testar de novo. Para agentes, o dano emergente é encontrado revisando combinações de ferramentas, não ferramentas isoladas: ler um documento e enviar um e-mail são inofensivos cada um, mas juntos podem vazar o documento.
16.4 Análise de perigos
Técnicas como a análise de modos de falha e efeitos (FMEA) e a análise de processos teórica de sistemas (STPA) procuram as maneiras pelas quais o sistema pode atingir estados perigosos. Acrescente os modos de falha de IA: mudança de distribuição, entradas adversariais, envenenamento, excesso de confiança, uso inseguro de ferramentas. O foco da STPA em ações de controle inseguras se encaixa naturalmente em agentes que emitem comandos. A FMEA trabalha de baixo para cima, a partir das falhas de componentes, e serve à cadeia de percepção do TrackEye. A STPA trabalha de cima para baixo, a partir dos perigos, perguntando quais ações de controle seriam inseguras se executadas, omitidas, executadas no momento errado ou por tempo demais. Para o Wrench, uma ação insegura é uma ordem de serviço enviada ao ativo errado, e a STPA pergunta o que levaria o agente a emiti-la.
16.5 Exemplo resolvido (caso sintético da NRS)
Sam preencheu uma linha de FMEA para o TrackEye: modo de falha "defeito não detectado sob ofuscamento"; efeito "defeito não detectado até a próxima passagem"; causa "mudança de distribuição"; detecção "monitoramento do estrato do amanhecer"; severidade 9, ocorrência 4, detecção 5, número de prioridade de risco 180. Uma segunda linha, para "marcação adversarial", teve severidade 9, ocorrência 2, detecção 7 (difícil de detectar), RPN 126. Ambas excederam o limiar de ação de 100. A linha da marcação tem pontuação total menor porque a ocorrência é rara, mas sua pontuação de detecção é pior, já que ninguém monitora padrões deliberados. Exceder 100 dispara ação para as duas linhas, mas as ações diferem: melhores dados do amanhecer para uma, um método de detecção para a outra. Sam registra a base das pontuações, já que a ocorrência de ataques é uma estimativa.
16.6 Erros e limites
Três erros são comuns: requisitos para componentes de IA sem métodos de verificação estatísticos; interfaces que não declaram níveis de confiança; e análises de perigos que ignoram o ataque deliberado. Um requisito como "o modelo detecta defeitos" não pode ser verificado, porque nenhum teste finito o prova; uma taxa com um limite pode. Interfaces sem níveis de confiança deixam texto não confiável fluir para componentes privilegiados sem que ninguém perceba. Análises de perigos que consideram apenas falhas aleatórias deixam de lado os casos em que alguém procura de propósito a pior entrada, o que costuma ser muito pior do que o caso típico que a análise pressupôs.
Exercícios
- EX046 — Decomponha. Decomponha "o Wrench não deve criar ordens de serviço não autorizadas" em três requisitos de componentes. Rubrica: 3 = aplicação de política, confirmação, escopo da ferramenta/registro em log, cada um verificável; 2 = dois; 1 = vago; 0 = nenhum.
- EX047 — RPN. Calcule o RPN para severidade 8, ocorrência 3, detecção 6 e diga se excede 100. Rubrica: 3 = 144, sim; 2 = deslize aritmético; 1 = método; 0 = nenhum.
- EX048 — Emergência. Dê um exemplo de dano emergente a partir de duas ferramentas seguras isoladamente. Rubrica: 3 = cadeia plausível (por exemplo, a busca recupera dados + a ferramenta de e-mail os envia); 2 = cadeia vaga; 1 = ferramenta única; 0 = nenhum.
Síntese
A engenharia de sistemas dá à segurança de IA uma espinha dorsal: requisitos decompostos e verificáveis, interfaces explícitas e análise de perigos que inclui falhas acidentais e adversariais.
Continue estudando — capítulo 16 de 50
← Capítulo 15 (rascunho) · Índice de capítulos do curso · Capítulo 17 (rascunho) →