Compartilhe »

Inizio » Governança de IA em seguradoras: controle e responsabilidade

Governança de IA em seguradoras: controle e responsabilidade

Isabelle Fujioka
16/09/2026
20 minutos
Imprensa

Governança de IA em seguradoras é definir quais usos de IA existem na operação, que efeito cada um produz sobre o segurado, quem responde por eles e que registro sustenta cada decisão. No Brasil, ela não depende de uma lei específica de IA: LGPD, normas do CNSP e da SUSEP e a Lei nº 15.040/2024 já alcançam esses processos.

A pergunta prática, portanto, não é se a seguradora precisa de governança de IA — é se ela consegue, hoje, listar onde a IA já decide ou influencia decisões, e provar como cada uma dessas decisões foi tomada. Na maior parte das operações, a adoção avançou por iniciativas isoladas, e o inventário nunca existiu.

Principais pontos

Governança de IA não é um comitê nem uma política genérica de uso de ferramentas: são quatro objetos concretos — inventário de casos de uso, classificação por efeito, dossiê mínimo por caso e revisão após a implantação.
Não existe, em setembro de 2026, lei específica de IA em vigor no Brasil nem norma da SUSEP dedicada ao tema. O que existe são obrigações que já alcançam IA: revisão de decisões automatizadas (LGPD, art. 20), controles internos e gestão de riscos (Resolução CNSP nº 416/2021), segurança cibernética e terceirização de serviços relevantes (Circular SUSEP nº 638/2021) e motivação da recusa de cobertura (Lei nº 15.040/2024).
O controle deve ser proporcional ao efeito. Um assistente que resume documentos para uso interno e um modelo que influencia a regulação de um sinistro não exigem o mesmo rito.
O ponto mais frágil raramente é o modelo: é o registro. Sem entrada, versão, saída e responsável por execução, não há como explicar uma decisão depois — nem ao titular, nem à auditoria interna, nem ao regulador.
Criar uma estrutura de governança paralela costuma ser mais caro e menos efetivo do que estender a estrutura de gestão de riscos que a seguradora já mantém por exigência regulatória.

O que é governança de IA em uma seguradora e o que ela não é

Governança de IA costuma ser apresentada como princípios: transparência, justiça, supervisão humana, responsabilidade. Os princípios ajudam a orientar, mas não organizam trabalho.

Em uma seguradora, governança de IA se materializa quando quatro perguntas têm resposta escrita para cada caso de uso — entendido aqui como a aplicação de um modelo ou assistente a um processo específico, e não como a tecnologia em si:

O que existe. Quais casos de uso de IA estão em produção ou em avaliação, em quais processos, com quais fornecedores.
O que cada um faz. Que decisão o caso apoia ou toma, e que efeito produz sobre o segurado, o corretor ou a própria operação.
Quem responde. Qual área de negócio é dona do caso, quem responde tecnicamente, quem aprova mudanças e quem revisa o comportamento depois.
Como se prova. Que registro permite reconstituir uma execução específica meses depois.

Não é um comitê de inovação

Comitês priorizam iniciativas; governança define condições de uso e limites de execução.

Não é uma política de uso de ferramentas generativas

Regras sobre o que os colaboradores podem digitar em um assistente são úteis, mas não alcançam o modelo que participa da subscrição ou da triagem de sinistros.

Não é conformidade declarada

Afirmar que um sistema “é auditável” não é o mesmo que ter o registro que permite auditá-lo.

Ainda está definindo onde a IA faz sentido no setor?

O panorama de aplicações e riscos de inteligência artificial em seguros ajuda a identificar onde a tecnologia pode entrar e quais riscos precisam ser considerados. A partir daí, o próximo passo é estruturar uma camada de controle proporcional — sem transformar cada iniciativa em um projeto de compliance.

Ver aplicações e riscos

Onde a ausência de governança aparece na operação

