LGPD: é possível legalizar-se sem custo e sem remover a transparência!

Agosto é mês do cachorro louco!   E este ano será também o mês que “deixará loucos” os controladores e seus encarregados nas organizações que se preocupam com a LGPD. Em 1º de agosto entra em vigor a aplicabilidade das sanções previstas; ou seja, a LGPD vai começar a punir quem se descuidar.

… E o que se percebe é que ainda existem muitas empresas e órgãos governamentais em dúvida, ou gastando dinheiro para realizar ações que não são as mais corretas. Muitos erros foram e continuam a ser cometidos por empresas que tentam estar “em conformidade com a LDPD”.

Sugestão aqui para este tópíco. Vale discutir aqui, com a visão da comunidade de Dados Abertos:

  • quais as interpretações errôneas da LGPD mais perigosas
    (na correria e com medo as empresas e governo estão sendo ainda menos transparentes!) ;

  • como ajudar, com apoio de ferramentas públicas, interoperáveis e abertas, aqueles que ainda não se prepararam para a LGPD, ou se depararam com custos exorbitantes de consultoria técnica e jurídica. Por exemplo, como usar a Wikidata, OSM, CNPJ ou Diários Oficiais para tomar decisões sobre a LGPD, transparência e publicidade na sua empresa ou organização.


Nota: apesar das penalidades da LGPD incidirem sobre a empresa, precisamos pensar no Mercado (ecossistema) como um todo, e ter a percepção de que esse tema também impacta o cidadão comum. Queremos as três coisa no Brasil: empresas mais eficientes, empresas mais transparentes e nada de repasse de “custo LGPD” para o consumidor final. Além disso, teoricamente, somos também donos, somos co-proprietários de uma fração das bases de dados pessoais das empresas.

1 Curtida

Entre as consequências de interpretações errôneas mais perigosas, está a remoção de mecanismos de transparêcia e a descontinuidade da publicação de dados abertos.

E que interpretações errôneas seriam estas?

  1. Confundir dados isolados com os dados vinculados;

  2. Remover dos mecanismos de transparência todos os dados ao invés de remover apenas os vínculos e/ou dados que possam sugerir vínculo.

  3. Remover os mecanismos de transparência por completo ao invés de isolar apenas os dados sensíveis dos dados públicos, e criar meios para a circulação segura (sigilosa) de dados sensíveis.

  4. (… sugira outras com base em casos reais!)


Ilustrando

Um dado público típico, que tem apresentado sumiço saltando aos olhos, é o endereço postal. Por exemplo, se a prefeitura ou minha empresa publicar abertamente, no seu site, uma listagem de endereços postais não é problema para a LGPD (!). Pode até ser uma planilha CSV ou Excel com mais colunas,
por exemplo <cidade, nome_da_rua, numero_predial, data_atualizacao>

Se, todavia, acrescentamos na mesma listagem uma coluna CPF (Cadastro de Pessoas Físicas), cada linha passará a caracterizar o CPF como morador ou proprietário daquele endereço: aí sim, o dado se torna um dado sensível e sujeito aos termos da LGPD. O mesmo aconteceria se, ao invés de CPF usarmos nome da pessoa (mesmo não sendo tão preciso vai caracterizar um vínculo).

Pegadinha: e se incluirmos uma coluna que é meramente um identificador (ID) interno e exclusivo do banco de dados da empresa, digamos id_pessoa, mas por descuido a empresa publica no seu site uma listagem de nomes com respectivos IDs… Para evitar esse risco recomenda-se não colocar a coluna id_pessoa na listagem de endereços publicada no site.

Resumindo: a LGPD é muito clara quando à necessidade de os dados estarem estabelecendo vínculo com a pessoa natural, e não existe risco ao se publicar dados isolados, tais como listas de endereços postais, desde que estejam realmente livres de vínculo (com dados pessoais dentro do mesmo dataset).

1 Curtida

Considero que hoje em dia as mais poderosas ferramentas abertas, que podem nos auxiliar efetivamente a garantir conformidade com a LGPD, são o padrão RDF da Web Semântica, as linguagens SparQL e SQL, e a Wikidata. Estão todas imersas num ecossistema bastante estável e totalmente interoperável. Vejamos como…

Como a Wikidata pode ajudar a descobrir quais dados da minha empresa são dados sensíveis no âmbito da LGPD!?


Receita através de exemplos

