Como a LGPD afeta (e qualifica) a Ciência de Dados

Assim como o General Data Protection Regulation (GDPR) europeu, a brasileira LGPD traz implicações à Ciência de Dados, principalmente aos modelos de aprendizado de máquina

A Lei Geral de Proteção de Dados entrou em vigor em setembro de 2020¹ e, como seu parente europeu, o General Data Protection Regulation (GDPR), traz questionamentos inevitáveis à Ciência de Dados.

Afinal, o direito à privacidade de dados pessoais afeta ou pode até inviabilizar modelos de machine learning e de deep learning? Um cientista de dados tem responsabilidade sobre aspectos da lei ou esta é uma questão que compete mais a departamentos jurídicos, de segurança da informação ou a CEOs? Como assegurar que a cultura de dados da organização seja condizente com a legislação e não inviabilize ou traga riscos ao trabalho técnico?

Antes de explorarmos essas questões, vale esclarecer que este texto não pretende ser um guia introdutório à LGPD, nem fornecer fórmulas prontas sobre aplicação da lei, muito menos pretende um tratamento jurídico rigoroso do tema. O intuito é lançar reflexões que contribuam com a Ciência de Dados à luz de uma de suas regulamentações, provavelmente a mais abrangente até o momento.

A quem necessitar ou desejar, um entendimento amplo da lei passa (não tem jeito) por lê-la na íntegra (afinal, todo o resto será interpretação, inclusive dos juízes que tomarão decisões com base nela). Na sequência, vale consultar alguma versão comentada. Para introduções mais amigáveis, há cartilhas e uma infinidade de conteúdos tentando simplificar os principais pontos.

Dado, tratamento e maturidade organizacional

Dois termos da LGPD são úteis para uma abordagem mais direcionada à Ciência de Dados: dado e tratamento. A maturidade com que organizações se estruturam em torno de ambos conta muito para atendê-los na prática.

Dado, aqui, diz respeito a dado pessoal de pessoa natural identificada ou identificável e a dado pessoal sensível, isto é, origem racial ou étnica, convicção religiosa, opinião política ou dado referente à saúde, à vida sexual, dado genético ou biométrico, entre outros, conforme Art. 5º, incisos I e II, da LGPD. Tratamento, por sua vez, é toda operação realizada com dados pessoais, conforme os vários verbos listados também no Art. 5º, inciso X, da lei.

Em organizações mais estruturadas, isto é, aquelas que nasceram data-driven, data-informed ou que passaram por transformação digital, já ocorre uma especialização de responsabilidade para com ambos os aspectos.

Dados pessoais são muito muito mais responsabilidade, na parte técnica, de data engineers, DBAs, devops. Já tratamento pode impactar mais business analytics, data scientists, machine learning ou deep learning engineers, além de desenvolvedores que colocam e mantêm modelos em produção.

Tudo bem que não é tão oito ou oitenta. Pode haver data scientists fazendo mais papel de engenheiro em determinada empresa. Pode haver data engineers que atuam em esquema “pastelaria”, apenas entregando dados para serem consumidos por setores de negócio, o que acaba envolvendo alguma tratamento das informações.

É provável, porém, que empresas que não estruturarem minimamente a parte técnica (contar ao menos com engenharia/segurança e análise/ciência de dados) e a parte de gestão (governança, compliance e Data Protection Officer, o DPO, um papel criado pelo GDPR que também ganha força com a LGPD) tenham mais dificuldades em se adequar à lei e em lidar com aspectos explanados a seguir.

Como a LGPD afeta e pode inviabilizar modelos

À primeira pergunta da introdução, a resposta curta é um “sim” relativo. Sim, algoritmos que tomam decisões automatizadas podem ser afetados ou até inviabilizados perante a lei. Também não é o fim da Inteligência Artificial. É relativo porque depende de muitas variáveis.