A falta de governança raramente se manifesta como um incidente único e visível. Ela aparece como um conjunto de perguntas sem resposta rápida, e todas elas costumam surgir no pior momento, quando alguém de fora pergunta.

Ninguém sabe quantos usos de IA existem. Áreas contrataram assistentes, o fornecedor do core embarcou um recurso de IA em uma atualização, uma equipe conectou uma API de modelo a um fluxo de atendimento. O inventário não existe porque nunca foi pedido.
A versão mudou e ninguém registrou. Um prompt foi ajustado, um fornecedor atualizou o modelo, um parâmetro de corte foi alterado. O comportamento do processo mudou sem que houvesse aprovação, data ou responsável.
A decisão não pode ser reconstituída. Um segurado questiona uma recusa ou uma classificação. O sistema guarda a saída, mas não o que foi consultado, com qual versão e quem revisou.
O contrato não acompanhou o uso. Um serviço externo passou a processar dados de segurados sem que o enquadramento como serviço relevante fosse avaliado.
A revisão humana é formal. Existe um revisor no fluxo, mas ele confirma praticamente tudo — por volume, por prazo ou por falta de informação para discordar.

Esse último item merece um alerta próprio, porque é o que mais frequentemente produz uma falsa sensação de controle.

Ponto de atenção

Quando a revisão humana existe no desenho, mas não tem condições de exercer discordância, a decisão é materialmente automatizada, ainda que formalmente atribuída a uma pessoa.

Considere o seguinte cenário ilustrativo, construído para explicar o mecanismo e não para descrever um caso real. Uma seguradora implanta um modelo que classifica avisos de sinistro por indício de fraude e devolve uma pontuação com três faixas.

A faixa superior vai para uma fila de análise especializada; a intermediária segue para conferência documental; a inferior segue o fluxo normal. Há revisão humana em todas as faixas, e o processo é descrito como “apoio à decisão”.

Na operação, a fila intermediária cresce, a meta de prazo permanece a mesma e o analista passa a ter poucos minutos por caso. A tela mostra a pontuação, mas não mostra quais variáveis a produziram. Em três meses, a taxa de divergência entre o analista e o modelo cai para perto de zero — não porque o modelo esteja certo, mas porque discordar exigiria uma investigação que o tempo não permite.

A condição que torna esse cenário provável é específica: revisão sem informação sobre o critério, sem tempo compatível e sem métrica de divergência acompanhada.

O controle que merece avaliação não é aumentar a quantidade de revisores; é medir a taxa de divergência por faixa e tratar uma taxa próxima de zero como sinal de que a revisão deixou de ser efetiva — e, portanto, de que o caso mudou de classificação sem que ninguém tenha decidido isso.

O que a regulação brasileira já exige de quem usa IA em seguros

Esta é a área em que a imprecisão custa mais caro, nos dois sentidos: tanto afirmar obrigações que não existem quanto tratar a ausência de uma lei de IA como ausência de exigência. Atualmente, o quadro aplicável a uma seguradora brasileira é o seguinte:

