Limitação de Armazenamento É a Fronteira de Fiscalização de 2026 para Analytics
Os reguladores pararam de perguntar se você coletou dados de forma lícita e passaram a perguntar quando você os apagou. Após a multa de €42M da CNIL contra a Free e a varredura de exclusão da EDPB, a retenção de analytics é o alvo da auditoria.
A pergunta cara do GDPR costumava ser você tem uma base legal para coletar isto. Em 2026 ela virou por que isto ainda está no seu banco de dados. Dois eventos de fiscalização tiraram a retenção de uma nota de rodapé documental e a colocaram na linha de frente, e os sistemas de analytics estão exatamente no raio de impacto.
Duas decisões que mudaram o alvo
Em 13 de janeiro de 2026, a CNIL multou a Free Mobile em €27 milhões e a Free em €15 milhões. A maior parte da cobertura focou na violação de 2024 que expôs 24 milhões de contratos de assinantes, mas a decisão também citou diretamente o Artigo 5(1)(e) — limitação de armazenamento. A Free Mobile havia mantido dados de 2,8 milhões de contratos cancelados há mais de dez anos sem justificativa. Os dados não foram coletados de forma ilícita. Eles foram mantidos de forma ilícita.
Um mês depois, a EDPB publicou os resultados de sua ação coordenada de fiscalização de 2025. Trinta e duas autoridades de proteção de dados auditaram 764 controladores em práticas de exclusão e encontraram duas falhas sistêmicas: ausência de classificação interna de dados e ausência de exclusão automatizada nos próprios sistemas de TI. Uma política de retenção documentada que nada faz cumprir tecnicamente foi tratada como fator agravante, não atenuante.
O sinal é inequívoco. Os reguladores agora presumem que a coleta aconteceu; eles auditam a exclusão.
Por que analytics é o lugar óbvio para olhar
A limitação de armazenamento sob o Artigo 5(1)(e) determina que dados pessoais não podem ser mantidos em forma identificável por mais tempo do que a finalidade exige. A maioria das stacks de analytics falha nisso silenciosamente.
Uma tabela de eventos típica armazena uma linha por interação vinculada a um identificador estável — um ID de cookie, um ID de dispositivo, um e-mail com hash — com um timestamp e sem expiração. O schema é projetado para guardar tudo para sempre, de modo que "talvez queiramos consultar isto depois" continue possível. Essa é exatamente a retenção por via das dúvidas que a CNIL penalizou.
O problema se agrava porque é o identificador que torna uma linha um dado pessoal. Enquanto user_id = a91f... puder ser relacionado de volta a uma pessoa ao longo de meses de eventos, cada uma dessas linhas está no escopo, cada uma está sujeita a pedidos de acesso e exclusão, e cada uma é um passivo em caso de violação. Retenção não é um custo de armazenamento. É exposição medida em tempo.
Minimização na escrita supera a exclusão na leitura
A correção durável não é um cron job melhor que poda linhas antigas. É um modelo de dados onde a forma identificável nunca persiste em primeiro lugar.
O modelo de identidade da Monoid é construído em torno disso. Um visitante é representado apenas por um hash diário:
SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)
O IP e o User-Agent brutos existem apenas na memória do Worker pelo tempo necessário para calcular esse hash; o D1 armazena o hash, nunca os valores brutos. Como a data é uma entrada, o hash do mesmo visitante muda toda meia-noite. Não existe identificador estável entre dias para reter, então o perfil entre sessões que a limitação de armazenamento visa não pode se acumular — não por política, mas por construção.
Isso é minimização de dados na escrita. Você não apaga a ligação depois porque nunca a escreveu. Um pedido de exclusão se torna trivial quando não há chave durável contra a qual apagar.
Retenção que você consegue de fato comprovar
A limitação de armazenamento ainda precisa de um limite externo, e um limite defensável é curto e aplicado, não longo e aspiracional. A Monoid mantém os dados de pageviews por no máximo 730 dias. Dois anos são um teto deliberado para análise de tendências, e o expurgo é uma operação real contra a tabela, não uma linha em um PDF de política. A conclusão da EDPB foi que políticas sem aplicação são a brecha que as investigações exploram; uma retenção que de fato é executada fecha essa brecha.
A combinação importa mais do que qualquer uma das metades. Hashes que giram diariamente significam que os dados já têm formato agregado antes mesmo de a retenção se aplicar. O expurgo de 730 dias significa que mesmo esse sinal agregado tem um fim rígido e demonstrável.
Como avaliar qualquer analytics do qual você depende
Seja qual for o analytics por trás do seu site, três verificações mapeiam diretamente o que os reguladores auditaram:
- Encontre cada campo que vincula um registro a uma pessoa ao longo do tempo. Um ID de usuário estável, um valor persistente de cookie, um IP bruto, um fingerprint. Cada um converte um log de eventos em um perfil retido — então pergunte se o analytics que você usa armazena algum deles, para começar.
- Pergunte quando a retenção é aplicada — na ingestão ou em uma revisão trimestral. A minimização que acontece à medida que os dados são escritos supera um job de exclusão que alguém precisa lembrar de rodar. A resposta mais forte é um modelo em que a forma identificável nunca foi armazenada em primeiro lugar.
- Pergunte se a exclusão é demonstrável. Se um fornecedor não consegue apontar um limite rígido de retenção que de fato é executado, ele tem uma política, não um controle — e a varredura da EDPB acabou de dizer qual dos dois é multado.
Os dados mais baratos de defender em uma auditoria são os dados que você nunca manteve em forma identificável. A limitação de armazenamento não é mais uma cláusula para parafrasear em uma política de privacidade; é o que a próxima investigação vai medir, e a arquitetura que responde a isso é aquela que nunca teve um perfil para apagar.
Comments
Loading comments…