Privacy by Design e Privacy by Default: distinções técnicas e jurídicas à luz do direito brasileiro e comparado

Alessandro C. Lavorante, Prof. Me. USP · OAB/SP

---

1. Introdução

Quem acompanha a produção sobre proteção de dados já terá notado que os conceitos de privacy by design e privacy by default costumam aparecer lado a lado, como se formassem uma única obrigação, um binômio indissociável que se resolve na mesma frase e com a mesma providência. Fala-se em "privacy by design/default" como quem diz "proteção de dados desde a concepção e por padrão", e o leitor, razoavelmente, conclui que bastaria projetar a privacidade na arquitetura do sistema para estar em conformidade com ambas as exigências. O problema é que não basta. E a confusão entre os dois conceitos não é inofensiva: ela compromete a forma como produtos digitais são concebidos, contamina a redação de contratos com fornecedores de tecnologia e, no limite, fragiliza a defesa de agentes de tratamento perante autoridades que, como se verá, já começaram a aplicar sanções expressivas com fundamento específico em cada uma dessas obrigações.

Fomos instados a tratar dessas distinções justamente porque, na prática consultiva e acadêmica, a indistinção entre by design e by default se revela o ponto cego mais frequente entre profissionais que, de resto, dominam a matéria de proteção de dados com competência. Nas linhas que seguem, o objetivo é examinar de onde vieram esses conceitos, como cada ordenamento jurídico os recepcionou (com graus bastante diversos de precisão normativa), e por que a diferença entre eles importa tanto na hora de construir um produto quanto na hora de responder por ele.

2. Origens e fundamentos conceituais

2.1. O privacy by design e os 7 Princípios Fundamentais de Ann Cavoukian

O conceito de privacy by design remonta a meados da década de 1990, quando a Dra. Ann Cavoukian, então Comissária de Informação e Privacidade da Província de Ontário, no Canadá, publicou, em parceria com a Autoridade de Proteção de Dados da Holanda e com a Netherlands Organisation for Applied Scientific Research, trabalho seminal sobre Privacy-Enhancing Technologies (PETs). Até aquele momento, a abordagem dominante era a de que a privacidade poderia ser assegurada mediante o acréscimo de tecnologias específicas a sistemas já em funcionamento. A privacidade era, nessa lógica, um complemento. Cavoukian propôs o inverso: que ela compusesse a própria arquitetura dos sistemas de informação, e não lhes fosse acoplada a posteriori.

Dessa premissa, a autora formulou os 7 Princípios Fundamentais, reconhecidos por unanimidade, em outubro de 2010, na 32ª Conferência Internacional de Comissários de Proteção de Dados e Privacidade, como componente essencial da proteção à privacidade. Os princípios abrangem: (1) proatividade — preventivo, não corretivo; (2) privacidade como configuração padrão; (3) privacidade incorporada ao design; (4) funcionalidade total — soma positiva, não soma zero; (5) segurança de ponta a ponta; (6) visibilidade e transparência; e (7) centralidade no titular dos dados.

O segundo princípio já contém o germe daquilo que, na nomenclatura europeia, viria a ser formalizado como privacy by default. No framework original de Cavoukian, entretanto, o by default era um desdobramento do by design; não uma obrigação autônoma. A cisão formal viria apenas com o GDPR.

2.2. A formalização no GDPR: o Artigo 25

O Regulamento (UE) 2016/679 (GDPR), em vigor desde maio de 2018, foi o primeiro diploma a conferir ao privacy by design e ao privacy by default o status de obrigações jurídicas autônomas e vinculantes. Ambos encontram sede no Artigo 25, mas em parágrafos distintos — e o Considerando 78 do próprio Regulamento confirma que se trata de deveres de natureza e alcance diversos, ao referir-se expressamente aos "princípios da proteção de dados desde a concepção (privacy by design) e da proteção de dados por padrão (privacy by default)" como categorias separadas.

O parágrafo 1º cuida do data protection by design. Determina que o responsável pelo tratamento implemente, tanto no momento da definição dos meios quanto no do próprio tratamento, medidas técnicas e organizacionais adequadas — como a pseudonimização — para aplicar com eficácia os princípios da proteção de dados e integrar as salvaguardas necessárias. A norma manda que se considere o estado da técnica, os custos de implementação, a natureza, o âmbito, o contexto, as finalidades e os riscos envolvidos, o que afasta qualquer possibilidade de leitura padronizada ou meramente formal da obrigação.

