Guia prático de audit trail para decisões automatizadas em seguros: os 6 campos obrigatórios, exigências da SUSEP e como evitar passivos em auditorias.
Compliance
# Seis campos. A maioria entrega dois. O resto é o que a auditoria vai perguntar.
A notificação chegou numa sexta-feira às 17h48. Não numa segunda de manhã, não com tempo para organizar equipe. Numa sexta, quando metade do time já tinha saído. O jurídico encaminhou sem comentário: reconstituição de 120 decisões de aceitação de risco automatizada dos últimos 18 meses, prazo de 72 horas.
Os logs existiam. Timestamp de execução, output da decisão, tudo lá. O problema apareceu nos primeiros trinta minutos de investigação: a versão da regra ativa em cada uma dessas 120 decisões não tinha sido persistida. O sistema atualizava regras sem versionamento e sobrescrevia sem snapshot. O passado era irreconstruível por design.
O fim de semana foi cancelado. Três dias cruzando deploys no Git com timestamps de banco, tentando inferir o que estava ativo. O esforço entregou uma reconstituição parcial. O jurídico classificou como insuficiente para defesa.
A tese deste artigo é objetiva: a maioria das seguradoras brasileiras não tem audit trail de decisões automatizadas. Tem log de aplicação. São coisas diferentes, com finalidades opostas, e confundir as duas é o passivo que vai aparecer na auditoria seguinte.
---
Essa distinção não é semântica. É arquitetural.
Um audit trail completo de decisão automatizada tem seis elementos: contexto da decisão, versão da regra aplicada, dados de entrada, output gerado, autor (humano ou sistema) e timestamp de vigência, não de execução. Cada um desses campos responde a uma pergunta diferente que regulador, contestante ou juiz pode fazer. Remova qualquer um e você deixa uma pergunta sem resposta.
A maioria dos sistemas de aceitação de risco automatizada entrega dois: timestamp de execução e output. Os outros quatro ficam implícitos ou dispersos em logs não estruturados que não foram projetados para reconstituição.
O campo mais frequentemente ausente é a versão da regra. E é o mais crítico. Sem ele, você prova o que aconteceu. Mas não consegue provar por quê, no momento em que aconteceu, com a versão que estava ativa naquele instante. Quando a regra já foi alterada duas versões depois, o output sozinho não reconstrói o raciocínio. É exatamente o que regulador e juiz perguntam.
Há um erro mais perigoso que o campo ausente: o campo preenchido com o dado errado. Timestamp de vigência e timestamp de execução colapsam em sistemas sem controle de versão de regras. A regra pode ter sido executada às 14h32, mas a versão vigente era a publicada três dias antes. Um sistema que grava todos os seis campos mas usa o timestamp de execução no lugar do timestamp de vigência entrega evidência que contradiz a realidade. Agora há um documento incorreto assinado pelo sistema, e a posição jurídica da seguradora piora.
---
Quando uma autoridade regulatória ou um processo judicial solicita a demonstração do processo decisório de aceitação de risco automatizada, o prazo raramente é generoso. Não é tempo para começar a procurar. É tempo para entregar.
A exigência de retenção de rastreabilidade de decisões automatizadas cobre anos. Decisões que afetam precificação de vida têm precedente de auditoria retroativa de uma década em processos administrativos.
O custo de não ter essa estrutura é mensurável. Reconstituir uma única decisão automatizada sem audit trail estruturado exige cruzamento manual de logs, backups de banco e histórico de deploys. Multiplique por cinquenta decisões contestadas num processo administrativo: o esforço técnico e jurídico se acumula antes de qualquer penalidade ser aplicada. Esse número não inclui o custo de oportunidade das equipes que pararam de desenvolver produto para fazer reconstituição forense.
Há ainda um conflito estrutural que legislações de proteção de dados introduzem: o direito de explicação exige que a decisão seja reconstituível, mas o direito ao esquecimento exige que dados pessoais sejam apagados. Resolver esse conflito sem uma arquitetura que separa metadados da decisão de dados pessoais do titular é tecnicamente impossível. A maioria das seguradoras ainda não endereçou isso como problema de design.
---
O diagnóstico arquitetural preciso: sistemas legados de aceitação de risco foram construídos com o motor de regras acoplado ao banco transacional. A versão da regra que gerou a decisão não é um atributo persistido junto ao registro. Ela existe apenas no estado atual do sistema. Quando a regra muda, o passado torna-se irreconstruível por design.
Implementar audit trail completo num sistema com essa arquitetura não é adicionar campos num schema. Exige event sourcing ou snapshot imutável da regra no momento da decisão, o que conflita diretamente com a arquitetura CRUD predominante e exige refatoração de camada de persistência. O esforço realista: entre três e seis meses de engenharia para fazer certo.
A alternativa mais comum é um proxy de auditoria externo: interceptar a decisão antes e depois, persistir num storage separado. É mais rápido. E cria uma dependência de sincronização que falha silenciosamente sob carga. Em implementações que usaram esse caminho, falhas de sincronização foram descobertas durante auditorias, não antes. O custo de um deploy emergencial para corrigir um gap de rastreabilidade descoberto durante auditoria é tipicamente três vezes maior que implementar o audit trail correto desde o início, pela combinação de pressão de prazo e escopo mal definido.
A arquitetura correta trata o audit trail como artefato de primeira classe, não subproduto de infraestrutura. O motor de decisão grava um *decision record* imutável em storage append-only antes de retornar o resultado, com hash da versão da regra e snapshot dos parâmetros de entrada. Não depende de log de aplicação para reconstituição. A versão da regra é parte do registro, não inferência posterior.
---
Uma seguradora de médio porte com trinta e oito ramos ativos implementou esse padrão após o primeiro processo administrativo envolvendo aceitação de risco automatizada. Antes da mudança, responder a uma solicitação de auditoria exigia uma semana de trabalho cruzando manualmente logs, backups e histórico de deploys, com resultado classificado como reconstituição parcial. Após a separação entre motor de decisão e camada de evidência, com *decision records* imutáveis indexados por ID de decisão, o tempo de resposta a auditorias internas de compliance caiu para menos de quatro horas. A mesma pergunta, "qual regra, em qual versão, com quais dados, gerou essa decisão específica", passou de dias para segundos via query direta.
O Gerente de Compliance descreveu o antes com precisão incômoda: "A gente tinha logs. Mas logs não são evidência. São matéria-prima para construir evidência. Construir em 72 horas o que deveria ter sido gravado no momento da decisão não é auditoria. É perícia forense."
---
A diferença entre uma seguradora preparada e uma não preparada para uma notificação de auditoria não é a existência de logs. É se a evidência é um artefato estruturado, imutável, com os seis campos corretos, ou se é uma promessa de que, dado tempo suficiente, alguém consegue reconstituir.
Pega as últimas três decisões de aceitação de risco automatizada contestadas internamente. Pergunta quanto tempo levou para reconstituir o raciocínio completo do sistema, não o output, o raciocínio. Se a resposta envolver mais de um dia e múltiplas equipes, você já sabe qual é o seu passivo quando a próxima notificação chegar. A questão não é se ela chega. É quantas decisões ela vai cobrir.
