8 Junho 2017

Business Intelligence & General Data Protection Regulation (GDPR)

Após quatro anos de debate e preparação, o Regulamento Europeu Geral de Proteção de Dados (GDPR) foi finalmente aprovado pelo parlamento europeu a 14 de abril de 2016. Entrou em vigor vinte dias após a sua publicação no Jornal Oficial da União Europeia e será diretamente aplicável a todos os estados-membro dois anos depois, a 25 de maio de 2018, momento a partir do qual todas as organizações que não estejam em conformidade serão confrontadas com elevadas multas.

O GDPR, que substitui a Diretiva de Proteção de Dados 95/46/EC, foi desenhado de modo a colmatar a necessidade de uniformização de leis a nível europeu, a responder a uma maior exigência e capacitação por parte dos cidadãos, e finalmente a responsabilizar as entidades que recolhem, tratam e armazenam dados pessoais.

O objetivo do GDPR é o de proteger os cidadãos da UE da violação de dados e de privacidade num mundo com cada vez mais informação, completamente diferente do tempo em que a diretiva de 1995 foi constituída. Sendo os princípios da privacidade de dados os mesmos, foram propostas muitas alterações à política atual. De entre o conjunto de alterações, podemos considerar que as mais relevantes são:

Âmbito territorial:

> Âmbito alargado de território (aplicabilidade extraterritorial);

> Aplicável a todas as entidades que processem dados pessoais de cidadãos da UE, independentemente da localização da entidade.

Penalidades:

> Entidades em violação do GDPR estão sujeitas a multas que poderão ir até aos 4% do valor global anual de faturação ou 20 Milhões de Euros.

Consentimento:

> O pedido de consentimento de tratamento de dados deverá ser apresentado ao cidadão de uma forma clara e de fácil entendimento.

De modo a assegurar a conformidade com o novo regulamento, todas as entidades por ele abrangidas deverão adaptar-se, tendo para isso de criar grupos de trabalho de modo a responder a perguntas pertinentes, como sendo:

> Quais são os processos de negócio que usam dados abrangidos pelo regulamento?

> Quais são os sistemas operacionais e analíticos onde estes dados residem?

> Qual é o ciclo de vida da informação?

> Quais são os processos de transformação aplicados a estes dados?

> Quem acede à informação em cada um dos sistemas?

No âmbito desta discussão iremos centrar-nos nos sistemas analíticos das organizações. Tipicamente, os dados analíticos de uma organização são usados para, entre outros, tomar decisões operacionais e estratégicas, reportar aos reguladores, descobrir tendências de mercado, ou ainda para prever acontecimentos futuros com base em comportamentos passados. Podemos assim entender que grande parte destes dados são da própria organização, como por exemplo dados relativos a todas as ações realizadas pelos seus clientes (encomendas, pagamentos, …), mas também enriquecidas por informação proveniente de providers externos como sendo, por exemplo, macro indicadores relativos ao mercado onde a organização opera, permitindo-lhe comparar a sua performance com a dos seus pares.

Estes dados analíticos estão normalmente disponíveis em Data Warehouses ou em Data Lakes, e são consumidos através de ferramentas analíticas, mas há ainda muitas organizações onde esta não é uma realidade, estando estes dados residentes em ficheiros Excel onde o controle de acesso à informação não é tão efetivo. O controle ao acesso desta informação é um caminho que pode ser percorrido de modo a uma organização tornar-se em conformidade com o novo regulamento, mas será sempre um caminho que tenta remediar uma situação que, para todos os efeitos, não deveria ocorrer à partida.

Contrariamente a um sistema de Customer Relationship Management (CRM) onde é necessário conhecer univocamente os clientes / possíveis clientes, nomeadamente nomes, contactos e moradas, e desenvolver campanhas de contacto direto de modo a alargar a base de clientes ou a desenvolver novo negócio com campanhas de up-sell ou cross-sell, os sistemas analíticos não necessitam desta informação.

As organizações poderão seguir vários caminhos rumo à conformidade com o regulamento, uma vez mais ressalvando que a discussão está centrada nos sistemas analíticos. De entre as várias possibilidades, iremos focar-nos em dois cenários possíveis:

> Aplicar técnicas de mascaramento de dados, apenas para dados sensíveis, aquando da sua entrada nos sistemas analíticos (cenário 1);

> Prevenir que esta informação entre nos sistemas analíticos (cenário 2).

