Em quase toda conversa técnica sobre IA aplicada a seguros, alguém menciona SHAP. Em quase toda apresentação para diretoria de risco, há um slide com SHAP values. Em quase todo paper acadêmico sobre fairness em ML financeiro, SHAP é a ferramenta default.
SHAP é uma boa ferramenta. Para o que ela faz.
O problema é que o que ela faz cobre só uma fatia pequena do que uma decisão real de seguro envolve em 2026.
O que SHAP realmente explica
SHAP (proposto por Lundberg & Lee em 2017, e LIME por Ribeiro et al em 2016) responde uma pergunta específica: dado um modelo de machine learning treinado em dados tabulares, qual foi a contribuição de cada feature para o output de uma predição individual?
É uma pergunta excelente para o cenário em que SHAP foi desenhado: você tem um random forest, um XGBoost, ou uma rede neural, alimentados por uma tabela de features estruturadas, produzindo um score numérico. SHAP te diz: "o CNPJ ativo contribuiu +0.12 para o score, a sinistralidade declarada contribuiu -0.08".
Para uma decisão de crédito tabular, isso resolve. Para uma decisão de seguro corporativo em 2026, é insuficiente — porque a decisão deixou de ser tabular.
Por que decisão de seguro deixou de ser tabular
Uma submissão de risco corporativo hoje passa por uma cadeia de transformações antes de chegar ao modelo final.
Primeiro, o input chega como PDF, e-mail ou planilha. Um sistema de extração precisa converter isso em campos. SHAP não cobre essa etapa.
Depois, esses campos são enriquecidos com retrieval — busca semântica em bases internas e externas. SHAP não cobre essa etapa.
Em seguida, o caso é classificado por apetite — frequentemente com uma combinação de regras hard-coded e modelo ML. SHAP cobre o ML, mas não as regras nem a lógica de combinação.
Finalmente, um pricing engine produz output — às vezes um número, às vezes uma frase explicativa para o subscritor. Quando o explicativo é gerado por LLM, SHAP não cobre.
A consequência: você pode ter SHAP perfeito no modelo de scoring final e ainda assim ser incapaz de explicar ao regulador por que essa submissão específica recebeu essa decisão específica.
Auditabilidade nativa é arquitetura. Não é feature. Você não a adiciona depois — você a constrói antes.
As 4 camadas de explicabilidade real
A arquitetura que adotamos na WIR tem quatro camadas. SHAP, quando aplicável, vive na camada 3.
Camada 1: Input logging com versionamento. Toda submissão entra no sistema com um snapshot imutável: arquivos originais, hashes, timestamps, canal de origem, identidade do remetente. Antes de qualquer transformação. Esse snapshot é o ponto de partida da trilha.
Camada 2: Provenance da extração e enriquecimento. Cada campo extraído carrega metadata: qual ferramenta extraiu, qual versão, qual confiança. Cada enriquecimento carrega: qual fonte foi consultada, qual versão da resposta, qual timestamp.
Camada 3: Decisão modelo + regras com SHAP onde couber. Aqui SHAP pode entrar — mas só para a parte do pipeline que é ML tabular. Para regras hard-coded, registramos a regra disparada, sua versão, e os campos que a satisfizeram. Para LLM-as-judge, registramos o prompt, modelo, versão, temperatura, e a justificativa textual.
Camada 4: Decision Q&A. A camada que falta na maioria das implementações: a interface que permite a um auditor fazer uma pergunta em linguagem natural sobre uma decisão específica e receber resposta apoiada nas três camadas anteriores. "Por que esse caso foi recusado?" — resposta: "Porque a regra R-014 disparou. A regra foi atualizada em 12/03/2026. O CNAE foi extraído com confiança 0.97 a partir da página 2."
Por que isso importa fora da sala de TI
Resseguro. Resseguradoras europeias e norte-americanas já estão exigindo trilha completa para subscrição automatizada acima de certos limites. SHAP isolado não atende.
Susep e LGPD. A LGPD (Lei 13.709/2018) garante ao titular do dado o direito de obter explicação sobre decisões automatizadas que o afetam. As comunicações da SUSEP sobre IA em subscrição estão evoluindo na mesma direção. Operações que dependem de SHAP isolado vão precisar refazer arquitetura quando a fiscalização chegar.
Diretoria. Quando o CFO pergunta por que a sinistralidade aumentou 1.2 pontos no trimestre, a resposta com auditabilidade nativa é uma query, não uma investigação de semanas.
O que isso muda no roadmap
Auditabilidade nativa é arquitetura. Não é feature. Você não a adiciona depois — você a constrói antes, e ela vira o ambiente em que tudo o mais opera. Tentar adicionar trilha completa a um sistema que foi construído sem ela é, em geral, mais caro do que reescrever.
SHAP fica. Mas como uma das ferramentas, não como a resposta. A discussão completa sobre como LLMs e motores de regras se complementam está em LLMs não substituem motores de regras, e o monitoramento contínuo desses sistemas em produção em Observabilidade de agentes.
Referências e leituras
- Lundberg & Lee 2017 — A Unified Approach to Interpreting Model Predictions (SHAP)
- Ribeiro et al 2016 — "Why Should I Trust You?" (LIME)
- LGPD — Lei 13.709/2018
- SUSEP — comunicações regulatórias
- ISO/IEC 27001 — Sistema de Gestão de Segurança da Informação
- LLMs vs motores de regras — arquitetura híbrida
- Observabilidade de agentes em produção