Segurança, Privacidade e Governança de IA

12.1 OWASP Top 10 para aplicações com LLM

(Baseado na versão 2025 da lista; consulte a versão atual no site do OWASP.)

12.2 Prompt injection direta e indireta

• Direta: o próprio usuário tenta manipular ("finja que não tem regras").
• Indireta: a instrução vem num conteúdo que o sistema lê: página web, e-mail, documento do RAG, resultado de ferramenta. É a mais perigosa, porque o usuário legítimo nem vê.

As camadas

1. Separar dado de instrução: delimitar o conteúdo externo com uma etiqueta aleatória que o atacante não consegue "fechar".
2. Detectar sinais no conteúdo e avisar o modelo (heurísticas, classificadores).
3. Limpar a saída: links e imagens para fora são o canal clássico de exfiltração (renderizar a imagem já envia os dados na URL).
4. Menor privilégio e aprovação humana para tudo que tem efeito (12.3).
5. Monitorar e transformar ataques encontrados em testes (12.5).

python python/01_injecao_indireta.py

12.3 Segurança de ferramentas e agentes

A tríade letal

O risco é máximo quando o mesmo agente tem as três coisas:

Corte pelo menos uma perna: separe agentes, remova o canal de saída ou exija aprovação humana nele. O projeto tem um verificador automático:

verificarTriadeLetal([
  { nome: "ler_crm", acessaDadosPrivados: true },
  { nome: "ler_email", recebeConteudoNaoConfiavel: true },
  { nome: "enviar_email", comunicaComExterior: true },          // sem aprovação → risco: true
]);

• Menor privilégio: credenciais das ferramentas só com o necessário (banco só leitura, escopos OAuth mínimos).
• Identidade do usuário, não do modelo: autorização pela sessão autenticada, nunca por um id que o modelo passou (Módulo 5.6).
• Sandbox para execução de código e acesso a arquivos: contêiner sem rede, sem segredos, com tempo e memória limitados.
• Aprovação humana para ações irreversíveis, com o que será feito visível (Módulos 6 e 10).

12.4 Dados pessoais e segredos no contexto

Os guardrails do projeto detectam dados pessoais validando, não só casando padrões:

detectarDadosSensiveis("Pedido 123.456.789-00 e CPF 529.982.247-25")
// → só o segundo: o primeiro tem formato de CPF, mas os dígitos verificadores não batem

mascarar("Sou Ana, CPF 52998224725, cartão 4111-1111-1111-1111, [email protected], (31) 98765-4321.")
// → "Sou Ana, CPF [CPF], cartão [CARTAO], [EMAIL], [TELEFONE]."

• Na entrada: mascarar o que o modelo não precisa ver.
• Na saída: conferir se a resposta traz dados de terceiros.
• Nos logs: prompts e respostas são dados pessoais; mascarar, limitar acesso e retenção.
• No RAG: filtrar a busca pelas permissões do usuário antes de chegar ao modelo.
• Segredos: chaves e tokens nunca no prompt; detectores de formato conhecido na entrada, na saída e no código (Módulo 7).

12.5 Red teaming automatizado

O harness do projeto roda 12 ataques em seis categorias contra um alvo e avalia por consequências verificáveis, não por impressão: o segredo canário do prompt de sistema apareceu? Há link para fora? Uma ferramenta proibida foi chamada? Dados pessoais saíram?

O teste com o modelo comprometido

Nos testes, o "modelo" é falso e obedece a todo ataque: repete o segredo, copia links e chama a ferramenta de reembolso. Com ele, a versão ingênua do alvo falha em 12 de 12. A versão protegida, com o mesmo modelo comprometido, bloqueia o canário, os links e o reembolso, porque essas defesas estão no código. O que resta (o modelo ainda "fala" um CPF) fica documentado no teste como a próxima defesa a implementar, em vez de escondido.

npm test                # 13 testes, incluindo o modelo comprometido
npm run redteam         # contra o modelo real (precisa de ANTHROPIC_API_KEY)

12.6 Vieses, explicabilidade e uso responsável

• Vieses aparecem no resultado, não no prompt: avalie o eval estratificado por grupo (região, gênero, faixa etária, quando aplicável e permitido) e compare taxas de erro.
• Teste contrafactual: troque só o nome ou o bairro num caso e veja se a decisão muda.
• Explicabilidade possível: LLMs não explicam com fidelidade o próprio raciocínio interno. Explique o sistema: quais dados entraram, qual regra decidiu, qual trecho foi citado. Por isso decisões importantes ficam em regras e pessoas, com o LLM preparando o caso.
• Transparência com o usuário: dizer quando ele fala com uma IA, o que ela faz e como chegar a um humano.

12.7 Regulação, normas e governança

Material didático, não é aconselhamento jurídico: leis mudam, e a aplicação depende do caso. Envolva o jurídico e o encarregado de dados (DPO).

python python/02_ficha_do_sistema.py      # usa dados/questionario.json (um assistente de crédito)

## Classificação de risco: **ALTO**

## Obrigações e práticas a verificar
- [ ] LGPD: base legal definida para cada finalidade (art. 7º; art. 11 para dados sensíveis)
- [ ] LGPD: direito de revisão de decisões tomadas unicamente com base em tratamento automatizado (art. 20); explicar critérios
- [ ] Brasil: acompanhar o marco legal de IA (PL 2338/2023) e normas setoriais (BC, ANS, CFM, CVM...)
- [ ] Boa prática (ISO/IEC 42001, NIST AI RMF): dono do sistema, inventário de modelos, ...

Projeto do módulo: red team de um app do curso

1. Adapte o harness para atacar um projeto seu do curso (o RAG do Módulo 4, o agente do Módulo 6 ou o app do Módulo 8): escreva a função alvo.
2. Amplie o conjunto para pelo menos 30 ataques, incluindo os específicos do seu domínio.
3. Rode contra o modelo real, com 3 repetições. Documente os ataques bem-sucedidos.
4. Implemente as correções em camadas (inclusive o filtro de dados pessoais na saída, a lacuna que o teste documenta) e mostre o antes e depois.
5. Coloque o red team no CI como teste de regressão, e escreva a ficha do sistema (lab 12.7).

Critérios de avaliação

Recursos para aprofundar

• OWASP Top 10 for LLM Applications
• The lethal trifecta · o modelo mental de risco para agentes
• LGPD (texto oficial) e ANPD
• AI Act da UE (texto oficial)
• NIST AI Risk Management Framework