O que é data retention e por que importa

Data retention, ou retenção de dados, é a prática de armazenar categorias específicas de dados por períodos predefinidos antes de descartá-los, anonimizá-los ou movê-los para arquivamento de longo prazo. Não se trata apenas de guardar informação: trata-se de guardar a informação certa, pelo tempo certo, com propósito documentado.

Dentro desse ciclo, dois estados precisam ser distinguidos. A retenção ativa cobre dados em uso operacional, consultados por sistemas, campanhas ou equipes com frequência. O arquivamento cobre dados sem uso imediato que precisam ser preservados por obrigação legal ou para auditorias futuras. Os controles de acesso, os custos de infraestrutura e as ferramentas de busca aplicáveis a cada estado são diferentes.

Organizações que não formalizam uma política de retenção acabam tomando decisões ad hoc: times de TI que nunca deletam nada “por segurança”, áreas de negócio que mantêm planilhas com dados de clientes inativos há anos, integrações que acumulam logs sem nenhum processo de expurgo. O resultado é um ambiente difícil de auditar e caro de manter.

As consequências práticas são concretas: exposição ampliada em caso de incidente de segurança (quanto mais dado retido desnecessariamente, maior o impacto de um vazamento), risco de multas regulatórias sob a LGPD e legislações setoriais, e custos crescentes de armazenamento sem retorno proporcional para o negócio.

Períodos de retenção: como são definidos

O prazo de retenção de qualquer categoria de dado é determinado por três fatores combinados: obrigação legal aplicável, necessidade de negócio demonstrável e sensibilidade do dado. Quando os três fatores apontam para prazos diferentes, prevalece o mais restritivo que ainda atenda à obrigação legal.

Obrigações legais no Brasil

O cenário regulatório brasileiro impõe prazos específicos para diversas categorias. Registros trabalhistas devem ser mantidos por ao menos 5 anos após o término do vínculo (prazo prescricional trabalhista). Documentos fiscais ficam sujeitos a guarda de 5 anos pelo Código Tributário Nacional, podendo chegar a 10 anos dependendo do tributo e da esfera (federal, estadual, municipal). Instituições financeiras têm obrigações próprias pelo Banco Central, incluindo registros de transações e KYC por períodos que variam de 5 a 10 anos conforme a instrução normativa aplicável.

A LGPD não define prazos fixos por categoria, mas estabelece que os dados só podem ser tratados pelo período necessário para atingir a finalidade declarada ou para cumprimento de obrigação legal. “Fins comerciais” como justificativa genérica de retenção não é suficiente: a organização precisa articular qual finalidade específica justifica manter aquele dado naquele momento.

Categorização por classes de dado

Uma abordagem prática é agrupar dados em classes com prazos distintos na tabela de retenção. Um exemplo de estrutura:

• Dados cadastrais de clientes ativos: enquanto durar o relacionamento + prazo prescricional aplicável ao contrato
• Dados de clientes inativos (sem compra/interação): 12 a 24 meses após inatividade, salvo obrigação legal específica
• Logs de acesso a sistemas: 6 a 12 meses para fins de segurança operacional; até 5 anos se houver investigação pendente
• Registros financeiros e fiscais: 5 a 10 anos conforme legislação aplicável
• Dados de candidatos não contratados: 6 a 12 meses após o processo seletivo, salvo consentimento para oportunidades futuras

A granularidade da categorização depende do volume e da diversidade dos dados tratados. Empresas com operações simples podem trabalhar com 5 a 8 classes; organizações com múltiplos produtos financeiros ou de saúde podem precisar de dezenas de categorias distintas.

Estrutura de uma política de retenção de dados

Uma política de retenção funcional tem componentes mínimos que não podem ser omitidos: escopo (quais dados e sistemas estão cobertos), inventário de dados atualizado, tabela de prazos por categoria, responsáveis pela execução e pelo monitoramento, e procedimento documentado de descarte.

Mapeando o ciclo de vida do dado

