Governança e Gestão de dados na prática-Parte I

Introdução:

Com o crescimento do volume de dados, há uma clara percepção de que as empresas já estão atrasadas com relação a um olhar mais cuidadoso em direção aos seus problemas potenciais de dados. A isso se acrescenta a potencialização dos riscos e das consequências tecnológicas e gerenciais que chegarão com o desembarque de outras tendências apontadas, como Big Data e IoT, que para muitos tipos de  “business” mudarão a escala dos dados e as dimensões dos problemas por eles gerados.

Uma das formas mais simples de se buscar entender qual a situação atual de uma empresa com relação aos seus dados é através de dinâmicas entre grupos, com discussões sobre dados. Isso convoca os envolvidos principais a participarem de forma mais aberta e não define soluções monocráticas, especialmente sobre um ativo sensível e capilarizado, como são os dados de uma empresa. Como estão os nossos dados mestres na empresa?, numa visão mais vertical, ou Como minimizar os riscos de compliance dos nossos dados, junto aos nossos reguladores? Ou Como vamos pensar na definição de um Escritório de dados (DMO), a partir de um grande projeto de BI! , seriam exemplos de temas que podem abrir discussões nesses caminhos . Envolve-se, dessa forma, os diversos “stakeholders” em sessões de discussões e aprendizados colaborativos. São ações sempre muito ricas e que trazem “insights” importantes, clareando problemas e dores vigentes, manifestadas pelas áreas convidadas. Essas dinâmicas produzem formas interativas de identificações da “dores” (OnCotô, no mineirês) e proposições de soluções(Proncovô, idem), e que são apenas táticas simplificadas e lúdicas de memorização. Ganha-se aqui, pela abertura das discussões e pelo envolvimento de áreas, criando caminhos para apoios e patrocínios de mudanças que podem não ser tão triviais de serem implementadas, sem a digital de muitos do alto escalão da empresa.

Outra forma, não excludente desta, é a aplicação de abordagens mais formais de Assessment de dados. Nesse caso, aplica-se os modelos diretos ou derivados, por exemplo do  DMM-Data Management Maturity Model, ou do DAMA-DMBOK, como elemento de avaliação mais formal e estruturada. Ambas aproximações, oferecem, via seus conceitos e resultados, uma visão sobre o estado da empresa com relação às suas práticas de dados e de Gestão de dados e podem ser aplicadas em conjunto. Uma, via métodos mais formais, formatados e estruturados(DMM, DMBOK), enquanto a outra mais interativa, lúdica e colaborativa, como o MGD-Canvas com UAAI-Learning.

Nos artigos dessa série, focaremos, de início,  na abordagem mais cooperativa e interativa do MGD-Canvas, método que estamos aplicando há mais de 4 anos em empresas consultadas e em laboratórios de cursos de pós-graduação e treinamento “in-house”.

Comece por : Escolher o tema/problema:

De início você deverá escolher com cuidado o tema das dinâmicas. Pense sempre primeiro no Why(Por quê). Problemas de dados, podem ter amplitudes variadas, gravitando sobre pontos específicos. O mais recomendável aqui é ter uma visão gerencial de quais problemas de dados são os mais críticos, percebidos e sentidos, mesmo com uma lupa que não esteja tão calibrada.(Por que os projetos de BI não trazem os resultados esperados?)  ou dores mais genéricas(Por que temos problemas de ambiguidade no significado dos dados e como melhorá-los?). Para ilustrar o artigo com experiências reais, cataloguei abaixo, uma lista de problemas de dados, observada nessas diversas dinâmicas, das quais participei, como consultor:  Basta olhar cuidadosamente que você verá que as empresas apresentam um conjunto padrão de problemas de dados, às vezes mascarados por nomes diferentes, mas iguais na sua essência. Ao longo desses vários anos de aplicação do MGD-Melhoria de Gestão/Governança de Dados, temos observado problemas comuns nas  diversas empresas, os quais seguem sintetizados abaixo:

a)A empresa não possui controle sobre os seus dados(acesso a relatórios ou aos bancos de dados existentes).Por vezes, há acessos indevidos e questionamentos sobre essa fragilidade;

b)Não há uma plena visão das necessidades de dados da organização;

c)Não há definição formal para o significado dos dados. Não há padrão definido para as descrições dos dados. Não há um Dicionário de dados ou Glossário onde se tenha definições formais do significado dos dados. Não há padrões de apresentação ou de visualização dos dados;

d)Os dados, quando muito, estão definidos em modelos de Entidades e Relacionamentos-DER simples, não constituindo uma visão conceitual confiável em termos de uma arquitetura sustentável de dados;

e)Não há uma área formal de GD-Governança de dados,  e as empresas resolvem os problemas relativos aos dados quase sempre de forma reativa;

f)Há claramente redundância de dados, manifesta pela presença duplicada do mesmo dados em fontes diferentes ou de fontes duplicadas de dados, em áreas de negócios diferentes;

g)Há erros de cálculos de alguns indicadores/métricas, resultantes de problemas de redundância e inconsistência de dados das fontes;  

h)Há uso de tecnologias inadequadas para armazenamento de dados( por exemplo, uso de DBASE com 1 GB), associado com Access (Sim ainda existem, acredite..);

i)Empresas possuem uma variedade grande de tecnologias armazenando dados, que provavelmente estão com redundância não controlada (Sistemas legados, Excel,Access, ou mesmo Bancos SQL). São os chamados “Silos de dados”. Cada solução tem suas camadas de dados e não há consistência e integração entre elas, havendo multiplicidade de dados mestres. Alguns desses dados mestres estão desatualizados, na espera da implantação de uma solução de MDM ou de CRM, por exemplo;

j)Não há uma camada para BI-Informações analíticas, nem soluções mais inteligentes de “analytics”, para, por exemplo, realizar estudos mais elaborados de prospecção de clientes, devido, por exemplo, aos problemas de silos de dados;

k)Os dados não estão associados claramente à iniciativas de negócio;

l)Empresas possuem sistemas de BI, com relatórios definidos, porém, não garantem a veracidade dos dados(indicadores e métricas) produzidos, devido à baixa confiabilidade dos arquivos fontes mestres;

Há, nesse segmento, uma pluralidade de relatórios, cujo conteúdo, objetivos e responsáveis não estão plenamente identificados(falta a figura do owner/responsável pelo dados, ou de seus gestores);

m)Empresa sujeitas a regulamentações produzem informações a serem enviadas para organismos controladores, mas não garantem a veracidade das informações passadas. Há aqui, um alto risco em termos de “compliance”;

Conclusão: Aqui se percebe um conjunto(provavelmente comum) de problemas encontrados em diversas empresas, acerca de seus dados, independentemente do seu “business”. Você que leu até aqui, provavelmente identificou muitos. Há outros tantos. É importante entender e não esperar soluções mágicas, vindas de tecnologias revolucionárias  ou de processos milagrosos ou Canvas inovadores. Botar a ordem nos dados de uma empresa é tarefa árdua e exige caminhos cuidadosos, muitos deles começando com a letra P, conforme falaremos adiante: Problemas(entendimento do Why ), definição de  Patrocínio(depois que os problemas estão claros e os caminhos delineados para resolvê-los, buscar apoio, com foco no Who), Processos, Padrões e Políticas  consensadas, aprovadas e seguidas ( é o primeiro detalhamento do How(Como). A Gestão e a Governança de dados tratam disso. Sobre  a sua aplicação prática, continuaremos a falar nos próximos artigos.

Os 10 principais problemas em projetos de BI e a Governança de dados(GD).

Fiz a 4 grandes amigos/parceiros e excepcionais profissionais de BI(Priscila Matuck, da Unimed-BH, Gideão Neri, da Nexx Tecnologia e coordenador de BI do Hermes Pardini, Marcelo Lamounier, da MG-Info, especializada em serviços de BI para grandes empresas e Rafael Piton, um dos principais nomes do Agile BI & Analytics no Brasil) uma simples pergunta : Quais são os principais problemas que vocês enfrentam(na vida real), implantando grandes projetos de BI? O meu objetivo, neste texto, é alinhavar esses fatores apontados pelos especialistas de hoje, com os aspectos de Governança de dados que temos desenvolvido e verificar como a GD pode influenciar positivamente num projeto de BI.  Houve respostas que variaram, mas a maioria convergiu. Para cada uma delas, estabeleci o racional abaixo, sobre como um Projeto de BI e as propostas de GD se alinham, na mitigação e resolução de problemas:

1) Falta de patrocinador forte em projetos de BI