Norma vigente	O que exige	O que muda em um caso de uso de IA
LGPD, art. 20	Revisão de decisões tomadas unicamente por tratamento automatizado que afetem o titular; informação sobre critérios e procedimentos (§ 1º); auditoria de aspectos discriminatórios pela ANPD (§ 2º).	Modelos que influenciam recusa, preço, elegibilidade ou priorização precisam deixar rastro suficiente para explicar o critério.
LGPD, art. 6º	Transparência, segurança, prevenção e responsabilização.	É preciso demonstrar a adoção de medidas, não apenas afirmá-las.
Resolução CNSP nº 416/2021	Controles internos, gestão de riscos e auditoria interna; identificação dos riscos relevantes, incluindo o operacional (art. 14); dever da administração de zelar pela efetividade (art. 36); conservação de políticas, normativos e relatórios (art. 43).	Processo apoiado por IA é processo da supervisionada: entra no escopo existente, sem categoria nova.
Circular SUSEP nº 638/2021	Política de segurança cibernética e classificação de serviços por relevância (art. 4º); incidentes relevantes em até 5 dias úteis (art. 8º); serviços relevantes com notificação à SUSEP em até 30 dias (art. 10) e controles do prestador não inferiores aos da supervisionada (art. 11).	Contratar API de modelo ou plataforma de IA que processa dados de segurados é decisão de terceirização.
Manual de Segurança Cibernética da SUSEP (junho/2026)	Orienta identificar e classificar serviços relevantes, citando “processamento, armazenamento e análise de dados, inclusive por meio de soluções baseadas em inteligência artificial”.	Encerra a dúvida de enquadramento: IA está entre os exemplos de serviço relevante.
Lei nº 15.040/2024 (vigor desde 9/12/2025)	30 dias para manifestação sobre a cobertura; recusa expressa e motivada (art. 86); entrega dos documentos que fundamentaram a negativa (art. 83).	Se um modelo participa da regulação do sinistro, o que ele produziu se conecta à motivação exigida.

O que ainda não existe, e que costuma ser anunciado como se existisse: uma lei brasileira de IA em vigor. O PL 2338/2023 foi aprovado pelo Senado e remetido à Câmara dos Deputados em março de 2025, onde tramita em regime de prioridade e, em 2 de setembro de 2026, constava como aguardando parecer.

A ele foi apensado, em abril de 2026, o PL 6237/2025, enviado pelo Executivo, que institui o Sistema Nacional para Desenvolvimento, Regulação e Governança de Inteligência Artificial e prevê categorias de alto risco, avaliação de impacto algorítmico, comunicação de incidentes graves e competência normativa e fiscalizatória de autoridades setoriais.

Duas consequências práticas. A primeira: o desenho em discussão tende a pedir exatamente o que hoje falta — inventário, classificação por risco, avaliação de impacto e rastreabilidade. Quem organiza isso agora não antecipa obrigação inexistente; constrói o que já é necessário para responder às normas vigentes. A segunda: no setor de seguros, a autoridade setorial seria a SUSEP.

O Plano de Regulação da SUSEP para 2026 concentra prioridades na implementação da Lei nº 15.040/2024 e da Lei Complementar nº 213/2025, em revisões de normas setoriais, sandbox, Open Insurance e prevenção à lavagem de dinheiro — sem entrega dedicada ao uso de IA. Já a ANPD incluiu “inteligência artificial e tecnologias emergentes no contexto do tratamento de dados pessoais” entre os temas prioritários de fiscalização para o biênio 2026-2027.

Ou seja: a pressão mais próxima não vem de uma futura lei de IA. Vem da proteção de dados e das obrigações contratuais e de sinistro que já estão em vigor.

Ainda não existe um inventário dos usos de IA e seus enquadramentos?

Esse tende a ser o primeiro entregável: identificar onde a IA já participa dos processos, quais normas alcançam cada uso e quais controles precisam existir. Esse mapeamento costuma ser mais útil no início do que discutir qual modelo adotar.

Mapear usos e enquadramentos

Como estruturar governança sem criar uma estrutura paralela

O erro mais caro nesta etapa é tratar IA como um domínio de governança separado, com política própria, comitê próprio, taxonomia própria e relatórios próprios. Isso cria um segundo sistema de controles que precisa ser mantido, auditado e conciliado com o primeiro — e que tende a envelhecer rápido.

A alternativa mais estável é tratar IA como fonte de risco dentro da estrutura que já existe. A Resolução CNSP nº 416/2021 já obriga a seguradora a identificar riscos operacionais e outros riscos relevantes, a documentar políticas e relatórios e a manter auditoria interna. Um caso de uso de IA é um processo que muda a forma como um risco conhecido se manifesta — não um risco de natureza nova.

Sobre essa base, quatro objetos concretos sustentam a governança:

Inventário de casos de uso

