Privacidade desde a conceção ao abrigo do artigo 25º do RGPD: Guia de implementação para equipas de produtos e engenharia

O artigo 25.º do RGPD estabelece duas obrigações complementares: a proteção de dados desde a conceção e a proteção de dados por defeito. Não se trata de objectivos ambiciosos. São requisitos juridicamente vinculativos que se aplicam a todos os responsáveis pelo tratamento, passíveis de aplicação de coimas até 10 milhões de euros ou 2% do volume de negócios anual a nível mundial, nos termos do n.º 4 do artigo 83. No entanto, para muitas equipas de produtos e de engenharia, traduzir estas obrigações legais em fluxos de trabalho de desenvolvimento práticos continua a ser um desafio.

Este guia preenche a lacuna entre o texto regulamentar e o desenvolvimento quotidiano de software. Fornece uma estrutura prática para incorporar a privacidade no ciclo de vida do seu produto, desde a conceção inicial até à implementação e mais além.

Compreender o artigo 25.

O nº 1 do artigo 25º exige que o responsável pelo tratamento aplique medidas técnicas e organizativas adequadas para aplicar eficazmente os princípios da proteção de dados e para integrar as garantias necessárias no tratamento. Esta obrigação aplica-se no momento da determinação dos meios de tratamento e no momento do próprio tratamento.

O n.º 2 do artigo 25.º exige que, por defeito, apenas sejam tratados os dados pessoais necessários para cada finalidade específica do tratamento. Isto aplica-se à quantidade de dados recolhidos, ao âmbito do tratamento, ao período de conservação e à acessibilidade. Por defeito, os dados pessoais não podem ser tornados acessíveis, sem intervenção individual, a um número indefinido de pessoas singulares.

As Orientações EDPB 4/2019 sobre o artigo 25.º clarificam que a obrigação de implementar a proteção de dados desde a conceção é um requisito contínuo e dinâmico que deve ser avaliado continuamente ao longo do ciclo de vida do tratamento.

Os 7 princípios fundamentais

A estrutura fundamental de Ann Cavoukian para a privacidade desde a conceção, originalmente desenvolvida na década de 1990, continua a ser o modelo concetual mais amplamente referenciado. Estes sete princípios constituem a base filosófica do artigo 25:

1. Proactivo e não reativo; preventivo e não corretivo. Antecipe e previna eventos de invasão da privacidade antes que eles aconteçam. Não fique à espera que os riscos à privacidade se materializem.
2. Privacidade como predefinição. Garanta que os dados pessoais são automaticamente protegidos em qualquer sistema. Não deve ser necessária qualquer ação por parte do indivíduo para proteger a sua privacidade.
3. Privacidade incorporada na conceção. Integre a privacidade na conceção e arquitetura dos sistemas de TI e nas práticas comerciais. A privacidade não é um complemento.
4. Funcionalidade total: soma positiva, não soma zero. Acolha todos os interesses e objectivos legítimos. A privacidade não deve ser obtida à custa da funcionalidade, e a funcionalidade não deve ser obtida à custa da privacidade.
5. Segurança de ponta a ponta: proteção total do ciclo de vida. Garanta a aplicação de medidas de segurança adequadas aos dados ao longo de todo o ciclo de vida, desde a recolha até à eliminação.
6. Visibilidade e transparência: mantenha-o aberto. Garanta a todas as partes interessadas que os processos que envolvem dados pessoais estão a funcionar de acordo com as promessas e objectivos declarados, sujeitos a verificação independente.
7. Respeito pela privacidade do utilizador: mantenha-a centrada no utilizador. Os arquitectos e operadores devem manter os interesses do indivíduo em primeiro lugar, oferecendo fortes predefinições de privacidade, avisos adequados e opções fáceis de utilizar.

Integração da privacidade desde a conceção em fluxos de trabalho ágeis

A privacidade desde a conceção é muitas vezes vista como incompatível com o desenvolvimento ágil. Na prática, integra-se naturalmente em fluxos de trabalho baseados em sprints, quando abordada corretamente.

Planeamento Sprint

Durante o planeamento do sprint, cada história de utilizador que envolva dados pessoais deve desencadear uma avaliação da privacidade. Adicione uma lista de verificação de privacidade ao seu modelo de história:

• Esta funcionalidade recolhe novos dados pessoais?
• Esta funcionalidade altera a forma como os dados pessoais existentes são processados?
• Esta funcionalidade partilha dados pessoais com novos destinatários?
• Esta funcionalidade envolve decisões automatizadas ou definição de perfis?
• A funcionalidade pode ser implementada com menos dados pessoais (minimização de dados)?

Se alguma das respostas for afirmativa, a história requer uma análise da privacidade antes do início da implementação. Esta revisão pode ser efectuada pelo DPO, por um engenheiro de privacidade ou por um membro da equipa com formação, dependendo da complexidade.

Histórias de utilizador com requisitos de privacidade

Os requisitos de privacidade devem estar explícitos nas histórias de utilizador. Por exemplo:

História de utilizador padrão: "Como utilizador, quero ver o meu histórico de encomendas para poder acompanhar as minhas compras."

Privacidade reforçada: "Como utilizador, quero ver o meu histórico de encomendas para poder acompanhar as minhas compras. Critérios de aceitação: (1) Apenas são apresentadas as encomendas pertencentes ao utilizador autenticado. (2) Os dados da encomenda são recuperados com os campos mínimos necessários para a visualização. (3) Os endereços de entrega são parcialmente mascarados por defeito. (4) O acesso é registado para fins de auditoria."

Definição de Feito

A definição de "feito" da sua equipa deve incluir critérios de privacidade:

• Lista de controlo da privacidade revista e preenchida
• Minimização de dados confirmada (sem recolha ou retenção desnecessárias de dados)
• Controlos de acesso implementados e testados
• Aviso de privacidade atualizado se for introduzida uma nova recolha de dados
• Retenção de dados alinhada com a política de retenção documentada
• A AIPD é actualizada se a caraterística alterar o perfil de risco

Padrões de minimização de dados

A minimização dos dados (artigo 5.º, n.º 1, alínea c)) é a expressão mais prática da privacidade desde a conceção. Exige que os dados pessoais sejam adequados, pertinentes e limitados ao que é necessário para efeitos de tratamento. Os padrões efectivos de minimização de dados incluem:

Minimização da recolha:

• Recolha apenas os campos necessários para a finalidade declarada
• Utilize a divulgação progressiva: recolha inicialmente um mínimo de dados, solicite dados adicionais apenas quando necessário
• Evite os campos "é bom ter": se os dados não forem necessários para o tratamento, não os recolha

Minimização do processamento:

• Processe os dados ao mais alto nível de agregação que sirva o objetivo
• Utilize a pseudonimização quando a identificação individual não for necessária para o tratamento
• Implemente a separação de dados: guarde os identificadores separadamente dos dados comportamentais

Minimização da retenção:

• Defina e aplique períodos de retenção para cada categoria de dados
• Implemente a eliminação automática ou a anonimização no final do período de conservação
• Reveja anualmente os períodos de retenção e reduza-os sempre que possível

Minimização do acesso:

• Aplique controlos de acesso baseados em funções: os utilizadores só devem aceder aos dados de que necessitam para a sua função
• Implemente o acesso baseado no tempo: acesso temporário para tarefas específicas, automaticamente revogado
• Registe e audite todos os acessos a dados pessoais

Tecnologias de proteção da privacidade

O artigo 25.º e o considerando 78 do RGPD referem especificamente medidas técnicas, incluindo a pseudonimização e a cifragem. Um conjunto mais vasto de tecnologias de melhoria da privacidade (PET) pode reforçar a sua implementação da privacidade desde a conceção:

Pseudonimização (n.º 5 do artigo 4.º):

Substitua os dados de identificação direta (nomes, endereços de correio eletrónico) por identificadores pseudónimos. O mapeamento entre pseudónimos e identidades é armazenado separadamente com controlos de acesso rigorosos. A pseudonimização reduz o risco em caso de violação, permitindo ainda que os dados sejam reidentificados quando necessário para um processamento legítimo.

Encriptação:

Implemente a cifragem em repouso (AES-256 ou equivalente) para os dados pessoais armazenados e a cifragem em trânsito (TLS 1.3) para todas as transmissões de dados. A cifragem torna os dados ininteligíveis para partes não autorizadas e é explicitamente reconhecida pela alínea a) do n.º 3 do artigo 34.º como um fator que pode eliminar a obrigação de notificar as pessoas em causa de uma violação.