Considerações: Em muitas empresas, os projetos de BI nascem por inspiração da gerência tática ou operacional e não necessariamente de uma estratégia alinhada e definida pelos negócios. Uma das grandes ações da GD é estabelecer uma estrutura, onde stakeholders importantes participem das decisões de “dados” da empresa. O P do Patrocínio(um dos P´s da GD, conforme definimos, já há tempos) é um dos mais fortes elementos para a implementação de GD. A presença de uma área forte de GD certamente vai alavancar soluções em direção a projetos de dados estratégicos e BI é um deles. O patrocínio de GD se reflete no patrocínio de BI e de outros projetos de Dados, como MDM, Qualidade, Segurança, Compliance, etc.

2) Há uma falta de clareza ou conhecimento das regras de negócios

Considerações: As regras de negócios, num ambiente de GD devem estar definidas num Glossário de negócios, repositório central onde dados e definições organizacionais habitam, diferentemente dos Dicionários de dados, mais focados no plano físico. As regras de negócios, que envolvem dados básicos ou derivados estarão definidas, com uma semântica comum à organização, ou com suas variações consentidas e consensadas. Nessa Plataforma(outro P da GD), residirão os dados, mantidos por definições de gestores de dados das diversas áreas organizacionais, que participam de Comitês de gestão de  dados, onde diferenças semânticas são resolvidas e convergências obtidas.

3) O BI é uma camada vitrine e por vezes apresenta dados com erros

Considerações: Esse é o mais clássico dos problemas de dados de BI. O famoso Garbage-in->Garbage-out. Como a camada de BI é predominantemente transformadora dos dados transacionais, mestres e referenciais, os seus resultados serão diretamente proporcionais à qualidade dos dados encontrada na organização. A GD(Governança de dados) atua fortemente atrelada às áreas de gerências de dados, como BI, BD,MDM, Qualidade,etc. A GD, neste relacionamento,  funciona como um ente legislativo e judiciário dos dados, enquanto as respectivas áreas de gerências(BI, BD, Qualidade, etc), tem o papel da camada executiva. Se, por Políticas(outro P da GD), há a definição de que os dados de certos domínios deverão passar por Processos(outro P da GD) de Profiling de dados, resultará que estes, quando chegarem às portas do BI, estarão com maior probabilidade de qualidade nas suas diversas dimensões(integridade, completude, precisão,etc). Dessa forma, a GD, por Políticas fortes, pode antecipar a mitigação/detecção de problemas de dados e processos, minimizando o fenômeno garbage-in/garbage-out.

4) As empresas ainda desconhecem o potencial das ferramentas e muitas compram essas tecnologias  por impulso, ou por sedução de marketing. E olhe que essas tecnologias são caras...

Considerações: A GD ajuda a definir, no âmbito das diversas gerências, o conceito de Políticas, conforme já referenciado aqui. Políticas são regras normativas  e direcionadoras que foram definidas, por consenso, em função de princípios estabelecidos na organização. Políticas relativas à aquisição de ferramentas e tecnologias de dados certamente estarão presentes nas empresas com maior maturidade em Governança e Gerência de dados. Normalmente há políticas atreladas a Dados Mestres, BI, Qualidade de dados, Segurança, etc e , dentre elas, algumas que regulam a escolha e aquisição de ferramentais daqueles domínios. Há mais de 40 anos na área, já vi várias ocorrências de empresas que compram ferramentas e depois  perguntam o “porquê”.

