Dados: O novo petróleo ou o novo urânio?

Dados: O novo petróleo ou o novo urânio?

Postado originalmente em 4 Abril, 2021.

Eu venho pensado ultimamente sobre o papel de engenheiros de dados e de machine learning em relação a forma na qual nós trabalhamos, especialmente no que diz respeito à privacidade de todas as pessoas que geram dados que analisamos, mineramos, criamos modelos e armazenamos em nossos empregadores e/organizações.

Em especial dois eventos serviram como ponto de inflexão na minha cabeça em relação a esses aspectos de privacidade.

O primeiro foi o megavazamento de dados no Brasil que comprometeu mais de 223 milhões de CPFs, e que curiosamente ainda não se sabe (qual) quais são as fontes desses dados, e ninguém sabe ainda a extensão e cadeia de consequências disso.

O segundo evento foi o roubo de informações de sessões de terapia de aproximadamente 40 mil pessoas na Finlândia; que além ser algo abjeto por si só, mostra que estamos muito mais expostos do que nunca; em que o antigo caderno de anotações de um psicólogo que teria no máximo uma exposição local (se tivesse), virou algo que pode ser difundido e comercializado por toda internet.

Com isso comecei a me perguntar sobre a real utilidade do armazenamento destes dados considerando inúmeras perspectivas: análise de dados, machine learning, e até mesmo aspectos jurídicos.