Em boa verdade, tanto análises típicas como análises com recurso a técnicas avançadas (redes neuronais, análises de clusters, análises semânticas) não necessitam dos dados que identifiquem univocamente uma pessoa. Não são necessários nomes ou números de contribuinte para este tipo de análises, o que realmente interessa é conhecer características como o género, a faixa etária, ou a freguesia onde o cliente mora. Porém, estas questões nunca são simples, e poderemos estar perante situações em que os sistemas analíticos fornecem dados a sistemas de CRM / sistemas operacionais. A título de exemplo, após uma segmentação de clientes onde descobrimos que 5% estão em risco de desistir dos serviços contratados, a organização poderá querer desenvolver campanhas específicas para estes clientes, e para isto é forçoso que os conheça. A forma mais fácil será canalizar esta lista de clientes para os sistemas acima mencionados, e não poderão ser enviados dados fictícios. Existem diversas técnicas de mascaramento de dados, incluindo técnicas que permitem o seu desmascaramento através de uma chave. Esta será a opção certa caso a organização opte pelo mascaramento dos dados.


Cenário 1 – Mascaramento de dados

Por outro lado, se este não for o caminho seguido, e se os dados sensíveis não estiverem à partida presentes nos sistemas analíticos, como pode uma organização canalizar a informação necessária conforme o cenário descrito anteriormente? Antes de analisar esta situação, importa referir que os sistemas operacionais e os sistemas analíticos garantem a unicidade dos registos de diferentes formas:

> Sistemas operacionais: são usadas chaves naturais ou de negócio, chaves essas criadas no decorrer do negócio (i.e., número da fatura);

> Sistemas analíticos: uma boa prática nestes sistemas é a criação de uma chave substituta, que normalmente assume a forma de um número inteiro. Estes sistemas mantêm a correspondência entre a chave substituta e a chave natural / negócio.

Outra boa prática no desenho de uma arquitetura de um sistema analítico é a criação de um Operational Data Store (ODS). Esta base de dados poderá, entre outros, ser usada para transferência de dados entre os sistemas operacionais e o sistema analítico, e vice-versa.

Voltando ao cenário descrito anteriormente relativo à inexistência da informação necessária à identificação unívoca de uma pessoa no sistema analítico, esta informação poderia residir apenas no ODS. O ODS é um sistema onde melhor se conseguem controlar os acessos uma vez que tipicamente apenas sistemas, e por conseguinte processos automáticos, é que aqui acedem de modo a transferir a informação necessária. Neste caso, e uma vez que o sistema analítico tem a correspondência entre chave natural / negócio e a chave substituta, a lista que o CRM necessita e que foi apurada no Data Warehouse, pode ser enviada para ODS, neste caso apenas a lista de chaves, e o ODS encarregar-se-ia de enviar ao sistema destino a informação que realmente identifica o cliente.


Cenário 2 – Não inclusão de dados sensíveis nos sistemas analíticos

Estivemos até aqui sempre focados em ambientes de produção, ambientes onde o negócio é realmente desenvolvido e analisado, mas muitas organizações dispõem de ambientes não produtivos, normalmente ambientes de desenvolvimento onde são desenvolvidas novas funcionalidades, e ambientes de qualidade onde estes desenvolvimentos são testados antes de serem migrados para os ambientes de produção. Um dos grandes desafios destes desenvolvimentos é o de se basearem na realidade da organização, ou seja, um desenvolvimento é tanto melhor quanto a qualidade dos dados em que se baseia. Aqui poderá existir um de dois cenários:

> Dados fictícios: as organizações podem optar por disponibilizar nestes ambientes dados que não são reais, podendo estar a colocar em risco a qualidade dos desenvolvimentos uma vez que não são feitos tendo por base a realidade da empresa, sendo ainda necessário algum tempo e know-how para idealizar estes dados;

> Dados reais: as organizações podem optar por transferir um conjunto de dados reais diretamente do ambiente de produção, fazendo com que os desenvolvimentos sejam feitos com base na realidade da organização. Caso não se recorra a uma política de mascaramento de dados nestes ambientes (conforme o cenário 1 apresentado anteriormente), e caso não se opte pela opção da sonegação de informação (conforme cenário 2 apresentado anteriormente), os dados estão a ser propagados para outros ambientes, não nos esquecendo que em muitas situações estes desenvolvimentos são realizados por empresas externas contratadas para o efeito, e aqui para além de disponibilizar dados sensíveis de pessoas a terceiros, ainda se estão a disponibilizar dados sensíveis da própria organização.

Voltando ao início da nossa discussão, as organizações terão se adaptar ao GDPR, e existem várias receitas a aplicar de modo a assegurar a compatibilidade com o regulamento, não havendo uma solução única aplicável a todas as organizações. Cada caso é um caso, e no âmbito deste artigo foram discutidas algumas formas de compatibilizar os sistemas analíticos das organizações com este regulamento. Cabe agora a cada uma avaliar qual a melhor que se adapta à sua situação.

 .
.
.
.
.
.
.
      Sérgio Costa
          Manager
Solutions Development