Uma apólice diverge entre o cotador e o core system. Ninguém consegue dizer, com precisão, qual dos dois registros está certo — nem por que eles deixaram de bater. Esse tipo de sintoma é comum em seguradoras que operam com core system, cotador, plataforma de resseguro, ferramentas de atendimento e, cada vez mais, modelos de IA para precificação e detecção de fraude. Cada um desses sistemas produz e consome dados. Poucos foram desenhados para conversar entre si.
O mesmo padrão se repete de outras formas: um número de sinistros que não bate entre a área técnica e a atuarial, uma auditoria que exige rastrear a origem de um dado e ninguém sabe explicar com precisão de onde ele veio. Cada ocorrência isolada parece pequena. Somadas, elas indicam a ausência de uma arquitetura de dados — não a falta de mais um sistema, mas a falta de uma estrutura que organize como os dados circulam entre os sistemas já existentes.
Esse problema deixou de ser apenas operacional. Com o avanço do Open Insurance, exigências da Susep sobre terceirização e segurança de dados, e a LGPD já consolidada, a forma como uma seguradora organiza seus dados passa a ser também uma questão de conformidade e de risco financeiro direto. Este artigo explica o que é arquitetura de dados aplicada a seguros, onde a fragmentação aparece na operação, quais riscos ela cria, quais critérios usar para avaliar a estrutura atual e quando faz sentido buscar uma solução mais estruturada.
Principais pontos
- Arquitetura de dados não é um projeto de TI isolado: é a estrutura que sustenta decisão, auditoria e conformidade em toda a operação de uma seguradora.
- A fragmentação de dados entre sistemas cria um risco que fica invisível até o volume ou a complexidade aumentarem — e então aparece como retrabalho, divergência ou falha de auditoria.
- Circular Susep nº 638/2021, a agenda de Open Insurance e a LGPD tornam a estrutura de dados um requisito de conformidade, não apenas de eficiência.
- Nem toda seguradora precisa de uma reestruturação completa agora: existem critérios objetivos para decidir entre manter, evoluir gradualmente ou buscar uma solução especializada.
- O próximo passo depende de mapear onde os dados hoje se tornam inconsistentes antes de decidir qual caminho seguir.
Ponto de atenção
⚠️ Quando a consistência dos dados entre sistemas depende de conferência manual ou de poucas pessoas que “sabem onde olhar”, o impacto tende a ficar pouco visível no início.
Com o aumento do volume de apólices, das integrações ou das exigências regulatórias, essa dependência tende a aparecer em forma de retrabalho recorrente, divergência entre áreas e dificuldade de responder a uma auditoria com precisão.
O ponto central não é eliminar o risco imediatamente, mas garantir estrutura, rastreabilidade e capacidade de evolução antes que o custo de não ter isso apareça de forma concentrada.
O que é arquitetura de dados no contexto de seguros
Arquitetura de dados é a definição de como os dados de uma organização são estruturados, armazenados, integrados e disponibilizados — incluindo os modelos de dados, os fluxos entre sistemas, os padrões de qualidade e as responsabilidades sobre cada informação. O framework DAMA-DMBOK, referência internacional em gestão de dados, trata a arquitetura de dados como uma das áreas centrais de qualquer estrutura de governança.
Em uma seguradora, essa definição ganha um recorte específico. Os dados não nascem em um único lugar: nascem na cotação, são complementados na emissão, alterados em endossos, referenciados no sinistro, replicados no resseguro e, cada vez mais, expostos a terceiros via Open Insurance. Arquitetura de dados para seguradoras, portanto, é a estrutura que garante que uma apólice, um segurado ou um sinistro sejam a mesma entidade — com o mesmo significado e o mesmo histórico — em todos os sistemas que a tocam.
Isso é diferente de “ter um banco de dados” ou “ter um data lake”. Um repositório central sem padrão de qualidade, sem regra de origem (linhagem) e sem dono definido continua sendo dado disperso, só que concentrado em um único lugar. A arquitetura é o conjunto de regras — não a ferramenta.
Esse recorte de dados é um desdobramento de uma discussão mais ampla sobre decisões estruturais de tecnologia, tratada em Arquitetura de Software: decisões erradas podem custar 25% do seu orçamento — vale como leitura complementar para quem quer entender também os padrões arquiteturais por trás dos sistemas que produzem e consomem esses dados.
Onde a fragmentação de dados aparece na operação
Na prática, o problema raramente aparece como “falta de arquitetura de dados”. Ele aparece como sintomas pontuais, espalhados entre áreas:
- Na cotação e emissão: o mesmo segurado é cadastrado de formas diferentes no cotador e no core system, exigindo reconciliação manual para evitar duplicidade.
- Nos sinistros: o status de um sinistro diverge entre a área técnica, a financeira e o atendimento, porque cada uma consulta um sistema diferente, atualizado em momentos diferentes.
- No resseguro: cálculos que dependem de dados de apólices e sinistros usam extrações manuais ou rotinas batch que atrasam o fechamento e aumentam o risco de erro.
- Na auditoria e compliance: quando um órgão regulador ou uma auditoria interna pede para explicar a origem de um número, a resposta depende de alguém reconstruir manualmente o caminho do dado entre sistemas.
- No Open Insurance: dados que precisam ser compartilhados com terceiros via API carregam as mesmas inconsistências internas, agora expostas a um ecossistema externo.
Nenhum desses pontos, isoladamente, costuma justificar um projeto. É a recorrência entre eles — e o fato de todos terem a mesma raiz — que indica a ausência de uma arquitetura de dados estruturada.
Avalie se sua operação consegue explicar, hoje, a origem de qualquer dado usado em uma decisão de subscrição ou sinistro sem depender de uma pessoa específica →
Entenda o que costuma sustentar (ou comprometer) essa rastreabilidade no artigo sobre arquitetura de software para seguradoras.
Os impactos que ficam invisíveis até a operação crescer
O custo da fragmentação de dados raramente aparece em uma única linha de orçamento. Ele se distribui como:
Tempo de fechamento contábil e atuarial mais longo, porque parte do trabalho é reconciliar números que deveriam bater automaticamente.
Retrabalho recorrente em áreas operacionais, quando um erro identificado tardiamente exige refazer um lote inteiro de processamento em vez de corrigir um registro isolado.
Dependência de conhecimento concentrado, quando só uma ou duas pessoas sabem explicar de onde vem um dado específico ou como reconciliar divergências entre sistemas — um risco que se agrava em trocas de equipe.
Lentidão para responder a exigências regulatórias, porque cada pedido de informação vira um projeto de levantamento manual em vez de uma consulta estruturada.
Esses impactos crescem de forma não linear. Um cenário de baixo volume tolera reconciliação manual. O mesmo processo, sob o dobro de apólices ou sob uma nova exigência de compartilhamento de dados via Open Insurance, deixa de ser tolerável — e a transição costuma ser abrupta, não gradual.
Riscos regulatórios e operacionais de manter dados sem estrutura
A estrutura de dados de uma seguradora deixou de ser apenas uma decisão técnica interna. Três frentes regulatórias tornam isso explícito:
A Circular Susep nº 638/2021 estabelece requisitos de segurança cibernética para seguradoras, incluindo regras sobre contratação de serviços relevantes de processamento e armazenamento de dados em nuvem e sobre comunicação de incidentes relevantes à autarquia.
Cumprir essas exigências pressupõe saber, com precisão, onde cada dado está armazenado, quem o processa e como ele é protegido — algo inviável sem uma arquitetura definida.
O Open Insurance segue em evolução regulatória. A Susep abriu, pela Portaria nº 8.442/2025, uma tomada pública de subsídios entre 5 de março e 5 de abril de 2026 para aprimorar aspectos estruturais, operacionais e regulatórios do ecossistema — abrangendo governança, participação, certificação de jornada, interoperabilidade e monitoramento.
Isso significa que os requisitos de compartilhamento de dados entre instituições devem continuar mudando, e seguradoras com arquitetura frágil terão mais dificuldade para se adaptar a cada nova fase.
A LGPD (Lei nº 13.709/2018) já impõe multas de até 2% do faturamento bruto, limitadas a R$ 50 milhões por infração, além de sanções como bloqueio ou eliminação de dados.
Uma arquitetura sem controle claro sobre onde os dados pessoais residem e como circulam entre sistemas aumenta diretamente a exposição a essas penalidades, porque dificulta demonstrar conformidade quando solicitado — o tema é aprofundado em LGPD nas Empresas: adequação, governança e compliance na prática.
Nenhuma dessas normas resolve, isoladamente, o problema de fragmentação — mas todas as três dependem, na prática, de uma arquitetura de dados que sustente rastreabilidade e resposta a auditoria.
O que costuma dar errado na prática
| Erro recorrente | Por que acontece | Consequência | Como reduzir o risco |
|---|---|---|---|
| Integração ponto a ponto sem padrão | Cada novo sistema é conectado individualmente aos demais, sem camada intermediária | Custo de manutenção cresce a cada nova integração; qualquer mudança em um sistema quebra várias conexões | Adotar camada de integração (API ou middleware) que padronize a comunicação entre sistemas |
| Ausência de dono definido para cada dado | O dado é tratado como responsabilidade “de todos”, ou seja, de ninguém | Divergências não são corrigidas na origem, apenas contornadas a cada ocorrência | Definir responsáveis (data owners) por domínio de dado, mesmo em estrutura enxuta |
| Migração ou integração sem mapeamento prévio | Pressão de prazo leva a migrar ou conectar sistemas sem inventariar os dados existentes | Inconsistências antigas são replicadas na nova estrutura, em vez de corrigidas | Mapear e validar dados antes de qualquer migração ou nova integração |
| Uso de IA sobre dados não estruturados | Modelos de precificação, fraude ou atendimento são implementados sobre dados sem padrão de qualidade | Resultados pouco confiáveis, difíceis de auditar e sujeitos a viés não identificado | Estruturar e validar a base de dados antes de aplicar IA sobre ela |
| Dependência de conhecimento concentrado | Poucas pessoas entendem como os sistemas se conectam e onde os dados divergem | Risco de continuidade operacional em caso de saída dessas pessoas | Documentar fluxos de dados e reduzir dependência de conhecimento tácito |
Critérios de decisão para avaliar sua arquitetura de dados
Antes de decidir entre manter, evoluir ou reestruturar, avalie a operação atual segundo estes critérios:
Maturidade: existe um modelo de dados documentado, com definição clara de entidades como segurado, apólice e sinistro, usado por todos os sistemas?
Rastreabilidade: é possível reconstruir a origem e as transformações de um dado específico sem depender de uma pessoa?
Integração: as conexões entre sistemas seguem um padrão (APIs, camada de integração) ou são pontuais e crescem de forma desordenada?
Governança: há responsáveis definidos por domínio de dado, com regras claras de qualidade e acesso?
Conformidade: a estrutura atual permite responder, em tempo razoável, a uma exigência da Susep, da ANPD ou de uma auditoria interna?
Escalabilidade: a estrutura atual suporta o dobro do volume de apólices ou uma nova exigência de compartilhamento externo sem reconstrução completa?
Capacidade interna: a equipe atual tem tempo e conhecimento para manter e evoluir essa estrutura, ou já opera no limite mantendo o que existe?
Investimento: o custo de reestruturar agora é menor do que o custo projetado de continuar operando com reconciliação manual pelos próximos dois ou três anos?
Mapeie quais integrações da sua operação concentram mais esforço de manutenção manual antes de decidir por qual caminho seguir.
Comparação com alternativas
| Alternativa | Quando pode funcionar | Limitação principal | Impacto possível | Critério para avançar |
|---|---|---|---|---|
| Reconciliação manual entre sistemas | Baixo volume de apólices e poucas integrações | Não escala; depende de pessoas específicas | Retrabalho crescente, risco de erro em auditoria | Volume ou frequência de exceções já consome tempo relevante da equipe |
| Integrações ponto a ponto | Poucos sistemas, mudanças raras | Cresce em complexidade a cada nova conexão | Manutenção cara e frágil conforme o ecossistema cresce | Mais de três ou quatro sistemas trocando dados entre si |
| Desenvolvimento interno de uma camada de dados | Empresa com equipe de dados própria e tempo disponível | Exige manter conhecimento especializado internamente, com risco de dependência de poucas pessoas | Estrutura pode ficar defasada se a equipe não acompanhar a evolução regulatória | Capacidade interna de sustentar e evoluir a estrutura no médio prazo |
| Outsourcing especializado / squads dedicados | Quando falta capacidade interna, mas o modelo de dados já está mapeado | Depende de governança clara do lado da seguradora sobre o que é terceirizado | Reduz risco de dependência de conhecimento concentrado, mas exige gestão do contrato | Ausência de time interno dedicado, mas modelo de negócio já definido |
| Plataforma especializada com integração nativa (API-first) | Operação com múltiplos sistemas (cotador, core system, resseguro) que precisam conversar de forma padronizada | Exige adequação dos sistemas existentes à integração via API | Reduz integrações ponto a ponto e sustenta conformidade com Open Insurance | Fragmentação já afeta fechamento, auditoria ou compartilhamento externo de dados |
Quando faz sentido e quando não faz
Considere manter a estrutura atual quando…
O volume de apólices e integrações é baixo, as divergências de dados são raras e a equipe consegue reconciliar manualmente sem impacto relevante no prazo de fechamento ou de resposta a auditorias.
Considere uma evolução gradual quando…
Já existem sinais de esforço crescente — mais tempo gasto em reconciliação, mais exceções manuais —, mas o modelo de dados ainda não está mapeado ou a operação não tem urgência regulatória imediata. Nesse caso, mapear e documentar os fluxos existentes antes de qualquer integração nova costuma reduzir risco sem exigir um projeto completo.
Considere uma solução especializada quando…
A fragmentação já afeta prazos de fechamento, respostas a auditorias ou a capacidade de atender exigências de Open Insurance, e a equipe interna não tem tempo ou conhecimento disponível para reestruturar sem apoio externo.
Como uma arquitetura orientada a dados sustenta decisão e conformidade
Uma arquitetura de dados estruturada resolve, na prática, os pontos levantados até aqui: define um modelo comum de entidades (segurado, apólice, sinistro), padroniza como sistemas trocam informação e estabelece rastreabilidade sobre a origem de cada dado.
Isso é o que sustenta, por exemplo, a plataforma Proteo, desenvolvida pela Tecnologia Única com a InsureMO como Middle Office desacoplado para seguradoras. A plataforma usa arquitetura de microsserviços e integrações nativas via APIs REST e webhooks — em vez de arquivos processados em lote —, com autenticação via OAuth2 e OpenID Connect, protocolos compatíveis com os requisitos técnicos do Open Insurance.
Na prática, isso significa que subscrição, emissão, cobrança e sinistros compartilham a mesma base de regras de integração, em vez de cada módulo criar sua própria forma de trocar dados com os demais — mecanismo detalhado em Integração de Sistemas Empresariais: o guia estratégico para a evolução do setor de seguros.
O mesmo raciocínio orienta a solução EDISeg, usada para padronizar a troca de dados entre seguradoras e corretoras, e o modelo de squads especializados em outsourcing, quando a limitação não está na tecnologia disponível, mas na capacidade da equipe interna de mapear, integrar e manter essa estrutura ao longo do tempo.
Um exemplo de arquitetura integrada em operação é o caso da Herval Seguradora, que utiliza a plataforma Proteo-InsureMO em uma operação autorizada pela Susep — evidência de que uma estrutura de integração via API pode sustentar uma operação regulada sem depender de reconciliação manual entre sistemas.
Identifique quais desses mecanismos de integração já fazem falta na sua operação.
Como estruturar o próximo passo
Independentemente do caminho escolhido, a sequência costuma ser a mesma:
Mapear onde os dados de segurado, apólice e sinistro hoje residem e como circulam entre sistemas.
Registrar as divergências e pontos de reconciliação manual mais recorrentes.
Validar com as áreas de compliance e auditoria quais exigências regulatórias (Susep, Open Insurance, LGPD) dependem diretamente dessa estrutura.
Priorizar os pontos que geram mais retrabalho ou mais risco regulatório, em vez de tentar resolver tudo ao mesmo tempo.
Documentar os fluxos definidos, reduzindo dependência de conhecimento concentrado em poucas pessoas.
Integrar os sistemas prioritários usando um padrão comum, como uma camada de APIs.
Testar e monitorar a qualidade dos dados de forma contínua, não apenas na implementação inicial.
Quando o mapeamento indicar que a limitação está na capacidade de estruturar e manter essa integração — e não apenas em ajustes pontuais —, um diagnóstico de arquitetura conduzido com apoio externo tende a reduzir o tempo até a primeira melhoria concreta.
Diagnóstico rápido: sua arquitetura de dados sustenta a operação?
Use o diagnóstico interativo abaixo para identificar, em poucos minutos, quais pontos da sua estrutura de dados concentram mais risco hoje.
Sua arquitetura de dados ainda sustenta a operação?
Marque as situações que descrevem sua operação hoje. Ao final, você recebe uma leitura consultiva sobre onde sua estrutura de dados concentra mais risco — sem substituir uma análise técnica completa.
0 de 8 situações marcadas
Conclusão
A fragmentação de dados entre cotação, emissão, sinistros e resseguro raramente aparece como um problema único e visível. Ela se manifesta como pequenas divergências, reconciliações manuais e dependência de poucas pessoas — até que o volume de apólices ou uma nova exigência regulatória, como uma nova fase do Open Insurance, tornem essa estrutura insustentável de uma vez.
Arquitetura de dados é a estrutura que evita que esse cenário se torne crítico: um modelo comum de entidades, integrações padronizadas e rastreabilidade sobre a origem de cada informação — a base de uma estrutura pensada para crescer com a operação, não para ser refeita a cada novo volume ou nova exigência regulatória.
Se hoje a reconciliação entre sistemas ainda depende de ajustes manuais e conhecimento concentrado em poucas pessoas, a Tecnologia Única pode apoiar a estruturação de uma arquitetura mais integrada, rastreável e preparada para evoluir, por meio de diagnóstico de arquitetura, integração de sistemas ou squads especializados.
O próximo passo é agendar um diagnóstico de arquitetura de dados com um especialista da Tecnologia Única.
Perguntas frequentes (FAQ)
Integração de sistemas conecta plataformas para que troquem informação. Arquitetura de dados define as regras que essa integração deve seguir — modelo de dados comum, padrão de qualidade e responsabilidades — para que a troca de informação seja consistente, não apenas tecnicamente viável.
Depende do volume e da complexidade das integrações. Operações pequenas, com poucos sistemas e baixo volume, podem sustentar reconciliação manual por mais tempo. O ponto de atenção é o momento em que o volume ou uma exigência regulatória tornam essa reconciliação inviável.
Não sozinha. Ela é uma condição necessária, não suficiente: sustenta rastreabilidade e resposta a auditorias, mas a conformidade com a LGPD também depende de política de privacidade, papel do encarregado de dados (DPO) e processos jurídicos que estão fora do escopo técnico da arquitetura.
Data lake e data warehouse são tipos de repositório de dados — onde os dados ficam armazenados. Arquitetura de dados é a estrutura mais ampla que define como os dados chegam até esse repositório, com que qualidade, com que rastreabilidade e sob quais responsabilidades, independentemente de qual repositório for escolhido.
Pode fazer sentido quando a limitação está na capacidade interna de mapear, integrar e manter a estrutura — não na tecnologia disponível. Nesses casos, squads especializados reduzem o tempo até a primeira melhoria, desde que a seguradora mantenha governança clara sobre o que foi terceirizado e como isso será monitorado.
Referências externas
[1] LegisWeb. Circular Susep nº 638/2021.
[2] Susep/Gov.br. Susep coleta contribuições com o objetivo de aprimorar o Open Insurance.
[3] Open Insurance Brasil. Portal oficial do Sistema de Seguros Aberto
[4] Planalto. Lei Geral de Proteção de Dados (LGPD) — Lei nº 13.709/2018.
[5] DAMA International. DAMA-DMBOK (corpo de conhecimento em gestão de dados)
ES 
PT 
EN 
FR 
IT 
DE