Explicabilidade de IA em seguros é a capacidade de apresentar razões compreensíveis e fiéis para os resultados de um sistema que participa de decisões sobre aceitação, preço ou sinistros. Para sustentar uma decisão específica, essa capacidade precisa estar acompanhada de fundamentação adequada e de registros que permitam verificar o que aconteceu.
A diferença aparece quando um segurado contesta uma recusa meses depois. A seguradora precisa recuperar os dados considerados, identificar o modelo e as regras utilizados, demonstrar como o resultado influenciou a decisão e apresentar seus fundamentos.
Guardar tudo isso ajuda a reconstituir o caso. Ainda será necessário avaliar se a explicação corresponde ao funcionamento do sistema e se a decisão é defensável.
Para uma visão mais ampla dos usos da tecnologia no setor, veja o panorama de aplicações e riscos de inteligência artificial em seguros. Aqui, o foco é o que uma decisão apoiada por IA precisa deixar disponível para ser compreendida, revisada e sustentada.
Explicação, justificativa e rastro cumprem funções diferentes
Explicação
Descreve como o sistema produziu determinado resultado. Pode apresentar uma regra percorrida, a contribuição de variáveis ou os elementos de um documento que sustentaram uma extração.
O formato depende da técnica utilizada e de quem precisa compreender o resultado.Justificativa
Demonstra por que a decisão é defensável diante dos fatos e das regras aplicáveis.
Explicar que uma variável influenciou o resultado não comprova que seu uso foi adequado nem que havia fundamento para recusar uma proposta ou uma cobertura.
Explicar o resultado e sustentar a decisão são exigências diferentes.Rastro
Reúne as evidências da execução: dados utilizados, versões, resultados, intervenções humanas e comunicação realizada.
É o registro que permite reconstruir o que aconteceu ao longo da decisão.O projeto precisa tratar essas três necessidades em conjunto, preservando suas diferenças.
Quem precisa entender a decisão?
A mesma informação não atende a todos os destinatários.
| Destinatário | O que precisa compreender | Entrega adequada |
|---|---|---|
| Segurado ou proponente | Motivo da decisão, fatos considerados e caminho para questionamento. | Comunicação clara, relacionada ao caso. |
| Analista ou revisor | Fundamentos da recomendação, limitações e elementos que podem alterá-la. | Informações acessíveis na tela, com documentos e critérios relevantes. |
| Auditoria e autoridades competentes | Como a decisão foi produzida e quais controles foram aplicados. | Evidências recuperáveis, com histórico e integridade. |
| Equipes técnica e de riscos | Comportamento do modelo, falhas e mudanças ao longo do tempo. | Avaliações de desempenho, estabilidade e resultados por grupos pertinentes. |
O NIST propõe quatro princípios úteis: o sistema deve oferecer explicações; elas precisam fazer sentido para o destinatário; devem refletir corretamente o processo; e o sistema deve reconhecer seus limites de conhecimento.
Isso exige avaliar tanto a fidelidade técnica quanto a compreensão. Uma explicação pode estar matematicamente correta e ser inútil para quem precisa decidir se concorda com ela.
O que as obrigações brasileiras já exigem
O enquadramento depende do tipo de decisão, dos dados tratados e das regras aplicáveis ao produto. Há deveres distintos que precisam ser traduzidos em controles operacionais.
LGPD: critérios, procedimentos e revisão
O art. 20 da LGPD assegura ao titular o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais que afetem seus interesses. O § 1º exige, quando solicitadas, informações claras e adequadas sobre critérios e procedimentos, observados os segredos comercial e industrial.
A redação vigente não determina expressamente que a revisão seja feita por pessoa natural. Quando a operação adota supervisão humana como controle, porém, precisa verificar se o revisor dispõe de informação e autoridade para intervir.
Lei do Contrato de Seguro: fundamentação das recusas
A Lei nº 15.040/2024 estabelece obrigações diretamente relacionadas ao tema:
- Propostas: o art. 49 exige comunicação da justificativa da recusa. O prazo máximo é de 25 dias, com reinício nas hipóteses do § 2º.
- Subscrição: o art. 51 veda políticas técnicas e comerciais conducentes à discriminação social ou prejudiciais à livre iniciativa empresarial.
- Sinistros: o art. 83 determina a entrega dos documentos que fundamentem a negativa, ressalvadas as exceções legais de sigilo e proteção de terceiros.
- Recusa de cobertura: o art. 86, § 6º, exige manifestação expressa e motivada e restringe a alteração posterior do fundamento, salvo conhecimento de fatos antes desconhecidos.
Esses dispositivos tornam relevante preservar a relação entre evidências, critérios e decisão.
Regulação setorial: controles e regras do contrato
A Resolução CNSP nº 416/2021 trata de controles internos, gestão de riscos e auditoria interna. Processos apoiados por modelos devem ser avaliados dentro dessa estrutura, conforme os riscos envolvidos. A norma continua entre as referências utilizadas pela própria SUSEP em suas orientações de segurança para supervisionadas.
Nos seguros de danos, a Resolução CNSP nº 496/2026 também precisa entrar no mapeamento. Ela disciplina contratos e procedimentos de sinistro, com adaptação dos planos existentes até 4 de janeiro de 2027 e aplicação obrigatória aos contratos formados ou renovados a partir de 5 de janeiro de 2027, observadas suas disposições de transição.
Essas referências não estabelecem uma técnica universal de explicação. A aplicação prática exige identificar o que cada decisão demanda e demonstrar como o sistema atende a essa necessidade.
Modelos interpretáveis ou explicação pós-hoc?
A escolha deve começar pelo problema e pelo desempenho necessário. Modelos interpretáveis podem reduzir o esforço de explicação, especialmente em dados estruturados, mas continuam exigindo validação, documentação e comunicação adequada.
O trabalho de Cynthia Rudin sobre decisões de alto impacto apresenta argumentos para considerar modelos interpretáveis desde o desenho da solução, em vez de assumir que a complexidade é inevitável.
| Abordagem | Contribuição para a explicação | Cuidado necessário |
|---|---|---|
| Regras explícitas | Permitem identificar condições e caminhos aplicados. | Regras numerosas ou conflitantes podem dificultar a compreensão. |
| Modelos lineares, GLMs e scorecards | Podem oferecer contribuições legíveis, conforme sua construção. | Transformações, interações e grande quantidade de variáveis podem reduzir a interpretabilidade. |
| GAMs | Permitem examinar efeitos aditivos, inclusive não lineares. | Os efeitos podem variar ao longo dos valores da variável; não há necessariamente um único peso ou sinal. |
| Ensembles com atribuição pós-hoc | Ajudam a analisar a contribuição das variáveis para uma saída. | O resultado depende do método, de suas hipóteses e referências. |
| LLMs sobre documentos | Podem extrair informações e apresentar trechos de apoio. | Citações e respostas precisam ser verificadas no documento original. |
Os GAMs acomodam relações não lineares mantendo uma estrutura aditiva, como descreve a documentação do pyGAM.
Também é impreciso tratar toda atribuição pós-hoc como uma aproximação numérica. O Tree SHAP, por exemplo, oferece cálculos exatos sob determinadas hipóteses. Essa exatidão não estabelece causalidade nem demonstra a legitimidade da decisão.
O limite da regra aplicada sobre um score
Uma regra como “encaminhar para análise quando o score superar determinado valor” explicita o encaminhamento. Ela não esclarece, sozinha, por que aquele caso recebeu o score.
Quanto mais o resultado do modelo determinar preço, recusa ou prioridade de atendimento, maior a necessidade de compreender sua contribuição. A camada de regras ajuda a organizar a decisão, mas sua existência não resolve automaticamente a opacidade do modelo.
Um exemplo: quando a revisão corrige a recomendação
Considere um caso hipotético de análise documental de sinistro.
A apólice tem início de vigência em 15 de agosto. Um sistema de leitura interpreta a data do evento como 2 de agosto, embora o documento original registre 30 de agosto. A divergência aciona uma regra de encaminhamento para análise.
| Etapa | O que acontece | O que precisa ficar disponível |
|---|---|---|
| Documento recebido | O comprovante informa a data do evento. | Arquivo original e identificação de sua origem. |
| Leitura automatizada | O sistema extrai uma data incorreta. | Resultado extraído e identificação da versão utilizada. |
| Regra aplicada | A data anterior à vigência gera uma pendência. | Regra e configuração vigentes. |
| Revisão humana | O analista consulta o original e corrige a extração. | Conteúdo apresentado, correção e fundamento. |
| Decisão final | A cobertura é confirmada após as demais verificações. | Evidências e fundamentos efetivamente utilizados. |
| Comunicação | O segurado recebe a manifestação correspondente. | Conteúdo, data e registro do envio. |
O exemplo mostra por que a tela do revisor precisa oferecer acesso à evidência original. Se ela exibir apenas uma recomendação, a intervenção humana pode não identificar a falha.
Também mostra por que correções devem preservar o histórico. Sobrescrever a data extraída sem registrar a alteração apagaria a informação necessária para entender o encaminhamento inicial.
O que registrar para reconstituir uma decisão
Os registros precisam ser recuperáveis pelo identificador da proposta, apólice ou sinistro. Isso pode ser feito por vínculos entre sistemas, sem concentrar todos os dados em um único repositório.
O conjunto deve permitir recuperar:
Entradas utilizadas
Valores efetivamente considerados, fontes e momento da consulta, na medida necessária para o caso.
Preparação dos dados
Transformações, preenchimentos e validações que alteraram o conteúdo recebido pelo modelo.
Versões e configurações
Modelo, regras, parâmetros de corte e, quando aplicável, prompts e documentos de contexto.
Saída original
Score, classe, extração ou texto antes de sua apresentação na interface.
Explicação e método
Resultado apresentado ou recursos necessários para recalculá-lo, incluindo configuração e conjunto de referência.
Intervenção humana
Informação disponível ao revisor, decisão tomada e fundamento das alterações.
Comunicação
Conteúdo enviado, destinatário, data, canal e comprovação pertinente.
Esses registros devem ser protegidos contra alteração indevida, com controle de acesso e histórico das correções.
A capacidade de acompanhar um caso entre integrações, modelos e sistemas de negócio se relaciona à observabilidade em sistemas de seguros. Para explicabilidade, é necessário conectar esse acompanhamento aos fundamentos da decisão.
Persistir a explicação ou recalcular depois?
As duas opções podem ser adequadas, desde que suas condições sejam verificadas.
| Estratégia | Quando avaliar | Condição essencial |
|---|---|---|
| Persistir a explicação junto da decisão | Necessidade de resposta rápida ou dificuldade de reproduzir o ambiente. | Validar a explicação armazenada e preservar sua configuração. |
| Recalcular quando necessário | Demanda eventual e custo elevado de cálculo contínuo. | Preservar e testar o carregamento do modelo, dados e método originais. |
| Combinar estratégias | Decisões com efeitos e volumes diferentes. | Definir critérios documentados para cada grupo. |
Recalcular com o modelo atual não explica automaticamente uma execução antiga. Mesmo com o modelo preservado, mudanças no método de explicação ou em seus dados de referência podem alterar o resultado.
Em sistemas generativos, reconstituir o que ocorreu também exige preservar a saída efetivamente utilizada. Uma nova geração pode produzir outro texto.
Como verificar se a explicação funciona
A existência de um arquivo de explicação é apenas o começo. Sua avaliação deve responder a quatro perguntas:
Fidelidade
O conteúdo corresponde ao modelo, às regras e às evidências daquele caso?
Compreensão
O destinatário consegue identificar o motivo apresentado?
Utilidade
O revisor consegue detectar erros e fundamentar uma intervenção?
Recuperação
A operação consegue reunir as evidências dentro do prazo necessário?
A taxa de divergência entre analista e modelo pode ajudar no acompanhamento, mas não prova a qualidade da revisão. Poucas alterações podem refletir recomendações adequadas ou dificuldade para perceber e corrigir falhas. É necessário examinar casos e fundamentos.
O nível de detalhe também precisa considerar o destinatário. Em antifraude, divulgar limiares e mecanismos de detecção pode facilitar tentativas de contorno. A operação deve definir quais informações são necessárias para esclarecer a decisão e quais detalhes exigem proteção, com fundamento aplicável a cada situação.
Checklist para avaliar uma decisão real
Diagnóstico rápido
Escolha um caso concluído e verifique quantas respostas são “sim”.
O objetivo é testar se a decisão pode ser compreendida, reconstruída e sustentada a partir dos registros efetivamente disponíveis.
A Tecnologia Única pode apoiar a estruturação de sistemas, integrações e fluxos de dados para que informações relevantes permaneçam conectadas e recuperáveis ao longo da operação.
Cada resposta negativa indica uma lacuna a investigar. A contagem não constitui nota de maturidade nem atestado de conformidade.
Os registros podem conter dados pessoais e sensíveis. Por isso, o desenho deve contemplar finalidade, base legal, necessidade, segurança e descarte, conforme as disposições aplicáveis da LGPD. Preservar evidências não significa guardar indiscriminadamente tudo o que estiver disponível.
Como estruturar o próximo passo
Comece por um caso de uso que influencie diretamente aceitação, preço ou sinistro. Reúna negócio, jurídico, riscos e tecnologia para examinar uma decisão já tomada.
A partir desse caso, defina as explicações necessárias, seus destinatários e os prazos de resposta. Depois, estabeleça o que será preservado, o que poderá ser recalculado e como a recuperação será testada. Transforme as lacunas encontradas em entregas com responsável e prazo.
Esse trabalho deve fazer parte da governança de IA em seguradoras, com critérios de aprovação, acompanhamento e revisão dos usos.
A configuração dos produtos e a organização do fluxo de aceitação são partes dessa arquitetura.
Na solução de Gestão de Seguros da Tecnologia Única, o módulo administrativo permite configurar produtos, a cotação utiliza suas parametrizações e o gerenciamento de workflow organiza a aceitação. Os controles de explicação, versionamento e registro por execução precisam ser definidos no escopo de cada implementação.
O primeiro passo pode ser estruturar um fluxo com evidências suficientes para compreender o resultado, revisar falhas e sustentar a decisão antes de ampliar a arquitetura para outros processos da operação.
Perguntas frequentes (FAQ)
O art. 20, § 1º, trata de informações claras e adequadas sobre critérios e procedimentos, observados os segredos comercial e industrial. Não estabelece uma obrigação geral de entregar código-fonte. O § 2º prevê a possibilidade de auditoria pela ANPD quando a informação for negada com base nesses segredos.
Essas técnicas podem ajudar a analisar a influência das variáveis. A fundamentação também precisa considerar os fatos, as regras aplicáveis e a forma como o resultado participou da decisão. Uma atribuição técnica não demonstra, por si, que o critério utilizado era legítimo.
A definição deve considerar as exigências de conservação aplicáveis, a necessidade de exercício de direitos e a finalidade do tratamento. O prazo e seus fundamentos precisam ser documentados, com participação das áreas responsáveis e critérios de descarte. Não se deve adotar retenção indefinida apenas porque os registros podem ser úteis no futuro.
Referências
[1] Planalto. Lei nº 13.709, de 14 de agosto de 2018 — Lei Geral de Proteção de Dados Pessoais (LGPD).
[2] Planalto. Lei nº 15.040, de 9 de dezembro de 2024 — Lei do Contrato de Seguro.
[3] CONSELHO NACIONAL DE SEGUROS PRIVADOS — CNSP. Resolução nº 416, de 20 de julho de 2021.
[4] Susep. Resolução nº 416, de 20 de julho de 2021.
[5] CONSELHO NACIONAL DE SEGUROS PRIVADOS — CNSP. Resolução nº 496, de 17 de agosto de 2026.
[8] PHILLIPS, P. Jonathon et al. Four Principles of Explainable Artificial Intelligence.
EN 
PT 
ES 
FR 
IT 
DE