Uma lista viva, com dono de negócio, dono técnico, processo afetado, fornecedor, dados utilizados, data de entrada em produção e data da última revisão. Sem inventário, nenhum outro controle é verificável, porque não se sabe a que se aplica. Na prática, montá-lo costuma revelar mais usos do que a liderança esperava — inclusive recursos de IA embarcados em sistemas já contratados.

Classificação por efeito

Cada caso recebe uma faixa conforme o efeito sobre o segurado e o grau de autonomia. A faixa determina o rito de aprovação, o nível de registro e a frequência de revisão.

Dossiê mínimo por caso

O conjunto de informações que permite explicar o caso e reconstituir uma execução.

Revisão após a implantação

Amostragem periódica, gatilhos de reavaliação e responsável nomeado. É o controle mais esquecido e o que mais diferencia governança real de documento aprovado.

Quanto aos papéis, a divisão que costuma funcionar acompanha as linhas de defesa que a seguradora já opera: a área de negócio responde pelo caso de uso e por suas exceções; tecnologia responde pela implementação, versionamento e registro; riscos e compliance definem critérios de classificação e revisam os casos de faixa mais alta; auditoria interna verifica se o processo desenhado é o processo executado.

Um comitê pode ser útil quando há volume de casos e decisões de priorização a tomar — mas ele é uma consequência do volume, não um pré-requisito para começar.

Para quem quer referência externa de estrutura, dois documentos são citados com frequência e podem ser adotados de forma voluntária: a ISO/IEC 42001:2023, que especifica requisitos para um sistema de gestão de IA, e o NIST AI Risk Management Framework, organizado em quatro funções — governar, mapear, medir e gerenciar.

No setor segurador europeu, a Opinion da EIOPA sobre governança e gestão de riscos de IA, de agosto de 2025, orienta supervisores nacionais com abordagem baseada em risco e proporcionalidade.

Nenhum desses documentos é exigência no Brasil, e adotar qualquer um deles não comprova conformidade com a regulação brasileira — mas os três ajudam a não reinventar a taxonomia.

Classificação por efeito: o controle proporcional ao que está em jogo

Tratar todos os usos de IA com o mesmo rigor produz um de dois resultados: ou o rito é tão pesado que as áreas passam a contornar a governança, ou é tão leve que não protege os casos que realmente importam. A classificação por efeito resolve isso ao separar o que exige rito formal do que exige apenas registro básico.

Faixa	Exemplos típicos	Controles mínimos que costumam se aplicar	Quem aprova
A — Apoio interno, sem efeito sobre o titular	Resumo de documentos internos, apoio à redação, busca em base de conhecimento, sugestão de código.	Finalidade registrada, regra sobre que dados podem ser usados, responsável nomeado, orientação de uso.	Dono do processo.
B — Apoio a decisão sobre pessoa, com decisão humana efetiva	Sugestão de classificação de sinistro, priorização de fila, apoio à subscrição, indício de fraude para análise.	Tudo da faixa A, mais: registro da saída apresentada e da decisão tomada, medição de divergência, informação suficiente para o revisor discordar, revisão periódica de amostras.	Dono do processo e riscos/compliance.
C — Decisão automatizada com efeito sobre o titular	Recusa, precificação, elegibilidade ou liquidação definidas sem intervenção humana.	Tudo da faixa B, mais: limites de execução escritos, procedimento de revisão previsto no art. 20 da LGPD, dossiê completo, trilha por execução, plano de reversão e aprovação formal antes do go-live.	Riscos/compliance e administração, conforme a política interna.

Duas observações sobre essa tabela. A primeira: a faixa não é uma propriedade do modelo, e sim do uso. O mesmo modelo de extração de dados pode ocupar a faixa A em um processo interno e a faixa B quando alimenta a regulação de um sinistro.

A segunda: a passagem da faixa B para a C raramente é decidida — ela acontece quando a revisão humana perde efetividade, como no cenário descrito acima. Por isso a medição de divergência é um controle de classificação, não apenas de qualidade.

