O que são dados não sensíveis

A LGPD não define “dados não sensíveis” de forma direta. A classificação emerge por exclusão: são todos os dados pessoais que não se enquadram nas categorias especiais listadas no art. 5º, inciso II, e disciplinadas pelo art. 11 da lei. Se o dado não revela origem racial ou étnica, convicção religiosa, opinião política, filiação sindical, condição de saúde, vida sexual, dado genético ou biométrico, ele é tratado como dado comum, ou não sensível.

Na prática cotidiana de CX e CDP, os dados não sensíveis são a matéria-prima principal: nome completo, endereço de e-mail, número de telefone, CPF, data de nascimento, histórico de compras, páginas visitadas, itens adicionados ao carrinho, canais de atendimento utilizados e preferências declaradas em formulários. São esses dados que alimentam a maior parte dos modelos de segmentação, scoring e personalização.

O erro mais comum das equipes é concluir que, por não serem sensíveis, esses dados podem ser coletados, armazenados e compartilhados sem restrições. A ausência de sensibilidade reduz alguns requisitos específicos, como a exigência de consentimento explícito prevista no art. 11, mas não elimina a obrigação de ter uma base legal válida, definir finalidade, garantir segurança e respeitar os direitos do titular.

Diferença entre dados sensíveis e não sensíveis na LGPD

O art. 5º, inciso II da LGPD lista taxativamente as categorias sensíveis: origem racial ou étnica, convicção religiosa, opinião política, filiação a sindicato ou organização de caráter religioso, filosófico ou político, dado referente à saúde ou à vida sexual, dado genético ou biométrico. A lista é fechada. Se o dado não aparece nela, é classificado como comum.

O tratamento de dados sensíveis exige fundamento legal mais restrito: consentimento específico e destacado, ou hipóteses específicas do art. 11, como proteção da vida, tutela da saúde, prevenção à fraude ou cumprimento de obrigação legal. Para dados não sensíveis, o leque de bases legais é mais amplo e inclui legítimo interesse, execução de contrato e cumprimento de obrigação legal, entre outras previstas no art. 7º.

A fronteira tênue: dados derivados e combinados

A separação entre sensível e não sensível pode se dissolver quando múltiplos dados comuns são cruzados. Um CEP combinado com frequência de compras em farmácias e histórico de buscas pode revelar, por inferência, uma condição de saúde. Uma sequência de compras em lojas de artigos religiosos, associada ao bairro de residência, pode indicar convicção religiosa. Esses dados derivados, não coletados como sensíveis mas que se tornam sensíveis pela combinação, exigem atenção específica.

A ANPD ainda não produziu regulamentação específica sobre dados derivados, mas a doutrina majoritária e guias de proteção de dados europeus (que influenciam a interpretação brasileira) indicam que o resultado do cruzamento deve ser classificado conforme sua natureza, não conforme a origem dos dados brutos. Isso significa que o processo de enriquecimento de perfis em um CDP pode, inadvertidamente, gerar dados sensíveis a partir de fontes não sensíveis.

Como dados não sensíveis são usados em CDP e CRM

Em plataformas de CDP que operam com resolução de identidade e unificação de perfis, dados não sensíveis são o núcleo dos golden records. Nome, e-mail, telefone e identificadores de dispositivo são usados para resolver identidades entre canais distintos, sem necessidade de consentimento reforçado, desde que haja base legal adequada para cada finalidade de tratamento.

Em CRM, o histórico transacional (datas de compra, valores, categorias de produto, canais utilizados) alimenta modelos de RFM (Recência, Frequência, Valor Monetário) e scoring de propensão. Esses modelos são construídos inteiramente sobre dados não sensíveis e sustentam decisões de comunicação, oferta e retenção sem tocar em categorias especiais.

Personalização com dados declarados e inferidos

Preferências declaradas, aquelas que o próprio usuário informa em formulários, centrais de preferência ou onboarding, têm tratamento mais simples do ponto de vista jurídico: a finalidade é clara e o dado veio diretamente do titular. Já as preferências inferidas, derivadas de comportamento de navegação ou histórico de compras, exigem maior cuidado com transparência e com os limites da finalidade original de coleta.

Um dado de navegação coletado para melhorar a experiência de um e-commerce não pode ser reutilizado livremente para segmentação em canais de terceiros sem avaliação de compatibilidade de finalidade, mesmo sendo um dado não sensível.

Risco de re-identificação

Quanto mais fontes de dados não sensíveis são cruzadas, maior o risco de re-identificação de um titular que, em cada fonte isolada, seria anônimo. Um identificador de dispositivo, combinado com localização aproximada e padrão de horário de acesso, pode ser suficiente para identificar uma pessoa específica. Equipes de dados precisam avaliar esse risco antes de ampliar o escopo de cruzamento em projetos de enriquecimento de perfil.

Boas práticas de governança para dados não sensíveis

Mapeamento no ROPA

O Registro de Operações de Tratamento (ROPA) não é exclusivo para dados sensíveis. Todas as operações de tratamento de dados pessoais devem constar no mapeamento, incluindo as que lidam apenas com nome, e-mail e histórico de compras. O ROPA é a base para qualquer resposta a auditoria da ANPD e para a gestão interna de riscos.

Finalidade, necessidade e proporcionalidade