O parágrafo 2º trata do by default. O responsável deve aplicar medidas técnicas e organizacionais para assegurar que, por padrão, só sejam tratados os dados pessoais necessários para cada finalidade específica. Essa obrigação se projeta sobre quatro dimensões: a quantidade de dados recolhidos, a extensão do tratamento, o prazo de conservação e a acessibilidade. O dispositivo exige, em especial, que dados pessoais não sejam disponibilizados sem intervenção humana a um número indeterminado de pessoas — regra cuja violação, como se verá, tem sido objeto de enforcement crescente.

As Guidelines 4/2019 do European Data Protection Board (EDPB) aprofundam a interpretação: a efetividade é o critério central. Cada medida deve produzir o resultado protetivo pretendido na prática, e não apenas existir como documento de política interna. Não basta a conformidade formal; exige-se a conformidade material — uma distinção cujas repercussões no campo sancionatório já se fazem sentir com clareza.

3. A distinção técnica: arquitetura versus configuração

Assentadas as bases normativas, cumpre examinar de que modo a distinção entre by design e by default se projeta no plano técnico — e por que confundi-los é um erro que compromete tanto a engenharia quanto a conformidade jurídica do produto.

O privacy by design diz respeito à arquitetura do sistema. Trata-se de decisões de engenharia que precedem a coleta de qualquer dado: a definição de quais informações serão coletadas e quais descartadas; a implementação de pseudonimização ou anonimização na camada de armazenamento; a adoção de controle de acesso baseado em funções (role-based access control); a utilização de criptografia de ponta a ponta; a segregação de ambientes; e a construção de mecanismos de auditabilidade. A privacidade, nessa acepção, precisa ser componente intrínseco da engenharia — não um módulo acoplado depois de pronto o sistema.

O privacy by default se refere à configuração com a qual o produto é entregue ao titular. A pergunta relevante não é como o sistema foi construído, mas como ele se apresenta ao usuário que o acessa pela primeira vez, sem alterar nada. Se esse usuário, ao criar uma conta numa plataforma de e-commerce, já tem seus dados de navegação coletados para personalização de ofertas sem que tenha optado por isso, há falha de by default — ainda que a infraestrutura por trás seja tecnicamente sofisticada. Do mesmo modo, uma plataforma pode entregar configurações restritivas por padrão e, internamente, operar sobre uma arquitetura que não implementa sequer o mínimo de pseudonimização ou segregação — o que configuraria falha de by design sem falha de by default.

As duas obrigações operam, portanto, em camadas distintas. É perfeitamente possível — e frequente — falhar em uma sem falhar na outra.

O exemplo talvez mais tangível é o das redes sociais. Considere-se um usuário que cria uma conta e, sem tocar em nenhuma configuração, já tem seu perfil acessível a qualquer pessoa na internet. A plataforma viola o by default, porque a configuração padrão não corresponde ao nível mais restritivo de acessibilidade. Se, além disso, os dados do perfil são armazenados sem criptografia, sem minimização e sem segregação por finalidade, há violação concomitante de by design. A lei exige ambas — e a conformidade parcial, aqui, equivale a desconformidade.

4. Panorama normativo: Brasil, Europa e outras jurisdições

4.1. A recepção pela LGPD

A Lei nº 13.709/2018 (Lei Geral de Proteção de Dados Pessoais — LGPD) não emprega as expressões privacy by design e privacy by default de forma literal. Os conceitos, entretanto, foram absorvidos pelo Artigo 46 e seu § 2º.

O caput do Artigo 46 determina que os agentes de tratamento adotem medidas de segurança, técnicas e administrativas aptas a proteger dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou qualquer forma de tratamento inadequado. O § 2º complementa: essas medidas devem ser observadas desde a fase de concepção do produto ou serviço até a sua execução.

A redação é consideravelmente mais concisa que a do GDPR. A ausência de parágrafos distintos para by design e by default cria uma dificuldade hermenêutica concreta: onde termina a obrigação de projetar a privacidade na arquitetura e onde começa a de entregá-la como configuração padrão? A LGPD, em sua literalidade, não oferece essa demarcação.

Uma leitura sistemática, entretanto, permite avançar. O Artigo 46, § 2º, ao determinar que as medidas sejam observadas "desde a fase de concepção", absorve o núcleo do by design. Já os princípios de necessidade, finalidade e adequação, inscritos no Artigo 6º, informam o conteúdo do by default — a exigência de que o tratamento, por padrão, não exceda o estritamente necessário. Não se trata de importação conceitual; trata-se de reconhecer que o diploma brasileiro, embora com menor granularidade, contemplou ambas as exigências.

