Blockchain e LGPD: como conciliar permanência, correção e eliminação

Blockchain e LGPD começam pelo entendimento da tecnologia

Uma blockchain é um tipo de ledger distribuído. Em linguagem comum, ledger é um livro de registros. Ele é distribuído porque cópias ou partes desse histórico ficam em diferentes computadores, chamados nós, que seguem regras para validar novas transações e manter uma visão consistente. Os registros são agrupados em blocos, ligados criptograficamente aos blocos anteriores. Alterar uma informação já aceita tende a produzir uma inconsistência detectável pelas demais cópias.

Isso não significa que toda blockchain seja pública, anônima ou impossível de governar. Há redes públicas ou privadas, com participação aberta ou permissionada. Em uma rede permissionada, uma organização ou consórcio define quem pode ler, escrever ou validar. A escolha muda o nível de exposição, os atores envolvidos e a capacidade de aplicar controles.

Também é essencial separar dois ambientes:

On-chain: informação registrada na própria blockchain, como identificadores, valores da transação, eventos, referências e dados mantidos por smart contracts.
Off-chain: informação guardada fora da cadeia, por exemplo em banco de dados controlado, com apenas uma referência ou prova registrada na blockchain.

Um hash é um resultado criptográfico calculado a partir de uma informação. Ele pode funcionar como uma impressão digital para verificar se um arquivo mudou sem colocar o arquivo inteiro na cadeia. Mas hash não deve ser tratado automaticamente como dado anônimo. Se puder ser relacionado a uma pessoa por meios razoavelmente disponíveis, se houver acesso ao dado original ou a outras informações de ligação, ele pode continuar sendo dado pessoal. A análise também considera a previsibilidade do dado original e se a proteção usa um salt aleatório e suficientemente longo ou um mecanismo autenticado com chave secreta, como HMAC.

A chave pública e o endereço de carteira são elementos relacionados, mas distintos em muitas redes, nas quais o endereço pode ser derivado da chave pública. Ambos podem constituir dados pessoais quando associados direta ou indiretamente a uma pessoa. Essa distinção é relevante em projetos de blockchain e LGPD. Já um smart contract é um programa que executa ações previamente definidas quando certas condições são atendidas. Ele pode automatizar pagamentos, validações ou liberações, mas sua execução também pode registrar novos dados e, em certos casos, produzir decisões automatizadas com efeitos sobre pessoas.

Onde está o conflito entre permanência e direitos

No debate sobre blockchain e LGPD, o valor empresarial da tecnologia costuma estar na integridade do histórico: participantes conseguem detectar alterações e conferir a sequência de transações. O problema aparece quando o mesmo mecanismo recebe dado pessoal incorreto, excessivo ou que deveria deixar de ser tratado. O registro pode estar replicado em muitos nós e não ter uma função simples de exclusão individual.

As diretrizes do EDPB são claras ao afirmar que uma escolha técnica não justifica o descumprimento de direitos. Também alertam que uma transação corretiva nem sempre apaga a anterior. É possível registrar um novo evento informando que o dado anterior foi cancelado ou corrigido, mas a informação original pode continuar visível no histórico. Para alguns dados contábeis ou estados de ativos, essa lógica pode ser útil. Para dado pessoal prejudicial, desatualizado ou sem finalidade vigente, ela pode ser insuficiente.

Por isso, blockchain e LGPD não devem ser tratadas como um debate abstrato sobre “imutabilidade versus privacidade”. A análise deve identificar cada elemento: metadado, conteúdo da transação, endereço, log, dado mantido por smart contract, referência externa, endereço IP e informação armazenada fora da cadeia. O tratamento só pode ser avaliado quando o fluxo completo está visível.

A primeira pergunta é se blockchain é necessária

Antes de escolher plataforma, fornecedor ou protocolo, a empresa deve documentar por que um banco de dados convencional, um registro assinado digitalmente ou outra solução com controle central não atenderia à finalidade. A análise de blockchain e LGPD começa por essa justificativa. Segundo o EDPB, a necessidade da tecnologia deve ser avaliada previamente, considerando alternativas e riscos.

Perguntas úteis para a decisão:

Há participantes independentes que realmente precisam compartilhar e validar o mesmo histórico?
A detecção de alterações é essencial ao caso de uso ou apenas desejável?
Uma rede privada e permissionada atende ao objetivo?
O projeto funcionaria com dados pessoais fora da cadeia?
A finalidade exige publicidade ou a exposição pode ser limitada?
Existe uma solução menos invasiva que entregue o mesmo resultado?
Como o sistema atenderá correção, oposição, acesso e eliminação quando cabíveis?

