Uma ap\u00f3lice diverge entre o cotador e o core system. Ningu\u00e9m consegue dizer, com precis\u00e3o, qual dos dois registros est\u00e1 certo \u2014 nem por que eles deixaram de bater. Esse tipo de sintoma \u00e9 comum em seguradoras que operam com core system, cotador, plataforma de resseguro, ferramentas de atendimento e, cada vez mais, modelos de IA para precifica\u00e7\u00e3o e detec\u00e7\u00e3o de fraude. Cada um desses sistemas produz e consome dados. Poucos foram desenhados para conversar entre si.<\/p>\n\n\n\n
O mesmo padr\u00e3o se repete de outras formas: um n\u00famero de sinistros que n\u00e3o bate entre a \u00e1rea t\u00e9cnica e a atuarial, uma auditoria que exige rastrear a origem de um dado e ningu\u00e9m sabe explicar com precis\u00e3o de onde ele veio. Cada ocorr\u00eancia isolada parece pequena. Somadas, elas indicam a aus\u00eancia de uma arquitetura de dados \u2014 n\u00e3o a falta de mais um sistema, mas a falta de uma estrutura que organize como os dados circulam entre os sistemas j\u00e1 existentes.<\/p>\n\n\n\n
Esse problema deixou de ser apenas operacional. Com o avan\u00e7o do Open Insurance, exig\u00eancias da Susep sobre terceiriza\u00e7\u00e3o e seguran\u00e7a de dados, e a LGPD j\u00e1 consolidada, a forma como uma seguradora organiza seus dados passa a ser tamb\u00e9m uma quest\u00e3o de conformidade e de risco financeiro direto. Este artigo explica o que \u00e9 arquitetura de dados aplicada a seguros, onde a fragmenta\u00e7\u00e3o aparece na opera\u00e7\u00e3o, quais riscos ela cria, quais crit\u00e9rios usar para avaliar a estrutura atual e quando faz sentido buscar uma solu\u00e7\u00e3o mais estruturada.<\/p>\n\n\n\n
\u26a0\ufe0f Quando a consist\u00eancia dos dados entre sistemas depende de confer\u00eancia manual ou de poucas pessoas que “sabem onde olhar”, o impacto tende a ficar pouco vis\u00edvel no in\u00edcio. <\/p>\n\n\n\n
Com o aumento do volume de ap\u00f3lices, das integra\u00e7\u00f5es ou das exig\u00eancias regulat\u00f3rias, essa depend\u00eancia tende a aparecer em forma de retrabalho recorrente, diverg\u00eancia entre \u00e1reas e dificuldade de responder a uma auditoria com precis\u00e3o. <\/p>\n\n\n\n
O ponto central n\u00e3o \u00e9 eliminar o risco imediatamente, mas garantir estrutura, rastreabilidade e capacidade de evolu\u00e7\u00e3o antes que o custo de n\u00e3o ter isso apare\u00e7a de forma concentrada.<\/p>\n\n\n\n
Arquitetura de dados \u00e9 a defini\u00e7\u00e3o de como os dados de uma organiza\u00e7\u00e3o s\u00e3o estruturados, armazenados, integrados e disponibilizados \u2014 incluindo os modelos de dados, os fluxos entre sistemas, os padr\u00f5es de qualidade e as responsabilidades sobre cada informa\u00e7\u00e3o. O framework DAMA-DMBOK, refer\u00eancia internacional em gest\u00e3o de dados, trata a arquitetura de dados como uma das \u00e1reas centrais de qualquer estrutura de governan\u00e7a.<\/p>\n\n\n\n
Em uma seguradora, essa defini\u00e7\u00e3o ganha um recorte espec\u00edfico. Os dados n\u00e3o nascem em um \u00fanico lugar: nascem na cota\u00e7\u00e3o, s\u00e3o complementados na emiss\u00e3o, 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, \u00e9 a estrutura que garante que uma ap\u00f3lice, um segurado ou um sinistro sejam a mesma entidade \u2014 com o mesmo significado e o mesmo hist\u00f3rico \u2014 em todos os sistemas que a tocam.<\/p>\n\n\n\n
Isso \u00e9 diferente de “ter um banco de dados” ou “ter um data lake”. Um reposit\u00f3rio central sem padr\u00e3o de qualidade, sem regra de origem (linhagem) e sem dono definido continua sendo dado disperso, s\u00f3 que concentrado em um \u00fanico lugar. A arquitetura \u00e9 o conjunto de regras \u2014 n\u00e3o a ferramenta.<\/p>\n\n\n\n