5) O BI é uma função de Negócios ou de TI?

Considerações: Com a chegada da GD, há uma forte tendência de se deslocar a responsabilidade sobre os dados para as áreas de negócios. Os dados pertencem sim, ao negócio. Isso, entretanto, não deve restringir uma forte participação da TI como custodiadora técnica dos dados(onde eles são armazenados, protegidos e controlados fisicamente). Para isso, a GD define os papéis de Gestores de dados de negócios(aqueles da área de negócios, próximos do Owner dos dados, que são os que tem responsabilidades/accountability sobre eles). Para isso também a GD define, com a TI, os gestores técnicos/operacionais de dados(DBA´s, analistas de BI) e esses dois grupos em conjunto (Gestores de dados de negócios e Gestores de dados técnicos)  buscam a harmonia da melhor solução.

6) Por vezes os gerentes/usuários das áreas clientes do BI não tem a perfeita noção do que precisam; às vezes querem algo como as planilhas excel com as quais estão acostumados a trabalhar.

Considerações: Aqui reside o problema da eterna lacuna do “Why”. Dentre os elementos do 5W2H, o Why é um dos melhores indicadores e deve ser sempre o primeiro a ser perguntado. A GD, quando existente na empresa, tem na figura dos Gestores de dados de negócios(residentes nas áreas de business) os grandes guardiões do Why. Por conhecerem bem o negócio naqueles domínios onde gravitam e por serem gestores de dados com formação, tornam-se fundamentais para alinhar o desejo de suas gerências com a efetiva necessidade dos negócios da área.

7) Por vezes o BI é implantado mas a sua utilização não é efetiva ou torna-se muito mais um custo(liability) do que uma solução.

Considerações: Aqui pode-se pensar no P (de Performance) da GD. A Performance é a medida efetiva dos resultados produzidos pela implementação de uma abordagem de GD(Governança e Gerência) de dados. Advém da antiga máxima de que só se gerencia o que se mede. A implantação de um Sistema de dados(BI, MDM,QD,etc) deverá vir sempre lastreado por Políticas que definam a sua real utilização, em pró do negócio. Alguns motivos citados acima, podem justificar o baixo uso/efetividade do BI. O importante é a monitoração desta performance, para se entender os reais motivos e ajustá-los, caso possível, ou aprender as lições para o próximo projeto de BI. Ferramentas mal avaliadas, Requisitos de BI pobremente definidos, qualidade de dados que afetam a credibilidade dos indicadores, podem ser detectados e transformados em lições futuras.

8) Faltam definições claras sobre a semântica dos dados e as responsabilidades sobre eles.

Considerações: Este é um dos grandes objetivos da GD. Definir formalmente responsabilidades (e accountability-responsabilidade final) sobre os dados. Cada elemento de dados fundamental da empresa(ou um conjunto deles, ou a Entidade mestre relativa a eles), terão um gestor responsável. Esse profissional será o gestor daquele dado, trabalhando com o Owner do dado(normalmente a unidade organizacional onde o dado é originado ou mais impactada pela sua qualidade). A responsabilidade implica na manutenção correta dos metadados acerca dele (de dados e de processos), bem como todos os cuidados relativos a qualidade do seu conteúdo. Os elementos de BI, como dados básicos ou métricas derivadas (Tabelas Fato), regras de derivação, hierarquias de dimensões com seus atributos, regras de transformações e conversões, são dados/metadados que compõem esse portfólio de responsabilidade dos gestores de dados.

9)Há nítidos erros na confecção de modelos dimensionais de dados.

Considerações: Os erros de modelos dimensionais poderão ser tratados e mitigados pela GD através de Políticas de treinamento de dados, bem como de aplicação de processos e procedimentos(outros P da GD) de QA-Quality assurance, ou garantia da Qualidade, que constarão de revisões técnicas de verificação e validação. Um QA aplicado com método, melhora a qualidade dos artefatos/insumos de um projeto de BI. 

10) Por vezes o BI entrega algo que o cliente não quer ou não vai usar ou as entregas podem levar meses ou ano.

