2.1. Dados pessoais

Sabemos que dados pessoais constituem qualquer tipo de informação associada a uma pessoa identificada/-ável. Sabemos também que (i) o Regulamento europeu só se aplica caso estejamos perante um dado considerado como "pessoal"; e que (ii) dados anónimos não entram no escopo da regulamentação europeia. Para saber se a blockchain lida com dados pessoais, precisamos perceber que dois são os tipos de dados que nela interagem: public keys e aquilo a que se chama de transactional data¹.

Dados financeiros, médicos, de identificação, comportamento de consumo online são informações pessoais que se costumam designar por transactional data, e sobre os quais costumam girar as transações online. Como vimos, há três formas de armazenar dados na blockchain: texto, criptografia ou hashing; pelo que a resposta a esta pergunta exige uma apreciação sob todas aquelas alternativas. A primeira hipótese não levanta grandes dúvidas: quando os dados são armazenados na DLT sob a forma de texto simples, estão necessariamente em causa dados pessoais que permitem identificar uma pessoa, pelo que colhe aplicação o RGPD. Já relativamente aos dados armazenados sob a forma criptográfica, como permanece possível o seu acesso mediante o uso de uma chave privada, então não podemos dizer serem anónimos e, portanto, acabem por permitir o seu rastreamento até ao respetivo titular dos mesmos.

Por último, se os transactional data forem transformados em hashes, ainda poderão ser considerados como dados pessoais. É verdade que o nível de privacidade oferecido por um hash é significativamente maior que a mera criptografia, pois este não pode ser projetado reversamente. Mas para efeitos da recente jurisprudência europeia, quer a criptografia, quer o hashing são uma forma de pseudonimização (e não de anonimização) de dados pessoais, já que a pessoa pode ainda ser rastreada e identificável. Ganha relevo aqui o Parecer do GT 216 (Opinion 05/2014) sobre o artigo 29 a respeito da diferente conceção dos dados como pseudonimizados ou anónimos.

As public keys, não são dados transacionáveis, mas um conjunto alfanumérico que identifica de forma pseudonimizada um usuário que pretende fazer transações ou comunicações². Nos termos do 4.º, n.º 5 do RGPD, a pseudonimização corresponde ao tratamento de dados pessoais que não pode ser atribuído a uma pessoa específica sem recorrer a informações suplementares. Ora, as transações/comunicações na blockchain que são efetuadas através da publicação de uma chave pública (public key), estão irremediavelmente associadas a um IP address. Todavia, se por um lado é certo que esta public key se encontra criptografada para que se consiga um certo anonimato na operação online; não menos certo é que é possível identificar indiretamente a entidade/sujeito que representa aquele usuário pela reutilização daquela chave-pública e correspondente associação a determinado IP address^{3 4}. A não ser assim e mal se conceberia um sistema que usa precisamente a técnica da cadeia de blocos para garantir a unicidade da operação entre determinados sujeitos, ie, para garantir que aquela operação em concreto foi efetivamente realizada por aqueles indivíduos em particular.

A ser assim, ie, conseguindo associar aquela chave pública - leia-se, aquele dado pessoal (realização de uma transação, promoção de um registo, realização de uma operação de voto, etc.) - a determinado usuário, então teremos de concluir que também as public keys se qualificam como dados pessoais para efeitos da aplicação da regulamentação europeia de dados pessoais.

Também paralela a esta discussão, encontra-se o case law C-582/14 Patrick Breyer v Bundesrepublik Deutschland de 19 de Outubro de 2016, relacionado a dynamic IP addresses; e isto porque aqui o TJUE vem discutir o conceito de "dados pessoais" de forma muito relevante para as podermos extrair para um contexto de blockchain. Não obstante o case law ser anterior ao RGPD, como o conceito de dados pessoais deste manteve-se inalterado, a referência mantém a sua pertinência.