O algoritmo a seguir pode ser automatizado, não se assuste, a intensão aqui é demonstrar a aplicabilidade e relevância das ferramentas.

Primeiro passo. Experimente essa consulta SparQL na Wikidata. Basta seguir o link e clicar no play.

      lixo22

No resultado você vai encontrar todos os conceitos, elencados e não-elencados explicitamente na LGPD. Podemos portanto apelidar essa lista de itens LGPD. Eles foram atribuídos por suas relações semânticas, e são consistentes com todo universo de conceitos geridos e bem definidos pela Wikipedia. Ou seja, agregam conhecimento universal auditado por uma comunidade de milhares de experts e usuários.

Por exemplo o conceito de “orientação religiosa da pessoa” é definido univocamente como conceito Q9174, e como uma subclasse de sistema de crenças (Q5390013) e ideologia (Q7257)… Ou o conceito bem mais objetivo de número de telefone (Q214995), uma subclasse de identificador (Q853614) e de endereço de rede (Q4418000).

Como isso foi possível? Simples, todos os ~20 conceitos listados são subclasse também do elemento-chave da LGPD, o conceito de dados pessoais (Q3702971). A consulta SparQL seleciona todos os itens da “enciclopédia RDF Wikidata” que satisfazem a frase:

Item é subclasse (P279) de dado pessoal (Q3702971).


Segundo passo. Vamos então organizar esses resultados em dois grupos, “Caracterização da pessoa natural” e “Potencial informação sensível”. Como vimos na discussão acima, a LGPD só considera sensíveis os dados pessoais quando vinculados à pessoa natural.
Precisamos identificar esses dois grupos para, só então depois, conferir se eles ocorrem vinculados na base de dados da empresa.

Caracterização da pessoa Potencial informação sensível
Documento de identidade:      
• Cartão de RG
Certidão de nascimento
Identificador:
CPF
Nome pessoal
 
… 
 
 
 
 
 
 
 
 
Orientações:
Religiosa
Sexual
Localização física:
endereço postal residencial ou de trabalho
Localização eletrônica:
IP da rede onde a pessoa se conectou
Número de telefone
Endereço de e-mail pessoal
Conteúdo legalmente sigiloso:
Senhas de acesso pessoais
Prontuário médico
Anamnese (histórico médico)
Catamnese (histórico de acompanhamento médico)
Identificador biométrico
Outros conteúdos:
Data de nascimento
• …

      Nota: a listagem acima não é completa, se alguém se animar criamos uma em planilha.

Exceto pelo grupo “legalmente sigiloso” das potenciais informações pessoais, sem a vinculação com a pessoa, todos os demais itens isolados podem ser públicos. Por exemplo uma listagem de “datas de nascimento mais frequentes no Brasil” é um dado público.


Terceiro passo. É o momento mais técnico e suado da nossa receita, incluir descritores semânticos no banco de dados da empresa.

Bancos de dados típicos (SQL) são conjuntos de tabelas, análogas planilhas CSV ou Excel, onde cada coluna tem um nome, conhecido como “nome do campo” ou “nome da coluna”. De agora em diante a sua empresa vai precisar catalogar esses nomes de coluna da seguinte forma:

  • Escolher vocabulários complementares à Wikidata (prefixo wd), e seus prefixos. O mais popular entre os arquitetos de bancos de dados é o Schema.org (prefixo sh), mas podem ser qualquer outro da preferência da empresa ou sua especialidade.

  • A cada tabela determinar as classes semânticas que se aplicam a ela. Por exemplo a tabela Clientes que lista nome, telefone e CNPJ de clientes pode ser classificadas como ambos sh:Organization e wd:Customer. Já a tabela Colaboradores que lista os nome, CPF e data de nascimento dos funcionários seria classificada como sh:Person e wd:Employ.

  • A cada coluna deterninar aproximadamente o seu significado: por exemplo nome, tanto de pessoa como de organização, é a propriedade sh:name. Já o números de CPF e de CNPJ podem ser associados precisamente com o vocabulário Wikidata, ou aproximadamente com o seu genérico no vocabulário SchemaOrg, o sh:vatID.

Nota técnica 1: a Wikidata comporta uma infinidade de outros vocabulários através da declaração de equivalência semântica.
Por exemplo nesta parte da Wikidata declara-se a equivalência wd:Personsh:Person.
Quando essa equivalência é reconhecida de ambas as partes, dizemos que há uma “ponte semântica” sólida entre os vocabulários. Por exemplo a ponte SchemaOrg-Wikidata ou OpenStreetMap-Wikidata.