Considerações: Há claros ganhos na adoção de métodos ágeis em Projetos de BI, pelas características de maior aproximação de usuários com a solução em desenvolvimento. Sprints menores, com entregas definidas garantem esses ganhos. A presença dos gestores de dados de negócios na equipe de Scrum, potencializa essas melhorias, pela comunicação estabelecida, pela documentação correta dos elementos de BI nos glossários de negócios e pelo maior comprometimento e coesão da equipe TI e de negócios.  

GDPR: General Data Protection Regulation-Parte III-final- A Governança de dados e a GDPR.

A GDPR, certamente, vai mudar o cenário da Governança de Dados(GD) e de seu relacionamento com os aspectos de segurança e privacidade. Esses conceitos sempre fizeram parte dos processos de Gestão de dados, conforme o diagrama do DMBOK e   outros frameworks de dados. O que aconteceu foi que os hackers prestaram um serviço “involuntário”  a esses conceitos, antecipando a necessidade de se trabalhar mais intensamente segurança e consequentemente privacidade, antes do amadurecimento da GD. Assim, muitas empresas já tem núcleos de Segurança, mesmo sem ter ainda formalizada a presença da GD nas suas estruturas. Dessa forma, o casamento entre ambas(GD e Segurança) passará a compor um foco mais integrado, onde também entrará a figura do CDO, caso haja. Por exemplo, dentro da Gerência de Segurança temos processos de  Gerência de Incidentes de Segurança (vazamentos, impactos, etc), Gerência de mudanças(via mudanças é que também se introduz brechas de segurança nos dados), Gerência de Riscos(ação proativa para se mitigar e contingenciar riscos de dados) e Gerência de Correções(garantir que se corrigiu corretamente o que deveria ).

Visão prática do casamento de GD-Governança de dados com a GDPR:

Se analisarmos os principais  P´s da GD, conforme temos discutido ao longo desses últimos anos (ver figura-03), veremos que há vários deles com perfeito encaixe nos aspectos de GDPR :

Patrocínio: Esse será o mais fácil deles, pois envolverá aspectos de alto risco de multas e arranhões na reputação. As multas aplicadas pela UE poderá chegar até a 20 milhões de euros ou 4% do faturamento bruto anual, o que for maior. Assim, analisadas as condicionantes da empresa e seu encaixe nas premissas da GDPR, o patrocínio deverá ser obtido com facilidade, pelo tamanho do risco desenhado;

Políticas: Aqui entrarão as diversas políticas de segurança e privacidade de dados, algumas já em curso nas empresas. O detalhe é que, deverão ser rigorosamente observadas em função das penalidades aplicadas para “no-compliance”. Por exemplo, haverá políticas para definição de consentimento(autorização),políticas para definir ações de notificação de incidentes de segurança, escolha dos elementos  processadores, etc;

Processos: Alguns processos novos deverão ser desenvolvidos/revistos com foco nas exigências da GDPR. Processos de registros de incidentes(tipo ITIL), Processos de Mudanças com foco em preservação de dados PII(Personal Identifiable Information), Processos de Riscos, como DPIA-Data Protection Impact Assessment,etc. Os Processos de negócios também serão analisados visando a identificação dos PII  e como estes serão atualizados, usados e comporão relatórios, etc . As áreas que são responsáveis pelos processos e seus dados, apontarão os Owners de dados e potenciais gestores, sendo que nesse caso, o foco é Privacidade e Segurança. Os Procedimentos são os detalhes , dentro de um Processo específico, podendo ser fatorado e usado em vários outros;

Padrões: Padrões sobre dados de PII deverão ser definidos a fim de proporcionar melhor controle sobre os dados. Padrões sobre criptografias, ou anonimização de dados serão definidos neste contexto;

Papeis/Pessoas: A GDPR , por certo, exigirá a definição de gestores de dados de segurança e privacidade, para os dados mais críticos, dentro do contexto de PII. A criação de um grupo de gestores envolvidos com segurança e privacidade, com o rótulo de CPO-Chief Protection Office poderá ser definido como um adendo do CDO, trabalhando com a área de GD; 