Primeiramente, a lei diz que tem de ficar clara a finalidade, forma, duração e outros critérios do tratamento ao titular dos dados, e desde que este consentir em fornecê-los (Art. 9º). E que autorizações genéricas serão nulas (Art. 7º), ou seja, é necessário pedir consentimento específico para cada tipo de tratamento pretendido. Isto parece implicar saber de antemão que tipo de tratamento será aplicado e pode dificultar tarefas como análise exploratória sobre dados pessoais, ou qualquer outra decidida posteriormente à coleta de tais dados.

Na prática, a regra visa impedir — ou tornar bastante trabalhoso —  o ato de coletar o máximo de dados primeiro, sem finalidade nem critérios, para em outro momento extrair conhecimento por meio de mineração dos mesmos. Faz sentido para proteger usuários. Exigirá bastante criatividade de profissionais e organizações no planejamento da coleta e do tratamento para que não se caia em inviabilidades sutis.

Pensando-se no dia a dia da Ciência de Dados, isso pode afetar o cenário em que se elenca um problema de negócio, procura-se fontes de dados e mergulha-se nelas tentando extrair padrões, fazer cruzamento, encontrar insights. É claro que tais exigências não impactam dados não pessoais (variações da bolsa de valores, tráfego de veículos, movimentação de cargas, supply chain etc.). Mas se uma das fontes a ser tratada contiver dados pessoais, estes terão de já estar (ou de serem, uma tarefa a mais) anonimizados, pseudoanonimizados ou nem entrar na base utilizada no tratamento.

Na sequência, deve-se considerar o direito de o titular dos dados requerer correção de suas informações, anonimização, bloqueio ou eliminação de dados “desnecessários, excessivos ou tratados em desconformidade com a lei” (pode haver disputas em torno da exatidão destes termos), eliminação de dados tratados com consentimento, exceto nos casos do Art. 16, e revogação do consentimento.

Considerando-se que os dados foram anonimizados (é impossível associá-los a uma pessoa natural), tudo bem, é possível continuar utilizando-os para finalidades estatísticas, por exemplo. Agora, há dúvidas sobre como proceder se dados são utilizados no treinamento de modelos. Os modelos teriam de ser retreinados após portabilidade ou revogação de consentimentos? O Art. 10, que trata do “legítimo interesse” do controlador (também pode haver disputas em torno da exatidão da expressão) e o Art. 16 (desde que os dados permaneçam com o controlador e estejam anonimizados) dão a entender que não. Caso não estejam anonimizados, ou seja, a decisão algorítmica leve em conta dados de pessoa identificável ou haja disputa em torno do que venha a ser “legítimo interesse”, fica a incerteza.

Outro ponto importante para o aprendizado de máquina é o Art. 20, reproduzido na íntegra, a seguir:

Art. 20 O titular dos dados tem direito a solicitar a revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais que afetem seus interesses, incluídas as decisões destinadas a definir o seu perfil pessoal, profissional, de consumo e de crédito ou os aspectos de sua personalidade.

§ 1º O controlador deverá fornecer, sempre que solicitadas, informações claras e adequadas a respeito dos critérios e dos procedimentos utilizados para a decisão automatizada, observados os segredos comercial e industrial.

§ 2º Em caso de não oferecimento de informações de que trata o § 1º deste artigo baseado na observância de segredo comercial e industrial, a autoridade nacional poderá realizar auditoria para verificação de aspectos discriminatórios em tratamento automatizado de dados pessoais.

O direito de o titular dos dados poder solicitar tal revisão pode afetar modelos de aprendizado de máquina no que diz respeito à “explicabilidade” dos mesmos. Aparentemente, isto impacta mais no resultados de modelos (explicação local) e menos na decomposição de etapas de processamento (explicação global), já que esta poderia comprometer segredos comerciais e/ou industriais do controlador ou do operador (dois atores no âmbito da lei), o que a LGPD protege.

Aqui também surge a possibilidade de o aprendizado de máquina se ver inviabilizado, sobretudo modelos de deep learning do tipo “caixa-preta” — em que, devido à profundidade de camadas e parâmetros, pode ser impossível fazer engenharia reserva do processamento a fim de explicar porque determinada saídas foram geradas.