Alguns sites de serviços federais alemães para se protegerem de ataques online e permitir ações penais, guardam em registo todas as consultas (sessão, nome do sítio, ficheiro consultado, dados transferidos, indicação do endereço IP do computador do utilizador, etc.) de usuários que acedem aos seus sítios. P. Breyer, um desses usuários, deu entrada de uma ação contra a República Federal Alemã alegando que a conservação do seu endereço IP era desnecessária para os propósitos alegados. Em resposta à questão prejudicial colocada ao TJUE sobre saber se esse IP dinâmico poderia ou não ser considerado dado pessoal, foi considerado que a noção de dado pessoal da então Diretiva 95/46 deveria ser interpretada no sentido de incluir esse endereço (dinamic IP address), mesmo quando careça de informações de terceiro (neste caso o fornecedor de acesso à internet) para prestar informação complementar necessária à identificação do computador usuário (§31); entendendo que um dado pessoal pode ser assim considerado mesmo que nem todas as informações necessárias para identificar o seu titular se encontrem na posse da mesma pessoa (§44).

Algumas tentativas têm sido postas em prática para ultrapassar esta situação e retirar estes dados da alçada do RGPD. Relativamente aos transactional data, caso os mesmos dados sejam armazenados off-chain (fora da cadeia pública), mas vinculados ao ledger através de um hash, seria possível encriptar os dados de forma segura pois estes estariam protegidos por um hash irreversível. No ledger apenas um aleatório dado alfanumérico ficaria visível enquanto os verdadeiros dados a que o hash se referia ficariam armazenados fora da cadeia de blocos. O principal risco associado a esta alternativa prende-se com o fato de implicarem o chamamento de um terceiro para fazer a gestão desse banco de dados editável off-chain, o que acabaria por precisamente em causa o principal fator que os levaria a recorrer à blockchain: não depositar o controlo/confiança em entidades centralizadas.

Ao contrário daqueles, as public key não podem ser transferidas para fora da cadeia por serem parte integrante do funcionamento do próprio blockchain e necessárias para que a validação de transações possa ocorrer.

2.2. Tratamento de dados

Nos termos do art.º 4, n.º 2 do RGPD, o tratamento de dados é considerado como qualquer operação que é executada com dados pessoais, "(...) tais como a recolha, o registo, a organização, a estruturação, a conservação, a adaptação ou alteração, a recuperação, a consulta, a utilização, a divulgação por transmissão, difusão ou qualquer outra forma de disponibilização, a comparação ou interconexão, a limitação, o apagamento ou a destruição". Resta saber que ações são executadas nos dados que são carregados para o blockchain como dados pessoais. Aqui a análise uma vez mais ponderará quer as public keys e transactional data, quer os próprios nodes.

Para cada chave pública corresponde uma determinada chave privada que é entregue a todos os usuários da cadeia de blocos, pelo que todos os usuários de uma chave pública se podem controlar mutuamente e verificar a autorização de novas transações. Essas verificações de validade são automatizadas segundo um algoritmo da tecnologia DLT. Tendo em conta a amplitude do termo de tratamento de dados dado pelo RGPD, mesmo que o tratamento seja autonomizado e se processe pela via de um algoritmo matemático, é possível de qualificar como tal esta operação de verificação da validade de transações através de chaves públicas.

No que respeita aos transactional data, os dados da transação são validados também através de certos algoritmos: são armazenados num determinado bloco, que é posteriormente anexado ao blockchain e distribuído por todos os outros usuários. Isto implica que operações de uso e armazenamento são necessariamente realizadas, pelo que também quanto a estes dados se deve considerar existir tratamento de dados para efeitos do art. 4.º, n.º 2 do RGPD.

Quanto aos nodes/usuários e respetivo endereço, também vimos que cada um mantém cópia e registo com todos os outros nodes com os quais comunica, o que faz com que também eles mantenham uma rede de armazenamento de dados pessoais que possam ser qualificados como tratamento de dados⁴.

3.1. Direito ao esquecimento