Palavras(adaptado para Comunicação): é uma abordagem fundamental, pois ajuda na divulgação de um Programa fundamental como este. Envolverá mecanismos de conscientização sobre a criticidade do GDPR, o envolvimento de todos e o alinhamento com as ações em desenvolvimento, sempre visando à minimização dos riscos;

Performance: cuidará de medidas e indicadores sobre os principais processos e sua aplicação na empresa. Apontará números de incidentes, valores acumulados de multas, problemas judiciários envolvidos, problemas com processadores, evolução do número de  representantes,etc ;

Abordagem da Governança de Dados:

Os principais passos de uma abordagem de GD em conjunto com a GDPR são, conforme a figura-04:

1-Levantar e analisar os processos de negócios que tratam dos dados PII

2-Identificar e catalogar, no Glossário de Negócios, os dados PII, com detalhamento de  ciclo de vida, envolvendo Processos, Dados,  Tipos de processamentos(criação, modificação, eliminação), regras de retenção, etc

3-Identificar  e catalogar os dados indiretos que, por hipótese, podem sugerir ou levar aos dados PII

4-Definir uma estratégia de Privacidade e Segurança, alinhada com a Estratégia de Dados e a de Negócios da empresa. Os aspectos de Segurança e Privacidade passam a compor uma visão mais alinhada com a estratégia da organização

5-Definir, baseado nos passos anteriores as áreas responsáveis(data owners) e gestores para os dados PII e indiretos, atribuindo “acccountability” e responsabilidade para esses envolvidos

6-Considerar na MDS-Metodologia de Desenvolvimento de sistemas, seja agile ou tradicional, os aspectos de “Privacy by design”. Isso significa que as considerações sobre Segurança e Privacidade deverão, agora, ser tratadas já no nível de projetos de sistemas e não mais a posteriori. Considerar a possibilidade do uso de técnicas de criptografias, anonimização de dados,etc, como parte do design

7-Definir o P da Performance, estabelecendo medidas e indicadores de controle e de “compliance”. Esses indicadores deverão ser tratados como metadados e armazenados no Glossário/Repositório dos dados

8-Considerar a integração entre Segurança e Privacidade dos dados com outras dimensões da Gestão de dados como: Qualidade dos dados , Gerência de Metadados, Gerência do Ciclo de vida dos dados e Gerência de Risco de dados. A gerência de Qualidade dos dados assegurará que os dados de PII estão no nível mais atualizado e precisos. A Gerência de Metadados garantirá que os dados estão plenamente descritos com todos os seus elementos de identificação, definição e classificação. A Gerência de ciclo de vida dos dados garantirá o entendimento dos processos e fluxos de dados, com a percepção de potenciais transformações aplicadas neles. A Gerência de Risco garantirá que os dados estarão mantidos na estrita definição da GDPR, com controles sobre cenários de riscos(probabilidade e impacto), além de  aspectos de contingência e de mitigação.

Conclusão:

A entrada em vigor, a partir de 25 de Maio de 2018 da GDPR, certamente mudará o patamar da Governança de dados, já praticado na Europa. Nos EUA, onde grande parte de empresas de consultoria de âmbito internacional  estão localizadas, esse exigente protocolo de Segurança e Privacidade já começou a ser profundamente discutido e já está na tela de radar das empresas de consultoria em dados. Essa tendência deverá ser seguida por outros países, que se fortalecem, nesse momento, com o desenvolvimento de práticas de Gestão de dados, como a China, África do Sul, Austrália e Nova Zelândia. O Brasil, em função do nosso momento, ainda engatinha nessas práticas. Empresas brasileiras, com mercado global deverão se preparar para esse novo momento. No site da União Europeia, há até um “count down” para o dia em que as empresas deverão estar preparadas. Pense nisso.. 

GDPR: General Data Protection Regulation-Parte II-Visão focal

