Avaliação Sistêmica e Risco
De testador de prompts para avaliador de sistemas críticos. Aprenda a identificar riscos operacionais e cognitivos em escala organizacional.
A Diferença do Nível Masterclass
Na Trilha 3, você aprendeu a testar prompts individuais. Aqui, você aprende a avaliar sistemas inteiros — comportamentos emergentes, riscos operacionais, superfícies de ataque em nível arquitetural e resposta a incidentes. O prompt deixa de ser apenas texto e se torna superfície de risco.
Avaliação Sistêmica de Comportamento
Avaliação sistêmica examina não apenas se prompts individuais funcionam, mas se o sistema como um todo exibe comportamentos desejados de forma consistente e previsível.
Dimensões de Avaliação Sistêmica
Consistência
O sistema produz outputs similares para inputs similares? Variância é aceitável?
Coerência
Outputs de diferentes partes do sistema são compatíveis entre si?
Degradação Graciosa
Como o sistema se comporta em edge cases e condições de estresse?
Alinhamento
O comportamento observado corresponde à intenção de design?
Métodos de Avaliação em Escala
- • Eval sets automatizados: suites de testes que rodam continuamente
- • Red teaming: tentativas deliberadas de quebrar o sistema
- • Shadow testing: comparar sistema novo vs baseline em produção
- • A/B testing comportamental: medir impacto de mudanças em prompts
Risco Operacional e Cognitivo
Sistemas baseados em prompt introduzem categorias de risco que sistemas tradicionais não têm. Distinguimos entre risco operacional (falhas técnicas) e risco cognitivo (falhas de julgamento do modelo).
Matriz de Riscos
| Tipo | Exemplos | Mitigação |
|---|---|---|
| Operacional | Rate limits, latência, custos | Throttling, caching, budgets |
| Cognitivo | Alucinação, viés, inconsistência | Grounding, validação, guardrails |
| Reputacional | Outputs ofensivos, erros públicos | Content filtering, human review |
| Compliance | Vazamento de dados, discriminação | Data masking, bias testing |
Riscos de Alta Severidade
- • Decisões automatizadas irreversíveis
- • Acesso a dados sensíveis
- • Ações financeiras ou legais
- • Comunicação externa automatizada
Riscos de Baixa Severidade
- • Sugestões internas revisáveis
- • Análise de dados agregados
- • Rascunhos com aprovação humana
- • Ferramentas de produtividade pessoal
Prompt Injection em Nível Arquitetural
Prompt injection não é apenas um ataque pontual — é uma classe de vulnerabilidade que afeta toda a arquitetura. O arquiteto precisa pensar em superfícies de ataque em nível sistêmico.
Vetores de Ataque Arquiteturais
Direct Injection
Input malicioso diretamente no prompt do usuário.
Indirect Injection
Payload escondido em dados que o sistema processa (documentos, emails, web).
Cross-Agent Injection
Um agente é comprometido e injeta payloads em outros agentes via outputs.
Persistence Attack
Payload armazenado em memória/histórico que afeta sessões futuras.
Defesas Arquiteturais
- • Privilege separation: diferentes níveis de acesso para diferentes prompts
- • Input sanitization: filtrar/escapar conteúdo antes de incluir no prompt
- • Output validation: verificar outputs antes de executar ações
- • Context isolation: separar contextos de diferentes usuários/fontes
- • Canary tokens: detectar quando instruções de sistema vazam
⚠️ Realidade Incômoda
Não existe defesa perfeita contra prompt injection. Todas as mitigações reduzem risco mas não eliminam. O arquiteto deve assumir que injection pode acontecer e projetar sistemas que limitam o dano possível (blast radius).
Auditoria de Decisões
Quando um sistema baseado em LLM toma ou influencia decisões, é necessário poder auditar a cadeia de raciocínio. Isso é essencial para compliance, debugging e confiança.
Requisitos de Auditabilidade
Para cada decisão, registrar:
- • Input que disparou a decisão
- • Prompt/contexto usado
- • Output raw do modelo
- • Transformações aplicadas
- • Ação resultante
Metadados essenciais:
- • Timestamp preciso
- • Versão do modelo
- • Versão do prompt/skill
- • ID de correlação
- • Usuário/sistema que iniciou
A auditoria não é apenas sobre o que aconteceu, mas por que. Chain-of-thought prompts facilitam explicabilidade, mas também aumentam custo e latência.
Níveis de Audit Logging
| Mínimo | Input, output, timestamp — suficiente para debugging básico |
| Padrão | + prompt completo, versões, metadados — para compliance |
| Completo | + chain-of-thought, alternativas consideradas — para investigações |
Observabilidade Estratégica
Observabilidade em sistemas LLM vai além de métricas tradicionais. É preciso monitorar comportamento semântico, não apenas performance técnica.
Pilares de Observabilidade LLM
Métricas Tradicionais
Latência, throughput, error rate, custo por request
Métricas de Qualidade
Relevância, completude, precisão, tone match
Métricas de Comportamento
Refusals, hallucination rate, safety triggers
Métricas de Negócio
Task completion rate, user satisfaction, escalation rate
Alertas Estratégicos
Alertar imediatamente:
- • Safety violations
- • Cost spikes anormais
- • Error rate > threshold
- • Potential data leakage
Monitorar tendências:
- • Drift de qualidade ao longo do tempo
- • Mudanças em padrões de uso
- • Degradação de performance
- • Evolução de distribuição de inputs
Dashboard Executivo
O arquiteto deve projetar dashboards em múltiplos níveis: operacional (para SREs), produto (para PMs), e executivo (para liderança). Cada nível precisa de métricas e granularidade diferentes.
Incidentes e Resposta a Falhas
Sistemas LLM vão falhar. A questão não é se, mas quando e como você responde. Incident response para sistemas de prompt tem características únicas que diferem de sistemas tradicionais.
Categorias de Incidentes LLM
P1 - Crítico
Safety violation, data breach, sistema offline
P2 - Alto
Degradação severa de qualidade, custo fora de controle
P3 - Médio
Aumento de erros, reclamações de usuários, drift de comportamento
P4 - Baixo
Edge cases não tratados, melhorias de qualidade
Runbook de Resposta
- Detectar: Alertas disparam ou report manual é recebido
- Triagem: Classificar severidade e escopo do impacto
- Conter: Desabilitar feature, rollback prompt, ativar fallback
- Investigar: Analisar logs, reproduzir problema, identificar root cause
- Remediar: Aplicar fix, testar em staging, deploy gradual
- Comunicar: Notificar stakeholders com status e timeline
- Postmortem: Documentar, identificar melhorias, implementar
⚠️ Erro Comum
Não trate incidentes LLM como bugs de software. A causa raiz pode ser mudança no modelo do provider, shift na distribuição de inputs ou interação entre prompts. O debugging requer raciocínio diferente.
Preparação Proativa
- • Fallbacks prontos: versões simplificadas de prompts que sempre funcionam
- • Feature flags: desabilitar features específicas sem deploy
- • Rollback automatizado: voltar para versão anterior com um comando
- • Comunicação templates: mensagens pré-aprovadas para diferentes cenários
Pontos-Chave do Módulo
Avaliação sistêmica examina consistência, coerência e alinhamento
Risco cognitivo é tão importante quanto risco operacional
Prompt injection é vulnerabilidade arquitetural, não bug pontual
Auditabilidade é essencial para compliance e debugging
Observabilidade LLM inclui métricas semânticas, não só técnicas
Incident response para LLM requer raciocínio diferente