Se o principal motivo for tendência de mercado, marketing ou promessa genérica de confiança, a justificativa é fraca. A adoção deve responder a uma necessidade concreta. Essa etapa é central para uma estratégia de blockchain e LGPD porque evita criar permanência sem benefício proporcional.

Minimização: mantenha dados pessoais off-chain quando possível

A recomendação prática mais importante do EDPB é armazenar fora da cadeia os dados pessoais adicionais, além dos identificadores que já possam existir nos metadados da transação. Para empresas brasileiras, a mesma escolha ajuda a aplicar necessidade, segurança, qualidade e retenção de forma controlável.

Em uma arquitetura off-chain, o dado pessoal fica em ambiente com controle de acesso, prazo de retenção, versionamento e exclusão. Na blockchain pode permanecer uma referência, um compromisso criptográfico ou um hash com proteção adequada, quando isso for necessário para demonstrar integridade. Em blockchain e LGPD, a empresa ainda precisa avaliar se o elemento on-chain permite identificar alguém e se as informações mantidas fora da cadeia podem restabelecer o vínculo.

Criptografia não resolve tudo. Dados cifrados continuam exigindo governança de chaves, atualização de algoritmos e análise sobre o tempo durante o qual precisam permanecer protegidos. Apagar uma chave pode tornar a leitura impraticável em determinado contexto, mas a eficácia depende da arquitetura, das cópias existentes, da robustez criptográfica e da possibilidade de futura quebra do algoritmo. Da mesma forma, um hash simples pode permitir testes e reidentificação quando o universo de valores é previsível. Salt aleatório e suficientemente longo e mecanismos como HMAC respondem a riscos diferentes e devem ser avaliados conforme o caso.

Para reduzir risco em blockchain e LGPD, a equipe deve minimizar:

a quantidade de dados na cadeia e fora dela;
o número de participantes com acesso;
a publicidade dos metadados;
o tempo de retenção das bases auxiliares;
os vínculos entre endereços e identidades;
os logs técnicos que revelam IP, dispositivo ou comportamento;
os dados usados e gerados por smart contracts.

Papéis e governança não desaparecem em uma rede distribuída

Descentralização técnica não significa ausência de responsabilidade. Em blockchain e LGPD, é necessário avaliar quem determina a finalidade e os meios essenciais, quem opera nós, quem desenvolve a aplicação, quem administra permissões, quem guarda dados off-chain e quem atende titulares. Os papéis dependem dos fatos e do poder real de decisão, não apenas do nome usado no contrato.

Em uma rede privada, a organização líder ou o consórcio pode definir regras, formatos, participantes e atualizações. Em uma rede pública, a análise pode ser mais complexa, pois validadores, desenvolvedores, aplicações, carteiras e outros atores exercem funções diferentes. O EDPB recomenda examinar governança, relações entre participantes e influência sobre o tratamento. No Brasil, essa análise deve ser traduzida para os papéis e obrigações da LGPD conforme o caso concreto.

Um modelo mínimo de governança para blockchain e LGPD deve registrar:

finalidade e base legal avaliada para cada operação;
responsáveis por decisões de arquitetura e privacidade;
regras de entrada, saída e identificação de participantes;
procedimentos para mudanças de software e protocolo;
gestão de chaves, vulnerabilidades e incidentes;
regras para correção, oposição, acesso e eliminação;
retenção de dados on-chain, off-chain e backups;
auditoria, trilhas de decisão e revisão periódica.

Contrato ajuda, mas não corrige desenho inviável. Se nenhum participante consegue executar um pedido ou limitar a exposição, atribuir a obrigação no papel não basta.

Transferências internacionais e localização dos nós

Uma blockchain pode replicar ou tornar dados acessíveis em diferentes países. Esse aspecto de blockchain e LGPD precisa entrar no mapa de dados. Em redes públicas, a empresa talvez nem escolha todos os nós. Em redes privadas, participantes, provedores de nuvem e cópias de contingência ainda podem estar fora do Brasil.

No contexto europeu, o EDPB destaca que o compartilhamento com nós fora do Espaço Econômico Europeu pode configurar transferência internacional e deve ser tratado desde o desenho. Para blockchain e LGPD, a empresa brasileira deve verificar onde estão participantes e fornecedores, quais dados circulam, que contratos e mecanismos aplicáveis sustentam a transferência, quais acessos remotos existem e se é possível restringir geografia e permissões.