É um exercício rico pensar como se comportaria um assistente virtual por voz ou mesmo um chatbot nesses casos. E, para complicar mais, tome-se como exemplo um serviço de telemedicina, no futuro. Mesmo que o bot recomende ao usuário tomar um analgésico ou procurar um médico, porque este informou sua temperatura corporal (um dado biométrico, portanto sensível), o bot terá de pedir consentimento antes da conversa e, a cada dado pessoal ou sensível solicitado, terá de explicar o que irá fazer (tratamento)? Caso a recomendação prejudique o usuário — o algoritmo julgou que, por seu peso, o mesmo está em uma faixa de risco de doença —, como fornecer informações claras e adequadas, se solicitadas, sobre a decisão automatizada ou, pior, como responder a uma auditoria da Autoridade Nacional de Proteção de Dados (ANPD), o órgão regulador da lei, por que um determinado procedimento não foi sugerido, posto que o usuário foi julgado acima do peso, o que pode vir a ser interpretado como discriminação? A cada pequeno ponto que se avança de forma aritmética, a complexidade parece aumentar de forma geométrica.

O uso de carros autônomos, de algoritmos para determinar penas de prisão ou seu emprego em tecnologia de segurança pública levam hipóteses como essas a extremos, que fogem ao escopo deste artigo.

O GDPR, por vir antes e ser até mais rigoroso quanto à revisão de decisões automatizadas², já iniciou e ampliou debates similares. Sobre a “explicabilidade” no regulamento europeu, há inclusive quem negue a existência de tal direito. Há também estudos que sugerem que modelos podem vazar dados de treinamento, permitindo a descoberta de dados originais, inclusive após a base de treinamento ter sido excluída — embora sejam abordagens bastante acadêmicas (ainda é mais fácil roubar dados de usuários simplesmente pedindo-os numa landing page falsa do que se dar todo esse trabalho de engenharia).

Obviamente, só erros e acertos na realidade e jurisprudência construída a partir da aplicação da lei dirão quais caminhos serão trilhados. Para começo, é de se imaginar que a lei deva ficar associada a casos escabrosos, como venda de dados pessoais (vide uma primeira ocorrência no Brasil), marketing irritante e ofensivo sem consentimento e decisões algorítmicas absurdas em serviços bastante utilizados e visados. À medida que organizações e profissionais se depararem com nuances da lei, soluções condizentes também serão criadas, forçando o mercado a inovar dentro da regulamentação.

Nesse sentido, propostas argumentativas e técnicas já têm surgido em relação à GDPR, podendo se estender à LGPD, mesmo que algumas sejam bastante experimentais. “Explicações contrafactuais” — o crédito foi negado porque a renda da pessoa é de R$ 3.000 e não de R$ 5.000, por exemplo — é um caso no campo argumentativo. No campo técnico, Local Interpretable Model-Agnostic Explanations (LIME) é uma das tentativas de avançar na “explicabilidade”, não só para atender a legislação, mas para qualificar a própria Ciência de Dados.

Outras siglas e termos seguem-se neste campo, que pode se revelar promissor para profissionais especializados em um futuro próximo: “Explaining Classifications for Individual Instances”, “Explanation Vectors”, “Variable and Feature Selection” (referências aqui e aqui), “Black Box Explanations through Transparent Aproximations (BETA)”, “Explainable Artificial Intelligence (XAI)”, entre outros.

Assim, a curto prazo, o que pode parecer limitador à Ciência de Dados (e, provavelmente, terá detalhes ignorados por ação ou omissão), a longo prazo poderá ser fator de avanço acadêmico, qualificação profissional, amadurecimento de organizações no trato com usuários e também na educação destes para com sua privacidade e no entendimento da Ciência de Dados e do aprendizado de máquina.

A responsabilização técnica, a exemplo do que já existe em Engenharia Civil ou em Medicina, por exemplo, acabará forçando soluções e qualificação em prol de segurança, boas práticas, legalidade e ética.

Um porém, obviamente, é o desnivelamento de regulamentação entre países, com alguns ousando (e abusando) justamente por não terem marcos regulatórios e outros restritos por tentarem proteger seus cidadãos.