Quando a discussão envolve sistemas que decidem a própria sequência de passos e executam ações em vários sistemas, o recorte muda: a decisão passa a ser quanto de autonomia delegar, degrau a degrau, tema tratado em níveis de delegação para agentes de IA em seguradoras.

O classificador a seguir organiza, para um caso de uso por vez, quais controles merecem tratamento conforme as respostas. Ele não atribui nota nem atesta conformidade.

O que sai do classificador é uma lista de trabalho, não um diagnóstico da operação. O passo seguinte é transformar cada item em responsável e prazo — e, nos casos em que a lacuna for registro ou integração, tratar isso como projeto de arquitetura antes de ampliar o uso.

O dossiê mínimo de um caso de uso de IA

Quando a auditoria interna, a ANPD, a SUSEP ou o advogado de um segurado perguntam sobre uma decisão específica, a resposta não pode depender de quem estava no projeto. O dossiê mínimo é o que torna a resposta institucional. Dez itens costumam bastar:

Finalidade e decisão afetada

O que o caso apoia ou decide, e em qual processo.

Faixa de classificação

A classificação atribuída ao caso, sua justificativa e a data em que foi definida.

Dados utilizados

Base legal e, para cada dado relevante, qual sistema é a fonte autoritativa.

Versões e histórico de alterações

Versão do modelo, do prompt, das regras de pós-processamento e dos parâmetros de corte, com histórico de alterações.

Critérios e limites

O que o sistema pode fazer, o que precisa de aprovação e em que situações deve parar e escalar.

Registro por execução

Entrada consultada, versão aplicada, saída, decisão final e quem revisou.

Desenho da revisão humana

Quem revisa, com qual informação, em quanto tempo e como a divergência é registrada.

Monitoramento e gatilhos

Métricas de monitoramento e gatilhos de reavaliação, incluindo o que dispara uma revisão fora do calendário.

Fornecedor, hospedagem e contrato

Onde processa, se os dados são usados para treinamento, como a versão é depreciada e a quais registros o contrato dá acesso.

Última revisão e responsável

Data da última revisão e responsável por realizá-la.

Os itens 4, 6 e 8 são os que mais frequentemente dependem de trabalho de engenharia, e não de documentação: exigem que a aplicação propague contexto, versione configuração e guarde a trilha de cada execução de forma recuperável por caso. É o mesmo conjunto de capacidades discutido em observabilidade em sistemas de seguros, aplicado a decisões apoiadas por modelos.

Antes do dossiê, confirme se o dado tem dono e fonte oficial.

Se um modelo consulta informações sem responsável definido ou sem um sistema de origem autoritativo, o controle pode documentar perfeitamente uma decisão baseada em dado desatualizado. Nesse caso, o problema precisa ser tratado primeiro na camada de governança de dados — não no modelo.

Revisar governança de dados

Fornecedor, nuvem e modelo de terceiro

A maior parte da IA que entra em uma seguradora hoje não é construída internamente: é contratada, embarcada em um sistema já existente ou consumida como API. Isso desloca boa parte da governança para a relação com terceiros — e é aqui que o enquadramento regulatório costuma ser descoberto tarde.

A Circular SUSEP nº 638/2021 exige que a contratação de serviços relevantes de processamento e armazenamento de dados e de computação em nuvem seja precedida de avaliação da capacidade do prestador, que o contrato assegure controles não inferiores aos que a própria supervisionada adota e que a SUSEP seja notificada em até 30 dias após a formalização.

O Manual de Orientações sobre Segurança Cibernética publicado pela SUSEP em junho de 2026 cita expressamente, entre os exemplos de serviço relevante, o processamento, armazenamento e análise de dados "inclusive por meio de soluções baseadas em inteligência artificial" — e reforça que a terceirização não transfere a responsabilidade institucional pela segurança e pela continuidade operacional.

O conjunto de exigências de segurança cibernética e de documentação de fornecedores está detalhado em segurança cibernética em seguradoras.