Cada categoria de dado deve ter seu ciclo de vida mapeado em quatro etapas: coleta (onde e como o dado entra na organização), uso ativo (quais sistemas e processos o consomem), arquivamento (se aplicável, quando e onde é movido para armazenamento frio) e eliminação (método e evidência de execução).

Esse mapeamento revela pontos cegos que passariam despercebidos. É comum descobrir, durante esse exercício, que dados coletados por um formulário de landing page estão sendo replicados para três sistemas diferentes, sem que nenhum deles gerencie o ciclo de vida de forma coordenada.

Integração com o ROPA

A LGPD recomenda que controladores mantenham um Registro de Operações de Tratamento (ROPA), equivalente ao Records of Processing Activities do GDPR europeu. A política de retenção deve ser integrada ao ROPA: cada operação de tratamento listada precisa ter o prazo de retenção correspondente e a base legal associada. Isso elimina redundância documental e facilita auditorias, pois o DPO encontra tudo em um único ponto de referência.

Revisão periódica

A frequência mínima recomendada para revisão da política é anual. Há gatilhos, porém, que exigem revisão imediata independente do calendário: entrada de um novo produto ou serviço que trata categorias de dados ainda não mapeadas, mudança na legislação aplicável, aquisição de empresa ou migração de sistema, e qualquer incidente de segurança que exponha fragilidades no ciclo de vida dos dados.

Descarte e eliminação de dados ao fim do prazo

Quando o período de retenção expira, a organização tem três caminhos: eliminação definitiva, anonimização ou arquivamento de longo prazo com acesso restrito. A escolha depende da base legal original do tratamento e do uso futuro pretendido para o dado.

Deletar versus anonimizar

A LGPD trata dados anonimizados como fora do seu escopo, desde que o processo de anonimização seja irreversível com os meios técnicos disponíveis. Isso abre a possibilidade de manter dados anonimizados para análise estatística ou treinamento de modelos mesmo após o prazo de retenção original. O ponto crítico é garantir que a anonimização seja real: pseudonimização (dado com identificador substituído mas recuperável) não equivale a anonimização perante a lei.

A exclusão definitiva é o caminho mais simples para dados sem valor analítico remanescente. Para dados em mídia física, como fitas de backup, discos rígidos e pen drives, a exclusão lógica não é suficiente; é necessária sobrescrita certificada ou destruição física da mídia. Fornecedores especializados emitem certificado de descarte seguro, documento que deve ser arquivado como evidência do cumprimento da política.

Exceções por litígio ou investigação

Quando há investigação regulatória em andamento, processo judicial ou expectativa razoável de litígio, a organização pode precisar preservar dados além do prazo normal — o chamado legal hold. Essa exceção precisa ser documentada formalmente: quem autorizou, qual o escopo dos dados preservados, qual o prazo da exceção e quem é o responsável pelo monitoramento. Sem documentação, a preservação extra pode ser interpretada como retenção sem base legal em vez de exceção justificada.

Data retention em contextos de CDP e CRM

Plataformas de dados de clientes (CDPs) e sistemas de CRM têm uma característica que as torna particularmente problemáticas sob a ótica de retenção: são projetadas para acumular e enriquecer perfis continuamente. A lógica de negócio favorece ter mais dados; a lógica de privacidade e qualidade favorece ter apenas os dados relevantes e atualizados.

Retenção excessiva nessas plataformas não é apenas um problema legal — é um problema de qualidade. Perfis com dados de comportamento de 4 ou 5 anos atrás distorcem modelos de propensão e segmentação. Duplicatas geradas por múltiplas interações ao longo do tempo, sem processos de merge e purge adequados, inflam bases e reduzem a precisão das campanhas. Dados demográficos desatualizados levam a personalizações incorretas.

Configurando expiração diretamente nas plataformas

CDPs e CRMs modernos, independente do fornecedor, oferecem algum nível de configuração de expiração de atributos ou eventos. A abordagem recomendada é configurar TTL (time-to-live) diretamente nos atributos e tipos de evento dentro da plataforma, em vez de depender de processos manuais de limpeza executados periodicamente. Isso garante consistência e reduz o risco de esquecimento.

