O que auditores da SUSEP vão exigir na prática sobre explicabilidade em IA: as três camadas de audit trail que a maioria das seguradoras não cobre.
Compliance
# Explicabilidade em sistemas de IA para seguros: o que auditores vão pedir na prática
A Circular SUSEP 667 existe. A Resolução CNSP 395/2020 existe. E as perguntas que vêm com elas, na prática, são mais específicas do que a maioria das seguradoras está preparada para responder.
A conversa sobre "explicabilidade" no setor segurador brasileiro costuma girar em torno de XAI, feature importance e SHAP values. Isso é a segunda camada do problema. Auditores de decisão automatizada, quando chegam de verdade, constroem a pergunta em três níveis distintos, e a maioria das implementações que combinam IA com regras de negócio cobre apenas o primeiro.
Identificar onde estão os buracos é o que separa uma arquitetura que passa pela fiscalização de uma que produz explicação técnica bonita, mas não responde ao que a SUSEP quer saber.
Quando um auditor abre uma investigação sobre uma decisão automatizada de sinistro, subscrição ou precificação, o raciocínio segue uma sequência lógica. Cada camada pressupõe que a anterior está resolvida.
A pergunta aqui é: com que informação o sistema decidiu?
Isso envolve saber de onde vieram os dados, em que momento foram capturados, se passaram por transformações antes de chegar ao modelo, e se o dado usado na decisão é o mesmo que está documentado no contrato ou na proposta. Um modelo de IA treinado com dados históricos de sinistros que contêm viés regional vai reproduzir esse viés em produção sem nenhum sinal de erro técnico.
A maioria das seguradoras tem algum nível de resposta para essa camada: catálogos de dados, pipelines documentados, linhagem de origem. O problema aparece quando o auditor pergunta se o dado de entrada que alimentou aquela decisão específica, naquele contrato específico, em 14 de março de 2025, estava correto e é verificável. Log de execução com snapshot do payload de entrada é o que responde essa pergunta. Sem ele, o que existe é rastreabilidade do pipeline. Rastreabilidade do pipeline é diferente de audit trail de decisão.
A pergunta aqui é: por que o modelo chegou a esse resultado para esse caso específico?
É aqui que XAI entra. Feature importance global ("a variável X importa 34% em média para o modelo") não responde a pergunta de auditoria. O que responde é explicabilidade local: para aquele segurado específico, com aquele conjunto de variáveis, qual foi o peso de cada fator na decisão do modelo naquela execução.
SHAP values, LIME, modelos substitutos locais, arquiteturas inerentemente interpretáveis como árvores de decisão com profundidade controlada: existem abordagens. O problema é que boa parte das implementações registra a saída do modelo (score, classificação, valor), mas não registra a explicação local no momento da decisão. Recalcular depois é possível em alguns casos. Recalcular com os pesos exatos do modelo que estava em produção naquela data, sem ter o registro da versão exata, dos hiperparâmetros e dos dados que produziram aquela decisão, frequentemente não é possível.
O auditor não aceita "calculamos a explicação agora com o modelo atual". Ele quer a explicação do que aconteceu naquele momento.
A pergunta aqui é: qual critério de negócio foi executado, em qual versão, e quem autorizou?
Essa é a camada que mais consistentemente está ausente. No contexto regulatório brasileiro para o mercado segurador, é a que a SUSEP vai priorizar quando a decisão envolve elegibilidade de cobertura, cálculo de prêmio ou negativa de sinistro.
O modelo de IA produz um score de risco: 0,73. O que acontece com esse 0,73? Em algum lugar do sistema existe uma regra que diz: "se score acima de 0,70, aplicar fator de agravamento 1,3 sobre o prêmio puro". Ou: "se score acima de 0,75, recusar subscrição no ramo 11". Quem definiu esse threshold? Quando? Qual versão dessa regra estava ativa quando o contrato foi emitido?
Se essa regra está hardcoded no serviço de subscrição, a resposta para essas perguntas vive no histórico de commits do repositório. Histórico de commit não é audit trail de decisão de negócio. O commit diz que o código mudou. Não diz quem autorizou a mudança de critério, qual foi a justificativa de negócio, qual a vigência da regra anterior, e se houve análise de impacto atuarial antes da alteração.
Essa distinção vai ser central nas fiscalizações de 2026 em diante.
A resposta tem a ver com onde o esforço de governança começa. Projetos de IA em seguradoras normalmente partem do dado: governança de dados, data quality, linhagem. É natural, é o que o time de dados conhece, é o que os frameworks de MLOps endereçam.
A segunda camada (XAI) recebe atenção quando o time de modelagem tem maturidade técnica suficiente e quando existe pressão de produto ou regulatória para incluir explicabilidade no design. Não é universal, mas existe em implementações mais recentes.
A terceira camada, quase nunca. Porque ela não vive no mundo do dado nem no mundo do modelo. Ela vive na camada de decisão de negócio, que em seguradoras brasileiras ainda está, na maior parte dos casos, embutida no código da aplicação ou dispersa em planilhas que o time atuarial mantém manualmente.
O resultado é uma arquitetura que diz "o modelo avaliou esses dados e chegou a esse score com esses pesos", mas não diz "esse score foi processado pela regra de subscrição versão 2.4, vigente desde 15 de fevereiro de 2025, aprovada pelo gerente de subscrição em 12 de fevereiro após revisão da nota técnica atuarial NTA-2025-07".
A SUSEP, quando exige explicabilidade de decisão automatizada, está pedindo as três camadas juntas. XAI isolada não fecha.
O caso do threshold merece atenção separada porque é o ponto de fricção mais frequente e menos óbvio.
Em sistemas que combinam modelo de IA com lógica de decisão, existe sempre uma fronteira entre o que o modelo calcula e o que a regra de negócio executa. Essa fronteira se materializa em thresholds, bandas de score, tabelas de fator de agravamento, regras de elegibilidade por faixa de risco. São critérios de negócio, definidos por alguém com base em análise atuarial, histórico de sinistros, apetite de risco da seguradora.
Quando esse critério muda, e ele muda com frequência porque o ambiente de risco muda, o padrão de sinistros muda, a estratégia comercial muda, essa mudança precisa ser rastreável com a mesma granularidade de uma alteração em tabela de prêmio: data de vigência, autor, justificativa, versão anterior preservada.
Com a regra dentro do código, cada alteração de threshold exige um ticket para TI, um deploy, e o rastro que fica é o commit no repositório. Com a regra em uma camada externalizada de gestão de regras de negócio, a mudança é feita pelo próprio time de subscrição ou atuarial, tem versionamento automático com data e autor, e a versão que estava ativa em qualquer data passada é recuperável com precisão.
A diferença prática é concreta: uma seguradora que opera com threshold hardcoded, quando um auditor perguntar "qual era o critério de aceitação de risco para apartamentos com mais de 30 anos de construção no ramo residencial em março do ano passado", vai passar dias tentando reconstruir a resposta a partir de commits, deploys e e-mails internos. Uma seguradora com regras versionadas responde em minutos.
IA faz muito bem o que a lógica determinística faz mal: interpreta texto livre de descrição de bem segurado, extrai informações de laudos e documentos, classifica padrões de sinistro em volume, sugere faixas de risco com base em dados históricos massivos. Essas capacidades têm valor real e crescente.
O que IA não faz, por ter sido projetada para outro propósito, é executar regra explícita com rastreabilidade garantida. O modelo aprende padrão. Ele infere qual deve ser a resposta correta dado o histórico. Ele não executa "se CEP no grupo de risco 3 e bem construído antes de 1990, aplicar fator 1,45". Ele aprendeu que, historicamente, situações similares levaram a prêmios mais altos. Isso parece igual ao regulador. Para o regulador, é completamente diferente.
A fronteira que funciona é clara: IA extrai, classifica e pontua. A camada de regras determinísticas decide com base nessa saída, segundo critérios explícitos, versionados e auditáveis. A decisão que vai para o contrato, para o sinistro, para o endosso, é sempre produto de uma regra que pode ser mostrada, datada e justificada.
Arquiteturas que tentam fazer o modelo de IA ser também o decisor final criam um problema de explicabilidade que XAI não resolve. Feature importance explica o modelo. Não explica a política de negócio que estava vigente naquela decisão.
A partir das exigências da Circular SUSEP 667 e da Resolução CNSP 395/2020, o cenário regulatório está se consolidando em torno de decisão automatizada com impacto ao consumidor: negativa de sinistro automatizada, precificação com variação individual, recusa de subscrição por critério automatizado.
As perguntas que vêm com essas decisões são:
Uma seguradora que cobre as três camadas tem resposta para as quatro perguntas. Uma que cobre só a primeira vai entrar numa negociação longa com o fiscal sobre o que "explicabilidade" significa na prática, e essa negociação raramente termina bem.
Pegue uma decisão automatizada que sua seguradora tomou em qualquer data dos últimos 12 meses, de preferência uma negativa de sinistro ou uma aplicação de fator de agravamento. Tente reconstruir as três camadas: qual dado de entrada, qual versão do modelo com quais pesos para aquele caso específico, qual regra de negócio na versão vigente naquela data com o nome de quem autorizou.
Quanto tempo levou? O que não foi possível responder?
Esse exercício localiza exatamente onde a arquitetura de explicabilidade está incompleta. O auditor vai fazer esse mesmo exercício, mas com um prazo e uma pauta que estão fora do seu controle.
Regra muda. Sprint enche. Feature não sai. O audit trail da decisão de negócio continua sem resposta.