Na avaliação de um fornecedor de IA, seis perguntas costumam separar uma contratação sustentável de uma dependência difícil de desfazer:

Onde os dados são processados e quais subcontratados participam do fluxo.
Se os dados da seguradora são usados para treinar modelos do fornecedor, e sob quais condições.
Como a versão do modelo é gerenciada — há aviso prévio de atualização, é possível fixar uma versão, qual o prazo de depreciação.
Que registros o contrato torna acessíveis, em qual formato e por quanto tempo.
Como a substituição acontece se o serviço for descontinuado ou se a relação terminar.
Se o contrato prevê acesso da SUSEP às informações relacionadas ao serviço.

Uma atualização silenciosa de modelo, sem aviso e sem possibilidade de fixar versão, muda o comportamento de um processo em produção sem passar por nenhuma aprovação interna. Esse é o tipo de dependência que só aparece no contrato — e raramente aparece na demonstração.

Quando a lacuna está na base, trocar o modelo não resolve o problema.

Integração insuficiente, ausência de registro por execução e fluxos que atravessam sistemas sem deixar rastro exigem primeiro uma camada capaz de sustentar automação verificável. É sobre essa base que qualquer modelo de IA pode operar com mais controle e rastreabilidade.

Conhecer a base de automação

Comparação com alternativas

Alternativa	Quando pode funcionar	Limitação principal	Impacto possível	Critério para avançar
Tratar caso a caso, sem estrutura	Poucos usos, todos internos e sem efeito sobre o titular.	Não escala e não produz visão consolidada; a primeira pergunta externa exige reconstrução manual.	Retrabalho e respostas lentas quando houver questionamento.	O primeiro caso com efeito sobre o segurado entra em produção.
Política única de uso de IA	Necessidade imediata de orientar colaboradores sobre ferramentas generativas.	Alcança comportamento de pessoas, não modelos embarcados em processos.	Falsa sensação de cobertura.	Existem usos de IA dentro de processos de negócio, não apenas ferramentas de apoio.
Estender a estrutura de gestão de riscos existente	A seguradora já opera SCI, EGR e auditoria interna conforme a Resolução CNSP nº 416/2021.	Exige critérios de classificação específicos para IA e capacidade técnica de registro.	Aproveita rito, papéis e evidências já auditados.	Há inventário e responsáveis nomeados para começar.
Estrutura dedicada, com referencial próprio (ex.: ISO/IEC 42001)	Volume relevante de casos, exigência de cliente ou parceiro, ambição de certificação.	Custo de manutenção e risco de duplicar controles já existentes.	Organiza, mas pode competir com a governança de riscos vigente.	O volume de casos justifica um sistema de gestão próprio.
Terceirizar a governança a um fornecedor	Falta de capacidade interna para estruturar o primeiro ciclo.	A responsabilidade permanece com a seguradora; o conhecimento tende a ficar fora.	Acelera a montagem, mas cria dependência na sustentação.	Há plano de transferência de conhecimento e dono interno nomeado.

Para a maioria das operações, a terceira linha é o caminho mais defensável hoje: estender o que já existe, com critérios específicos para IA, e reservar a discussão de estrutura dedicada para quando o volume de casos justificar.

O que costuma dar errado na prática