A avaliação não deve olhar apenas o conteúdo principal. Metadados de comunicação, endereços, logs, chaves e dados off-chain também podem cruzar fronteiras. Uma rede permissionada com participantes conhecidos tende a oferecer mais condições de documentar esses fluxos do que uma rede pública irrestrita, embora a adequação dependa da finalidade.

Retenção, correção e eliminação precisam nascer no desenho

A vida útil da blockchain não deve ser adotada automaticamente como prazo de retenção. O EDPB afirma que cada dado deve ter prazo ligado à finalidade e que, se o período necessário for menor que a vida da cadeia, a solução deve permitir exclusão ou anonimização efetiva. Se isso não for possível, dados pessoais não devem ser colocados on-chain.

Em blockchain e LGPD, a empresa deve testar cenários antes de produzir o primeiro bloco com dados reais:

Como corrigir um dado sem manter exposição prejudicial do valor antigo?
O que acontece quando termina a finalidade ou o prazo regulatório?
A exclusão dos dados off-chain impede de fato a identificação por meios razoáveis?
Existem cópias, indexadores, exploradores ou participantes que preservam o vínculo?
Um endereço pode voltar a ser relacionado ao titular por transações futuras?
Quem executa o pedido e como a conclusão é comprovada?

Em alguns casos, uma transação posterior pode registrar a correção e preservar a trilha legítima. Em outros, o direito só será efetivo se a arquitetura impedir a identificação do titular a partir do que permanece. O resultado deve ser validado, não presumido. Essa é uma das decisões mais sensíveis em blockchain e LGPD.

RIPD ou DPIA: documente risco antes da implementação

O EDPB indica a DPIA quando o tratamento provavelmente gerar alto risco e recomenda que a avaliação considere a operação inteira. Isso inclui modelo da blockchain, papéis, destinatários, smart contracts, dados on-chain e off-chain, direitos, transferências, chaves, logs, consenso, governança e medidas de segurança.

No Brasil, o instrumento correspondente de análise é o Relatório de Impacto à Proteção de Dados Pessoais, RIPD, dentro do contexto da LGPD. Os critérios e efeitos jurídicos não devem ser copiados automaticamente do GDPR. Mesmo assim, o método europeu ajuda a organizar a avaliação de necessidade, proporcionalidade, riscos aos titulares e medidas de mitigação. O conteúdo da TOGETHER sobre RIPD na LGPD e o template europeu de DPIA aprofunda essa conexão.

Um RIPD para blockchain e LGPD deve mostrar por que a tecnologia foi escolhida, quais alternativas foram rejeitadas, quais dados podem identificar pessoas, quanto tempo cada camada os mantém e como direitos serão exercidos. Se os riscos não puderem ser reduzidos por medidas técnicas e organizacionais, a decisão responsável pode ser mudar o modelo de rede ou usar outra tecnologia.

Checklist executivo antes de aprovar o projeto

Para transformar blockchain e LGPD em uma decisão de gestão, reúna produto, tecnologia, segurança, jurídico, privacidade e fornecedores. A aprovação deve depender de evidências, não apenas de uma apresentação técnica.

Finalidade: o objetivo está definido e comunicado de forma compreensível?
Necessidade: existe justificativa para blockchain em vez de alternativa menos invasiva?
Inventário: todos os dados, metadados, logs, chaves e vínculos foram mapeados?
Arquitetura: dados pessoais ficam off-chain sempre que possível?
Identificadores: endereços, chaves públicas e hashes foram analisados no contexto?
Acesso: a publicidade é realmente necessária ou pode ser limitada?
Papéis: decisões e responsabilidades estão claras entre os participantes?
Direitos: correção, acesso, oposição e eliminação foram testados de ponta a ponta?
Retenção: cada camada tem prazo e procedimento de descarte efetivo?
Transferências: localização de nós, provedores e acessos internacionais está documentada?
Segurança: chaves, incidentes, vulnerabilidades e evolução criptográfica têm responsáveis?
Impacto: o RIPD foi elaborado ou sua necessidade foi formalmente avaliada?

Esse checklist não garante conformidade sozinho. Ele cria um ponto de controle para impedir que decisões irreversíveis sejam tomadas antes da análise adequada.

Como a TOGETHER pode apoiar projetos de blockchain e LGPD

A TOGETHER oferece consultoria em LGPD para revisar finalidade, fluxo de dados, papéis, arquitetura on-chain e off-chain, contratos, transferências e RIPD. Também atua com DPO as a Service para coordenar governança, direitos de titulares, fornecedores, incidentes e evidências ao longo do projeto. O objetivo é permitir uma decisão técnica e empresarial informada, inclusive quando a melhor recomendação for reduzir o uso da cadeia ou escolher outra solução.