Juntar todos os dados do cliente não é o projeto. Decidir qual contexto muda uma ação é

A primeira pergunta é qual decisão vai mudar de comportamento: priorizar quem atender primeiro, personalizar uma oferta, antecipar um cancelamento, definir limite de crédito.

Cada uma dessas decisões exige um subconjunto pequeno e identificável de dados. Priorizar atendimento pede histórico de chamados e valor do contrato; antecipar cancelamento pede sinais de uso e prazo de renovação.

Consolidar tudo antes de saber para quê produz um repositório caro, com governança pesada e sem consumidor definido. O projeto entrega volume e não entrega decisão.

Começar pela ação também torna o resultado verificável. Existe um indicador que deveria mudar, um prazo para observar a mudança e um responsável por ela, o que raramente acontece em projetos definidos como consolidação de bases.

O mesmo cliente aparece com CNPJ em um sistema, e-mail pessoal em outro, telefone antigo no terceiro e razão social desatualizada no quarto. Nenhum desses registros está errado isoladamente.

Sem resolução de identidade — a regra que determina quando dois registros são a mesma entidade —, a visão consolidada é a soma de quatro visões parciais com duplicidade embutida.

Definir a chave de identificação e o critério de sobrevivência do registro, isto é, qual valor prevalece quando dois sistemas discordam, precisa vir antes de qualquer integração técnica.

Considere uma empresa que atende o mesmo grupo econômico por três contratos distintos. Sem uma regra explícita de hierarquia entre matriz e filiais, a mesma informação de risco pode aparecer duplicada em um relatório e ausente em outro.

A regra de identidade precisa ser documentada e versionada, porque ela muda quando novos sistemas entram. Alterar o critério sem registro invalida silenciosamente comparações históricas já apresentadas à diretoria.

Base legal, finalidade declarada e prazo de retenção determinam o que pode ser combinado com o quê. Essa não é uma checagem final: é uma restrição de arquitetura.

Dado coletado para uma finalidade não migra livremente para outra. A LGPD organiza o tratamento em torno de princípios, bases legais e um regime mais estrito para dados sensíveis, e o desenho da base precisa refletir isso.

Tratar o tema no início evita refazer a integração depois, quando descobrir que um atributo central não pode alimentar a ação que justificou o projeto.

Na prática, isso significa marcar cada atributo com sua finalidade de coleta e permitir que a arquitetura recuse combinações incompatíveis. Controle aplicado no dado é mais confiável do que política escrita e verificada por amostragem.

Campo preenchido há três anos é pior que campo vazio, porque produz confiança indevida. O vazio sinaliza ausência; o desatualizado se apresenta como informação.

Cada atributo tem uma validade diferente: razão social muda pouco, contato muda com rotatividade, faturamento muda todo mês. Tratar todos com a mesma regra de atualização é ignorar essa diferença.

Definir a validade por atributo e o que acontece quando ela expira — sinalizar, ocultar ou bloquear o uso — é o que separa uma base confiável de um cadastro grande.

A consequência operacional é direta: uma equipe comercial que descobre três contatos inválidos em uma lista deixa de confiar na lista inteira, inclusive na parte correta. Confiança em base de dados se perde por evidência anedótica e demora para voltar.