A gestão de consentimento no Open Insurance é o conjunto de processos e controles que sustenta o consentimento do cliente do pedido à expiração. A Resolução CNSP nº 415/2021 limita cada consentimento a doze meses, exige discriminação granular dos dados e revogação imediata — obrigações que recaem sobre sistemas, não sobre uma tela.
A confusão mais cara nesse tema é tratar consentimento como um formulário. Na prática, cada consentimento é um objeto com estado, prazo, escopo e histórico, que precisa ser criado, consultado, alterado, renovado, revogado e expirado — e que precisa produzir o mesmo efeito em todos os sistemas que recebem aquele dado. Quem constrói apenas a tela costuma descobrir o problema meses depois, quando o primeiro lote de consentimentos vence ou quando uma revogação não interrompe um fluxo que já estava em andamento.
Este artigo trata do que a regra exige, de onde a operação costuma travar, das alternativas de arquitetura disponíveis e dos critérios para decidir entre manter, evoluir ou reestruturar.
Principais pontos
- O consentimento no Open Insurance tem prazo máximo de doze meses (Resolução CNSP nº 415/2021, art. 11, § 1º, III) e é revogável a qualquer tempo, com efeito imediato (art. 16 e § 3º).
- O compartilhamento segue três etapas encadeadas — consentimento, autenticação e confirmação — em interface dedicada e canais eletrônicos, com a confirmação ocorrendo simultaneamente à autenticação.
- Consentimento obtido por contrato de adesão, formulário pré-marcado ou de forma presumida é vedado. Alterar as condições exige novo consentimento, não um ajuste silencioso no registro existente.
- O gargalo raro é a tela; o gargalo comum é a propagação: fazer a revogação alcançar réplicas, filas, caches e relatórios que já consumiram o dado.
- A Resolução Susep nº 61/2025 reforçou a padronização da jornada (Manual de Experiência do Cliente) e criou o Manual de Monitoramento, com métricas de API e qualidade de dados — o que torna o comportamento do seu sistema observável por terceiros.
O que a regulação efetivamente exige do consentimento
A base está na Resolução CNSP nº 415/2021, que define consentimento como manifestação livre, informada, prévia e inequívoca de vontade, feita por meio eletrônico (art. 2º, VII). A partir daí, o texto estabelece requisitos que se traduzem diretamente em requisitos de sistema:
Sobre essa base incide a LGPD. O art. 8º, § 5º da Lei nº 13.709/2018 estabelece que o consentimento pode ser revogado a qualquer momento por procedimento gratuito e facilitado; o art. 9º, § 1º torna nulo o consentimento cujas informações tenham conteúdo enganoso ou abusivo, ou que não tenham sido apresentadas com transparência; e o art. 18 lista os direitos do titular, incluindo conhecer as entidades com as quais o controlador compartilhou dados.
São regimes complementares: atender ao fluxo técnico do Open Insurance não dispensa a governança de dados pessoais da seguradora, tratada em LGPD nas empresas: adequação, governança e compliance na prática.
Por que a gestão de consentimento é um problema de arquitetura, e não de interface
Lendo a norma como requisito de produto, é fácil concluir que basta uma boa tela de consentimento. O que a operação revela é outra coisa: o consentimento é um estado que precisa ser respeitado por todos os sistemas que tocam aquele dado, durante todo o tempo em que ele estiver vigente — e deixar de ser respeitado no instante em que deixar de estar.
Um consentimento percorre, no mínimo, este ciclo:
Cada transição precisa ser registrada de forma reconstituível: quem consentiu, quando, com que escopo, por qual canal, e o que mudou desde então. É esse registro que responde a uma reclamação, a uma auditoria interna ou a um pedido do titular — e é ele que quase nunca existe quando o consentimento foi implementado como campo em uma tabela do sistema de atendimento.
O ponto crítico está na etapa 6. Interromper o compartilhamento é simples no ponto de entrada: a API para de responder. É bem menos simples quando o dado já entrou na operação — foi replicado para um data warehouse, alimentou um modelo, entrou em uma fila de processamento assíncrono, foi consumido por um relatório de BI ou por um fluxo de campanha.
“Revogação imediata” é uma obrigação sobre o compartilhamento; o que acontece com o que já foi compartilhado depende do regime de tratamento aplicável e da governança interna de cada participante. Definir isso antes, e não durante o primeiro incidente, é o que separa uma implementação sustentável de uma que gera exceção manual.
Identifique quais sistemas da operação consomem os dados recebidos por compartilhamento e, principalmente, como cada um deles saberia que um consentimento foi revogado ou expirou. Esse mapa revela onde a arquitetura precisa propagar o estado do consentimento para evitar uso indevido após o fim da autorização.
Ponto de atenção: o vencimento chega em lote
Como todo consentimento tem prazo máximo de doze meses, a curva de expiração reproduz a curva de adesão com um ano de atraso. Uma campanha bem-sucedida que gerou milhares de consentimentos em um mês produzirá, doze meses depois, milhares de expirações concentradas no mesmo mês.
A consequência prática não é regulatória — é operacional e comercial. Serviços construídos sobre dados compartilhados (recomendação, precificação, conciliação com parceiros) param silenciosamente para aquele grupo de clientes. Sem visibilidade de vencimento, a equipe descobre pela queda no volume, não pelo calendário.
O controle que merece avaliação é simples de descrever e frequentemente ausente: um inventário de consentimentos ativos com data de expiração, volume por mês e responsável por acionar a jornada de renovação. Não é uma exigência específica da norma; é o que impede que a regra de doze meses vire surpresa.
Onde a jornada trava na prática
A padronização da experiência tem base normativa e operacional. A Resolução Susep nº 61/2025, publicada em 3 de novembro de 2025 com vigência imediata, alterou a Circular Susep nº 635/2021 para instituir um capítulo sobre experiência do cliente.
Dessa forma, passa a incluir uma guia que harmoniza as etapas de consentimento, autenticação e confirmação entre participantes (art. 13-A), determinar a manutenção de plataforma de resolução de disputas entre participantes (art. 13-B) e criar o Manual de Monitoramento, que abrange desempenho de APIs, qualidade de dados e experiência do cliente (art. 13-C).
No plano operacional, o Guia de Experiência do Usuário do Open Insurance (versão 2.4, de 25/06/2024) detalha a jornada em dez passos e fixa parâmetros que costumam surpreender equipes técnicas:
O parâmetro de 60 segundos é o que mais expõe arquitetura legada. Uma consulta que depende de uma rotina em lote, de um sistema que responde bem em uso interno mas não sob concorrência, ou de uma integração ponto a ponto acumulada ao longo de anos, tende a estourar esse limite sob volume — e o efeito não é um erro discreto, é sair da jornada do cliente.
Esse é um sintoma clássico de fragmentação de dados, tema aprofundado em arquitetura de dados para seguradoras.
O que costuma dar errado
| Erro recorrente ou risco de execução | Por que acontece | Consequência possível | Como reduzir o risco |
|---|---|---|---|
| Consentimento tratado como campo de cadastro | A primeira entrega é uma tela; o modelo de dados é definido depois. | Impossibilidade de reconstruir escopo e histórico em uma auditoria ou reclamação. | Modelar consentimento como entidade própria, com estado, escopo, prazo e trilha de alterações. |
| Revogação que só desliga a API | O efeito no ponto de entrada é visível; o efeito nos sistemas a jusante, não. | Dado continua sendo usado em fluxos internos após o fim da autorização. | Mapear consumidores do dado e definir o que acontece em cada um quando a autorização cessa. |
| Sem inventário de vencimentos | O prazo de doze meses parece distante durante o projeto. | Expirações concentradas derrubam serviços dependentes sem aviso. | Painel de consentimentos ativos por data de expiração, com acionamento da renovação. |
| Tempo de resposta dimensionado para uso interno | Testes feitos em volume baixo, sem concorrência real. | Saída da jornada por timeout e reclamações de cliente sobre “erro na seguradora”. | Testar sob carga com o limite de resposta em tela como critério de aceite. |
| Alteração de escopo feita no registro existente | A norma parece admitir “atualizar” o consentimento. | Consentimento com escopo diferente do que o cliente confirmou. | Tratar mudança de condição como novo consentimento, encerrando o anterior. |
| Finalidade exposta à transmissora | O time replica o modelo de dados da receptora sem ler a vedação. | Descumprimento do art. 11, § 4º da Resolução CNSP nº 415/2021. | Revisar contratos de API e telas quanto ao que trafega para cada parte. |
| Autenticação terceirizada sem governança | Contratação resolve o prazo do projeto. | Responsabilidade permanece com a transmissora, agora sobre processo que ela não controla. | Formalizar requisitos, evidências e monitoramento do fornecedor de autenticação. |
Nem todos esses pontos pesam igual em cada operação. O diagnóstico abaixo ajuda a localizar onde está a sua concentração de esforço — no registro, na propagação ou no desempenho.
Sua operação sustenta o ciclo de vida do consentimento?
Marque as situações que descrevem a sua operação hoje. Ao final, você recebe uma leitura consultiva sobre onde o esforço tende a se concentrar — no registro, na propagação ou no desempenho. É um ponto de partida, não uma avaliação de conformidade.
0 de 7 situações marcadas
Nenhuma resposta é salva ou enviada. As marcações existem apenas nesta página e desaparecem ao recarregar.
Essa leitura não substitui uma análise técnica, mas separa três problemas que costumam ser tratados como um só. É essa distinção que define o próximo passo — e os critérios das próximas seções.
Comparação com alternativas
Quando faz sentido e quando não faz
Considere manter a estrutura atual quando:
O volume de consentimentos ativos é baixo, a jornada não muda com frequência, revogações são raras e o time consegue responder a um pedido de auditoria sobre um consentimento específico em poucas horas, sem levantamento manual entre sistemas.
Considere uma evolução gradual quando:
Já existe registro de consentimento, mas ele não cobre todo o ciclo: falta histórico de alterações, falta visibilidade de vencimento ou a revogação depende de acionamento manual de mais de uma equipe. Nesse cenário, mapear e documentar os consumidores do dado costuma reduzir mais risco, no curto prazo, do que trocar de ferramenta.
Considere uma reestruturação quando:
O tempo de resposta às chamadas já compromete a jornada, cada novo produto ou parceria exige uma integração nova sem padrão comum, ou não é possível demonstrar, com registro, o escopo exato que um cliente confirmou em determinada data.
Critérios de decisão
Rastreabilidade
É possível reconstruir, para um consentimento específico, quem consentiu, quando, com que escopo e o que mudou desde então — sem depender de uma pessoa específica?
Propagação
Existe uma lista dos sistemas que consomem dados originados de compartilhamento e uma definição do que acontece em cada um quando a autorização cessa?
Desempenho sob concorrência
Os sistemas que respondem às chamadas foram testados no volume projetado, tendo o limite de resposta em tela como critério de aceite?
Capacidade de mudança
Quanto tempo leva, hoje, para alterar a jornada de consentimento em produção? Se a resposta é “depende da próxima janela do core”, esse é um custo recorrente.
Governança de terceiros
Se autenticação ou infraestrutura são contratadas, há evidências e monitoramento correspondentes à responsabilidade que permanece com a seguradora?
Capacidade interna
A equipe tem tempo e conhecimento para acompanhar a evolução dos manuais do ecossistema, ou já opera no limite mantendo o que existe?
O que uma arquitetura preparada sustenta e o que ela não resolve
Uma estrutura adequada ao tema tem características identificáveis:
- Consentimento como entidade própria, com estado explícito e trilha de auditoria.
- Escopo modelado de forma granular, coerente com o agrupamento apresentado ao cliente.
- Autenticação baseada em protocolos padronizados.
- Integrações via API com contrato estável, em vez de rotinas em lote.
- Observabilidade suficiente para saber quantos consentimentos estão ativos, quantos vencem no próximo mês e quantas chamadas ultrapassaram o tempo aceitável.
Essa é a descrição de uma categoria, não de um produto. Na prática, seguradoras chegam lá por caminhos diferentes — e o caminho depende mais do estado do core system e das integrações existentes do que da escolha de uma ferramenta.
A Tecnologia Única atua nesse ponto por três frentes verificáveis: integração de sistemas empresariais, com padronização de contratos de API entre seguradora, corretoras e parceiros; desenvolvimento e modernização de sistemas, quando a limitação está no core; e squads especializados, quando a arquitetura está definida mas falta capacidade de execução.
A plataforma Proteo, desenvolvida com a InsureMO, ilustra o mecanismo: arquitetura de microsserviços, integrações nativas via APIs REST e webhooks e protocolos OAuth2 e OpenID Connect — os mesmos padrões de autenticação e autorização que o ecossistema exige. A operação da Herval Seguradora é um exemplo público dessa arquitetura em produção.
Duas ressalvas importam aqui. A primeira: descrever uma arquitetura demonstra plausibilidade técnica, não comprova ganho de eficiência ou adequação regulatória em outra operação — o resultado depende do contexto de cada seguradora.
A segunda: nenhum componente técnico, isoladamente, produz conformidade. Protocolo de autenticação, registro de consentimento e API padronizada são meios; a obrigação continua sendo do participante, e depende de processo, governança e evidência, como discutido em segurança cibernética em seguradoras.
Como estruturar o próximo passo
Independentemente do caminho escolhido, a sequência para organizar a gestão de consentimento no Open Insurance costuma ser a mesma:
Inventariar
Levante os consentimentos ativos, incluindo volume, escopo, data de expiração e finalidade associada.
Mapear
Identifique todos os sistemas que recebem dados originados de compartilhamento, incluindo réplicas analíticas e filas assíncronas.
Definir
Para cada sistema consumidor, estabeleça o comportamento esperado quando um consentimento é revogado ou expira.
Medir
Meça o tempo de resposta das chamadas no volume projetado, usando o limite de resposta em tela como critério de aceite.
Documentar
Estruture a trilha de auditoria: o que é registrado em cada transição de estado e por quanto tempo cada evidência é retida.
Revisar
Compare a jornada com o guia de experiência vigente e os manuais do ecossistema, verificando escopo obrigatório versus opcional e as vedações de obtenção do consentimento.
Monitorar
Acompanhe a agenda regulatória. Em 2026, a Susep conduziu tomada de subsídios sobre governança, participação, certificações de jornada, interoperabilidade e monitoramento do Open Insurance, com prazo de contribuições encerrado em 5 de maio de 2026. Ajustes decorrentes podem alterar requisitos de jornada e certificação.
Monitoramento contínuoOs três primeiros passos costumam ser feitos internamente em poucas semanas. É a partir do quarto — medição sob carga e trilha de auditoria — que a maioria das operações descobre se o problema é de processo ou de arquitetura.
Conclusão
Gestão de consentimento no Open Insurance é, no fundo, uma questão de estado distribuído: um cliente autoriza algo por um tempo determinado, e todos os sistemas que dependem daquele dado precisam reconhecer o mesmo começo e o mesmo fim.
A regra é clara quanto ao prazo, à granularidade e à imediatidade da revogação; a dificuldade está em fazer isso valer dentro de uma operação que foi construída em camadas ao longo de anos.
O ganho de resolver bem esse ponto é proporcional: não é uma vantagem competitiva por si só, mas é a condição para participar do ecossistema sem gerar exceção manual a cada vencimento, revogação ou nova finalidade. O limite também é claro — nenhuma arquitetura elimina a necessidade de governança e de decisão sobre o que acontece com o dado depois que ele entra.
Se hoje a sua operação não consegue responder, com registro, qual escopo um cliente confirmou e quais sistemas ainda usam aquele dado, a Tecnologia Única pode apoiar o mapeamento e a estruturação dessa camada — por integração de sistemas, modernização do core ou squads especializados, conforme o estágio da sua arquitetura.
Perguntas frequentes (FAQ)
Não. O prazo de validade deve ser compatível com as finalidades e está limitado a doze meses (Resolução CNSP nº 415/2021, art. 11, § 1º, III). Para continuar, o cliente precisa passar por uma nova confirmação.
Não pelo registro existente. A alteração das condições requer a obtenção de novo consentimento (art. 11, § 2º). Na prática, isso significa encerrar o consentimento anterior e criar outro, preservando o histórico de ambos.
São questões distintas. A norma determina que a revogação seja assegurada a qualquer tempo e efetuada de forma imediata (art. 16 e § 3º), o que trata da interrupção do compartilhamento. O destino dos dados já tratados depende da base legal aplicável e das obrigações de retenção de cada participante, conforme a LGPD — é uma decisão que precisa estar documentada antes do primeiro pedido.
A contratação de serviços de autenticação é permitida, mas a responsabilidade permanece com a sociedade transmissora, e não se contrata para autenticar a própria entidade a ser autenticada (arts. 17 a 20). Isso torna evidência e monitoramento do fornecedor parte do controle, não um detalhe contratual.
Não são sinônimos. O consentimento do Open Insurance é um mecanismo específico, com etapas, prazo e interface definidos pela regulação setorial. A LGPD trata do regime geral de tratamento de dados pessoais, no qual o consentimento é uma entre várias bases legais. Uma operação pode estar tecnicamente correta na jornada do ecossistema e ainda ter lacunas de governança de dados pessoais.
No ambiente de gestão de compartilhamentos das instituições participantes — apresentado ao consumidor, no material oficial do ecossistema, como a área de "Meus compartilhamentos", com jornadas de revogação, alteração e renovação. Para a seguradora, isso significa que esse ambiente precisa refletir o mesmo estado que os sistemas internos reconhecem.
Referências externas
[1] Susep. Resolução CNSP nº 415, de 20 de julho de 2021 (texto consolidado).
[2] Susep. Resolução Susep nº 61, de 29 de outubro de 2025.
[3] Susep. Susep publica alterações na norma do Open Insurance.
[4] Área do Desenvolvedor OPIN. Guia de Experiência do Usuário do Open Insurance, versão 2.4 (25/06/2024).
[5] Open Insurance Brasil. Gestão de consentimento.
[6] Planalto. Lei nº 13.709/2018 (LGPD).
[7] Susep. Susep coleta contribuições com o objetivo de aprimorar o Open Insurance.
IT 
PT 
EN 
ES 
FR 
DE 