Nesse contexto, a experiência europeia — com guidelines do EDPB, jurisprudência administrativa e volume crescente de precedentes sancionatórios — constitui, a nosso ver, referência hermenêutica não apenas útil, mas em muitos casos indispensável para a prática brasileira.

4.2. O Reino Unido e o Data (Use and Access) Act 2025

O Data (Use and Access) Act 2025, sancionado em 19 de junho de 2025, introduziu alterações ao UK GDPR. O Information Commissioner's Office (ICO) atualizou, em 5 de fevereiro de 2026, sua orientação sobre data protection by design and by default, incluindo nova subseção relativa à obrigação de children's higher protection matters: organizações que oferecem serviços online suscetíveis de serem acessados por crianças devem considerar as necessidades específicas desse público ao definir suas medidas técnicas e organizacionais.

A alteração é relevante porque evidencia uma premissa que o legislador europeu já havia deixado implícita: configurações padrão não são neutras. Devem ser calibradas conforme o perfil dos titulares que razoavelmente utilizarão o serviço, conectando-se diretamente ao Age Appropriate Design Code britânico. O by default, aqui, se expande para incluir não apenas a minimização genérica de dados, mas uma adequação contextual ao perfil etário dos usuários.

4.3. O enforcement europeu

A experiência europeia de aplicação do Artigo 25 já é suficientemente robusta para se extraírem tendências, e elas revelam mais do que simples multas.

A Future of Privacy Forum, em relatório que analisou mais de 92 decisões envolvendo o Artigo 25 — provenientes de 16 Estados-membros do Espaço Econômico Europeu, do Reino Unido e do EDPB —, identificou uma divergência importante na postura das autoridades. Algumas tratam o Artigo 25 como obrigação de natureza eminentemente preventiva: encontram violação mesmo sem incidente concreto, pela simples inexistência de salvaguardas na fase de concepção. Outras preferem aplicá-lo apenas em conjunto com violações substantivas de outros dispositivos, como os Artigos 5 ou 32. A divergência importa porque, na primeira leitura, o by design funciona como obrigação autônoma de resultado; na segunda, como mero acessório de outras infrações.

No campo das sanções, os números são eloquentes. A Data Protection Commission da Irlanda multou a Meta em 251 milhões de euros, em dezembro de 2024, por uma violação de 2018 no Facebook que afetou 29 milhões de usuários — e a decisão apontou expressamente que a empresa não havia implementado medidas de by design e by default capazes de prevenir a violação. Na Polônia, a UODO sancionou a McDonald's Polska em mais de 4 milhões de euros em 2025, com fundamento no Artigo 25(1). As multas cumulativas por infrações ao GDPR atingiram 5,65 bilhões de euros até março de 2025, e o Artigo 25 aparece com frequência crescente como parte de ações multifacetadas — especialmente quando a autoridade investiga um incidente e constata que a causa não foi pontual, mas estrutural: a ausência de proteções desde a concepção.

5. Implicações práticas

A distinção entre by design e by default se projeta diretamente sobre a forma como produtos e serviços digitais devem ser concebidos e disponibilizados, e sobre como os agentes de tratamento serão avaliados quando algo der errado.

No que se refere ao by design, a obrigação exige envolvimento conjunto de jurídico e engenharia desde as fases mais iniciais do projeto. A decisão sobre quais dados coletar, como armazená-los, quando descartá-los e quem pode acessá-los não pode ser relegada a um momento posterior ao desenvolvimento — sob pena de se construir um sistema cuja arquitetura é, desde o início, incompatível com as exigências normativas. A elaboração de Data Protection Impact Assessments (DPIAs), conforme previsto no Artigo 35 do GDPR e nos artigos 22 a 24 da atual redação do Projeto de Lei nº 2.338/2023, constitui, nesse sentido, instrumento essencial.

No que se refere ao by default, o teste de conformidade é direto e revelador: se o titular de dados, ao acessar o produto pela primeira vez, sem realizar nenhuma ação de configuração, não tem sua privacidade protegida, há desconformidade. A qualidade da arquitetura subjacente, nesse cenário, é juridicamente irrelevante para fins de by default.