Nestes sistemas, assim que transações são registadas na cadeira, deixam de poder ser modificadas ou apagadas: uma transação subsequente que anule ou modifique os termos da anterior pode sempre ocorrer, mas fá-lo-á mediante a adição de um novo bloco ao hash original, que além de registar a nova transação onde ratifica os dados da anterior e ainda a reproduz. A forma de garantir que a cadeia não é alterada e editável encontra-se na referência que cada bloco subsequente tem necessariamente que fazer do anterior, através de hash criptográfico; desta forma, caso a informação contida nesse bloco anterior for alterada, assim também o será o respetivo hash o que permitirá a detetar a falsificação. Quer isto dizer, então, que em princípio todos os dados lançados no blockchain seriam tendencialmente indestrutíveis, imutáveis e impassíveis de modificação; o que claramente representa um problema na óptica do RGPD. Veja-se que já desde Maio de 2014, no processo C-131/12 que opôs a Google Spain e Google Inc. à Agência Espanhola de Proteção de Dados e a Mario González, o TJUE determinou que os cidadãos da UE têm direito a remover dos motores de busca qualquer conteúdo recuperável nos índices de resultados de pesquisa. Na sua justificação, o tribunal europeu considerou que esse direito é independente de saber se a manutenção dessa informação em resultados de pesquisa causa, ou não, qualquer prejuízo ao titular dos dados (§96); e que, nos termos dos direitos fundamentais plasmados no art. 7º e 8º da Carta, esse direito se sobrepõe não só sobre qualquer interesse económico do operador do motor de busca, como também de qualquer interesse público em encontrar essa informação em resultados de pesquisa, excepto em circunstâncias muito excepcionais (§97). Desta jurisprudência, retirou o legislador europeu o "direito ao esquecimento" para o plasmar no mencionado art. 17º e no art.º 5.º, n.º 1, al. d) do RGPD.

Naturalmente que o direito ao esquecimento não é de natureza absoluta. As circunstâncias em que os titulares dos dados podem fazer uso deste direito restringem-se, entre outras, às situações em que: (i) deixem de ser necessários à finalidade que motivou a recolha (art. 17º, n.º1, al. a) do RGPD); (ii) o titular retire o seu consentimento (art. 17º, n.º1, al. b) do RGPD); (iii) o titular oponha-se ao tratamento sem que haja interesses legítimos prevalecentes que o justifiquem (art. 17º, n.º 1, al. c) do RGPD); ou (iv) tenham sido tratados ilicitamente (art. 17º, n.º 1, al. d) do RGPD). Mas independentemente disto, outros problemas práticos também poderiam advir desta situação. Desde logo o titular dos dados que pretendesse fazer valer este direito não tinha como reclamar perante todos os outros nodes da rede os seus direitos, por não ter como os identificar. Por outro lado, mesmo que o conseguisse, esses nodes não teriam como, eles mesmos, conseguir modificar ou apagar qualquer dado armazenado no DLT.

Além deste âmbito limitado, também caberá perguntar o que efetivamente constitui a noção de "esquecimento" / "erasure". Será que representa o total desaparecimento dos dados do mundo real e/ou virtual, ou basta que haja técnicas de proteção que tornem os mesmos criptografados de forma irreversível? Já vimos que no âmbito do sistema blockchain uma erasure é tecnicamente impossível porquanto o sistema foi criado precisamente com o propósito de impossibilitá-lo. No entanto, a criação de alternativas tecnológicas que limitem o processamento dos dados⁵, ou que façam referência a dados anteriores como não sendo mais consideráveis, poderá ser questionável como sendo suficiente para efeitos de acautelar este direito.

Já têm sido desenvolvidas ideias que permitem ultrapassar este problema. Mas mais uma vez a análise passa por uma distinção entre transatctional data e public keys.

