Entenda por que a linhagem de dados não basta: auditabilidade real exige rastrear dado, versão da regra e decisão final num único trail.
Compliance
Rastreabilidade de decisão: como conectar dado, regra e resultado numa auditoria
O pipeline entrega dados limpos, catalogados, com linhagem documentada desde a fonte. O modelo recebeu esses dados, treinou, foi validado em homologação. O resultado chegou. A decisão saiu.
A fiscalização pergunta: qual critério foi aplicado nessa apólice? Qual versão da tabela estava vigente? Quem autorizou a mudança que entrou em produção no dia 14?
Silêncio.
O problema não está nos dados. Está no que acontece depois deles.
A maioria das arquiteturas de dados modernas tem linhagem razoável até a camada de consumo: origem da coluna, transformações aplicadas, histórico de versão do dataset. Ferramentas de data catalog, pipelines documentados, data mesh com ownership declarado por domínio. O trabalho foi feito.
Existe um nó que essas arquiteturas raramente capturam: a decisão. Não o dado que a alimentou. Não o modelo que processou. A decisão em si, com a regra exata que a produziu, na versão exata que estava ativa naquele momento, autorizada por quem e desde quando.
Esse nó fica fora do grafo de linhagem na maioria dos sistemas que operam em seguradoras brasileiras hoje.
O resultado prático é que você tem dois mundos que não se falam: data quality de um lado, decision quality do outro. Engenheiros de dados entregam features limpas e rastreáveis. A camada de decisão consome essas features e produz um output que ninguém sabe explicar no detalhe que o auditor vai pedir.
Documentar linhagem até o dado de entrada da decisão e parar aí é o equivalente a mapear a cadeia de custódia de um contrato até a mesa do gerente e não registrar o que aconteceu depois que ele assinou.
O trail completo que permite responder a uma auditoria da SUSEP tem exatamente quatro nós:
1. Dado de entrada: qual valor, de qual fonte, com qual versão, capturado em qual momento. Esse nó a maioria documenta bem.
2. Versão da regra aplicada: qual conjunto de critérios estava ativo no momento da decisão, quem criou essa versão, quando entrou em vigência, se houve versão anterior e o que mudou. Esse nó a maioria ignora porque a "regra" vive no código, e código não é versionado do ponto de vista do negócio, apenas do ponto de vista do repositório git.
3. Output do modelo ou do cálculo: o resultado intermediário antes da decisão final. Para seguros, isso pode ser o prêmio calculado, o score de risco, o resultado do motor de elegibilidade. Esse nó existe em alguns sistemas, mas sem vínculo explícito com a versão da regra que o produziu.
4. Decisão final: o ato decisório com timestamp, contexto completo e referência aos três nós anteriores. Não um log de evento genérico. Uma decisão rastreável.
A maioria dos sistemas loga apenas o quarto. Às vezes o terceiro. Os dois primeiros, quando aparecem, aparecem fragmentados em sistemas diferentes que não conversam.
Esse gap de dois ou três nós é o que o auditor vai encontrar quando perguntar por uma decisão específica de sinistro ou subscrição de dois anos atrás.
Esse é o ponto onde a maioria dos times de dados erra a análise, e vale ser direto: XAI não resolve o problema de audit trail de regra de negócio.
SHAP values, LIME, feature importance, saliency maps, todas as técnicas de explicabilidade de modelos de machine learning respondem a uma pergunta legítima: quais variáveis o modelo considerou relevantes para produzir aquele output específico? É útil para detectar viés, para entender comportamento do modelo, para diagnóstico técnico.
O modelo pode ter funcionado perfeitamente, com explicabilidade técnica completa, e ainda assim a seguradora não conseguir responder à fiscalização. Por um motivo simples: o modelo aprende padrões históricos e infere. A regra de negócio determina com precisão. São camadas diferentes, com responsabilidades diferentes, e confundir as duas é o erro arquitetural mais comum que se vê hoje em seguradoras que adotaram IA sem estruturar a camada de decisão.
O repositório git tem histórico de commit. Isso não é audit trail de regra de negócio, por mais que pareça.
Um commit registra que um engenheiro modificou um arquivo em determinada data. Não registra qual critério de negócio mudou, quem do negócio solicitou, qual processo de aprovação foi seguido, qual vigência foi definida para aquela nova lógica. Registra o delta técnico, não a intenção de negócio e sua autorização.
Quando o auditor pergunta "qual era a regra de subscrição para imóveis em zona de risco 3 no dia 7 de março?", a resposta que ele precisa é: "a versão 2.4 da política de subscrição residencial, aprovada pelo gerente técnico em 15 de fevereiro, com vigência até 30 de abril". A resposta que o commit entrega é: "o arquivo pricing-rules.java foi alterado em 12 de fevereiro às 16h47 pelo usuário dev-andre-07".
Uma dessas respostas resolve a auditoria. A outra a complica.
O problema se multiplica quando há modelo de IA na cadeia. O modelo foi treinado nos dados históricos que incluíam aquela regra embutida no código. Ele não tem como distinguir "aprendi o comportamento do negócio" de "aprendi o comportamento de uma regra específica que pode ter mudado". Essa distinção é invisível para o modelo. É crítica para o auditor.
Data mesh resolve bem ownership de dado por domínio, qualidade e contrato de interface entre domínios. É avanço real na governança de dados.
O que o data mesh não resolve por padrão é a camada de decisão. Um produto de dados bem definido no domínio de subscrição pode entregar features impecáveis para o modelo, com linhagem documentada, SLA de qualidade definido, ownership claro. A decisão que consome esse produto pode ainda ser uma caixa-preta do ponto de vista regulatório.
A lacuna não está no contrato entre domínios de dados. Está na ausência de um contrato equivalente para a camada de decisão: versão da regra, vigência, autorização, output versionado.
Integrar esses dois mundos exige que a camada de decisão produza um objeto de decisão tão rastreável quanto o dado que a alimentou. Com a mesma disciplina de versionamento, a mesma clareza de ownership, o mesmo nível de documentação que o time de dados aplicou no pipeline.
O ponto de partida é aceitar que decisão é dado. Não no sentido metafórico, mas no sentido operacional: toda decisão automatizada deve produzir um artefato persistido, estruturado, consultável, com referências explícitas aos quatro nós do grafo.
Isso muda o projeto de logging. A maioria dos sistemas loga eventos de aplicação: "sinistro 98432 processado com sucesso, status=aprovado, timestamp=2026-03-07T14:32:11Z". Isso é log de sistema. Audit trail de decisão tem estrutura diferente: quais dados de entrada foram usados (com referência à versão do dataset e à query que os produziu), qual versão da regra de negócio estava ativa (com referência ao repositório de regras e ao identificador de vigência), qual foi o output intermediário de cada componente, qual foi a decisão final e por qual caminho lógico ela foi produzida.
Essa estrutura não é automática em nenhum framework de logging padrão. Precisa ser projetada.
O segundo requisito é que o repositório de regras tenha versionamento com semântica de negócio, não só semântica técnica.
Semântica técnica: "versão 3.1.7, commit a4f2c89". Semântica de negócio: "política de franquia para sinistros residenciais, versão aprovada em 03/03/2026 pela gerência técnica atuarial, vigente de 10/03/2026 até 31/12/2026, substituindo versão anterior que aplicava franquia fixa de R$ 500 para imóveis tipo A".
Quando a regra vive externalizada do código, em um motor de regras com controle de versão próprio, essa semântica de negócio pode ser capturada no momento da criação da regra, por quem a criou, sem passar por tradução técnica. O atuário ou o gerente de produto define a vigência, registra a justificativa, aprova pelo fluxo definido. O motor persiste isso como metadado da versão.
Uma seguradora de médio porte que migrou regras de subscrição do ramo residencial para motor externalizado, processo que se repetiu em dezenas de implementações que acompanhamos ao longo de mais de uma década, passou a ter exatamente esse inventário: cada versão de regra com autor, data de aprovação, vigência e referência ao processo interno que a originou. O tempo de revisão de regras caiu 70%, mas o ganho de compliance foi o que efetivamente fechou o argumento para o board.
O nó mais frágil do trail costuma ser o ponto de junção entre o dado de entrada e a versão da regra que o processou. Se esses dois são consultados de sistemas diferentes sem um identificador de correlação explícito, qualquer consulta retrospectiva vai exigir reconstrução manual. Exatamente o que você não quer fazer durante uma auditoria.
O padrão que funciona é este: toda chamada ao motor de decisão persiste um registro de execução com ID único que referencia, de forma imutável, o snapshot do dado de entrada usado e o identificador de versão da regra ativa naquele momento. Esse registro fica disponível para consulta independente do sistema que originou a chamada.
Parece simples. O obstáculo prático é que exige que o motor de regras e o pipeline de dados compartilhem uma camada de persistência de execução, o que raramente está no escopo inicial de nenhum dos dois projetos. Engenharia de dados projetou o pipeline sem saber que precisaria expor referência de versão de dado. O projeto de IA projetou o modelo sem saber que precisaria vincular output a versão de regra. O projeto de BRMS, quando existe, frequentemente foi iniciado com foco em agilidade de mudança de regra, sem atenção à necessidade de que cada execução produza um artefato de audit.
Esses três projetos precisam definir, conjuntamente, o contrato do objeto de decisão. Antes de construir qualquer um dos componentes em produção.
A Circular SUSEP 667 é clara sobre explicabilidade de decisões automatizadas. O mercado sabe disso. O que o mercado subestima é a velocidade com que a fiscalização vai operacionalizar essa exigência.
Menos de 20% das seguradoras brasileiras têm audit trail completo nos quatro nós descritos aqui. A maioria tem o quarto nó, às vezes o terceiro, e acredita que isso é suficiente porque "o sistema loga tudo". Log de evento e rastreabilidade de decisão são coisas diferentes, e o auditor que conhece a diferença vai pedir o segundo.
Regra muda. Decisão sai. Auditoria chega.
Para qualquer decisão automatizada produzida pelo seu sistema nos últimos 5 anos: você consegue reconstruir o estado exato do dado de entrada, a versão exata da regra aplicada, o output intermediário de cada componente e a decisão final, com referência cruzada entre todos os quatro? Em menos de uma hora, sem envolver a engenharia?
Se a resposta não é sim imediato, o gap existe. Identificar onde ele está é o primeiro movimento.
