Governança de IA em seguros vai além de políticas: entenda o que a SUSEP exige em audit trail de decisões automatizadas e o papel do Compliance.
Compliance
# Por que sua área de Compliance precisa entrar na sala antes do projeto de IA começar
O projeto já tem nome, tem squad, tem OKR. O modelo de IA está em fase de treinamento. Alguém do time de Inovação apresentou os resultados preliminares para a diretoria na semana passada. Compliance ainda não foi chamado.
Esse padrão se repete em seguradoras e instituições financeiras brasileiras hoje. O problema não é falta de intenção de incluir a área de riscos. O problema é estrutural: projetos de IA nascem em TI ou Inovação com lógica de produto, e Compliance entra quando já existe algo em produção para auditar. Às vezes, quando já existe algo em produção que deu errado.
A pergunta que o Diretor de Riscos vai precisar responder em 2026 não é "o modelo funciona bem?". É: "quem aprovou a regra que esse modelo está aplicando, quando ela entrou em vigor, e como eu consigo mostrar isso para a SUSEP?"
A Resolução CNSP 395/2020 estabelece requisitos de governança para o uso de modelos internos e processos de subscrição automatizada. A Circular SUSEP 667 avança nas exigências de explicabilidade para decisões automatizadas que afetam segurados. O que essas normas têm em comum: pressupõem que a seguradora consegue explicar, com precisão, qual critério foi aplicado em uma decisão específica, em qual versão estava esse critério no momento da decisão, e quem tinha autoridade para modificá-lo.
Essa é a pergunta que a fiscalização vai fazer. Seguradoras que não têm resposta operacional para ela não têm um problema de compliance futuro. Têm um problema presente que ainda não foi auditado.
O nó é este: IA generativa e modelos preditivos não respondem essa pergunta por construção. Um modelo de machine learning que aprende padrões históricos de subscrição não "aplica uma regra". Ele infere uma probabilidade com base em padrões que o treinamento identificou nos dados. Quando o auditor pergunta "por que esse sinistro foi negado?", a resposta técnica honesta é "o modelo atribuiu score 0,23 para elegibilidade com base em 47 variáveis ponderadas de forma que o próprio modelo não decompõe em linguagem humana auditável". Isso não é uma resposta que a SUSEP vai aceitar.
O Artigo 20 da Lei Geral de Proteção de Dados estabelece o direito do titular de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais. Em seguros, isso inclui decisões de subscrição, de elegibilidade de cobertura e de liquidação de sinistros.
O que esse artigo exige operacionalmente: a seguradora precisa conseguir revisar a decisão. Revisar pressupõe explicar. Explicar pressupõe que existe uma cadeia de decisão documentada, não apenas um output de modelo.
A maioria das seguradoras brasileiras que adotou modelos preditivos nos últimos três anos não tem esse mecanismo implementado. O modelo produz uma decisão. A decisão vai para o sistema. O sistema executa a ação. Não existe camada intermediária que registre, em linguagem auditável, qual regra determinística foi aplicada sobre o output do modelo antes da ação final chegar ao segurado.
Isso não é hipótese regulatória. É a arquitetura que está em produção hoje.
Muitas seguradoras responderam ao avanço regulatório com documentos. Há uma "política de uso responsável de IA". Há um comitê que se reúne trimestralmente. Há princípios de ética e transparência publicados no site institucional.
Nenhum desses artefatos responde à pergunta da fiscalização.
O que a SUSEP vai pedir não é o documento de política. É o audit trail da decisão específica. Qual regra estava vigente em 14 de março de 2025 às 09h43 quando o modelo recusou a cobertura do sinistro 2025-RS-004821? Quem autorizou a versão dessa regra? Desde quando ela estava em produção?
Política de IA trata de intenção. Governança operacional trata de registro. A diferença entre os dois é exatamente o que aparece quando a fiscalização chega.
IA generativa e modelos preditivos têm capacidades reais e limitações reais. Fazem muito bem o que processos determinísticos não conseguem escalar: interpretar texto livre de laudos periciais, identificar padrões de fraude em volume massivo de dados, classificar automaticamente documentos de sinistros, inferir risco em variáveis não estruturadas.
O que IA não faz, por construção: executar regra determinística com garantia de auditabilidade. O modelo aprende padrões. Ele não "aplica" uma regra no sentido que o regulador entende por regra, ou seja, um critério explícito, versionado, com autor e data de aprovação, que pode ser inspecionado e contestado.
Isso cria uma fronteira arquitetural que quem desenha sistemas de decisão automatizada precisa respeitar. IA extrai, classifica e infere. A decisão final, quando tem consequência regulatória, precisa passar por uma camada determinística que saiba dizer exatamente o que foi aplicado e por quê.
Arquiteturas maduras de decisão automatizada combinam as duas coisas: IA na entrada (interpretação, extração, scoring), motor de regras na saída (decisão determinística sobre o resultado da IA, com versionamento e audit trail). As duas camadas fazem coisas diferentes. As duas são necessárias. Usar apenas uma cria um gap que vai aparecer na auditoria, no board, ou nos dois ao mesmo tempo.
Um motor de gestão de regras de negócio (BRMS) não é uma ferramenta de TI. É a camada onde a decisão de negócio se torna auditável.
O que isso significa operacionalmente para uma área de Compliance:
Toda regra de subscrição, elegibilidade ou liquidação tem versão com data de início e data de fim de vigência. Quando a SUSEP pergunta qual critério estava ativo em uma data específica, a resposta existe no sistema, com precisão de minutos.
Toda mudança de critério tem um autor e um aprovador registrados. Não é inferência a partir do histórico de commit do repositório. É um registro de negócio com identidade de quem autorizou.
O negócio muda o critério sem abrir ticket para TI. Isso importa para Compliance porque elimina a zona cinzenta onde a regra existe em planilha, em e-mail, em memória de colaborador, mas não em lugar nenhum que a fiscalização consiga inspecionar. Uma seguradora de médio porte que acompanhamos tinha regras de subscrição do ramo residencial distribuídas entre oito planilhas e três documentos internos, sem versão centralizada, sem autor, sem data de vigência.
Cada decisão produz um log que vincula o output ao conjunto de regras ativo naquele momento. Audit trail real: não "o sistema tomou essa decisão", mas "a regra X, versão 4.2, aprovada por Fulano em 15/01/2025, produziu esta decisão com estes parâmetros de entrada".
Quando Compliance entra depois que o modelo está em produção, as opções disponíveis são ruins. Desligar o modelo em produção tem custo operacional alto. Retrofitar audit trail em sistema já rodando é tecnicamente arriscado e caro. Documentar retroativamente decisões já tomadas, para uma auditoria que pode cobrir os últimos 24 meses, frequentemente não é possível.
Quando Compliance entra antes, as perguntas são diferentes: que camada vai garantir a auditabilidade das decisões que esse modelo vai produzir? Quem aprova mudanças de critério e como essa aprovação fica registrada? O output do modelo vai entrar direto no sistema de ação, ou vai passar por uma camada de regras determinísticas antes? Como vamos responder à SUSEP se questionarem uma decisão específica tomada 18 meses atrás?
Essas perguntas têm custo de engenharia baixo quando feitas no desenho. Têm custo alto quando feitas depois que o sistema está processando apólices.
Regra muda. Versão some. Auditoria chega.
O debate internacional sobre governança de IA, seja no EU AI Act, nas diretrizes do NIST AI Risk Management Framework ou nos princípios que o BACEN vem sinalizando para o setor financeiro brasileiro, converge num ponto: sistemas de IA de alto risco que tomam decisões com impacto significativo sobre pessoas precisam de explicabilidade operacional, não declaratória.
Explicabilidade declaratória é o documento de política que diz "nosso sistema é transparente e auditável". Explicabilidade operacional é o registro que prova, para um caso específico, em uma data específica, com um segurado específico, qual critério foi aplicado, por qual razão, por autoridade de quem.
O setor de seguros brasileiro opera majoritariamente com explicabilidade declaratória em sistemas que a SUSEP vai progressivamente exigir explicabilidade operacional. Esse gap tem endereço e tem prazo.
O ponto de intervenção mais eficiente para uma área de Compliance é o processo de aprovação de novos projetos. Antes de qualquer projeto de IA que toque decisão automatizada com impacto regulatório ir para desenvolvimento, quatro perguntas precisam ter resposta arquitetural documentada:
Como cada decisão produzida por este sistema vai ser registrada em forma auditável?
Quem aprova mudanças nos critérios que o sistema aplica, e como essa aprovação fica rastreável?
Se a SUSEP pedir o critério exato aplicado em uma decisão específica tomada há 18 meses, em menos de quanto tempo conseguimos responder?
O output do modelo entra direto no sistema de ação, ou passa por uma camada determinística antes?
Se as respostas a essas perguntas não estiverem no documento de arquitetura antes do projeto entrar em desenvolvimento, Compliance vai ser chamado quando algo der errado em produção. O cenário que o setor já conhece bem.
Pegue os projetos de IA que estão em produção hoje na sua organização. Para cada um, verifique se existe um registro que consegue responder, para uma decisão específica tomada em uma data específica, qual versão do critério estava ativa, quem aprovou, e desde quando. Se a resposta for "precisaria verificar com TI", o audit trail que a SUSEP vai pedir não existe ainda.
Se quiser olhar isso na arquitetura da sua seguradora: https://abaccus.com.br/fale-conosco