Erro ou risco de execução	Por que acontece	Consequência possível	Como reduzir o risco
Política aprovada sem inventário	O documento é mais rápido de produzir do que o levantamento.	A política não se aplica a nada verificável; a auditoria encontra usos fora dela.	Começar pelo inventário e escrever a política a partir dos casos reais.
Classificar por tecnologia, não por efeito	É mais simples listar “modelos” do que mapear decisões.	Casos críticos com rito leve e casos triviais com rito pesado.	Classificar pelo efeito sobre o titular e pelo grau de autonomia.
Revisão humana sem condição de discordar	Meta de prazo e volume não acompanham o desenho do controle.	Decisão materialmente automatizada sem os controles da faixa correspondente.	Medir divergência por faixa e tratar taxa próxima de zero como alerta.
Registro tratado como fase dois	O piloto prioriza demonstrar valor.	Impossibilidade de explicar decisões já tomadas em produção.	Tornar o registro por execução requisito de entrega do piloto.
Fornecedor avaliado só por funcionalidade	A demonstração impressiona mais do que o contrato.	Enquadramento em serviço relevante descoberto depois; dependência de versão.	Avaliar hospedagem, uso de dados, versionamento e cláusulas junto da funcionalidade.
Governança sem revisão após o go-live	Presume-se estabilidade como em software tradicional.	Degradação silenciosa descoberta pelo cliente ou pela ouvidoria.	Definir amostragem, gatilhos e responsável nomeado antes da implantação.
Estrutura paralela à gestão de riscos	IA é tratada como assunto novo e separado.	Dois sistemas de controle desalinhados e custo dobrado de manutenção.	Conectar a classificação de IA às categorias de risco já mantidas.

Critérios de decisão

Estes critérios ajudam a definir quanto de formalização a operação precisa agora, e quando o esforço passa a ser desproporcional:

Efeito sobre o titular

Existe algum caso que influencia recusa, preço, elegibilidade ou liquidação? Se sim, a formalização deixa de ser opcional.

Grau de autonomia real

A revisão humana consegue discordar? A resposta honesta a essa pergunta define a faixa, não o desenho no papel.

Capacidade de registro

A arquitetura consegue guardar versão, entrada e responsável por execução? Se não, essa é a primeira entrega, antes de qualquer expansão.

Ver critérios de software preparado para IA

Dependência de terceiros

Quantos casos rodam em serviço externo? O volume determina o peso do trabalho contratual e de segurança.

Sensibilidade dos dados

Dados de saúde, biometria e sinistros elevam o rito, independentemente do volume de uso.

Volume e dispersão de casos

Poucos casos concentrados pedem processo leve; muitos casos espalhados por áreas pedem inventário formal e papéis nomeados.

Capacidade interna de sustentação

Há quem revise amostras e mantenha o inventário atualizado? Sem essa função, a governança vira um documento com data de validade.

Vale registrar o critério inverso, que raramente aparece: se todos os usos são internos, sem dados pessoais e sem efeito sobre decisões que afetam pessoas, montar uma estrutura formal de governança de IA agora provavelmente não é a prioridade.

Nesse caso, o inventário e uma regra clara de uso de dados costumam ser suficientes até que o primeiro caso de faixa B apareça.

Como estruturar o próximo passo

Um primeiro ciclo de governança de IA, com escopo controlado, costuma seguir esta sequência:

Schema Markup · HowTo

Levantar o inventário

Faça o levantamento com as áreas, incluindo recursos de IA embarcados em sistemas já contratados e serviços consumidos por API.

Classificar cada caso por efeito

Distribua os casos entre as faixas A, B e C e registre a justificativa da classificação atribuída a cada um.

Priorizar os casos de maior efeito

Escolha os dois ou três casos de maior efeito e monte o dossiê mínimo apenas para eles, em vez de tentar cobrir todo o inventário de uma vez.

Verificar a capacidade de registro

Identifique o que a arquitetura já registra em cada caso, o que ainda falta e qual é o esforço necessário para fechar a lacuna.

Revisar contratos e enquadramento

Analise os serviços externos envolvidos em conjunto com segurança da informação e jurídico, considerando o enquadramento aplicável.

Desenhar a revisão humana

Para os casos das faixas B e C, defina qual informação fica disponível ao revisor, qual tempo é compatível com uma revisão efetiva e como a divergência será registrada.

Definir a revisão pós-implantação

Estabeleça periodicidade, tamanho da amostra, gatilhos de reavaliação e um responsável nomeado pela rotina de revisão.

Conectar à gestão de riscos existente

