Uma proposta foi aceita, mas a apólice não chegou ao cliente. O canal informa que enviou a solicitação, a integração registra uma chamada concluída, mas o sistema responsável pela emissão não apresenta o documento. Quem consegue explicar o que aconteceu entre essas etapas?
Quando uma jornada atravessa sistemas internos, APIs de parceiros, bases de dados e aplicações de inteligência artificial, verificar cada componente separadamente pode deixar lacunas. As equipes enxergam partes do processo, mas precisam reconstruir manualmente o caminho da transação.
A observabilidade em sistemas de seguros ajuda a organizar essa investigação. Seu valor aparece quando a seguradora consegue identificar onde o fluxo foi interrompido, quais solicitações foram afetadas e quem precisa atuar.
Isso influencia o esforço de manutenção, o atendimento ao segurado, a continuidade dos canais e a disponibilidade de evidências. A decisão sobre como evoluir deve considerar a criticidade das jornadas, a cobertura existente e a capacidade da equipe de transformar informação em ação.
Principais pontos
- Monitoramento e observabilidade são complementares. Acompanhar indicadores conhecidos e investigar comportamentos inesperados são capacidades necessárias à operação.
- APIs não tornam uma transação automaticamente rastreável. É preciso instrumentar os serviços e preservar o contexto entre as etapas.
- Infraestrutura, dados e IA exigem controles relacionados, mas distintos. Um registro técnico não substitui qualidade dos dados, governança ou explicabilidade.
- A criticidade importa tanto quanto o volume. Uma integração pouco utilizada pode sustentar uma etapa essencial.
- A evolução pode ser gradual. O primeiro passo é localizar uma lacuna relevante e definir como verificar sua melhoria.
⚠️ Ponto de atenção: um painel sem alertas não comprova que a jornada funciona corretamente. Antes de concluir que a operação está saudável, verifique se os sinais acompanhados representam o resultado esperado pelo cliente e pelas áreas de negócio.
O que é observabilidade em sistemas de seguros?
Observabilidade permite investigar um sistema por meio das informações que ele produz. O monitoramento acompanha indicadores, limites e condições conhecidas; a observabilidade amplia a capacidade de explorar relações e investigar situações que não foram previstas em um alerta específico.
No contexto de seguros, isso significa relacionar o comportamento técnico ao processo: uma solicitação de cotação foi respondida? A emissão terminou? O evento de pagamento foi recebido e processado? Uma falha afetou apenas um parceiro ou diferentes canais?
Logs, métricas e traces: o que cada sinal mostra
| Sinal | O que representa | Exemplo em seguros |
|---|---|---|
| Logs | Registros de eventos ocorridos em um componente. | Uma tentativa de emissão terminou com erro de validação. |
| Métricas | Medidas quantitativas acompanhadas ao longo do tempo. | Taxa de falhas e tempo de resposta de uma API de cotação. |
| Traces | Rastros das etapas percorridas por uma requisição distribuída. | Caminho da solicitação entre canal, integração e serviço de emissão. |
Esses sinais precisam ser úteis em conjunto. A documentação do OpenTelemetry destaca a importância da instrumentação para investigar o comportamento dos sistemas.
A propagação de contexto permite relacionar etapas executadas por serviços diferentes. Em uma integração com terceiros, a cobertura depende também das informações que o parceiro disponibiliza e das restrições de segurança aplicáveis.
Por isso, estruturar API Management para seguradoras e definir responsabilidades sobre as interfaces são iniciativas relacionadas à observabilidade, embora tenham escopos diferentes.
Por que essa capacidade ganhou peso na operação de seguros?
Em operações com múltiplos canais e parceiros, uma jornada pode depender do core, de motores de cálculo, sistemas financeiros, serviços antifraude e aplicações externas. Quanto maior essa interdependência, mais importante se torna compreender o caminho entre a solicitação e o resultado.
A integração de sistemas empresariais cria conexões necessárias ao negócio. A observabilidade ajuda a avaliar o comportamento dessas conexões durante a operação.
O contexto regulatório acrescenta uma dimensão documental. O artigo 83 da Lei nº 15.040/2024 prevê, em caso de negativa de cobertura, a entrega dos documentos que fundamentem a decisão, observadas as ressalvas legais. Uma estrutura de registros pode apoiar esse trabalho, mas não substitui a documentação exigida.
Também é necessário separar planejamento regulatório de obrigação vigente. O Plano de Regulação da SUSEP para 2026, instituído pela Resolução nº 72/2025, foi alterado pela Resolução nº 91/2026. Essa agenda orienta iniciativas regulatórias; não equivale, por si só, a uma exigência de contratar uma plataforma de observabilidade.
Onde a falta de observabilidade aparece na operação
Nas integrações entre sistemas e parceiros
Uma API pode aceitar a solicitação sem que todas as etapas seguintes tenham sido concluídas. Da mesma forma, uma fila pode acumular mensagens enquanto os serviços continuam disponíveis.
No cenário hipotético da apólice não emitida, a investigação deveria permitir responder:
Essas respostas orientam a recuperação. Antes de repetir uma operação, por exemplo, a equipe precisa conferir se alguma etapa já foi executada, evitando duplicidade de emissão ou cobrança.
No envio de dados a órgãos reguladores
Um lote pode chegar à validação final com inconsistências originadas em sistemas diferentes. Sem identificar a origem e as transformações de cada informação, a equipe precisa comparar arquivos, consultar responsáveis e reconstruir o processamento.
Para avaliar esse cenário, verifique se a operação relaciona registro, fonte, versão da transformação, regra de validação e retorno recebido. Isso ajuda a delimitar a correção, mas não substitui os critérios de qualidade nem determina, sozinho, se o reprocessamento parcial é permitido.
Nas decisões automatizadas por IA
Uma aplicação pode classificar documentos, sinalizar suspeitas de fraude ou recomendar encaminhamentos de sinistros. A investigação precisa distinguir o resultado do modelo da decisão efetivamente aplicada pela operação.
Para cada uso crítico, convém documentar a versão do modelo, a referência dos dados utilizados, as regras posteriores, o resultado e as intervenções humanas pertinentes. Os registros devem respeitar finalidade, necessidade e proteção de dados.
Impactos que costumam ficar ocultos
A falta de visibilidade pode aparecer como esforço disperso: reuniões para localizar um erro, consultas repetidas aos mesmos especialistas, conciliações manuais e demora para informar ao canal o que ocorreu.
Na operação, vale observar quatro consequências:
Diferentes equipes repetem buscas sem compartilhar o contexto.
Não há clareza sobre o que pode ser reprocessado.
O segurado ou parceiro recebe respostas vagas sobre o andamento.
O diagnóstico depende de quem conhece detalhes não documentados.
Em iniciativas de automação de sinistros, essa avaliação ajuda a identificar se as exceções continuam consumindo esforço manual mesmo depois da digitalização das etapas.
O custo da limitação deve ser estimado com dados da própria operação: horas de investigação, transações afetadas, reprocessamentos e tempo de indisponibilidade. Sem essa base, comparar investimentos se torna uma discussão de percepção.
Avalie quais integrações hoje concentram mais investigação manual, dependência entre áreas, dificuldade de rastreamento e retrabalho operacional.
Riscos de operar sem uma estrutura de observabilidade
Dificuldade para demonstrar controles e reconstruir eventos
A Circular SUSEP nº 638/2021 estabelece requisitos de segurança cibernética para entidades abrangidas por seu escopo. A SUSEP destaca governança, gestão de vulnerabilidades e incidentes, continuidade de negócios e terceirização de serviços relevantes.
Registros e sinais operacionais podem apoiar esses controles. A conformidade, porém, depende também de políticas, responsabilidades, procedimentos e evidências adequadas a cada obrigação.
Nas decisões tomadas exclusivamente com base em tratamento automatizado de dados pessoais que afetem interesses do titular, o artigo 20 da LGPD prevê o direito de solicitar revisão. Também estabelece o fornecimento, quando solicitado, de informações claras sobre critérios e procedimentos, observados os segredos comercial e industrial.
Exposição de informações nos próprios registros
Coletar mais dados não significa necessariamente investigar melhor. Logs e traces podem capturar documentos, credenciais ou informações pessoais desnecessárias.
A orientação técnica do OpenTelemetry recomenda minimizar a coleta e revisar os atributos registrados. Na implantação, isso deve se traduzir em seleção de campos, remoção ou mascaramento quando apropriado e controle de acesso à telemetria.
Confusão entre telemetria e trilha de auditoria
A amostragem de traces pode ajudar a controlar custos, mas também deixa parte das transações fora do conjunto retido. Sua adoção deve considerar o risco de perder informações relevantes e eventuais requisitos de preservação.
Por isso, registros necessários para comprovação de atos, decisões ou obrigações precisam de uma política própria de integridade, acesso e retenção. Não devem depender apenas da configuração usada para investigar desempenho.
Três camadas de observabilidade que a seguradora precisa considerar
Para organizar o escopo, é útil separar três frentes de aplicação. Elas não substituem os sinais de telemetria; mostram onde a operação precisa de visibilidade.
Infraestrutura, aplicações e APIs
Disponibilidade, latência, erros, filas e dependências.
Onde a jornada foi interrompida e quais solicitações foram afetadas?
Dados e fluxos regulatórios
Origem, atualização, transformações, validações e inconsistências.
Qual informação está incorreta e em que etapa surgiu a divergência?
Aplicações e decisões de IA
Versões, resultados, qualidade, regras e revisão.
Que resultado foi produzido, como foi utilizado e quais evidências permitem avaliá-lo?
Um problema pode atravessar essas frentes: uma integração entrega dados desatualizados, uma validação não identifica a mudança e uma aplicação de IA utiliza a informação inadequada.
A resposta exige cooperação entre engenharia, dados, operações, segurança e responsáveis pelo uso da IA. Centralizar painéis sem definir essas responsabilidades mantém a investigação incompleta.
Critérios para avaliar a maturidade de observabilidade da operação
O ponto de partida é verificar se a equipe consegue investigar jornadas críticas com as evidências disponíveis.
| Indicador | O que observar | Como usar na decisão |
|---|---|---|
| Tempo de detecção | Intervalo entre o início do problema e sua identificação. | Avaliar se o alerta chega antes das reclamações do canal. |
| Tempo de diagnóstico | Intervalo até identificar uma causa ou hipótese acionável. | Localizar lacunas que prolongam a investigação. |
| Tempo de recuperação | Intervalo até restabelecer a capacidade afetada. | Distinguir falta de informação de dificuldade de correção. |
| Cobertura das jornadas | Etapas críticas que podem ser acompanhadas e relacionadas. | Priorizar pontos sem registros ou correlação. |
| Sucesso e latência | Conclusões corretas, falhas e distribuição do tempo de resposta. | Relacionar saúde técnica à experiência da operação. |
| Qualidade dos alertas | Alertas que demandam ação, repetições e ruído. | Reduzir distrações e melhorar o encaminhamento. |
Defina o início e o fim de cada medição para evitar comparações inconsistentes. Na confiabilidade de serviços, SLIs são indicadores de nível de serviço e SLOs são objetivos associados a eles. As metas devem refletir o comportamento relevante para os usuários e para o negócio.
Em uma jornada de emissão, isso significa olhar além da disponibilidade da API: importa saber se a solicitação válida resultou no processamento esperado dentro do objetivo definido.
Quando faz sentido investir em observabilidade agora e quando não faz
Considere manter e revisar a estrutura atual quando…
As jornadas críticas já possuem cobertura suficiente, responsáveis definidos, evidências acessíveis e procedimentos de resposta testados. Nessa situação, o investimento pode se concentrar em manutenção e melhorias específicas.
Considere uma evolução gradual quando…
Existem sinais úteis, mas faltam correlação, contexto de negócio ou cobertura em algumas integrações. Pode ser possível aproveitar ferramentas já contratadas e começar por uma jornada prioritária.
Considere apoio especializado quando…
Os incidentes são recorrentes, atravessam diferentes equipes ou fornecedores e exigem competências que a organização não consegue sustentar no momento. Também vale avaliar apoio quando as lacunas envolvem arquitetura, dados e governança ao mesmo tempo.
As abordagens abaixo podem ser combinadas. Uma plataforma de seguros, uma ferramenta de APM e uma solução de observabilidade de dados cumprem funções diferentes.
| Caminho | Quando considerar | Limite ou cuidado |
|---|---|---|
| Evoluir o monitoramento e o APM existentes | Já há coleta útil, mas falta contexto ou instrumentação. | Verificar cobertura real e capacidade de investigação. |
| Adotar uma plataforma de observabilidade | Há necessidade de relacionar sinais de vários ambientes. | Considerar ingestão, armazenamento, consultas, integração e operação. |
| Ampliar a observabilidade de dados | A prioridade está em qualidade, atualização e transformações. | Não presumir que isso cobre toda a jornada de aplicações e APIs. |
| Modernizar componentes da arquitetura | Existem gargalos que a instrumentação não resolve. | Exige desenho de transição e continuidade operacional. |
| Manter conciliações manuais delimitadas | Há exceções pontuais, controladas e documentadas. | Não depender delas como principal mecanismo de investigação. |
Ferramentas de APM podem receber contexto de negócio. A documentação do Elastic APM, por exemplo, permite adicionar metadados a transações, spans e erros. O critério de escolha deve ser a capacidade configurada e demonstrada no ambiente, e não apenas a classificação “genérica” ou “especializada”.
Avalie onde a arquitetura ainda sustenta a operação e quais limitações já justificam integração, substituição gradual ou modernização de componentes.
O que costuma dar errado na prática
| Erro recorrente | Consequência | Como reduzir o risco |
|---|---|---|
| Coletar sinais sem relacioná-los à jornada | Há dados, mas a investigação continua manual. | Definir contexto e cobertura das etapas críticas. |
| Medir apenas disponibilidade | O serviço parece saudável enquanto o processo falha. | Incluir conclusão, latência e erros da jornada. |
| Presumir que APIs garantem rastreabilidade | Etapas entre sistemas permanecem sem evidência. | Verificar instrumentação e correlação nas integrações. |
| Registrar dados excessivos | Aumentam custo e exposição de informações. | Aplicar minimização e regras de acesso e retenção. |
| Confundir saída de IA com justificativa | A operação não consegue avaliar a decisão aplicada. | Documentar modelo, regras e revisão pertinente. |
| Criar alertas sem responsável | Os avisos se acumulam sem resposta consistente. | Definir criticidade, encaminhamento e procedimento. |
| Depender de poucas pessoas | Ausências dificultam o diagnóstico. | Documentar fluxos e exercitar a resposta com a equipe. |
Critérios de decisão: o que exigir antes de escolher uma solução
Na avaliação de fornecedores ou de um projeto interno, transforme necessidades em demonstrações verificáveis:
Quais sistemas, protocolos e parceiros serão acompanhados?
Como uma solicitação será relacionada às etapas seguintes?
Será possível identificar jornada, canal e versão sem expor dados desnecessários?
Quem acessa os registros, altera alertas e responde aos incidentes?
Como o investimento varia com volume, retenção e consultas?
Quem vai operar, manter e evoluir a estrutura?
Como dados e configurações poderão ser exportados ou migrados?
A solução consegue apoiar a investigação de uma falha representativa do ambiente?
Uma prova de conceito deve partir de um cenário delimitado, com critérios de aceite, dados protegidos e condições de execução seguras. A demonstração precisa revelar também onde a visibilidade termina.
Checklist: sua operação consegue investigar as jornadas críticas?
Avalie quais afirmações descrevem a realidade atual
Marque os controles que já fazem parte da operação e use o resultado para identificar prioridades de observabilidade, governança e resposta.
0 de 7 critérios aplicáveis atendidos
Use as respostas para organizar prioridades, não como certificação de maturidade.
Uma lacuna em uma jornada crítica pode exigir atenção mesmo quando os demais critérios estão atendidos.
Comece a avaliação
Marque os controles já presentes na operação para identificar quais pontos ainda merecem análise.
Há pelo menos uma lacuna relacionada à identificação ou à correlação das jornadas críticas. Esse ponto merece análise mesmo que a cobertura geral dos demais critérios seja alta.
Ainda é difícil identificar por onde começar?
Leve os principais pontos de dúvida para uma conversa com a Tecnologia Única e organize as prioridades da operação.
Como a arquitetura da Proteo se relaciona com a observabilidade
Quando a falta de visibilidade está associada à fragmentação de produtos, canais e processos, a avaliação pode envolver a arquitetura que sustenta a operação.
O Proteo é uma plataforma da Tecnologia Única com estrutura modular e baseada em microsserviços. Sua apresentação pública reúne capacidades de integração, configuração de produtos, administração de apólices, financeiro e sinistros.
Esse escopo permite discutir a organização das jornadas em conjunto com a evolução dos sistemas. A cobertura de observabilidade, entretanto, deve ser examinada no projeto: quais registros estarão disponíveis, como serão relacionados, quais integrações externas serão alcançadas e o que dependerá de configuração ou desenvolvimento.
No case da Herval Seguradora, a Tecnologia Única descreve o uso de Proteo-InsureMO como sistema central de uma operação digital, com APIs e processos que abrangem cotação, emissão e sinistros. O caso demonstra uma aplicação da plataforma; não estabelece resultados universais de observabilidade.
A escolha entre preservar componentes, integrar ferramentas e adotar uma plataforma end to end para seguradoras deve partir dos gargalos identificados. Uma necessidade pontual de instrumentação não exige, necessariamente, substituir o ambiente de gestão.
Como estruturar o próximo passo
Para começar sem ampliar desnecessariamente o projeto:
Escolha uma jornada crítica. Delimite o processo e o resultado esperado.
Mapeie as dependências. Inclua sistemas, parceiros, filas, dados, regras e intervenções humanas.
Registre a situação atual. Levante incidentes, esforço de investigação e sinais disponíveis.
Defina as perguntas prioritárias. Estabeleça o que a equipe precisa conseguir explicar.
Complete a instrumentação necessária. Relacione etapas e documente lacunas de cobertura.
Proteja as evidências. Defina campos, acesso, retenção e requisitos de auditoria.
Organize a resposta. Associe alertas a responsáveis e procedimentos de recuperação.
Teste em condições controladas. Verifique se o problema é detectado, investigado e encaminhado.
Compare os resultados. Avalie cobertura, tempos e esforço em condições comparáveis.
Expanda conforme o valor demonstrado. Priorize novas jornadas pela criticidade e pelas lacunas remanescentes.
O primeiro entregável deve ser uma capacidade verificável: a equipe consegue investigar uma jornada importante com menos incerteza e sabe como agir diante da falha.
Conclusão
A observabilidade em sistemas de seguros cria condições para investigar falhas e relacionar o comportamento técnico às jornadas do negócio. Seu valor depende da qualidade dos sinais, da cobertura das integrações e da capacidade das equipes de utilizar essas informações.
O avanço pode começar por uma emissão interrompida, um fluxo de sinistro com retrabalho ou uma integração cuja manutenção depende de poucas pessoas. O essencial é definir o problema, preservar as evidências necessárias e demonstrar melhoria antes de ampliar o escopo.
Avalie onde integrações, rastreabilidade, contexto de negócio e dependências entre sistemas ainda limitam a visibilidade da operação.
Perguntas frequentes sobre observabilidade em sistemas de seguros
Monitoramento acompanha indicadores e condições conhecidas. Observabilidade amplia a investigação do comportamento dos sistemas e de suas dependências. As duas capacidades se complementam; observar a operação não dispensa alertas e acompanhamento contínuo.
Não. Segurança de APIs envolve proteção de acessos, dados e operações. Observabilidade ajuda a investigar o comportamento das integrações. Os sinais podem apoiar a detecção de problemas, mas não substituem autenticação, autorização e demais controles de segurança.
Sim. Além de erros e desempenho, é necessário avaliar qualidade, versões, resultados e uso das saídas no processo. Registros operacionais devem ser combinados com documentação e governança; não garantem, isoladamente, explicabilidade ou decisões corretas.
A estrutura deve ser proporcional ao risco. Uma operação menor pode utilizar uma implementação mais simples, desde que consiga acompanhar suas jornadas críticas e responder a falhas. O número de transações não deve ser o único critério.
Não. Ela pode apoiar investigação e disponibilidade de evidências. A conformidade depende do conjunto de obrigações aplicáveis, políticas, controles, documentação e responsabilidades, incluindo requisitos específicos de proteção de dados.
Não necessariamente. A evolução pode começar com melhorias de instrumentação, correlação e procedimentos. A substituição de componentes faz sentido quando existem limitações arquiteturais relevantes que não podem ser resolvidas de forma adequada no ambiente atual.
Compare cobertura das jornadas, tempos de detecção, diagnóstico e recuperação, esforço manual e qualidade dos alertas. Considere mudanças de volume e de criticidade para não atribuir à implementação resultados causados por outras alterações.
Referências
[1] OpenTelemetry. Observability primer.
[2] OpenTelemetry. Context propagation.
[3] Planalto. Lei nº 15.040/2024.
[4] SUSEP. Plano de Regulação de 2026 e atualização pela Resolução nº 91/2026.
[5] SUSEP. Segurança Cibernética no Setor Supervisionado.
[6] Planalto. Lei Geral de Proteção de Dados Pessoais.
[7] OpenTelemetry. Handling sensitive data.
[9] Google SRE. Service Level Objectives.
FR 
PT 
EN 
ES 
IT 
DE