Responsabilidades do profissional

À segunda pergunta da abertura, cabe um “sim” e é melhor não brincar com o “depende”. Profissionais de dados devem estar cientes e seguros do que fazem e de que poderão ser responsabilizados por erros, vieses e descuidos no tratos com dados e no seu processamento, isto é, nos dados que tratam e nos modelos que implementam.

Como visto no tópico anterior, será tarefa técnica de data scientists ou de ML ou DL engineers — se não de um único profissional, mas do time e do líder técnico — garantir que decisões automatizadas baseadas em dados pessoais atendam ao Art. 20 da LGPD, ou seja, possam ser revisados, informados e auditados.

Em relação a possíveis solicitações de esclarecimentos e auditorias e à necessidade da empresa dispor de Relatórios de Impactos à Proteção de Dados Pessoais (outra exigência da LGPD, por meio da ANPD), será necessário um maior esforço de documentação, tanto de arquitetura e aspectos técnicos quando de objetivos e intenções dos modelos, assim como dos riscos envolvidos.

Outra boa prática é a restrição ao consumo e eventual armazenamento de dados pessoais em etapas de homologação de modelos, isto é, evitar importar dados pessoais desnecessários a um tratamento, solicitar que os dados pessoais venham anonimizados ou pseudoanonimizados da engenharia de dados ou, se necessário, ter e aplicar padrões seguros de anonimização ou pseudoanonimização, garantir que os dados estejam seguros contra vazamentos em ambientes de desenvolvimento, enfim, deveres básicos, como um químico lidando com componentes delicados.

É claro, ter uma compreensão apurada dos modelos, acompanhar seu desempenho e dominar técnicas que evitem ou corrijam vieses e erros que possam discriminar usuários serão fatores essenciais, o core do trabalho em Ciência de Dados.

Se vieses e problemas forem observados, por causa de características de dados de treino ou por necessidades de uma implementação, cabe a boa e velha comunicação e documentação. Explicar no âmbito interno da organização os problemas e possíveis impactos também deve ser tarefa de técnicos. Nesse ponto, um bom relacionamento tanto com outros técnicos, como engenheiros ou DBAs, quanto com o pessoal de gestão e política, como o DPO ou alguém do jurídico (melhor ainda se a organização tiver processos claros para isso) pode ser fundamental para se evitar problemas ou agir rapidamente caso ocorram. Até porque a LGPD cobra resposta e esclarecimentos em caso de incidentes.

É importante ter claro que a lei coloca como ônus do controlador a prova de consentimento (Art 8º, § 2º) no fornecimento de dados e, em casos judicializados, o juiz pode inverter o ônus a favor do titular dos dados quando a alegação for verossímil, não suficiente ou muito onerosa para produção de provas (Art. 42, § 2º). São formas de ser justo com o lado “mais fraco” e algo que eleva a responsabilidade nas organizações.

A LGPD também reforça (Art. 6º, X), como um de seus princípios, a responsabilização e prestação de contas. Este princípio atinge a pessoa jurídica que se relaciona com o titular dos dados, mas, por precaução, cabe aos profissionais técnicos se precaver frente à possibilidade de uma demissão por alegação de que o erro foi ocasionado por ação ou omissão deste, sem comunicação dos riscos.

Embora em ambientes de inovação, como nas startups, informalidade seja um ingrediente para agilidade, não será estranho se, com o tempo e a evolução da regulamentação, venha-se a assinar responsabilidade técnica ou algum termo entre organização e profissionais, visando segurança, tranquilidade e delimitação de atuação a ambos, principalmente nos negócios que atuam em ramos críticos quanto a dados pessoais. É um cenário pelo qual qualquer profissão enfrenta com a maturidade.

À medida que regulamentações de dados ganharem holofotes, sobretudo porque escândalos e crimes envolvendo dados se tornarão mais frequentes, será natural que profissionais (ou a categoria como um todo) também deixem de figurar só do lado do “bom mocismo” da coisa (“profissão sexy”, “unicórnios” e outros adjetivos) e passem a ser associados às consequências que podem gerar. Também sinal de amadurecimento da profissão.

