Privacidade por Design

Visão Geral

Integre proteções de privacidade na arquitetura de software desde o início, não como uma reflexão tardia. Esta habilidade aplica os princípios de Privacidade por Design (Artigo 25 do GDPR, framework de Cavoukian) ao projetar bancos de dados, APIs e fluxos de usuário. Protege os dados de usuários reais e constrói confiança.

Quando Usar Esta Habilidade

• Use ao construir aplicativos que coletam dados pessoais (nomes, e-mails, locais, preferências)
• Use ao projetar esquemas de banco de dados, APIs ou fluxos de autenticação
• Use quando o usuário mencionar formulários, contas de usuário, análises ou integrações de terceiros
• Use ao implantar em produção — verifique os controles de privacidade antes do lançamento

Estruturas Legais

GDPR (UE) — Referência principal. O Artigo 25 exige "proteção de dados por design e por padrão". Aplica-se a usuários da UE e é frequentemente adotado globalmente.

CCPA (Califórnia) — Direito de saber, excluir, optar por não vender. Princípios semelhantes: minimizar, divulgar, permitir controle.

LGPD (Brasil) — Alinhado com o GDPR. Limitação de finalidade, necessidade, transparência. Aplica-se a usuários do Brasil.

Projete para a estrutura mais rigorosa que você visa; ela geralmente satisfaz outras.

Princípios Fundamentais

1. Minimização de Dados

Colete apenas o que for estritamente necessário. Cada campo precisa de uma justificativa documentada. Evite "podemos precisar disso mais tarde".

2. Limitação de Finalidade

Armazene a finalidade de cada ponto de dados. Não reutilize dados para finalidades às quais o usuário não consentiu.

3. Limitação de Armazenamento

Defina períodos de retenção. Implemente exclusão ou anonimização automatizada quando a retenção expirar. Nunca mantenha dados "para sempre" por padrão.

4. Privacidade por Padrão

Opção de "opt-in" para coleta opcional, não "opt-out". Configurações sensíveis (análises, marketing) desativadas por padrão. Sem caixas de consentimento pré-marcadas.

5. Segurança de Ponta a Ponta

Criptografe em repouso e em trânsito. Use RBAC (Controle de Acesso Baseado em Função). Registre o acesso a dados sensíveis para auditoria.

6. Transparência

Documente o que é coletado e por quê. Políticas de privacidade claras. Fácil acesso e exclusão para usuários.

Direitos do Usuário (GDPR)

Garanta que estes sejam implementáveis desde o primeiro dia:

Mergulho Profundo: Por Que Importa

Minimização de dados — Menos dados = menor impacto de violação, menor custo de armazenamento, conformidade mais simples. Cada campo é uma responsabilidade.

Limitação de finalidade — Reutilizar dados sem consentimento é ilegal sob o GDPR. Documente a finalidade no esquema ou metadados.

Retenção — Armazenamento indefinido aumenta o risco e viola o GDPR. Defina retention_days por tipo de dado; automatize a limpeza.

Registro (Logging) — Logs frequentemente vazam PII (Informações de Identificação Pessoal). Redija e-mails, IDs, tokens. Use logging estruturado com listas de permissão.

Terceiros — Cada SDK (análises, relatórios de falhas, anúncios) pode enviar dados para outros lugares. Audite dependências; exija consentimento antes de carregar.

Exemplos de Código

JavaScript/Node — Modelo de Usuário Mínimo

// BAD: Collecting everything "just in case"
const user = { email, name, phone, address, birthdate, ipAddress, userAgent, ... };

// GOOD: Minimal, documented purpose
const user = {
  email,        // purpose: authentication
  displayName,  // purpose: UI display
  createdAt,    // purpose: account age
};

JavaScript — Consentimento Antes do Rastreamento

// BAD: Track first, ask later
analytics.track(userId, event);

// GOOD: Check consent first
if (userConsent.analytics) {
  analytics.track(userId, event);
}

Python — Logging Seguro

# BAD: Logging PII in plain text
logger.info(f"User {user.email} logged in from {request.remote_addr}")

# GOOD: Redact or hash identifiers
logger.info(f"User {hash_user_id(user.id)} logged in")
# Or: logger.info("User login", extra={"user_id_hash": hash_id(user.id)})

SQL — Esquema com Finalidade e Retenção

-- GOOD: Document purpose and retention in schema
CREATE TABLE users (
  id UUID PRIMARY KEY,
  email VARCHAR(255) NOT NULL,  -- purpose: auth, retention: account lifetime
  display_name VARCHAR(100),   -- purpose: UI, retention: account lifetime
  created_at TIMESTAMPTZ,      -- purpose: audit, retention: 7 years
  last_login_at TIMESTAMPTZ    -- purpose: security, retention: 90 days
);

-- Add retention policy (PostgreSQL example)
-- Schedule job to anonymize/delete last_login_at after 90 days

…