Muitas empresas do setor bancário, de serviços financeiros e de seguros (BFSI) acreditam que os dados de seus clientes estão em conformidade. Mas, quando um órgão regulador lhes pede para comprovar isso, sua confiança começa a abalar.
Prova não é o mesmo que uma política guardada em uma pasta de governança. Os órgãos reguladores querem algo mais específico do que isso.
Para um cliente e uma decisão específicos, as empresas precisam demonstrar:
- Qual registro foi considerado confiável e por que foi utilizado para uma decisão específica
- De onde vieram os dados e quem era o proprietário
- Quais dados e controles serviram de base para a decisão e quem aprovou eventuais exceções
A maioria das equipes de conformidade consegue descrever seus processos em detalhes. Mas poucas conseguem apresentar essas evidências de forma rápida, para um cliente específico, uma decisão específica e um momento específico.
Ter uma política não é o mesmo que ser capaz de demonstrar que ela foi aplicada de forma consistente, e é nessa diferença que muitas empresas do setor BFSI são pegas de surpresa. As regras estão em vigor, mas elas não têm uma maneira rápida e defensável de mostrar que as seguem.
Aqui está uma maneira simples de testar se sua empresa consegue apresentar essas evidências de forma rápida e consistente.
Os dados dos seus clientes resistem a uma análise regulatória?
Se um órgão regulador solicitasse provas sobre um cliente e uma decisão, sua equipe conseguiria responder em questão de minutos, ou você passaria semanas procurando esse cliente em sistemas que nunca foram projetados para se comunicarem entre si, reconciliando nomes e endereços que não coincidem antes mesmo de poder começar?
Responder rapidamente depende de dois fatores:
- Uma versão confiável desse cliente, em vez de várias versões conflitantes
- Um rastro visível que mostre de onde os dados vieram e quem os aprovou
Muitas empresas ainda enfrentam dificuldades para produzir ambos de forma rápida e consistente, especialmente quando os dados de apoio estão espalhados por vários sistemas.
O que os órgãos reguladores estão exigindo atualmente?
Diferentes estruturas regulatórias impõem obrigações distintas às empresas do setor BFSI, mas várias delas compartilham uma ênfase crescente em governança, prestação de contas e evidências comprováveis.
- O “Consumer Duty” e a FCA, que exigem que as empresas avaliem, compreendam e comprovem os resultados obtidos pelos clientes de varejo
- O GDPR, que exige que as empresas compreendam quais dados pessoais mantêm, por que são processados, por quanto tempo devem ser retidos e como os direitos individuais são garantidos
- A DORA, que exige que as empresas financeiras fortaleçam a gestão de riscos de TIC, a resiliência operacional e a supervisão de fornecedores de tecnologia críticos
- A Lei de IA da UE, que introduz obrigações de governança, transparência e gestão de riscos para determinados sistemas de IA utilizados em serviços financeiros.
Nada disso é novidade. O que mudou foi o nível de detalhamento que os reguladores esperam receber quando solicitado.
Quando esse órgão regulador aponta para um cliente e solicita a justificativa por trás de uma decisão, você deve ser capaz de relacionar o resultado aos dados, controles e aprovações que o sustentaram.
Como sistemas desconectados criam pontos cegos de conformidade para empresas do setor BFSI?
Cada sistema em uma empresa do setor BFSI captura dados de clientes para uma finalidade comercial diferente.
Por exemplo, uma plataforma bancária central pode registrar uma conta, um CRM pode registrar um relacionamento, um sistema de administração de apólices pode registrar um contrato e uma plataforma de sinistros pode registrar um evento ou prejuízo. Cada um deles atualiza sua própria versão de acordo com seu próprio cronograma, utilizando o que quer que o cliente ou colega tenha digitado naquele momento.
Ao longo de meses e anos, esses registros vão se distanciando uns dos outros. Nada os obriga a estarem em conformidade entre si, e nada indica a quem se deve confiar.
O resultado pode ser várias versões da mesma pessoa ou organização, com endereços, identificadores, funções e relacionamentos diferentes, espalhadas por sistemas que nunca foram projetados para reconciliá-las.
O que dá errado durante uma atualização do KYC, por exemplo?
- O sistema bancário central lista um endereço de três anos atrás
- O CRM tem um endereço mais recente
- A plataforma de integração indica uma pessoa jurídica diferente para o mesmo beneficiário efetivo, porque um formulário foi preenchido por outra pessoa em um momento diferente do relacionamento
Cada registro pode ter sido válido em seu contexto original, mas, juntos, eles apresentam um quadro contraditório e incompleto. Antes que a revisão possa começar, a equipe deve determinar se os registros se referem à mesma parte, qual fonte está atualizada e em quais informações se deve confiar.
É nesse momento que você não consegue mais responder a um órgão regulador em questão de minutos.
Por que a IA torna os dados fracos de clientes um risco de conformidade ainda maior?
Um modelo de IA trata qualquer registro de cliente que recebe como um fato. Ele toma uma decisão em milissegundos, seja essa decisão:
- Uma linha de crédito
- Uma aprovação de cadastro
- Uma verificação de adequação
- Um alerta de fraude
- Uma decisão sobre sinistros
- Um encaminhamento para análise de risco
- Uma avaliação de vulnerabilidade do cliente
A menos que registros conflitantes ou desatualizados sejam identificados e tratados na fase inicial, eles podem ser processados com a mesma confiança aparente que os dados confiáveis. Um registro não confiável pode, portanto, influenciar decisões rapidamente e em grande escala.
Cada vez mais, as empresas devem ser capazes de explicar não apenas como um modelo se comportou, mas também quais dados fundamentaram seus resultados, de onde esses dados vieram e quais controles foram aplicados.
- Erros manuais podem permanecer isolados ou ser detectados caso a caso
- Processos automatizados podem repetir o mesmo problema de dados em uma população muito maior
O teste que mencionei anteriormente também se aplica aqui. Mas, neste caso, o problema ocorre na velocidade da máquina. Uma empresa que não conseguia dar uma resposta a um cliente em questão de minutos agora tem um modelo repetindo essa mesma decisão não comprovada para milhares de clientes antes que alguém perceba.
Por que políticas de conformidade robustas ainda podem ser difíceis de comprovar?
Muitas empresas do setor BFSI já possuem políticas detalhadas, estruturas de governança de dados e controles documentados.
O problema surge quando chega a hora de comprovar que a política foi seguida:
- Para um cliente
- Em um determinado dia
- Para uma decisão
O verdadeiro teste é verificar se os dados, controles e aprovações por trás de uma decisão foram registrados e estavam disponíveis no momento em que alguém os solicitou. A maioria das empresas verifica se as políticas e os controles existem, mas pode estar menos preparada para testar com que rapidez as evidências de apoio podem ser reunidas para um cliente ou uma decisão reais.
E esse é o verdadeiro desafio.
Uma pesquisa recente da McKinsey sobre a preparação de dados para IA chega a uma conclusão semelhante do ponto de vista técnico: a IA não reduz os padrões de qualidade dos dados, mas aumenta o custo e a velocidade com que erros podem ocorrer. A mesma pesquisa constatou que apenas 7% das empresas implementaram a IA em toda a organização. Em grande parte porque os dados subjacentes não estavam prontos para dar suporte a isso.
Como as empresas do setor BFSI podem facilitar a apresentação de evidências de conformidade
A solução começa com o tratamento dos dados confiáveis de clientes e terceiros como uma infraestrutura compartilhada.
O Customer Experience Data Cloud, a solução de dados de clientes desenvolvida com base no STEP, a plataforma de inteligência confiável da Stibo Systems, oferece às empresas do setor BFSI uma base de dados mestres regulamentada que pode ajudá-las a conectar identidades, aplicar regras transparentes e manter evidências de como os registros confiáveis foram criados. A solução:
- Aplica regras transparentes de correspondência e sobrevivência, ajudando as empresas a entender por que os registros foram vinculados e quais valores foram selecionados
- Rastreia a linhagem, mostrando de onde cada dado do cliente veio e quando foi alterado pela última vez
- Gerencia relações e hierarquias entre clientes, contas, apólices, organizações, corretores e partes relacionadas
- Oferece suporte a fluxos de trabalho de gestão e exceções, para que decisões importantes sobre identidade possam ser revisadas, em vez de permanecerem ocultas na lógica do sistema
Empresas como a Royal London já administram seus dados de clientes dessa forma. Aquelas que passam no teste de um órgão regulador conseguem responder instantaneamente, sempre que a pergunta for feita, independentemente da quantidade de documentação que haja em uma pasta.
Perguntas Frequentes
Qual é a diferença entre um CRM, um data lake e uma camada de identidade governada para fins de conformidade?
Um CRM registra interações com um cliente. Um data lake armazena e analisa dados brutos. Nenhum deles é projetado para decidir qual versão de um registro de cliente está correta, ou para tornar essa decisão explicável, que é o que uma camada de identidade governada é projetada para fazer.
Quando o Regulamento de IA da UE se aplica às empresas de BFSI que usam IA nas decisões dos clientes?
O Regulamento de IA da UE entra em plena aplicação em agosto de 2026, com obrigações específicas para sistemas de IA de alto risco, que abrangem muitas decisões de crédito, integração, reivindicações e subscrição impulsionadas por IA no setor BFSI.
Uma camada de identidade governada substitui a necessidade de um programa de governança de dados?
Não. Isso dá a um programa de governança algo para impor. A política define as regras; a camada de identidade é o que torna essas regras verificáveis em relação a um registro real de cliente.
Uma empresa pode estar em conformidade no papel, mas ainda assim falhar em uma auditoria de IA?
Sim, e isso está se tornando uma das lacunas mais comuns que os reguladores estão encontrando. Política documentada mostra a intenção. Uma auditoria de IA testa se os dados por trás de uma decisão real correspondem a essa intenção, o que é uma questão completamente diferente.
O que acontece com os dados de clientes legados criados antes da aplicação das regras atuais?
Os dados legados não têm isenção. Se ainda alimenta uma decisão do cliente hoje, um regulador ainda pode pedir provas a respeito, independentemente de quando o registro foi originalmente criado.
Com que frequência uma empresa deve testar se pode produzir essa evidência?
Não há um intervalo regulatório fixo, mas as empresas líderes tratam isso como um exercício de incêndio, realizando o teste internamente em um cenário real de cliente em vez de esperar que um regulador o faça primeiro.