Cultura organizacional como proteção

A terceira pergunta deste texto é uma daquelas que tanto organizações como profissionais gostariam de responder para ontem. A resposta curta é só um amplo “depende”, que requer tempo, muita construção coletiva e irá variar de uma organização a outra.

Um bom ponto de partida a ser pensado e incentivado, de C-levels a analistas, é se perguntar: “Precisamos realmente de todos esses dados pessoais? Por quê? Para quê?” Apesar de parecer limitador à agilidade e à receita, é mais condizente (e barato) pensar em privacidade desde o início (privacity by design) e por padrão (privacity by default), ou seja, bem antes de descumprimentos à lei se embrenharem em modelos de machine ou de deep learning.

Novamente de encontro à skill da comunicação citada no tópico anterior, cabe aqui, a técnicos e a lideranças técnicas, ter um conhecimento mínimo da legislação para colocar implicações e riscos à mesa — até para que a responsabilização, como dito, não volte para os mesmos. 

Produto ou marketing estão abusando na coleta de dados? Voltar à pergunta acima pode ajudar a evitar riscos e, obviamente, tornar análise e automação mais específicas. Os dados não estão chegando anonimizados da base, o cientista tem que importar tudo para ambiente de desenvolvimento, podendo expor informações a riscos de vazamento? Dar um toque à equipe de engenharia ou conscientizar lideranças sobre a necessidade de profissionalizar este aspecto pode dar mais tranquilidade a todos que atuam na cadeia de dados da empresa.

Tudo bem que não é tão trivial assim dependendo da estrutura, da cultura já estabelecida e do momento da empresa. Detalhe com cadastro ou com base de dados é a última coisa que uma organização quer se preocupar se há outros problemas maiores à vista. Mas a lei está aí, a ANPD atuará e o que ficou como “débito técnico” pode virar dor de cabeça, em termos de dinheiro (multas da LGPD podem chegar a R$ 50 milhões) e de reputação, fora que não atender a lei é caminho para não cumprir também o GDPR e não poder atuar no mercado europeu (ou ser multado em euro).

Já que esses termos estão na moda, não há porque serem todos “mercenários” juntos: alguns “missionários” podem incentivar um movimento bottom-up a fim de tentar mudar a cultura organizacional aos poucos. Não deu certo? Ao menos haverá aprendizado. É provável, também, que técnicos que dominem conhecimento e responsabilidade sobre normas legais se vejam valorizados no mercado, ou seja, vale transitar da exatidão técnica para o mundo ambíguo e polissêmico da lei não só por causa de riscos, mas principalmente por causa das oportunidades.

Artigo escrito por Rogério Kreidlow, jornalista, que gosta de observar a tecnologia em relação a temas amplos, como política, economia, história e filosofia.

1. Para um histórico da proteção de dados pessoais, trata-se de um fenômeno desdobrado do direito constitucional à privacidade e dos direitos do consumidor, e que ganhou corpo com o avanço das tecnologias digitais e de vazamentos e escândalos neste âmbito. O debate na esfera jurídica federal iniciou em 2010; passou a tramitar na Câmara dos Deputados, por meio de um projeto de iniciativa legislativa, em 2012; deu origem a outro projeto em 2016, que então foi sancionado em 2018, deveria passar a viger em agosto de 2020, tentou ter a vigência adiada por causa da pandemia de Covid-19, mas acabou mantido pelo Senado. Mesmo assim, sanções a quem descumprir a lei só poderão ser aplicadas pela Autoridade Nacional de Proteção de Dados (ANPD) — uma figura nova no cenário regulador nacional, ainda não atuante — a partir de agosto de 2021 (Art. 65, I-A).

2. O General Data Protection Regulation (GDPR) é de 2016 e entrou em vigor em 25 de maio de 2018. É mais abrangente do que a LGPD em relação à revisão, por exemplo, porque prevê a de revisão humana de decisões automatizadas. Na LGPD, dispositivo similar foi vetado por entendimento de que inviabilizaria negócios, principalmente escaláveis.