Capítulo 11 — Observabilidade, Logging e Resposta a Incidentes
Décimo primeiro post do passeio capítulo a capítulo pelo LLM Primer VII: Segurança de IA. O capítulo que trata logging, alerting e resposta a incidentes como a camada que transforma defesas arquiteturais em sistema que operadores conseguem de fato rodar.
Por que este capítulo existe
Um sistema com estrutura correta mas sem visibilidade falha de forma invisível. O Capítulo 11 percorre a camada de observabilidade para sistemas LLM — o que logar, como detectar abuso e anomalia, como alertar sem produzir ruído, como conduzir um playbook de resposta a incidentes quando algo dá errado e como aprender com o que aconteceu. As disciplinas gerais se transferem da engenharia operacional em outros contextos, com extensões específicas de LLM: saídas probabilísticas significam que reproduzir incidentes exige capturar mais estado do que em sistemas determinísticos; as convenções semânticas OpenTelemetry GenAI, desenvolvidas desde 2024, dão o vocabulário vendor-neutral para esse estado.
11.1 O que logar é decisão de política, não default
Logar de menos deixa o time incapaz de investigar. Logar de mais cria problemas de compliance, custo e privacidade que eventualmente forçam redução. A posição defensável é o mínimo que sustenta os casos de uso operacionais que o time identificou, em forma estruturada que dê conta de cada um. Os propósitos costumam incluir alerting em tempo real de abuso ou anomalia, investigação a posteriori de incidentes, planejamento de capacidade e análise de custo, relatórios de compliance e avaliação contínua do comportamento do modelo. Cada propósito tem exigências diferentes de schema; um log projetado para um é insuficiente para os outros. As convenções semânticas OpenTelemetry GenAI definem spans e atributos para a chamada de LLM — nome do modelo, provedor, parâmetros da requisição, conteúdo do prompt, conteúdo da resposta, contagem de tokens, latência, custo — que deixam ferramentas a jusante consumirem a mesma telemetria independentemente do SDK específico. Langfuse, Helicone, Arize Phoenix e Datadog LLM Observability consomem esse formato. Uma entrada de log em produção geralmente inclui o request ID, o principal autenticado, o tenant, a versão e o provedor do modelo, o prompt montado completo (com o contexto recuperado e sua proveniência), as chamadas de ferramenta e suas saídas, o conteúdo da resposta, os scores do classificador de segurança na entrada e na saída e a contabilidade de latência e tokens. Armazenar isso com responsabilidade significa ser explícito sobre janelas de retenção, tratamento de PII e controles de acesso sobre o próprio armazenamento de log.
11.2 Detecção compõe sinais de assinatura, estatística e comportamentais
Uma vez que a telemetria está estruturada, a próxima pergunta é quais padrões indicam que algo está errado. Matching por assinatura é a primeira linha mais barata — frases conhecidas de prompt injection, preâmbulos estilo DAN, payloads codificados em base64, setups de role-play já observados. A lista é construída a partir de pesquisa pública, trabalho interno de red team e incidentes passados. Assinaturas pegam variantes conhecidas; adversários se adaptam assim que aprendem quais frases são sinalizadas. Detecção de anomalia estatística vigia divergência da baseline: distribuições incomuns de tokens, razões atípicas de latência sobre comprimento, picos súbitos em taxas de recusa ou na taxa de invocações de ferramentas específicas. Baselines derivam lentamente sob condições normais e se deslocam abruptamente sob condições anormais. Detecção de padrão comportamental casa perfis de abuso mesmo quando requisições individuais não são abertamente maliciosas — um único principal emitindo milhares de variantes parafraseadas do mesmo pedido restrito, um pico de requisições que combinam conteúdo legítimo com um sufixo específico, drift lento nas distribuições de resposta por usuário. Detecção só é útil se levar a alertas aos quais operadores respondem. A taxonomia geralmente distingue crítico (abuso ativo em escala, acordar engenheiro on-call), alto (padrão notável com dano limitado, notificação em horário comercial) e médio/baixo (dashboards e revisão semanal). Fadiga de alerta é o modo de falha; disciplina estrita de severidade é o que a previne.
11.3 Resposta a incidentes é playbook, não improvisação
A NIST SP 800-61 Revisão 2 dá o framework — preparação, detecção e análise, contenção, erradicação, recuperação, atividade pós-incidente — que o playbook específico de LLM estende. Preparação significa que runbooks, escalas on-call e acesso ao ferramental relevante existem antes do incidente. Detecção e análise é onde a observabilidade da Seção 11.1 dá retorno. Contenção para um incidente de LLM pode significar acionar uma feature flag para desabilitar uma ferramenta, degradar para uma versão de modelo mais conservadora, apertar rate limits para um principal ou tenant específico ou redirecionar tráfego para uma stack alternativa. Erradicação depende do tipo de incidente: um jailbreak pode precisar de uma regra de filtro adicional, um documento RAG comprometido pode precisar ser removido do índice, uma credencial vazada pode precisar de rotação. Recuperação é quando o sistema retorna ao normal, com a contenção revertida e a erradicação verificada. Atividade pós-incidente é onde o trabalho específico de modelo se concentra: reproduzir o comportamento se possível, caracterizar a fronteira da falha, decidir se o incidente reflete algo sobre o modelo que deveria mudar como ele é usado e alimentar o resultado na suíte de avaliação para que futuras regressões sejam pegas antes do deployment. Reprodução nem sempre é possível sob sampling com temperatura não-zero, mas o objetivo é definir quando o comportamento indesejado ocorre.
O que o Capítulo 11 prepara
O Capítulo 12 fecha a Parte IV com a camada de identidade e acesso — quem pode interagir com o sistema, sob quais termos, e como a imposição é estruturada entre os componentes. As disciplinas tradicionais se aplicam: autenticação com API keys, OAuth e mTLS; autorização com RBAC e ABAC; isolamento multi-tenant; rate limits e quotas; camadas de governança corporativa. As extensões específicas de LLM tratam do modelo como principal — um agente agindo em nome de um usuário tem sua própria identidade e suas próprias permissões — o papel dos capability tokens para invocação de ferramentas e a configuração por tenant do comportamento do modelo que plataformas LLM multi-tenant têm de suportar. O Capítulo 13 abre então a Parte V com o panorama regulatório, onde os controles técnicos que este livro desenvolveu precisam ser mapeados no AI Act, no GDPR, nas leis estaduais americanas e nos frameworks que os cercam.
Próximo — Capítulo 12: Controle de Acesso e Identidade. Autenticação, RBAC versus ABAC, isolamento multi-tenant, rate limits e a camada de governança corporativa que torna sistemas LLM utilizáveis em ambientes regulados.