Nota técnica 2: para efeitos de discussão aqui como tag semântica não precisamos, mas existe a sutileza de se diferenciar propriedade de classe. Por ex. na Wikidata a classe wd:Telephone = wd:Q214995 designa o aparelho, enquanto a propriedade wd:telephone = wd:P1329 designa um valor de número de telefone.
Na Wikidata as propriedades são apenas para a gestão interna do banco e dados, possuindo sempre seus equivalentes conceituais. Por ex. a classe wd:PersonName (Q1071027) e a propriedade wd:personName (P1559).


Quarto passo. Enfim, agora que o trabalho duro foi realizado, resta conferir na seguinte sequência:

  1. A cada tabela, conferir se sua semântica bate com um dos itens LGPD (listagem do primeiro passo). Se for “caracterização da pessoa natural” já pode ser eleita como dado sigiloso. Por exemplo a tabela inteira de Colaboradores seria caracterizada como sensível. Não aprece tão óbvio, mas uma tabela que guarda cópias de certidões de nascimentou ou de históricos médicos, mesmo não tendo colunas específicas, se caracteriza como dado sensível.

    1.1. Se a tabela parece “inocente”, sem dados sensíveis, importante submeter ao próximo passo, varrendo coluna a coluna antes de afirmar que não tem nada sensível.

  2. (nas demais tabelas) A cada coluna conferir se sua semântica bate com um dos itens LGPD.
    Isso requer testar a propriedade sozinha (por exemplo sh:telephone já bate), como a propriedade da coluna no contexto de cada uma das classes da tabela. Por exemplo, o que faz a propriedade sh:name da coluna nome da tabela Colaboradores se transformar em wd:personName é o fato da coluna nome estar contida numa tabela classificada como sh:Person.

  3. (nas demais colunas e tabelas) Refazer 1 e 2 considerando o conceito “mais geral” ou “mais específico”, caso seja nececessário um “pente fino” ou a atribuição semânica não tenha sido muito precisa.

  4. Entre tabelas e colunas associadas a itens LGPD do grupo “Potencial informação sensível”, verificar se na base de dados há vínculo com itens LGPD do grupo “Caracterização da pessoa”. Se houver, é dado sensível.

  5. Tratar exceções:
    5.1. se no contexto da publicação do dado há risco do público deduzir.
    Por exemplo havendo menos de 10 linhas em uma inocente “listagem de endereços dos funcionários do departamento X” pode-se alegar vínculo por todos conhecerem quem são as pessoas do departamento.
    5.2. se houver comprovação de que é “pessoa pública”, com os mesmos dados (vinculados ou não) já publicados pelo governo por exemplo em Diário Oficial ou CNPJ.
    5.3. … Outros tratamentos, tais como anonimização, caso seja constatado risco de vínculo.


Resumo

Os chamados “catálogos de dados” do banco de dados, quando baseados ou enriquecidos por tags semânticas padrão RDF, podem executar algorítmos similares aos descritos acima.
Tecnicamente as tags podem ainda ser auditadas por evidência estatística baseada em profile dos dados, revisão por terceiros, etc.

É uma abordagem interessante e que tem as suas vantagens. Porém, discordo que isso seja algo “sem custo”, como afirmado no título. O trabalho de interpretação humana da semântica de cada tabela e coluna estará presente em qualquer caso: com ou sem o mapeamento para vocabulários conhecidos.

Contudo, realizar o mapeamento como você propõe custa mais, pois a pessoa terá que consultar os vocabulários usados pela comunidade (schema.org, Wikidata, etc.) e registrar o mapeamento de uma forma metódica e organizada. Tudo isso pressupõe a existência de um grau razoável de maturidade na governança de dados. A realidade é que muitas organizações não sabem nem quais são os bancos de dados que possuem, quanto mais ter definidos os responsáveis, o ciclo de vida dos dados, a documentação semântica das tabelas e colunas, etc.

Não há dúvida que mapear semanticamente os bancos de dados traria vantagens, como por exemplo criar um conjunto de dados que pode servir mais tarde para, por exemplo, treinar algoritmos de aprendizagem de máquina. A questão é nem toda empresa pode considerar que o retorno futuro valerá o investimento.