A documentação dessas medidas, por fim, integra a própria obrigação. As Guidelines do EDPB não deixam margem: medidas que existem apenas no plano documental, sem produzir resultado protetivo concreto, não satisfazem o Artigo 25. Em caso de incidente, as primeiras perguntas da autoridade serão sobre o que foi implementado desde a concepção e qual era a configuração padrão — e a resposta precisará demonstrar efetividade, não apenas formalidade.

6. Considerações finais

Ao longo deste artigo, percorremos um caminho que vai da origem canadense do privacy by design nos anos 1990 até as sanções de centenas de milhões de euros aplicadas por autoridades europeias em 2024 e 2025, passando pela formalização normativa no GDPR e pela recepção — mais concisa, porém real — dos mesmos conceitos pela LGPD. Em cada etapa, uma constatação se reforçou: a de que by design e by default, embora complementares, operam em camadas distintas do processo de concepção e entrega de produtos digitais, e a confusão entre eles, longe de ser inócua, gera vulnerabilidades concretas tanto na arquitetura dos sistemas quanto na configuração com que esses sistemas chegam aos titulares de dados.

A separação normativa entre os dois institutos no Artigo 25 do GDPR, a expansão do by default para contextos etários pelo legislador britânico, e a crescente tendência das autoridades europeias de tratar o Artigo 25 como obrigação autônoma e preventiva — aplicável antes mesmo de qualquer incidente — confirmam que essas não são categorias acadêmicas abstratas; são critérios objetivos de avaliação da governança de dados de uma organização. No Brasil, a ausência de parágrafos distintos na LGPD não elide a exigência: uma leitura articulada entre o Artigo 46, § 2º e os princípios do Artigo 6º conduz, a nosso ver, à mesma conclusão.

O esforço de adequação, dito isso, não é intransponível. Exige, entretanto, uma mudança de perspectiva que muitas organizações ainda não fizeram: a de incorporar a privacidade como variável de engenharia desde o primeiro dia de concepção do produto, e como configuração de entrega ao titular desde a primeira interação. Quem faz isso desde o início gasta menos, responde melhor e se expõe menos. Quem deixa para depois descobre, geralmente pelo caminho mais caro, que remediar é sempre mais oneroso do que prevenir — e que a conformidade parcial, nesse campo, equivale a desconformidade.

---

Notas

1. Cavoukian, Ann; Borking, John. Privacy-Enhancing Technologies: The Path to Anonymity. Information and Privacy Commissioner of Ontario / Registratiekamer (The Netherlands), 1995. 2. 32ª Conferência Internacional de Comissários de Proteção de Dados e Privacidade, Jerusalém, outubro de 2010. Desde então, os princípios foram traduzidos para 37 idiomas. 3. Cavoukian, Ann. Privacy by Design: The 7 Foundational Principles. Information and Privacy Commissioner of Ontario, 2009 (rev. janeiro de 2011). 4. Regulamento (UE) 2016/679, Artigo 25(1). 5. GDPR, Artigo 25(2). 6. European Data Protection Board. Guidelines 4/2019 on Article 25 — Data Protection by Design and by Default. Versão 2.0, adotada em 20 de outubro de 2020, par. 10. 7. Lei nº 13.709, de 14 de agosto de 2018 (LGPD), Artigo 46, caput e § 2º. 8. Nessa direção, cf. Migalhas. Privacy by Design, by Default e by Redesign. 21 maio 2021. 9. Information Commissioner's Office. Data Protection by Design and by Default — Guidance. Atualizado em 5 fev. 2026. 10. Future of Privacy Forum. Unlocking Data Protection by Design and by Default: Lessons from the Enforcement of Article 25 GDPR. Maio de 2024. 11. Data Protection Commission (Irlanda). Decisão de dezembro de 2024, relativa à Meta Platforms Ireland Limited. 12. Urząd Ochrony Danych Osobowych (UODO — Polônia). Decisão de 2025, relativa à McDonald's Polska. 13. CMS. GDPR Enforcement Tracker Report. Dados até março de 2025. 14. EDPB, Guidelines 4/2019, par. 10-12.

---

Alessandro C. Lavorante é advogado especializado em Direito Digital, professor, mestre pela USP, sócio sênior da LF Sociedade de Advogados e cofundador de Advogando.AI, Minuta.Tech, JogoLimpo.com.br e CadernoDigital.ai. Autor de Responsabilidade Civil por Inteligência Artificial (Lumen Juris, 2025).

Contato: digital.adv.br | @oalessandrolavorante