Quanto aos primeiros, basta que os mesmos sejam armazenados num banco editável e criptografado de dados off-chain, para poder corresponder com as exigências do RGPD e permitir a eliminação dos dados sem interferir com a blockchain. Todavia, estas modificações ao software sempre acarretarão consequências indesejáveis, nomeadamente no plano da integralidade de teor e autenticidade dos documentos registados no blockchain, requerendo a nomeação de entidades responsáveis para as administrar e os únicos com autoridade para editar a cadeia de blocos de acordo com regras predeterminadas. Por outro lado, certas características apontadas como grandes vantagens desta tecnologia, tal como a descentralização de dados peer-to-peer, deixarão de poder subsistir, para que se permita a compatibilização da mesma com o regramento europeu. Alternativamente, e como já vimos acima, surge ainda a possibilidade de armazenar a informação/personal data num banco de dados encriptado e introduzir um hash desse mesmo banco na cadeia de blocos; técnica que mantém a integralidade e integridade do teor dos dados sem os tornar visíveis na ledger. Esta é, de resto, uma tendência nesta indústria: evitar enviar dados pessoais diretamente na cadeia de blocos, para os armazenar em bancos de dados, com apenas um e unidirecional hash dos dados armazenados no próprio blockchain a que se chama de PII (hash de informações de identificação pessoal); é esse hash que servirá de ponto de referência e link para o banco de dados off-chain.

No que respeita às public keys, há quem ateste a possibilidade transferir a chave ao titular dos dados para que este se encarregue do controlo sobre os seus próprios dados, o que poderá facilmente eliminar se escolher destruir a mesma, pois ela é a única responsável por desencriptar a respetiva informação. Em alternativa, há quem fale nos chamados chameleon-hashes ("hashes camaleão") que reescreveriam o teor dos blocos armazenados na blockchain, sob determinadas restrições e supervisão de autoridades autorizadas e com transparência. Esta solução, porém, ao confiar numa terceira autoridade/árbitro para realizar o serviço, acaba por voltar ao mesmo problema da própria essência do blockchain ser posta em causa.

3.2. Transferência de dados

Nos termos do disposto no art.º 3.º, n.º 1 e 2, o RGPD abrange tratamento de dados efetuados dentro ou fora da União, desde que o estabelecimento do responsável pelo tratamento ou subcontratante se encontre nele; ou, mesmo que não estabelecidos na União, quando respeitarem a residentes desta e o tratamento disser respeito à oferta de bens ou serviços ou ao controlo do seu comportamento dentro da União. Por outro lado, nos termos do art.º 44, as transferências de dados para países terceiros só são possíveis quando respeitadas um conjunto de condições, nomeadamente a existência de um nível de proteção adequado (a definir pela própria Comissão) e a existência de uma autorização específica do titular dos dados.

E é aqui que chegam as perguntas: como podemos determinar em que país determinado node se encontra? Como é que no blockchain podemos garantir que as transferências de dados se processam com níveis adequados de proteção? No âmbito da contratação digital, será possível estabelecer cláusulas contratuais padronizadas para salvaguardar estes direitos na blockchain?

Sucede, porém, que quando estão em causa public blockchains uma presunção quanto à existência de nodes situados ou de tratamentos realizados fora do território europeu torna-se fácil de extrair. Além disso, os miners (mineradores), que são quem resolve os problemas matemáticos que permitem o lançamento de dados para o ledger, são sempre escolhidos aleatoriamente para a tarefa, podendo encontrar-se em qualquer lugar do mundo⁶. Na falta da decisão tomada ao abrigo do art.º 45, dispõe o art.º 46 que os dados sempre poderão ser transferidos para terceiros, desde que apresentadas "garantias adequadas e na condição de os titulares dos dados gozarem de direitos oponíveis e de medidas jurídicas" eficazes. Ora, apesar de em teoria se poder conceber alterações ao protocolo do software para se compatibilizar com estas condições, dificilmente tal será possível. Por ser assim, a maioria da doutrina tem vindo a apontar o consentimento explícito para a transferência dos dados a terceiros, desde que tenha sido informado dos possíveis riscos envolvidos.

3.3. Controlo sobre os dados

Outro problema de compatibilização que encontramos entre blockchain e data protection regulation prende-se com a identificação do data controller ("responsável pelo tratamento", ie, aquele que determina as finalidades do tratamento de dados e assume a responsabilidade originária por qualquer violação⁷) e do data processor ("subcontratante", ie aquela entidade que efetivamente realiza o tratamento de dados conforme instruções do controller). E este problema é tanto mais complexo no contexto digital do blockchain, quanto mais nos apercebermos de que as mesmas entidades podem assumir, simultaneamente, mais do que um papel. Apesar de ambos os papeis desempenhados não serem livres de obrigações e responsabilidades pelo RGPD, a determinação precisa de cada um não deixa de ser determinante.

