Segurança/Governança · MOFU · IT

Auditoria de decisões assistidas por IA: como fazer

Por Adriano Schneider · · 10 min de leitura

Um sistema de IA que toma ou assiste decisões — aprovar crédito, recomendar tratamento, ranquear candidatos, responder a um cliente — precisa de rastreabilidade. Não é perfeccionismo: é o mínimo para responder perguntas legítimas como "por que o sistema tomou essa decisão?" sem entrar em pânico. Este artigo explica o que registrar, como estruturar e por quanto tempo guardar.

Por que rastreabilidade não é opcional em sistemas com IA

Em sistemas tradicionais, uma decisão de negócio tem uma trilha natural: o analista fulano aprovou o crédito na terça-feira às 14h22 porque o score estava acima de 700 e a renda declarada cobria o comprometimento máximo. Você pode reconstruir o raciocínio.

Em sistemas com LLM, essa trilha some por padrão. O modelo processa entrada, gera saída — e se você não logou o que aconteceu no meio, a decisão é irreconstruível. Isso cria pelo menos três problemas sérios:

  1. Problema legal (LGPD, art. 20): o titular tem direito à revisão de decisões automatizadas. Se você não consegue mostrar qual dado foi usado e qual foi o output, não consegue atender à solicitação — o que é, por si só, uma violação.
  2. Problema de responsabilidade civil: quando uma decisão assistida por IA causa dano, quem responde? Você — o operador do sistema — precisa demonstrar que o processo foi adequado. Sem log, você não tem defesa.
  3. Problema operacional: quando o sistema errar (e vai errar), você precisa entender o que aconteceu para corrigir. Sem log, você está voando às cegas.

Esquema de log de auditoria para decisão assistida por IA

A seguir, o esquema completo de campos para um log de auditoria de decisão assistida por IA. Os campos marcados como obrigatórios são o mínimo para conformidade com LGPD e rastreabilidade básica. Os campos recomendados aumentam a qualidade da auditoria e a capacidade de resposta a incidentes.

Esquema de log de auditoria para decisão assistida por IA
Campo Tipo Descrição Exemplo Obrigatoriedade Justificativa
log_id UUID Identificador único e imutável do evento de log. a3f2c1d4-... Obrigatório Referência para investigações e solicitações de titulares.
timestamp ISO 8601 com timezone Data e hora exata da chamada ao modelo, com fuso horário. 2026-05-05T14:22:07.341-03:00 Obrigatório Correlação temporal de eventos; linha do tempo de incidentes.
user_id String (ID interno) Identificador interno do usuário que iniciou a ação. Nunca CPF ou e-mail direto. usr_8f3a2c Obrigatório Atendimento a solicitações de titulares (LGPD art. 20).
session_id String Identificador da sessão de interação. Agrupa múltiplas chamadas ao modelo em uma mesma conversa. sess_4d9e1a Obrigatório Reconstrução de contexto conversacional em auditorias.
tenant_id String Identificador do cliente/empresa em sistemas multi-tenant. tenant_empresa_xpto Obrigatório (multi-tenant) Segregação de dados de auditoria entre clientes.
input_hash SHA-256 Hash criptográfico do input completo enviado ao modelo (incluindo system prompt e contexto). Permite verificação de integridade sem armazenar dados em claro. e3b0c44298fc1c... Obrigatório Verificação de integridade; prova de que o input era X em determinado momento.
model String Identificador exato do modelo utilizado, incluindo versão/snapshot. gpt-4o-2025-11-01 Obrigatório Reprodutibilidade; diferentes versões têm comportamentos diferentes.
temperature Float [0.0–2.0] Parâmetro de temperatura usado na geração. Afeta determinismo do output. 0.2 Recomendado Contexto para interpretar variabilidade do output em auditorias.
context_chunks Array de strings (IDs) IDs dos documentos/chunks recuperados pelo RAG e incluídos no contexto. Não o conteúdo — apenas a referência. ["doc_42_chunk_7", "doc_18_chunk_3"] Recomendado (sistemas RAG) Rastreabilidade da fonte de informação usada pelo modelo.
output_hash SHA-256 Hash do output gerado pelo modelo. Permite verificação posterior de integridade. a591a6d40bf420... Obrigatório Prova de que o output era Y no momento da decisão; detecção de adulteração.
human_review Boolean Indica se houve revisão humana antes da ação final. true Obrigatório LGPD art. 20 exige capacidade de revisão humana em decisões automatizadas.
reviewer_id String (ID interno) ID do revisor humano, quando human_review = true. usr_admin_2c9f Condicional Responsabilidade humana na cadeia de decisão.
decision_taken String (enum) Ação tomada com base no output: aprovado, rejeitado, escalonado, pendente, etc. APROVADO Obrigatório Central para qualquer auditoria — qual foi o resultado efetivo.
resultado JSON estruturado Dados estruturados do resultado específico da decisão — sem PII, com referências a entidades do domínio. {"score": 742, "limite": 5000, "prazo_meses": 24} Recomendado Contexto de negócio para auditorias e análises de qualidade do modelo.
latencia_ms Integer Tempo de resposta do modelo em milissegundos. 1842 Recomendado Monitoramento de performance; detecção de anomalias de latência.
custo_tokens JSON Tokens de input e output consumidos, para controle de custo. {"input": 1240, "output": 387} Recomendado Controle financeiro; detecção de uso anômalo (LLM04 — DoS).