Para eventos comportamentais (cliques, visualizações, interações), prazos de 12 a 24 meses costumam ser suficientes para a maioria dos casos de uso de personalização. Para atributos de perfil com base em consentimento explícito, o prazo deve respeitar o escopo do consentimento coletado: se o usuário consentiu para uma campanha específica, os dados associados não devem sobreviver ao fim daquela campanha sem nova base legal.

Zero data retention em APIs de IA

Com a integração crescente de APIs de modelos de linguagem e IA generativa em fluxos de CRM e atendimento, surgiu uma preocupação específica: esses provedores retêm os dados enviados via API para treinar seus modelos? A resposta varia por provedor e por tipo de contrato.

Provedores enterprise de APIs de IA geralmente oferecem opções de zero data retention, em que os dados processados não são armazenados após a inferência. Esse regime normalmente requer contrato específico, pode ter custo adicional e precisa ser verificado periodicamente, pois termos de serviço mudam. A organização deve verificar em contrato, não assumir com base em declarações de marketing.

Erros comuns e como evitá-los

Guardar dados “por precaução” sem base legal

É o erro mais frequente e um dos mais arriscados sob a LGPD. A lógica de “pode ser útil no futuro” não constitui finalidade legítima para tratamento de dados pessoais. Cada categoria de dado retida precisa ter base legal identificada: consentimento, cumprimento de obrigação legal, legítimo interesse documentado em LIA (Legitimate Interest Assessment), entre outras. Dados sem base legal identificável devem ser eliminados.

Política copiada de template estrangeiro

Templates de políticas de retenção desenvolvidos para o GDPR europeu ou para regulações norte-americanas não se traduzem diretamente para o contexto brasileiro. Prazos prescricionais, obrigações fiscais e trabalhistas, e a forma como a LGPD trata certas bases legais têm especificidades que exigem adaptação por profissional com conhecimento da legislação brasileira aplicável ao setor da organização.

Ausência de automação

Políticas que dependem exclusivamente de execução manual, seja alguém lembrar de rodar um script de limpeza, revisar uma planilha mensalmente ou acionar o time de TI para deletar registros, inevitavelmente falham. A automação não precisa ser complexa: agendamentos de purge configurados diretamente nos sistemas, alertas quando dados atingem o prazo e relatórios de auditoria automáticos já reduzem significativamente o risco de inconsistência.

Não informar prazos de retenção na política de privacidade

A LGPD é explícita: o titular tem direito a informação sobre o período de retenção dos seus dados ou, quando não for possível definir um prazo fixo, os critérios usados para determinar esse período. Políticas de privacidade que omitem essa informação estão em desconformidade. O texto não precisa listar cada categoria em detalhe técnico, mas precisa ser suficientemente específico para que o titular compreenda por quanto tempo seus dados serão mantidos e por quê.

Como avaliar e dar os próximos passos

Uma forma prática de iniciar é conduzir uma auditoria simplificada respondendo quatro perguntas para cada sistema que trata dados pessoais: quais categorias de dados estão armazenadas aqui, desde quando, qual a base legal para cada categoria e existe um processo ativo de eliminação ao fim do prazo? Sistemas que não conseguem responder essas perguntas são o ponto de partida prioritário.

Com esse diagnóstico em mãos, o próximo passo é construir ou atualizar o inventário de dados (data inventory) e derivar a tabela de prazos a partir das obrigações legais identificadas. Envolva as áreas jurídica, de compliance e de TI desde o início: a tabela de prazos sem o braço técnico que vai implementar a automação de descarte fica como documento sem efeito prático.

Antes de publicar a política, valide-a com o DPO ou com assessoria jurídica especializada, certifique-se de que ela está refletida na política de privacidade pública e estabeleça um calendário de revisão. Data retention não é um projeto com fim — é um processo contínuo que acompanha a evolução do negócio e do ambiente regulatório.