Esta compreensão, mais uma vez, não pode desconsiderar as naturezas públicas ou privadas de blockchain. Naturalmente que no caso dos private blockchain, aquele que se assume destinatário dos dados enviados pelo titular pode facilmente qualificar-se como controller. Todavia nos restantes distributed ledger technology, verdadeiramente descentralizados em dezenas ou centenas de nodes/computadores/usuários, todos podem carregar dados para determinada finalidade e tratar os dados de terceiros. Nesta ordem de ideias, ou concluímos que nenhum deles se pode qualificar como responsável pelo tratamento, já que verdadeiramente inexiste um agir autónomo e independente com propósitos de processamento, nem tão-pouco se poder dizer que eles ajam com propósitos de tratamento relativamente às informações distribuídas na rede por terceiros; ou então que todos o são porquanto nenhum deles está sujeito a instruções de terceiro no momento em que decidem carregar dados para o ledger. Outra alternativa, seria perceber os nodes como responsáveis conjuntos pelo tratamento, nos termos do art. 26.º, n.º 1 do RGPD, mas para isso eles teriam que determinar conjuntamente as finalidades e meios comuns de tratamento, o que realmente não acontece⁸.

Os usuários/nodes assumem um papel efetivamente importante no tratamento de dados, já que têm total autonomia para entrar e sair da blockchain, escolher que dados querem fornecer, etc. Todavia, o poder de decisão quanto aos objetivos destinados ao software não está nas mãos destes. Com efeito, é o criador de cada blockchain que determina o tipo de utilidade para o qual ele será requisitado: se para realização de registos, se para a promoção de transações, se para a gestão de propriedade e de ativos financeiros, etc. É neste contexto que surge a possibilidade de onerar os criadores dos vários DLT's como controllers, visto que são efetivamente estes que constroem algoritmos específicos para a subordinação de determinado blockchain a finalidades concretas e a propósitos determinados. Mas encontrar no criador do algoritmo o verdadeiro controller nem por isso torna a aplicação do RGPD mais fácil: basta relembrar que o criador do Bitcoin (Satoshi Nakamoto) permanece até aos dias de hoje sob anonimato, sendo a sua identidade desconhecida⁹.

Será que os usuários/nodes estariam então livres de responsabilidade? Se cada pessoa que atua na rede P2P constitui um node independente; se, como visto acima, cada node realiza tratamentos de dados; se os usuários não podem ser qualificados como controllers, mas ainda assim realizam tratamento de dados "em nome" destes; então teremos forçosamente de concluir que cada indivíduo que se conecta a uma blockchain pode ser qualificado como subcontratante. A ser assim, restaria perceber como é que a responsabilidade dada aos subcontratantes pelo RGPD seria aplicável numa rede como esta¹⁰. E é aqui que ressaltam uma série de perplexidades: (i) o fato de os nodes poderem encontrar-se fisicamente nos mais diversos lugares do mundo ou assumirem uma identidade encriptada pode gerar grandes dificuldades na aplicação de sanções¹¹; (ii) o fato de os usuários serem apenas utilizadores de um software desenvolvido por terceiros, agindo manualmente segundo as instruções registadas pelos criadores daquele num algoritmo blockchain; (iii) o fato destes nodes muitas vezes armazenarem cópias dos dados do ledger nos seus computadores em versões criptografadas ou em hashing, que nem podem ser editados; (iv) o fato de o RGPD exigir dos subcontratantes o fornecimento de garantias relativamente à existência de recursos para implementar soluções técnicas de proteção de dados pessoais; soluções estas que lhes são passadas diretamente pelo controller via algoritmo e com o qual estes nem sequer podem interagir ou interferir em caso de necessidade para proceder a alterações às medidas já criadas. Em suma, aos olhos de um RGPD que conceitua o subcontratante como alguém contratado para providenciar soluções técnicas ou processar dados, a qualificação dos nodes como processors perde muito o seu sentido útil.