O GDPR é amplo e complexo. O seu detalhamento está publicado na internet e já há uns 3 ou 4 livros na Amazon publicados sobre ele. Acesse http://www.eugdpr.org/ para começar a entendê-lo. A figura-01 mostra, sinteticamente, os pontos principais das mudanças trazidas pela GDPR.

Objetivo:

O objetivo, mostrado de forma simplificada,  é proteger o chamado PII-Personal Identifiable Infomation, ou seja as informações que permitem identificar alguém. Por exemplo, alguns campos são identificadores  mais diretos como o CPF, SSN, # da carteira de identidade, endereço de email, # do telefone. Outros são identificadores indiretos, como data de nascimento, cep e sexo, etc. Esses campos, claro não permitem (diretamente) chegar a alguém, mas podem, caso combinados, aumentar a chance de se chegar ao seu PII. Há uma pesquisa que aponta que, com a combinação dos três elementos de dados(cep, sexo e data-nascimento), há 87% de chance de alguém ser identificado. A conferir... Além da proteção dos dados,  o GDPR também foca nos direitos de cada cidadão com relação aos seus dados. Por exemplo, a entidade controladora(conceito explicado mais abaixo)  será obrigada a, em poucos dias, notificar o cidadão cujos dados foram desviados. A não observância dessa e de outras regras definidas implicará em multas pesadíssimas (até 4% do faturamento bruto anual ou 20 milhões de Euros, o que for maior). No exemplo citado anteriormente sobre o breach do Yahoo, já estaria caracterizada uma violação dessa natureza.

Escopo: 

O escopo das regras será para as empresas que estão localizadas na UE (União Europeia) e processam dados de residentes de lá, ou também empresas que estejam fora da UE, mas que também processam dados de cidadãos residentes naquela comunidade. Está fora do escopo os casos em que o processamento de dados tem a finalidade de segurança nacional ou atrelado a aspectos legais. Cada estado membro da UE definirá um órgão controlador-SA-Supervisory Authority, que terá a missão de receber e investigar reclamações, ofensas etc, naquele domínio e trabalhará, de forma integrada e colaborativa com as outras SA´s. A UE tem aproximadamente 350 milhões de habitantes, distribuídos por 28 estados(países) diferentes. Os membros da UE estarão subordinados a essa legislação, que prevalecerá sobre outras já, eventualmente, existentes.

Papeis importantes na GDPR:

Há os conceitos de Controladores-Processadores-Autoridade de Supervisão e Representantes. Esses conceitos são muito importantes para o entendimento do GDPR e estão representados na figura-02.

Controladores:

São pessoas, agências, autoridades públicas ou qualquer outro corpo organizacional que tenha como objetivo o uso dos dados coletados. Serão os responsáveis por garantir que os dados serão usados, de acordo com a GDPR. Deverão deixar claro: Quais objetivos procuram, quais dados existem e suas categorias, os meios pelos quais serão usados, a forma de coleta, a forma de busca de consentimento (autorização) para o uso dos dados, a descrição dos destinatários( por quem os dados serão usados), os mecanismos de transferência de dados(entre unidades, países, empresas, etc), além das descrições de processos e técnicas a serem aplicados na segurança organizacional daqueles dados. Acresce-se a isso os planos de riscos devidamente definidos para os dados, envolvendo incidência, probabilidade, impacto , mitigação e contingência. As notificações e avisos obrigatórios sobre o uso dos dados deverão incluir o período de retenção para os dados pessoais e informações de contato dos controladores de dados e  do escritório ou gestores de segurança e proteção, definidos. Aliás, já se usa a sigla DPO-Data Protection Office, para definir um grupo totalmente dedicado a isso. Outro aspecto considerado importante será sobre as decisões automáticas(ações por default), que poderão ser contestadas. Ou seja, um cidadão poderá questionar uma opção (definida automaticamente por um sistema-tipo Optin/out) de coleta de seus dados, caso não haja a sua manifestação explícita de concordância sobre aquilo. Os dados deverão ter seu uso explicitamente consentidos pelos usuários. Os sistemas e serviços deverão ter um Plano definido de Privacidade e Segurança. Por exemplo, um Hospital que coleta os dados de pacientes, via sistema de internação e os complementa via sistemas de informações médicas, será o Controlador desses dados nesse contexto, caso haja dados de cidadãos da UE. Como controlador, deverá responder por todos os pontos definidos anteriormente e deverá estar apto a demonstrar, via GD, os elementos requeridos pela GDPR.  