A conclusão que eu cheguei foi que na vasta maioria dos casos, diferentemente do que diz a The Economist, [**os dados não são o novo petróleo](https://www.economist.com/leaders/2017/05/06/the-worlds-most-valuable-resource-is-no-longer-oil-but-data) ou mesmo a nova eletricidade como nos querem fazer acreditar; mas sim os dados estão muito mais próximos de ser um novo urânio, **devido ao altissímo potencial de utilidade, mas que sem a infraestrutura adequada, e todo o custo de gerenciamento pode levar a situações catastróficas.

…

Por mais que estes eventos de vazamento de dados fossem o gatilho *para a minha reflexão, a inspiração final para esse ensaio, foi sem sombra de dúvidas o artigo do Bruce Schneier chamado *Data Is a Toxic Asset, So Why Not Throw It Out? (Dados são um ativo tóxico, então porque não jogar isso fora, em tradução livre).

Schneier coloca em seu ensaio todos os riscos envolvidos quando armazenamos dados, e concluí que os dados são um ativo tóxico dada a estrutura de riscos envolvida no armazenamento de informações.

Ele aponta que os 3 principais motivos pelo qual as empresas mantém dados como “ativos” são:

(i) o fato de que estamos no meio do ciclo do hype em Big Data em que as empresas não sabem nem o que fazer com os dados mas continuam coletando alucinadamente;

(ii) as empresas simplesmente estão menosprezando os riscos e as consequências do que pode acontecer caso ocorra um vazamento, e por fim

(iii) o fato de que existem empresas que entendem os pontos (i) e (ii) e mesmo assim armazenam os dados considerando um potencial modelo de negócios em que parte desses dados podem ser utilizados, mesmo com toda a estrutura de risco envolvida.

Eu tendo a concordar com esse ponto de vista, mas eu penso que essa agenda além de contar com uma baixa praticalidade, não considera alguns mecanismos que podem reduzir as possibilidades de um vazamento e minimizar as consequências de um potencial evento de violação de privacidade.

…

Em um mundo ideal teríamos em todas as empresas as “situações nirvana” de que (i) todos os dados estariam anonimizados e descentralizados de forma com que um potencial vazamento revelaria pouca ou nenhuma informação sobre nenhum membro do conjunto de dados, e (ii) os sistemas de armazenamento de dados seriam robustos o bastante para conter qualquer tipo de invasão ou vazamento devido a mecanismos de infraestrutura, segurança, e de treinamento das pessoas que trabalham na ingestão e consumo desses dados.

E claro que essas duas “situações nirvana” não seriam possíveis sem (i) treinamento de pessoal, (ii) investimentos em infraestrutura de segurança e mudança de métodos de coleta e armazenamento de dados, e (iii) potencial perda de informações por parte das empresas.

Entretanto, como não vivemos em um mundo ideal e a viabilidade tecnológica e financeira disso tudo pode ser proibitivo para a grande maioria das empresas, o que pode ser feito é a utilização de soluções para minimizar a superfície de ataque/vulnerabilidades.

Potenciais alternativas para minimizar um potencial vazamento de dados

Pessoalmente não sei se existe uma solução canônica para o problema de armazenamento de dados no que diz respeito a questões de privacidade, considerando os custos de implementação contra os custos de uma disputa litigiosa devido a violação de privacidade.

Contudo, penso que algumas medidas práticas podem ser utilizadas para minimizar alguns dos riscos em armazenar dados.

[Proverança dos Dados](https://www.artworkarchive.com/blog/provenance-what-is-it-and-why-should-it-matter-to-you): A proverança pode ser estabelecida no momento da aquisição dos dados com a identificação de origem de cada um dos registros. Um exemplo disso pode ser uma coluna com o timestamp e os metadados da origem. Por exemplo, no mundo de arte grande parte das obras vendidas legalmente tem tanto selo de autenticidade quanto de origem de quem vendeu. Em algumas obras a proverança é tão rígida que se consegue chegar no comprador original em um espaço de tempo de mais de 90+ anos. No caso de sistemas pode ser qual aplicação deu origem, endereço de IP, informações se os usuários estavam autenticados ou não, e no caso de dados externos a referência da fonte. Eu tive a oportunidade de trabalhar por alguns anos no setor de [skip tracing](https://en.wikipedia.org/wiki/Skiptrace) para o mercado de derivativos de crédito no Brasil ,e posso afirmar que hoje é virtualmente impossível saber como provedores de informação estão comprando ou vendendo dados, e como isso está sendo curado. E aqui não tem segredo: Não tem proverança? Não adquira os dados. A contar do momento em que a sua organização/empresa coloca os dados para a sua base de dados, ela vira oficialmente a fonte dessas informações, e a responsável jurídica.

Privacidade Diferencial: Eu já coloquei esse ponto no blog do Data Hackers nos posts “[O que é a Privacidade Diferencial e como isso está relacionado com segurança em Machine Learning?](https://medium.com/data-hackers/o-que-%C3%A9-a-privacidade-diferencial-e-qual-a-rela%C3%A7%C3%A3o-com-seguran%C3%A7a-em-machine-learning-bcba0d72eba6)” *e em um exemplo prático no R no post “Privacidade Diferencial no R usando o diffpriv”. A privacidade diferencial brilha devido ao fato de que ela não está preocupada com “quem está na base de dados” mas sim “quais as dinâmicas estão por trás de um comportamento agregado de forma na qual nenhuma pessoa possa ter o seu comportamento individual revelado”. Aqui eu gosto de usar a analogia entre os supermercados e a maioria dos websites que abusam de *tracking na web moderna. Grande parte dos sites web moderna utilizam-se de um rastreamento excessivo para coletar dados para personalização e recomendação artigos de consumo com uma baixíssima/questionável utilidade, como por exemplo, banners de portais de notícias, ou “anúncios personalizados”. Não é por acaso que algumas empresas estão saindo desse modelo e apostando em outras alternativas. Em contrapartida o modelo moderno de layout dos supermercados mostra como desenvolver uma forma de capturar uma dinâmica sem precisar coletar um caminhão de dados pessoais para induzir um comportamento ou tirar a fricção de um processo de compra. Os supermercados não sabem quem são as pessoas individualmente, mas eles sabem pelas dinâmicas dos dados que eles coletam que é sempre bom ter algum lugar com cafeteria *dentro de seus estabelecimentos, que *bens essenciais sempre vão ficar no meio do mercado, que salgadinhos e chocolates pequenos vão ficar perto dos caixas, e que bens de utilidade recorrente vão estar o mais longe possível da entrada. Tudo isso sem nenhum CPF registrado, com a esmagadora maioria dos clientes indo comprar de forma anônima (e agora de máscara).

[Aprendizado Federado (Federated Learning)](https://ai.googleblog.com/2017/04/federated-learning-collaborative.html): O aprendizado federado é uma técnica de machine learning que realiza o treinamento de modelos em inúmeros servidores ou dispositivos de forma totalmente descentralizada; de forma que não acontece nenhum tipo de compartilhamento de dados de treinamento entre as instâncias que realizam o ajuste dos algoritmos. Desta forma, as únicas informações compartilhadas são relativas ao parâmetros de treinamento (e.g. dados de atualização de gradiente, informações de convergência, taxa de perda durante o treinamento, etc) em cada um dos lugares em que treinamento ocorre. Isso maximiza a privacidade e a segurança dos dados, devido ao fato de que não existe um repositório central com todos os dados como da maneira tradicional de treinamento de algoritmos de machine learning.

Anonimização dos registros: Essa é uma alternativa mais tradicional e simples que se bem feita pode auxiliar na grande maioria dos casos. Um caso interessante foi de um banco digital que apesar de ter os dados pessoais dos usuários por obrigação legal, internamente só disponibilizava para os times de marketing e ciência de dados os dados anonimizados, ou com [Feature Hashing](https://arxiv.org/abs/0902.2206) (já anonimizadas previamente) pelo time de engenharia de dados.

Eliminar captura de dados irrelevantes: Uma coisa que eu venho observando na indústria a alguns anos é o impulso natural para capturar o máximo de dados possível, e em algumas situações, sem nenhum tipo de critério. Se eu tivesse que pensar algumas hipóteses pelas quais a captura de dados inúteis têm se tornado o padrão eu diria que são:

• (i) Com o barateamento do preço de armazenamento, o custo marginal para geração de novos dados foi praticamente zerado. Isso na prática significa que o antigo problema de armazenar um alto volume de dados foi minimizado, e agora o desafio é trazer mais dados o mais rápido possível;

• (ii) A mudança do paradigma de arquitetura baseada em transações para arquiteturas orientadas a eventos. A questão é bem simples: Se antigamente faziam-se aplicações que batiam em um banco de dados, realizava uma transação via stored procedure, e armazenava apenas um ciclo já fechado dessa transação, hoje o nome do jogo é praticamente capturar todas as mudanças de estados possíveis, comunicar isso entre outros sistemas, e por fim armazenar isso o mais rápido possível. Mesmo se isso significar implementar um stack de tecnologia totalmente dispensável fazendo [overarchitecture](https://www.nemil.com/on-software-engineering/beware-engineering-media.html) baseado em hype. Não é a toa que todo o hype sobre [Data Mesh](https://martinfowler.com/articles/data-monolith-to-mesh.html) *como proposta de arquitetura soa quase como contracultura moderna que saí do arquétipo “coleta tudo” para o “coleta o mínimo necessário para o domínio dentro de um contexto limitado*”;

• (iii) As plataformas estão cada vez mais famintas por dados: Por algum motivo que foge do meu conhecimento, qualquer plataforma fazendo fluxos de negócios triviais requer um grande número de informações que nem serviços cartoriais ou públicos pedem. Um exemplo simples são sites de serviços de comida ou de entrega de bebidas pedindo informações cada vez mais pessoais como CPF, data de nascimento, etc. Uma simples ida em uma farmácia no Brasil o atendente pede tudo isso para vender uma simples aspirina;

• (iv) *Demandas de *analytics *cada vez mais complexas (e cada vez mais questionáveis)**: Eu reconheço que a competição em algumas indústrias chegou em um ponto de que qualquer diferencial marginal pode significar o sucesso ou a disrupção, e que a análise de dados tem um papel fundamental. O que eu me pergunto é: se os clientes dessas análises têm a formação ou os conhecimentos necessários para realizar as perguntas corretas que motivem a coleta de tantos dados? Vamos pensar objetivamente: Quantos clientes entendem a importância dos testes de significância estatística para avaliar a efetividade de um teste A/B? Quantos destes clientes têm a percepção de que aspectos causais podem afetar os seus KPIs e que por isso parte das suas intervenções de produto são, na melhor das hipóteses, um teatro de resultados que confunde associação com causa? Meu ponto não é contra a análise de dados, mas pelo fato de que a pergunta errada ela não somente não tem um resultado de negócios, mas sim envolve toda uma engenharia por trás para a operacionalização desses dados (mais tempo de engenharia para coletar os dados, mais recursos computacionais alocados, mais prejuízo na experiência do usuário com sites cada vez mais lentos, mais tempo de engenharia para otimizar tempos de resposta de sites e apps que estão artificialmente lentos, *etc);

• (v) Por causa do (ii) e do (iii), e questionavelmente por conta do (iv) ,uma [porção de soluções de data streaming surgiram](http://porção de soluções de data streaming surgiram) para movimentar o maior volume de dados no menor tempo possível, [mesmo considerando os custos de engenharia para implementação dessas soluções](https://vicki.substack.com/p/you-dont-need-kafka). Isso porque não falei do fato de que essas ferramentas ao mesmo tempo que auxiliam na redução brutal em relação à latência de dados e de armazenamento, muitos dos domínios de negócios simplesmente não têm volume que justifique a implantação dessas tecnologias para captura e armazenamento dos dados.

Expurgo de dados: Provavelmente é solução mais simples, e ao mesmo tempo a mais difícil de se vender, dado que vai na contramão do dogma atual do “mais dados melhor”, mesmo quando a maioria desses dados tenha serventia quase zero do ponto de vista de utilização ou de relação causal que possa alavancar a empresa/organização. Assim como na vida offline, dados desnecessários sendo armazenados são no final do dia lixo. Puro e simples. Podemos racionalizar e tentar empurrar alguma serventia em stakeholders *desavisados, mas no final é apenas lixo que vai enriquecer provedor de armazenamento em *cloud ou fornecedor de HD Externo. O raciocínio é simples: Será que a sua empresa que vende remédios precisa mesmo do CPF de todas as pessoas que não tomam remédios controlados? Será que o seu aplicativo de entrega de comida precisa mesmo da localização do GPS e acesso ao sistema de arquivos dos celulares dos seus usuários mesmo fora de um contexto de entrega? Será que o seu aplicativo de *affair dating *realmente precisa armazenar em texto os nomes e endereços de seus usuários? Será que o seu aplicativo de vídeos precisa de 7TB de dados totalmente não criptografados? Hotéis precisam mesmo armazenar por anos a fio números de passaporte?Será que o teu chatbot precisa mesmo considerar informações de dados de conversas privadas de usuários para o treinamento de algoritmos?

Considerações Finais

No fundo cada uma das pessoas que trabalha com dados sabe (ou deveria saber) que existem riscos inerentes ao armazenamento, acesso e manipulação dessas informações; contudo a ausência de uma percepção maior sobre esse tema de privacidade é algo ainda que tem que ser trabalhado

Como eu coloquei anteriormente, algumas dessas técnicas utilizadas em conjunto podem ajudar a minimizar o impacto de um potencial vazamento ou mitigar alguns dos riscos inerentes à atividade de retenção e utilização de dados.

Inúmeros países do mundo estão com a marcha regulatória em relação a utilização dos dados de usuários; no Brasil com a Lei Geral de Proteção de Dados Pessoais (LGPD) e na Europa com a General Data Protection Regulation (GDPR). Com isso a margem para operar em zonas cinzentas *da regulação não somente está menor, mas já existe jurisdição para autuações e multas pesadas. Em outras palavras, a coisa toda saiu do mote infantil do “*Move fast and break things” e agora virou “Be professional, know the tradeoffs, run the risk and deal with the consequences”

A implantação ou não de algumas dessas técnicas dependem não somente de investimentos, mas também de capital intelectual, e de uma avaliação de viabilidade; com o último sendo potencialmente um concorrente de aspectos de negócios. Justo e compreensível.

Contudo existe uma grande diferença entre achar que a sua empresa está sentada em uma infinita bacia petrolífera no golfo pérsico, quando na realidade ela está mais parecida com uma pré-Chernobil.

Eu quero saber o que você pensa sobre isso, se possível deixe um comentário ou entre em contato no twitter ou no e-mail do meu perfil no Medium.

[Nota 1] — Referência incidental com esse twitt do Silvio Meira. Eu anotei essa frase em algum lugar e fiquei pensando sobre ela por algum tempo, e por fator de sincronicidade pura esse post saiu.