Leve o resultado para a estrutura de gestão de riscos já existente, conectando a classificação de IA às categorias de risco que a operação já mantém e reporta.

Os dois primeiros passos dependem sobretudo de articulação interna e produzem resultado rápido; os passos 4 e 6 são os que costumam revelar dependências técnicas e exigir priorização junto de tecnologia.

Na prática, o gargalo aparece com frequência nesses dois pontos — a operação sabe o que quer controlar, mas os sistemas não produzem o registro necessário, e a informação que chegaria ao revisor está espalhada entre bases que não conversam.

Se a lacuna está na arquitetura, escolher o fornecedor de IA ainda não é o próximo passo.

Primeiro, vale entender o que a operação consegue integrar e registrar hoje, quais execuções podem ser reconstruídas e onde ainda existem fluxos sem rastreabilidade. A partir desse diagnóstico, a governança de IA pode virar um plano proporcional ao estágio atual da operação — e não um documento que envelhece antes da próxima auditoria.

Avaliar integração e rastreabilidade

Perguntas frequentes (FAQ)

Existe uma norma da SUSEP sobre uso de inteligência artificial por seguradoras?

Não há, até setembro de 2026, norma dedicada exclusivamente ao uso de IA. O que se aplica é o arcabouço vigente: LGPD para dados pessoais e decisões automatizadas, Resolução CNSP nº 416/2021 para controles internos e gestão de riscos, Circular SUSEP nº 638/2021 para segurança cibernética e terceirização de serviços relevantes e Lei nº 15.040/2024 para a motivação da recusa de cobertura.

Quem deve responder pela governança de IA em uma seguradora?

A responsabilidade se distribui pelas linhas que já existem: a área de negócio responde pelo caso de uso; tecnologia, pela implementação, versionamento e registro; riscos e compliance, pelos critérios de classificação e pela revisão dos casos de maior efeito; auditoria interna, pela verificação independente. Cada caso de uso precisa de um dono nomeado — sem isso, a política não tem a quem se aplicar.

A seguradora precisa de um comitê de IA?

Não por exigência regulatória. O que precisa existir é responsabilidade nomeada por caso de uso e critério de aprovação conforme o efeito. Um comitê passa a fazer sentido quando o volume de casos exige priorização e decisões colegiadas — é consequência do volume, não ponto de partida.

IA pode decidir sozinha a recusa de um sinistro?

Tecnicamente é possível; do ponto de vista de controle, é a configuração mais exigente. Uma decisão tomada unicamente com base em tratamento automatizado que afete o titular atrai o direito de revisão previsto no art. 20 da LGPD, e a Lei nº 15.040/2024 exige recusa expressa e motivada, com entrega dos documentos que fundamentaram a decisão. Se a operação não consegue reconstituir o critério de uma execução específica, esse nível de autonomia não está sustentado.

Como diferenciar governança de IA de governança de dados?

Governança de dados responde por domínio, dono, qualidade, fonte oficial e ciclo de vida da informação. Governança de IA responde por casos de uso, efeito das decisões, versões, registro de execução e revisão do comportamento. Uma depende da outra: sem fonte autoritativa definida, o modelo pode produzir decisões coerentes a partir de dados desatualizados.

Vale esperar o marco legal da IA para estruturar a governança?

Esperar tende a adiar o trabalho que já é exigido hoje pela LGPD, pelas normas do CNSP e da SUSEP e pela Lei nº 15.040/2024. Além disso, os projetos em discussão apontam para inventário, classificação de risco, avaliação de impacto e rastreabilidade — as mesmas capacidades necessárias para responder ao que já está em vigor.

Certificar-se na ISO/IEC 42001 resolve a exigência regulatória?

Não. A ISO/IEC 42001 é uma norma voluntária de sistema de gestão de IA e pode ajudar a organizar processos e evidências, mas não substitui nem comprova o cumprimento da LGPD ou das normas do CNSP e da SUSEP, que têm requisitos próprios e supervisão específica.