Processadores:  

São pessoas, agências, autoridades públicas ou qualquer outro corpo organizacional que trabalha, em nome de outro(o controlador). São os contratados para  realizarem serviços de dados definidos e esperados pelo Controlador. Os seus processos devem estar de acordo com as definições do Controlador, que por sua vez estarão coerentes com a GDPR. Um contrato entre essas duas partes deverá regular os requisitos de proteção e privacidade, segundo a GDPR. O “How” dos processos, a serem aplicados não precisam ser detalhados pelo Controlador. Poderá ser definido pelos Processadores, desde que estejam em “compliance” com as regras da GDPR. Dessa forma os Processadores assumirão responsabilidades(em nome dos Controladores), definindo: o sistema(ferramentas-processos e tecnologia) usado, as formas de coleta, armazenamento, transferência dos dados,etc. Definem também como os dados PII serão usados  e apresentarão Planos de retenção, disposal(eliminação de dados), etc . O Processador contratado não poderá subcontratar outro processador, sem a autorização expressa do Controlador. É natural que muitos Controladores sejam também os seus próprios Processadores e assim, as regras e exigências permanecem no mesmo domínio organizacional.

As informações requeridas para os Processadores são: nome, detalhe de contratos, especificação de cada controlador e processador(um Controlador poderá ter n Processadores, e vice versa). Detalhamento dos processamentos realizados para cada Controlador, descrição geral de medidas, técnicas e processos de segurança.  

Autoridades de Supervisão-AS:

São organizações, corpos organizacionais, etc definido pela UE como elementos de supervisão e controle constante sobre a GDPR. Estão geograficamente distribuídas pelos vários (países) da UE e serão as responsáveis pela lupa sobre os Controladores, Processadores e Representantes. Serão uma espécie de QA, com autoridade plenamente instituída.

Representantes:

São uma espécie de “proxy” dos processadores, que não estão na geografia da UE. Assim, os representantes respondem pelos processadores, perante as Autoridades de Supervisão, junto ao solo da UE. Suponha, por exemplo, uma empresa brasileira de tratamento de dados (faça projetos de Qualidade de dados, Dados Mestres, BI, etc) que fará um serviço para a FIAT na Itália. Essa empresa, deverá ter um representante formal naquele pais, ou em algum lugar da UE, que será o elo com as autoridades de supervisão.

Outras considerações importantes:

a)O consentimento(ou a autorização concedida pelo donos dos dados), deverá ser feita explicitamente em termos claros, inteligíveis, sem juridiquês (legalese, em inglês), em um formulário facilmente acessível, com o objetivo do uso dos dados pelos controladores e processadores claramente definido. O consentimento dado poderá ser retirado a qualquer momento, bem como a solicitação de eliminação de dados existentes, porém agora sem relevância;

b)O direito ao acesso, por parte dos usuários, será rigoroso, podendo o dono dos dados questionar os controladores ou processadores se os seus dados estão sendo processados por eles;

c)O direito à portabilidade significa que o dono dos dados poderá solicitar (aos controladores e processadores) os seus dados em uso, entregues em forma digital (machine readable) e transferi-los para outro controlador;

d)O direito à Privacidade por projeto(Privacy by design) diz respeito à consideração desses conceitos(Privacidade e Segurança) serem feitas no nível de projetos e não mais à posteriori.

Como se percebe, as exigências da GDPR elevarão, em muito, os cuidados necessários com os dados de residentes da UE. Isso demandará uma visão organizacional sobre dados(nos domínios de Segurança e Privacidade) e , claro, chegará à Governança de dados e o seu papel fundamental e a importância  dos conceitos aplicados por ela. No próximo artigo, falaremos sobre isso.