Capítulo 5 — Segurança de IA e aprendizado de máquina: alternativas de projeto
Mapa da aula
Aula 05 publicada. Mapa, exemplo, EX021.
flowchart TD
N0["5.1 Gerar antes de escolher"]
N1["5.2 Padrões"]
N2["5.3 Lado do modelo versus lado do sistema"]
N3["5.4 Comparando projetos"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX021"]
Desenho lógico
flowchart LR
N0["5.1 Gerar antes de escolher"]
N1["5.2 Padrões"]
N2["5.3 Lado do modelo versus lado do sistema"]
N3["5.4 Comparando projetos"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX021"]
[5.1 Gerar antes de escolher]
|
v
[5.2 Padrões]
|
v
[5.3 Lado do modelo versus lado do sistema]
|
v
[5.4 Comparando projetos]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX021]
Objetivos de aprendizagem
Você vai (1) gerar várias arquiteturas para uma funcionalidade de IA; (2) compará-las quanto a segurança, utilidade, custo e reversibilidade; (3) aplicar padrões como separação de privilégios, planejar-e-executar e saídas estruturadas; (4) avaliar defesas do lado do modelo versus do lado do sistema; e (5) apresentar um compromisso (trade-off) de projeto.
5.1 Gerar antes de escolher
Uma falha comum é proteger o primeiro projeto proposto. Gere pelo menos três: o projeto mínimo (o modelo redige, um humano age); o agente limitado (o modelo chama ferramentas estreitas com verificações externas); e o agente amplo (o modelo tem ferramentas gerais). Depois compare. Muitas vezes o projeto mínimo entrega a maior parte do valor com pouco risco. A comparação de remarcação de Amira, no exemplo resolvido abaixo, começa com três projetos. Para a remarcação na Corvane, o projeto mínimo mantém um clique humano em cada alteração. Escreva cada projeto com seu limite de dano antes de pontuar qualquer um deles, para que a primeira ideia não ancore a comparação.
5.2 Padrões
Separação de privilégios: um componente lê conteúdo não confiável sem acesso a ferramentas e devolve dados estruturados; outro, que nunca vê o texto não confiável bruto, decide as ações. Planejar-e-executar: o modelo propõe um plano num esquema fixo; um verificador determinístico o valida contra a política antes da execução. Saídas estruturadas: as ações são campos tipados, não texto livre, de modo que a validação é exata. Credenciais com escopo: as chamadas de ferramenta rodam com os direitos do usuário final, nunca com uma conta de serviço capaz de alcançar todos os registros. O projeto de remarcação de Amira usa separação de privilégios e saídas estruturadas.
5.3 Lado do modelo versus lado do sistema
Defesas do lado do modelo — treinamento de segurança, classificadores de injeção, consultas estruturadas — reduzem a taxa de saídas ruins. Defesas do lado do sistema — verificações de política, limites, sandboxing, confirmação — limitam o dano quando saídas ruins acontecem. Wei et al. (arXiv:2307.02483) analisam por que o treinamento de segurança falha contra jailbreaks, o que sustenta a visão de que defesas do lado do modelo não devem ser a única camada. Use as duas, mas ponha as garantias no sistema. Na Corvane, o classificador de injeção fica do lado do modelo e o serviço de política do lado do sistema; a avaliação mostrou que só o segundo chegou perto de dano zero.
5.4 Comparando projetos
Pontue cada projeto em: limite de dano (perda no pior caso por incidente), taxa de falha esperada, valor para o usuário, custo de operação, esforço de implementação e reversibilidade. Apresente uma tabela e uma recomendação e diga quais pontuações são estimativas. Para a remarcação, a tabela de Amira mostraria o projeto C com dano ilimitado, o projeto A com pouco valor e o projeto B com um teto e muito valor. Marque quais pontuações são medidas e quais são estimativas. Apresente a tabela ao dono do produto com a recomendação e registre a decisão com seu responsável e seus gatilhos de revisão.
5.5 Exemplo resolvido (caso sintético da Corvane)
Para a remarcação, Amira compara: (A) o Copilot redige uma remarcação e um atendente clica para confirmar — limite de dano de uma reserva errada por clique, valor moderado; (B) o Copilot propõe uma remarcação estruturada, verificada contra o dono da remessa e as regras de data, executada automaticamente para remessas abaixo de €2.000 — limite de dano dado pelo teto de valor, valor alto; (C) o Copilot tem uma chave geral da API de logística — limite de dano: todo o banco de dados de remessas. Ela recomenda B com separação de privilégios: um modelo leitor converte os e-mails das transportadoras em campos; o planejador nunca vê o texto bruto do e-mail.
5.6 Erros e limites
Três erros são comuns: comparar um único projeto com "não fazer nada"; confiar em instruções do prompt como fronteira; e credenciais de ferramenta de conta de serviço. Cada erro estreita a escolha de modo injusto. Comparar um projeto com não fazer nada esconde opções seguras mais baratas, como o projeto mínimo. Instruções do prompt podem ser sobrepostas por texto injetado, por isso não podem ser a fronteira. Uma credencial de conta de serviço deixa uma única instrução injetada alcançar todos os registros, como faria a chave geral de API do projeto C. Uma revisão de projeto que caia numa dessas armadilhas deve voltar à equipe antes da aprovação.
Exercícios
- EX021 — Três projetos. Proponha três projetos para uma funcionalidade baseada em LLM que responde a perguntas sobre a folha de pagamento. Rubrica: 3 = mínimo, limitado e amplo, com as diferenças; 2 = dois; 1 = um; 0 = nenhum.
- EX022 — Separação de privilégios. Explique como a separação de privilégios limita a injeção indireta no projeto B. Rubrica: 3 = o texto não confiável não alcança o planejador; só campos tipados passam; risco residual pelos valores dos campos; 2 = sem o residual; 1 = vago; 0 = errado.
- EX023 — Modelo ou sistema. Classifique seis defesas como do lado do modelo ou do lado do sistema. Rubrica: 3 = as seis; 2 = cinco; 1 = três ou quatro; 0 = menos.
- EX024 — Tabela comparativa. Monte a tabela comparativa dos projetos A–C. Rubrica: 3 = seis critérios, estimativas marcadas, recomendação; 2 = quatro critérios; 1 = vago; 0 = nenhuma.
- EX025 — Credenciais. Por que as chamadas de ferramenta devem usar os direitos do usuário final? Rubrica: 3 = confused deputy, raio de impacto, auditoria; 2 = dois; 1 = um; 0 = nenhum.
Síntese
Um bom projeto de segurança de IA gera alternativas e as compara abertamente, pondo as garantias em controles do lado do sistema e usando defesas do lado do modelo para reduzir as taxas de falha.
Continue estudando — capítulo 05 de 12
← Capítulo 04 (rascunho) · Índice de capítulos do curso · Capítulo 06 (rascunho) →