Agentes de IA para seguradoras — também chamados de IA agêntica — são sistemas que interpretam um objetivo, decidem os passos e executam ações em mais de um sistema, em vez de apenas responder a perguntas.
Em seguros, isso desloca a discussão de “qual ferramenta usar” para “quanto de autonomia delegar”, com trilha de auditoria, limites de execução e responsabilidade definida antes da tecnologia.
Principais pontos
- Um agente se distingue de um chatbot, de um RPA e de um motor de regras por um ponto específico: ele decide a sequência de passos, em vez de seguir uma sequência definida previamente.
- O ganho operacional aparece em processos com muitos saltos entre sistemas — sinistros, conciliação, backoffice de subscrição —, não em tarefas isoladas que um robô já resolve.
- O limite não costuma ser o modelo de IA, e sim a base: APIs disponíveis, regras escritas, registro do que foi executado e alguém que responda pelo comportamento do processo.
- Até setembro de 2026 o Brasil não tem uma lei específica de IA em vigor. O que se aplica é o arcabouço já existente: LGPD, normas de controles internos e gestão de riscos do CNSP e requisitos de segurança cibernética da SUSEP — que já trata soluções baseadas em IA como serviço relevante para fins de terceirização.
- Delegar autonomia é uma decisão graduável. Assistir, recomendar, executar com aprovação e executar por exceção são estágios diferentes, com pré-condições diferentes.
O que é um agente de IA e o que o diferencia de chatbot, RPA e motor de regras
Um agente de IA é um sistema que recebe um objetivo (“apurar a documentação deste aviso de sinistro e classificá-lo”), decide quais passos executar, usa ferramentas e sistemas externos para executá-los e avalia o próprio resultado antes de concluir ou escalar.
É o que o mercado também chama de IA agêntica (em inglês, agentic AI): a diferença em relação às automações que uma seguradora já usa não está na presença de inteligência artificial — está em quem define a sequência.
Essa distinção é prática, porque determina o que pode dar errado e o que precisa ser controlado:
| Tecnologia | Quem define a sequência de passos | O que faz bem | Onde falha |
|---|---|---|---|
| Chatbot / assistente conversacional | A pessoa, a cada turno da conversa. | Interpretar linguagem natural, responder dúvidas, coletar dados. | Não executa a ação fim a fim; depende de alguém conduzir. |
| RPA (automação robótica) | O analista, no desenho do robô. | Repetir tarefas estáveis, com alto volume e baixa variação. | Quebra quando a tela, o layout ou o caso fogem do previsto. |
| Motor de regras | A área de negócio, ao configurar a regra. | Aplicar critérios explícitos de forma consistente e auditável. | Só decide o que foi previsto como regra; não lida com o inesperado. |
| Agente de IA | O próprio sistema, a cada execução. | Encadear passos variáveis, interpretar conteúdo não estruturado, recuperar-se de desvios. | Pode escolher um caminho errado de forma plausível; exige limites e registro para ser verificável. |
As quatro camadas não competem — em uma operação madura elas se combinam. Um agente que apura um sinistro tende a usar um motor de regras para aplicar critérios de cobertura, acionar um robô para extrair dados de um sistema sem API e entregar a conversa a um assistente quando precisa falar com o segurado. S
Se a dúvida atual está em atendimento, interação e conformidade
O recorte está mais próximo de um chatbot para seguradoras com controle e conformidade.
Se a dúvida está em RPA, workflows e integrações
O recorte está em automação de processos em seguradoras e na forma como essas tecnologias se combinam ao longo da operação.
O que muda com o agente é o grau de autonomia. E autonomia, em seguros, é uma decisão de governança antes de ser uma decisão de tecnologia.
Onde um agente de IA encontra trabalho real em uma seguradora
Agentes tendem a render onde o trabalho humano é caro por um motivo específico: a pessoa não está pensando, está saltando entre sistemas e reunindo contexto.
Alguns territórios em que esse padrão aparece com frequência no setor:
- Aviso e triagem de sinistro. Ler o aviso e os documentos anexos, verificar cobertura e vigência da apólice, identificar o que falta, pedir o complemento e classificar o caso por complexidade.
- Conciliação e cobrança. Cruzar arquivos de retorno bancário, parcelas em aberto e registros de apólice, isolar as divergências reais e preparar o lote de tratamento manual já com o motivo de cada exceção.
- Backoffice de subscrição. Reunir informações dispersas de uma proposta — cadastro, histórico, laudos, bases externas — e montar o dossiê que o subscritor analisa, em vez de o subscritor montá-lo.
- Atendimento a corretor e canal. Responder o status de uma proposta ou de um sinistro consultando o sistema em que a informação está, não uma base paralela de perguntas frequentes.
- Preparação de obrigações regulatórias. Organizar evidências e conferir consistência de informações antes de um envio, deixando a conferência final e o envio para a área responsável.
Em todos esses casos o agente é útil porque atravessa fronteiras de sistema. É também por isso que ele depende da arquitetura: um agente só executa aquilo que os sistemas permitem executar por serviço ou API.
Onde há apenas telas e integrações ponto a ponto, o agente herda a mesma fragilidade que hoje limita a automação — assunto que o core system de seguros e seus critérios de integração trata com mais profundidade.
É nesses pontos que a automação com autonomia tende a ampliar um risco já existente. O mapeamento ajuda a separar decisões mal estruturadas de problemas de integração antes de qualquer discussão sobre fornecedor.
O que muda no risco quando a execução deixa de ser humana
Quando uma automação determinística erra, ela erra sempre do mesmo jeito — e por isso é relativamente fácil de detectar. Um agente erra de forma variável: diante de duas execuções parecidas, pode escolher caminhos diferentes, ambos plausíveis. Isso cria três consequências práticas que merecem atenção antes da adoção.
A verificação muda de objeto
Não basta testar se o código funciona; é preciso avaliar amostras de execuções reais ao longo do tempo, porque o comportamento depende de entradas que variam. Sem amostragem periódica, uma degradação silenciosa pode durar meses.
O registro passa a ser o único meio de reconstrução
Se não houver log de qual informação o agente consultou, qual ação executou e com qual resultado, não existe maneira confiável de explicar uma decisão depois — nem para a auditoria interna, nem para o segurado, nem para o regulador.
A responsabilidade não se transfere
Delegar execução a um sistema não desloca a responsabilidade da seguradora pelo resultado. Isso vale tanto para a relação com o segurado quanto para a relação com a SUSEP.
Ponto de atenção
O risco mais subestimado em agentes não é a alucinação visível — é a execução parcialmente correta.
Considere o seguinte cenário ilustrativo, construído para explicar o mecanismo e não para descrever um caso real.
Uma seguradora coloca um agente para triar avisos de sinistro de um produto de garantia estendida. O agente lê o aviso, classifica corretamente a cobertura e consulta a apólice para confirmar limites. A consulta, porém, atravessa duas fontes: o core system e uma base de apoio alimentada por rotina noturna. Um endosso de redução de limite, feito há três dias, existe apenas na primeira. O agente lê a base de apoio, encontra o limite antigo, conclui pela cobertura integral e libera o caso.
O resultado parece consistente: a cobertura estava certa, o produto estava certo, o raciocínio registrado estava coerente. A revisão por amostragem, se olhar apenas a classificação, aprova.
O erro só aparece quando o segurado é comunicado de um valor que a apólice vigente não sustenta — e, a essa altura, o mesmo padrão já se repetiu em outros casos, porque a causa não é aleatória: é estrutural.
A condição que torna esse cenário provável é específica — fontes de dados duplicadas, sem uma origem única definida para cada informação.
O controle que merece avaliação antes de ampliar autonomia é simples de enunciar e trabalhoso de implantar: definir, para cada dado que o agente consulta, qual sistema é a fonte autoritativa, e registrar na execução qual versão do registro foi lida.
Em uma operação com integrações ponto a ponto acumuladas ao longo dos anos, esse mapeamento costuma ser o verdadeiro primeiro projeto.
O que a regulação brasileira exige hoje e o que ainda não existe
Esta é uma área em que a diferença entre “obrigação vigente” e “boa prática” costuma ser tratada com imprecisão. Na data desta publicação — setembro de 2026 —, o quadro é o seguinte.
Ainda não há lei específica de IA em vigor no Brasil
O PL 2338/2023, que estabeleceria o marco legal da inteligência artificial, foi aprovado pelo Senado e remetido à Câmara dos Deputados em 17 de março de 2025, onde segue sem parecer do relator e sem votação em plenário.
Planejar a arquitetura considerando que exigências de classificação de risco e de governança podem vir é prudente; afirmar que já existe uma obrigação legal específica de IA, não.
A LGPD já alcança decisões automatizadas
O art. 20 da Lei nº 13.709/2018 garante ao titular o direito de solicitar a revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses.
O § 1º obriga o controlador a fornecer informações claras sobre os critérios e os procedimentos utilizados, observados os segredos comercial e industrial.
Na prática, um agente que recusa uma proposta, nega uma cobertura ou define um preço precisa deixar rastro suficiente para que o critério aplicado seja explicável.
A governança de riscos e controles internos já é norma setorial
A Resolução CNSP nº 416/2021 estrutura o Sistema de Controles Internos, a Estrutura de Gestão de Riscos e a atividade de auditoria interna das supervisionadas.
A norma atribui à administração o dever de zelar pela adequação e efetividade desses sistemas e exige conservação de documentação para acesso da SUSEP.
Um processo executado por agente continua sendo um processo da seguradora — e entra nesse escopo como qualquer outro.
Soluções baseadas em IA já são tratadas como serviço relevante
A Circular SUSEP nº 638/2021 estabelece requisitos de política de segurança cibernética, prevenção e resposta a incidentes e exige que contratos de computação em nuvem e de terceirização de processamento de dados relevantes prevejam controles não inferiores aos da própria supervisionada, com comunicação à SUSEP em prazo determinado.
O Manual de Orientações sobre Segurança Cibernética publicado pela SUSEP em junho de 2026 torna essa leitura explícita ao incluir entre os serviços relevantes o “processamento, armazenamento e análise de dados, inclusive por meio de soluções baseadas em inteligência artificial”.
Contratar um agente que roda em infraestrutura de terceiro e processa dados de segurados não é apenas uma decisão de tecnologia: entra no regime de terceirização de serviço relevante.
Uma seguradora que delega execução a agentes já está sujeita a exigências de explicabilidade, controle interno, rastreabilidade documental e diligência sobre terceiros. A ausência de uma norma dedicada não cria uma janela de menor exigência: apenas retira o roteiro pronto e transfere para a própria seguradora o trabalho de definir seus critérios.
Níveis de delegação: quanto de autonomia entregar a um agente
Mais do que decidir se a seguradora “vai usar agentes de IA”, o que organiza o projeto é responder, processo a processo, até onde o agente pode ir sem uma pessoa no caminho. Quatro estágios ajudam nessa decisão, do mais contido ao mais autônomo:
Cada degrau acrescenta uma pré-condição, e pular degraus é o erro mais caro: operações que começam no estágio 4 costumam descobrir a ausência de trilha de auditoria exatamente quando precisam dela. O verificador a seguir organiza essas pré-condições de forma observável para um processo específico da sua operação — vale preenchê-lo pensando em um único processo por vez, não na seguradora inteira.
Até onde delegar execução a um agente de IA neste processo?
Pense em um processo específico da sua operação — triagem de sinistro, conciliação de cobrança, montagem de dossiê de subscrição — e marque apenas as condições que você consegue confirmar hoje. O resultado indica qual nível de delegação está sustentado e nomeia o que ainda falta. Itens não marcados são tratados como não verificados, não como inexistentes.
0 de 7 condições confirmadas até aqui.Itens não marcados não reduzem a avaliação da sua operação: indicam apenas o que ainda precisa ser verificado antes de ampliar autonomia.
Base do processo
Condições de controle
Enquanto nenhuma condição estiver marcada, nenhum nível de delegação é indicado — o estado inicial não descreve a sua operação. Se preferir não usar a interação, a regra é a mesma em texto: as três condições de base sustentam o nível assistir; com elas somadas às quatro condições de controle, é possível avaliar a execução por exceção; qualquer condição de controle ausente mantém o processo no nível executar com aprovação humana.
Esta é uma leitura editorial de pré-condições observáveis, não um índice de maturidade validado nem uma avaliação de conformidade regulatória. Decisões automatizadas que afetem o segurado atraem o direito de revisão previsto no art. 20 da LGPD, independentemente do nível marcado aqui.
O resultado do verificador não é um veredito sobre a operação: ele nomeia quais condições ainda faltam para que um determinado nível de delegação seja defensável. A ação seguinte é tratar essas condições como itens de trabalho — definir fonte autoritativa de dado, escrever os limites de execução, habilitar registro — antes de discutir fornecedor.
Quando faz sentido avançar e quando a base precisa vir antes
Existe escala suficiente para que a automação tenha impacto operacional real.
Os casos mudam demais para serem tratados com eficiência por um robô determinístico.
A execução depende de consultar ou agir sobre diferentes aplicações e fontes.
É possível determinar objetivamente se a execução terminou da forma esperada.
A área de negócio consegue escrever os critérios que orientam as principais decisões.
Quando esses cinco elementos aparecem juntos, o agente passa a resolver uma combinação de variabilidade, integração e decisão que automações tradicionais não tratam tão bem.
Se a sequência muda pouco e as exceções são raras, um robô resolve com menos custo e mais previsibilidade. Não há razão para adicionar autonomia onde uma automação determinística é suficiente.
Se ninguém consegue explicitar os critérios que orientam a decisão, o agente não corrige o problema: apenas automatiza a inconsistência em escala. Nesse cenário, o estágio adequado tende a ser apenas “assistir”.
Se as aplicações envolvidas não expõem ações de forma integrável, o projeto prioritário é de integração — não de IA. O agente não elimina uma arquitetura que ainda não consegue executar ações com segurança.
O que uma solução de agentes deveria oferecer para uma seguradora
Esses elementos são requisitos de desenho para uma operação com autonomia controlada e verificável.
O que as páginas de solução da Tecnologia Única apresentam
Essas são camadas sobre as quais um projeto de agentes pode se apoiar — não uma afirmação de que existe hoje um produto pronto de agentes autônomos para sinistros.
A operação com Proteo-InsureMO foi estruturada em abordagem API-first, conectando cotação, emissão, gestão de sinistros e o ecossistema de varejo do grupo. O case serve como referência de arquitetura integrada em produção, mas não descreve uso de agentes de IA e não deve ser lido como evidência de resultado com essa tecnologia.
Comparação com alternativas
| Alternativa | Quando pode funcionar | Limitação principal | Impacto possível | Critério para avançar |
|---|---|---|---|---|
| Manter o processo manual | Volume baixo, alta criticidade jurídica, regras instáveis. | Custo cresce linearmente com o volume; conhecimento fica concentrado em poucas pessoas. | Fila e tempo de resposta variam com a equipe disponível. | Volume estável e crescente com resultado verificável. |
| RPA determinístico | Tarefa repetitiva, entrada padronizada, sistema estável. | Quebra a cada mudança de tela ou caso fora do padrão. | Manutenção recorrente e falhas silenciosas. | Baixa variação e ausência de conteúdo não estruturado. |
| Motor de regras | Decisão precisa ser explicável e consistente entre canais. | Só resolve o que foi previsto como regra. | Casos não previstos voltam para a fila manual. | Critérios podem ser escritos e versionados. |
| Agente de IA com aprovação humana | Muitos saltos entre sistemas, conteúdo não estruturado, variação alta. | Exige APIs, registro e limites definidos. | Reduz reunião de contexto; mantém a decisão com a pessoa. | As pré-condições de registro e reversibilidade existem. |
| Agente executando por exceção | Processo maduro, com histórico de execução auditado. | Erro variável e de difícil detecção sem amostragem. | Escala o acerto e também o desvio. | Amostragem periódica e responsável nomeado já operando. |
Nenhuma linha dessa tabela é um destino obrigatório. Para boa parte das operações, o caminho mais defensável hoje é combinar motor de regras onde a decisão precisa ser explicável e agente com aprovação humana onde o trabalho é reunir contexto.
Uma observação vale para todas as linhas: a alternativa escolhida pesa menos do que a camada de conexão entre sistemas.
Quando o inventário de integrações é majoritariamente ponto a ponto, qualquer das opções acima herda a mesma fragilidade — motivo pelo qual os modelos de integração de sistemas empresariais no setor de seguros, de ponto a ponto a arquiteturas orientadas a APIs, costumam determinar o teto de autonomia possível antes de qualquer escolha de fornecedor.
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 |
|---|---|---|---|
| Automatizar um processo mal definido | A pressa de mostrar resultado antecipa a tecnologia ao desenho. | A inconsistência passa a ser aplicada em escala e com menos visibilidade. | Escrever o processo e suas exceções antes de escolher a ferramenta. |
| Agente sem trilha de execução | O registro é tratado como requisito de segunda fase. | Impossibilidade de explicar uma decisão à auditoria ou ao titular de dados. | Tornar o log de entrada, ação e resultado um requisito de entrega, não um item futuro. |
| Delegar autonomia sem limites escritos | Ninguém define até onde o agente pode ir sem aprovação. | Ações fora do apetite de risco descobertas depois do efeito. | Definir por escrito valores, prazos e situações de parada obrigatória. |
| Piloto que nunca vira operação | O piloto roda em ambiente isolado, sem integração real. | Investimento sem efeito na operação e ceticismo interno. | Escolher um processo com dono e incluir integração no escopo do piloto. |
| Fornecedor tratado como caixa-preta | A avaliação foca em demonstração, não em contrato e arquitetura. | Exposição em terceirização de serviço relevante e dificuldade de atender exigências de segurança. | Avaliar hospedagem, tratamento de dados e cláusulas de controle junto da funcionalidade. |
| Nenhuma revisão depois do go-live | Presume-se que o comportamento é estável como o de um software tradicional. | Degradação silenciosa por mudança de dados ou de modelo. | Estabelecer amostragem periódica de execuções e um responsável por revisá-la. |
Critérios de decisão
Ao avaliar um projeto de agentes de IA, estes são os critérios que costumam separar uma decisão sustentada de uma aposta:
- Verificabilidade. É possível dizer, depois, se a execução foi correta? Sem isso, não há como medir nem corrigir.
- Integração disponível. As ações necessárias existem como API ou serviço? Se a resposta depende de robô sobre tela, o projeto é de integração antes de ser de IA.
- Explicabilidade proporcional. A decisão afeta diretamente o segurado? Quanto mais afeta, mais o critério precisa ser reconstituível — inclusive por exigência do art. 20 da LGPD.
- Reversibilidade. Uma execução errada pode ser corrigida antes de gerar efeito externo? Processos irreversíveis pedem aprovação humana por mais tempo.
- Capacidade interna de sustentação. Existe quem revise amostras e ajuste limites depois do go-live? Sem essa função, a autonomia tende a envelhecer mal.
- Enquadramento em terceirização. Onde os dados serão processados e sob quais controles contratuais? Esse item costuma decidir o fornecedor tanto quanto a funcionalidade.
- Investimento proporcional à alternativa. Se um motor de regras ou um robô resolve com menos dependência e menos custo de sustentação, essa costuma ser a escolha mais estável.
Antes de partir para uma prova de conceito, vale entender quais frentes de automação e IA dependem de cada camada de integração. Esse diagnóstico ajuda a identificar o que precisa ser estruturado antes de colocar um agente em cena.
Como estruturar o próximo passo
Um caminho de baixo risco para sair da discussão conceitual costuma ter esta sequência:
Escolher um processo, não uma tecnologia
Prefira um processo com dono identificado, volume mensurável e resultado verificável.
Escrever o processo e suas exceções
Inclua os casos que hoje alguém resolve por experiência e não por regra.
Mapear as ações necessárias
Verifique quais ações já existem como API ou serviço — e quais ainda dependem de integração a construir.
Definir a fonte autoritativa de cada dado
Determine qual registro o agente deve consultar em cada caso, para evitar decisões corretas baseadas em informação desatualizada.
Escrever os limites de execução
Defina valores, prazos e situações em que o agente precisa interromper a execução e escalar o caso.
Definir o registro mínimo de cada execução
Estabeleça antes do primeiro piloto o registro de entrada, ação, resultado e versão dos dados lidos.
Rodar no estágio “recomendar”
Mantenha esse estágio por um período definido e compare sistematicamente a recomendação do agente com a decisão humana.
Revisar amostras antes de ampliar a autonomia
Revise amostras das execuções e só então discuta a ampliação da autonomia, com um responsável nomeado pela revisão contínua.
Essa sequência dá ao projeto algo que a discussão sobre modelos raramente dá: um critério objetivo para decidir se vale ampliar, manter ou recuar. Quando o gargalo aparece nos passos 3 e 4 — ações que só existem em tela, dados sem origem única —, o projeto pertinente é de integração e arquitetura antes de ser de inteligência artificial.
Uma conversa técnica ajuda a identificar quais integrações, registros e controles precisam existir para que a execução automatizada seja rastreável. A partir desse diagnóstico, a decisão sobre agentes de IA pode virar um plano proporcional ao estágio atual da operação.
Perguntas frequentes (FAQ)
São sistemas que recebem um objetivo de negócio, decidem os passos necessários e executam ações em mais de um sistema da seguradora — por exemplo, triar um aviso de sinistro consultando apólice, documentos e regras de cobertura. A diferença em relação a outras automações é que a sequência de passos é definida pelo próprio sistema a cada execução, e não previamente por um analista.
O chatbot conversa e responde; quem conduz a sequência é a pessoa, a cada turno. O agente recebe um objetivo e decide os passos necessários para cumpri-lo, executando ações em outros sistemas. Um agente pode usar um chatbot como interface, mas a conversa não é o que o define.
Na prática, sim. “IA agêntica” (do inglês agentic AI) descreve a abordagem — sistemas com capacidade de planejar e agir — e “agente de IA” descreve a unidade que executa esse comportamento. Em seguros, o termo importa menos do que a pergunta operacional que ele levanta: qual grau de autonomia está sendo delegado e com quais controles.
Não como regra. RPA continua sendo mais previsível e mais barato para tarefas estáveis e repetitivas. Agentes tendem a render onde há variação alta, conteúdo não estruturado e muitos saltos entre sistemas. Em boa parte das operações, os dois convivem — o agente inclusive aciona robôs quando um sistema não tem API.
Não há, até setembro de 2026, norma dedicada exclusivamente ao uso de inteligência artificial. 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 e Circular SUSEP nº 638/2021 para segurança cibernética, nuvem e terceirização — cujo Manual de Orientações de junho de 2026 inclui expressamente a análise de dados por soluções de IA entre os serviços relevantes.
Tecnicamente é possível; juridicamente e do ponto de vista de controle, é a configuração mais exigente. Uma decisão tomada unicamente por tratamento automatizado que afete o titular atrai o direito de revisão previsto no art. 20 da LGPD e a obrigação de informar critérios. 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.
Referências externas
[1] Planalto. Lei nº 13.709/2018 (Lei Geral de Proteção de Dados Pessoais).
[3] SUSEP. Circular SUSEP nº 638, de 27 de julho de 2021 — requisitos de segurança cibernética.
[4] SUSEP. Manual de Orientações sobre Segurança Cibernética, versão junho/2026.
[5] Senado Federal. PL 2338/2023 — marco legal da inteligência artificial: tramitação.
EN 
PT 
ES 
FR 
IT 
DE 