A proteção de dados desde a conceção (privacy by design) e por defeito (privacy by default) é a obrigação, imposta pelo artigo 25.º do RGPD, de integrar a proteção de dados desde o momento em que se concebe um produto, serviço ou processo — e não a acrescentar no fim. Na prática, significa duas coisas: desde a conceção, o responsável deve aplicar medidas técnicas e organizativas adequadas (como a pseudonimização e a minimização) em toda a fase de desenho; por defeito, os sistemas devem tratar, à partida, apenas os dados necessários para cada finalidade. Este guia traduz o artigo 25.º em decisões concretas de engenharia, produto e compras de software.
Pontos-chave
- O artigo 25.º obriga — não recomenda — a integrar a proteção de dados na fase de conceção.
- A proteção por defeito significa que as configurações iniciais devem ser as mais protetoras.
- Aplica-se a quem concebe processos, não apenas a quem programa software.
- Ao comprar software, exigir privacy by design ao fornecedor é parte do dever de diligência.
O que diz o artigo 25.º
O artigo 25.º tem dois números com lógicas distintas. O n.º 1 exige a proteção de dados desde a conceção: ao definir os meios de tratamento e durante o próprio tratamento, o responsável aplica medidas — técnicas e organizativas — destinadas a implementar os princípios do artigo 5.º de forma eficaz. O n.º 2 exige a proteção por defeito: por defeito, só são tratados os dados pessoais necessários para cada finalidade específica, quanto à quantidade recolhida, à extensão do tratamento, ao prazo de conservação e à acessibilidade.
O n.º 2 é o mais concreto e o mais esquecido: um formulário que traz caixas pré-marcadas, um perfil de rede social que nasce público, ou uma aplicação que recolhe a localização sem necessidade — todos violam a proteção por defeito. As Orientações 4/2019 do Comité Europeu para a Proteção de Dados (CEPD) detalham como aplicar o artigo em cada princípio.
Traduzir o artigo 25.º em decisões de engenharia
A proteção desde a conceção não é um documento; é um conjunto de escolhas técnicas. Eis como se traduz, princípio a princípio:
| Princípio (art. 5.º) | Decisão de engenharia |
|---|---|
| Minimização | Não recolher campos «úteis um dia»; separar dados identificáveis |
| Limitação da finalidade | Isolar bases de dados por finalidade; controlar reutilização |
| Limitação da conservação | Rotinas automáticas de apagamento; TTL nos registos |
| Integridade e confidencialidade | Cifragem em repouso e em trânsito; controlo de acessos por função |
| Exatidão | Mecanismos de correção pelo próprio titular |
| Pseudonimização | Substituir identificadores diretos por tokens sempre que possível |
Duas técnicas merecem destaque. A pseudonimização — expressamente citada no artigo 25.º, n.º 1 — separa os identificadores diretos dos restantes dados, reduzindo o risco em caso de violação. A minimização aplica-se na origem: cada campo de um formulário deve justificar-se por uma finalidade inscrita no registo de atividades de tratamento. Se um campo não tem finalidade, não deve existir.
A ligação com a AIPD
O artigo 25.º não vive isolado. Quando um tratamento é suscetível de implicar um risco elevado, a avaliação de impacto sobre a proteção de dados (AIPD) do artigo 35.º é o instrumento que operacionaliza a proteção desde a conceção: identifica riscos e define as medidas de mitigação que o artigo 25.º manda integrar. Na prática, a AIPD é o momento em que as decisões de privacy by design ficam documentadas. Para conduzir essa avaliação, disponibilizamos um modelo de AIPD preenchível. Quem concebe um produto novo deve, por isso, correr a AIPD durante o desenho — não depois do lançamento.
Privacy by design nas compras de software
Poucas organizações desenvolvem todo o seu software. A maioria compra-o. Nesse caso, a proteção desde a conceção transfere-se para o dever de diligência na seleção do fornecedor e para o contrato de subcontratação do artigo 28.º. Ao avaliar uma ferramenta, verifique se ela:
- Permite configurar prazos de conservação e apagamento automático.
- Oferece controlo de acessos granular por função.
- Cifra os dados em repouso e em trânsito.
- Nasce com as configurações mais protetoras por defeito.
- Aloja os dados na UE ou oferece garantias válidas para transferências internacionais.
Por defeito: o erro mais comum
A proteção por defeito é a parte do artigo 25.º que mais decisões de produto obriga a rever. A regra é simples: o utilizador não deve ter de agir para proteger a sua privacidade. As configurações iniciais devem já ser as mais protetoras. Isto exclui caixas de consentimento pré-marcadas, perfis públicos por omissão e recolha ampla que o utilizador teria de desativar. É a mesma lógica que o RGPD exige no consentimento: uma ação afirmativa clara, nunca o silêncio ou a inação como aceitação.
Como demonstrar o cumprimento do artigo 25.º
O artigo 25.º é uma obrigação que tem de ser demonstrável, por força do princípio da responsabilidade (art. 5.º, n.º 2). Não basta ter integrado a proteção de dados na conceção; é preciso poder prová-lo numa fiscalização. Na prática, isso significa manter três tipos de evidência:
- Documentação das decisões de conceção: que dados se decidiu não recolher, que campos se removeram, que configurações se definiram por defeito e porquê.
- A AIPD, quando exigida, com o registo dos riscos identificados e das medidas de mitigação escolhidas.
- As medidas técnicas e organizativas associadas a cada tratamento no registo — cifragem, controlo de acessos, pseudonimização, prazos de apagamento automático.
Um erro frequente é tratar o artigo 25.º como um princípio abstrato, sem tradução documental. Quando a CNPD pergunta como um novo sistema respeita a proteção desde a conceção, a resposta útil não é um discurso — é o conjunto de decisões registadas. É por isso que a proteção desde a conceção e a documentação de conformidade caminham juntas: uma sem a outra não resiste a uma inspeção. Organizar esta evidência de forma contínua, em vez de a reconstruir sob pressão, é o que distingue um programa de conformidade maduro.
Perguntas frequentes
A proteção desde a conceção é obrigatória ou recomendada?
É obrigatória. O artigo 25.º usa linguagem vinculativa: o responsável «aplica» as medidas adequadas. Não é uma boa prática opcional, mas um dever cujo incumprimento pode ser sancionado.
Qual a diferença entre desde a conceção e por defeito?
Desde a conceção (n.º 1) diz respeito a integrar a proteção de dados em toda a fase de desenho. Por defeito (n.º 2) exige que as configurações iniciais tratem apenas os dados necessários. A primeira é de método; a segunda é de resultado concreto nas configurações.
O artigo 25.º aplica-se a quem só compra software?
Sim. Quem compra software continua a ser responsável pelo tratamento e deve escolher ferramentas que permitam cumprir o artigo 25.º, exigindo privacy by design ao fornecedor e regulando-o no contrato de subcontratação.
Conclusão
A proteção de dados desde a conceção e por defeito transforma o RGPD de conjunto de regras num método de trabalho: pensar a privacidade no início, e não no fim. O artigo 25.º obriga a integrar medidas como a minimização e a pseudonimização na fase de desenho, e a fazer nascer os sistemas com as configurações mais protetoras. Para quem desenvolve, são decisões de engenharia; para quem compra, é dever de diligência na seleção e no contrato. Em ambos os casos, a AIPD é o instrumento que documenta essas escolhas — e a documentação é o que demonstra a conformidade quando a CNPD pergunta.