Controlos de acesso:

Implemente controlos de acesso granulares e baseados em funções com o princípio do menor privilégio. Combine com autenticação multi-fator para acesso a dados sensíveis. Monitorize e registe todos os acessos para auditoria e deteção de anomalias.

Anonimização:

Quando os dados pessoais já não forem necessários para a sua finalidade original, mas os padrões subjacentes forem valiosos (por exemplo, análise), aplique técnicas de anonimização que impossibilitem a reidentificação. Os dados verdadeiramente anónimos ficam totalmente fora do âmbito do RGPD. No entanto, tenha cuidado: o Parecer 05/2014 do Grupo de Trabalho do Artigo 29.º adverte que muitas das supostas técnicas de anonimização podem ser revertidas com dados auxiliares.

Privacidade diferencial:

Para casos de utilização de análise e aprendizagem automática, a privacidade diferencial adiciona ruído calibrado aos conjuntos de dados para impedir a inferência de registos individuais. Esta técnica permite a análise estatística ao mesmo tempo que fornece garantias matemáticas contra a reidentificação.

Integração da AIPD

A privacidade desde a conceção e as avaliações de impacto sobre a proteção de dados (artigo 35.º) são processos complementares. Quando uma nova caraterística ou sistema desencadeia um requisito de AIPD, a análise da privacidade desde a conceção é diretamente integrada na AIPD:

• A avaliação da minimização dos dados informa a análise da necessidade e da proporcionalidade da AIPD
• A seleção do PET informa a secção de atenuação dos riscos da AIPD
• A conceção do controlo de acesso informa a secção relativa às medidas de segurança da AIPD
• A política de conservação informa a análise da limitação de armazenamento da AIPD

Integre as revisões DPIA no seu ciclo de sprint para funcionalidades que envolvam processamento de alto risco. Isto evita o anti-padrão comum de conduzir DPIAs retrospetivamente, depois de um sistema já ter sido construído e implementado.

Medir a maturidade da privacidade desde a conceção

Para ir além da integração ad hoc da privacidade, estabeleça métricas que monitorizem a maturidade da privacidade desde a conceção da sua organização:

• Percentagem de histórias de utilizadores com listas de verificação de privacidade preenchidas
• Número de funcionalidades implementadas sem análise da privacidade (objetivo: zero)
• Tempo médio para resolver as constatações de privacidade da revisão do código
• Delta de recolha de dados: número de novos campos de dados pessoais adicionados versus removidos por trimestre
• Taxa de conformidade da conservação: percentagem de categorias de dados dentro do período de conservação definido
• Taxa de conclusão da AIPD: percentagem de caraterísticas de alto risco com AIPD concluídas antes da implantação

Criar uma cultura de engenharia da privacidade

O sucesso ou fracasso da Privacy by Design depende do facto de as equipas de engenharia interiorizarem a privacidade como uma restrição de conceção. Isto requer:

• Formação: Formação regular em engenharia de privacidade para programadores, QA e gestores de produtos
• Ferramentas: Ferramentas de linting de privacidade, integrações de mapeamento de fluxo de dados e accionadores de PIA automatizados no seu pipeline de CI/CD
• Campeões: Designe defensores da privacidade em cada equipa de engenharia que sirvam como primeiro ponto de contacto para questões de privacidade
• Incentivos: Reconheça e recompense as decisões de conceção que protegem a privacidade. A privacidade deve ser um atributo de qualidade e não um obstáculo burocrático.
• Circuitos de feedback: Partilhe acções de aplicação da lei, estudos de casos de violação e resultados de auditorias com as equipas de engenharia para manter a consciência das consequências do mundo real

O artigo 25.º não é um exercício de seleção. É um compromisso contínuo para construir sistemas que respeitem a privacidade individual por conceção e por defeito. As organizações que incorporam este compromisso na sua cultura de engenharia descobrirão que a privacidade se torna um facilitador e não um constrangimento: criando confiança no utilizador, reduzindo o risco de violação e demonstrando a responsabilidade que o RGPD exige.