Antes de iniciar qualquer coleta, a equipe deve responder três perguntas: para qual finalidade específica esse dado será usado? Esse dado é necessário para atingir essa finalidade, ou um dado menos intrusivo resolveria? A quantidade de dados coletados é proporcional ao objetivo? Esse exercício, previsto implicitamente nos princípios do art. 6º da LGPD, evita o acúmulo de dados sem propósito, prática que aumenta o risco e o custo de conformidade.

Políticas de retenção e descarte

Dados não sensíveis também envelhecem. Um e-mail desatualizado, um telefone que mudou de titular ou um endereço antigo não apenas perdem utilidade: podem gerar problemas operacionais e de comunicação. Políticas de retenção devem estabelecer prazos máximos de armazenamento por tipo de dado e por finalidade, com rotinas automatizadas de revisão e descarte.

Treinamento de equipes

Um dos maiores vetores de risco em operações de dados não é a tecnologia, é a percepção equivocada de que dados não sensíveis são “dados livres”. Equipes de marketing, produto e vendas frequentemente operam com essa premissa. Treinamentos periódicos, com exemplos concretos do setor e não apenas conceitos jurídicos abstratos, ajudam a mudar esse comportamento.

Riscos e armadilhas comuns no mercado brasileiro

Inferência de categorias sensíveis

O exemplo mais citado na literatura técnica é o CEP. Em cidades brasileiras com alta segregação socioeconômica e étnica, o código postal pode funcionar como proxy de origem racial ou de condição de saúde quando combinado com outros dados comportamentais. Modelos de machine learning treinados sobre dados não sensíveis podem produzir segmentações que discriminam grupos protegidos sem que a equipe perceba, e sem que nenhum dado sensível tenha sido coletado explicitamente.

Compartilhamento com terceiros sem cláusulas adequadas

É comum no mercado brasileiro que dados de clientes, como e-mails, telefones e histórico de navegação, sejam compartilhados com parceiros de mídia, plataformas de anúncios e fornecedores de enriquecimento sem contratos que estabeleçam obrigações claras de tratamento. O fato de os dados não serem sensíveis não afasta a exigência de instrumentos contratuais que delimitem finalidade, proíbam uso secundário e garantam segurança.

Confundir anonimização com pseudonimização

Dados pseudonimizados, substituídos por identificadores artificiais mas ainda reversíveis, continuam sendo dados pessoais sob a LGPD. Dados verdadeiramente anonimizados, que não permitem re-identificação por meios razoáveis, saem do escopo da lei. A confusão entre os dois conceitos gera uma falsa sensação de segurança: equipes operam com a crença de que “os dados estão anonimizados” quando, na prática, qualquer cruzamento com a tabela de chaves reverte a pseudonimização.

Fiscalização da ANPD

A ANPD já instaurou processos administrativos e emitiu notificações envolvendo tratamentos de dados não sensíveis. Casos relacionados a compartilhamento indevido de dados cadastrais, ausência de base legal para e-mail marketing e retenção excessiva de dados de clientes inativos aparecem na agenda regulatória. A percepção de que a autoridade foca apenas em vazamentos de dados sensíveis não corresponde à realidade da fiscalização atual.

O que sua equipe precisa saber antes de usar esses dados

Checklist rápido

Antes de qualquer novo uso de dados não sensíveis em campanhas, integrações ou modelos analíticos, aplique estas três verificações:

• Finalidade definida: o uso está descrito de forma específica, não genérica como “melhorar a experiência do cliente”?
• Base legal identificada: qual dos incisos do art. 7º da LGPD sustenta esse tratamento? Está documentado?
• Retenção estabelecida: há um prazo definido para descarte ou revisão desses dados após o encerramento da finalidade?

Quando escalar para o DPO ou área jurídica

Mesmo tratando exclusivamente dados não sensíveis, alguns cenários exigem envolvimento do DPO ou da área jurídica: cruzamento de múltiplas bases que possa gerar dados derivados sensíveis, compartilhamento com terceiros em jurisdições estrangeiras, uso de dados para decisões automatizadas com efeitos significativos sobre o titular, e qualquer situação em que a base legal seja legítimo interesse, que exige o balancing test documentado.

Próximos passos: integrando essa classificação à rotina de CDP e CRM

O ponto de partida prático é revisar o ROPA existente e garantir que cada campo de dado coletado pelo CDP ou CRM esteja classificado, com finalidade e base legal associadas. Ferramentas de data catalog e de governança de dados, sejam parte de suítes maiores ou soluções independentes, permitem atribuir metadados de classificação diretamente aos atributos de perfil.

O passo seguinte é estabelecer um processo de avaliação de novos casos de uso antes da implementação: toda nova segmentação, novo enriquecimento ou nova integração com terceiros deve passar por uma verificação mínima de finalidade e base legal. Esse processo não precisa ser burocrático. Um formulário simples revisado pelo DPO resolve a maior parte dos casos em menos de 48 horas.

Por fim, inclua a classificação de dados na documentação técnica de pipelines e modelos analíticos. Quando um engenheiro de dados ou analista de CRM consegue ver, no próprio repositório de código ou na interface da plataforma, que um campo é classificado como “dado pessoal comum — base legal: execução de contrato — retenção: 24 meses”, a conformidade deixa de depender de memória individual e passa a ser parte da operação.