O que NÃO logar: armadilha do excesso de dados

Existe uma tentação natural de logar tudo — o prompt completo, o output completo, o histórico de conversa. Isso parece mais seguro, mas cria um problema sério: você acaba construindo um banco de dados rico em PII que tem risco próprio de violação.

O log de auditoria deve conter referências e hashes, não os dados em claro. Se precisar reconstruir o conteúdo exato de um prompt para uma auditoria específica — ex.: investigação de incidente —, faça isso sob demanda, com acesso controlado e registro separado de quem acessou o quê.

Regra prática: pergunte-se "se esse banco de dados de logs vazar, que dano causa?" Se a resposta incluir "expõe dados pessoais de clientes", revise o que está sendo armazenado em claro.

Imutabilidade e integridade: o log precisa ser à prova de adulteração

Um log de auditoria que pode ser alterado é inútil como evidência. Para garantir integridade:

Retenção e ciclo de vida dos logs

O prazo de retenção deve ser proporcional ao impacto da decisão e à probabilidade de contestação posterior:

Após o prazo de retenção, os logs devem ser eliminados de forma segura e documentada — não apenas deletados do banco, mas também de backups e replicas.

Ferramentas para implementar log de auditoria de IA

Você não precisa construir tudo do zero. Algumas opções:

Para sistemas críticos, a recomendação é usar uma ferramenta especializada (LangSmith ou Arize) para a camada de observabilidade do LLM, combinada com um log de auditoria estruturado em banco dedicado — as duas camadas têm propósitos diferentes.

Como responder a uma solicitação de titular via LGPD

Quando um titular exercer o direito do artigo 20 — "por que o sistema tomou essa decisão?" — você deve ser capaz de responder em linguagem acessível, não técnica. O que o log de auditoria torna possível:

  1. Identificar quais interações do titular estão registradas.
  2. Reconstruir quais dados foram usados como entrada (sem revelar dados de terceiros que estavam no contexto).
  3. Informar qual modelo processou e qual foi o output.
  4. Informar se houve revisão humana e quem aprovou a decisão final.
  5. Oferecer revisão — um humano pode repetir a análise manualmente se o titular contestar.

Para a conformidade completa com LGPD em sistemas LLM, leia: LGPD em aplicações LLM: minimização e mascaramento. Para entender como o output do modelo deve ser tratado antes de resultar em ação, veja: Output handling seguro em LLM. Para rastreabilidade em sistemas RAG, veja também: RAG com citações e rastreabilidade.

Conclusão: log de auditoria é produto, não overhead

Equipes que constroem log de auditoria desde o início do projeto tratam isso como feature. Equipes que adicionam depois tratam como dívida técnica cara. A diferença de custo é significativa: retroativamente instrumentar um sistema em produção para auditoria adequada pode custar 3 a 5 vezes o que custaria fazer isso na fase de design.

O esquema de log apresentado aqui não é o único possível — ajuste ao seu contexto. O importante é ter os campos obrigatórios desde o primeiro deploy em produção. Você vai agradecer quando vier a primeira solicitação de titular ou a primeira investigação de incidente.