Privacidade desde o design: um guia prático para equipes de desenvolvimento de software

Privacy by Design não é uma sugestão – é um requisito legal nos termos do Artigo 25 do GDPR. As organizações devem implementar "medidas técnicas e organizacionais apropriadas" para garantir que os princípios de proteção de dados sejam integrados no próprio processamento. No entanto, a maioria das equipes de desenvolvimento trata a privacidade como algo secundário, recorrendo a formulários de consentimento e banners de cookies depois que a arquitetura é definida.

Este guia traduz os sete princípios fundamentais da Privacidade desde o Design em práticas de engenharia acionáveis, padrões de design e implementações em nível de código.

Principais conclusões

• Privacy by Design significa incorporar privacidade nas decisões de arquitetura, e não adicioná-la como um recurso posteriormente
• A minimização de dados no nível do esquema evita a coleta excessiva desde o início
• Pseudonimização e criptografia fornecem defesa profunda quando ocorrem violações
• A análise que preserva a privacidade pode fornecer insights de negócios sem expor dados individuais do usuário

---

Os Sete Princípios Aplicados ao Software

1. Proativo, não reativo

Crie controles de privacidade antes de coletar dados, não após uma violação.

Na prática:

• Incluir requisitos de privacidade nos critérios de aceitação de histórias de usuários
• Execute um modelo de ameaça à privacidade durante revisões de arquitetura
• Crie uma lista de verificação de privacidade para cada solicitação pull que afeta os dados do usuário

2. Privacidade como configuração padrão

Os usuários não devem precisar tomar medidas para proteger sua privacidade.

Na prática:

• Novas contas de usuário padrão para compartilhamento mínimo de dados
• O rastreamento do Analytics é opcional, não opcional
• A visibilidade do perfil é padronizada como privada
• A retenção de dados padroniza o período mínimo exigido

// Default privacy settings for new users
const DEFAULT_PRIVACY_SETTINGS = {
  profileVisibility: 'private',       // Not 'public'
  analyticsTracking: false,           // Opt-in required
  marketingEmails: false,             // Opt-in required
  dataSharing: false,                 // Opt-in required
  activityLog: true,                  // Security feature, on by default
  twoFactorAuth: true,               // Security feature, on by default
};

3. Privacidade incorporada ao design

A privacidade é um componente central do sistema, não um complemento.

Design de esquema de banco de dados:

-- Privacy-aware schema design
CREATE TABLE users (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    -- Separate PII from operational data
    email VARCHAR(255) NOT NULL,          -- PII
    email_hash VARCHAR(64) NOT NULL,      -- For lookups without exposing email
    name_encrypted BYTEA,                 -- Encrypted at rest
    -- Operational fields (non-PII)
    role VARCHAR(50) NOT NULL DEFAULT 'user',
    created_at TIMESTAMP DEFAULT NOW(),
    -- Privacy metadata
    consent_timestamp TIMESTAMP,
    consent_version VARCHAR(20),
    data_retention_until TIMESTAMP,
    deletion_requested_at TIMESTAMP
);

-- Separate sensitive data into its own table with stricter access
CREATE TABLE user_pii (
    user_id UUID PRIMARY KEY REFERENCES users(id) ON DELETE CASCADE,
    phone_encrypted BYTEA,
    address_encrypted BYTEA,
    date_of_birth_encrypted BYTEA,
    -- Audit trail
    last_accessed_at TIMESTAMP,
    last_accessed_by UUID
);

4. Funcionalidade completa (soma positiva)

A privacidade não deve prejudicar a funcionalidade. Projete sistemas que ofereçam ambos.

Exemplo: em vez de escolher entre personalização e privacidade, use a personalização que preserva a privacidade:

• Aprendizagem federada: modelos de ML treinados em dados locais, apenas resultados agregados compartilhados
• Privacidade diferencial: adicione ruído às análises para evitar a identificação individual
• Processamento no dispositivo: recomendações calculadas no dispositivo do usuário, não no servidor

5. Segurança ponta a ponta

Proteja os dados durante todo o seu ciclo de vida.

6. Visibilidade e transparência

Os usuários devem entender o que acontece com seus dados.

Implementação:

// Privacy dashboard API endpoint
@Controller('privacy')
export class PrivacyController {
  @Get('my-data')
  @ApiOperation({ summary: 'Get all personal data (GDPR Art. 15)' })
  async getMyData(@Req() req: AuthenticatedRequest) {
    return {
      profile: await this.userService.getProfile(req.user.sub),
      orders: await this.orderService.getUserOrders(req.user.sub),
      supportTickets: await this.supportService.getUserTickets(req.user.sub),
      loginHistory: await this.authService.getLoginHistory(req.user.sub),
      consentRecords: await this.consentService.getUserConsents(req.user.sub),
      dataProcessors: this.getDataProcessorList(),
    };
  }

  @Post('export')
  @ApiOperation({ summary: 'Export personal data (GDPR Art. 20)' })
  async exportMyData(@Req() req: AuthenticatedRequest) {
    // Generate machine-readable export (JSON)
    return this.privacyService.generateDataExport(req.user.sub);
  }

  @Post('delete')
  @ApiOperation({ summary: 'Request data deletion (GDPR Art. 17)' })
  async requestDeletion(@Req() req: AuthenticatedRequest) {
    return this.privacyService.initiateDataDeletion(req.user.sub);
  }
}

7. Respeito pela privacidade do usuário

Mantenha o usuário no centro de todas as decisões de design.

---

Padrões de arquitetura que preservam a privacidade

Padrão 1: Separação de Dados

Separe as informações de identificação pessoal dos dados operacionais:

[Frontend] --> [API Gateway] --> [Application Service]
                                       |
                      +----------------+----------------+
                      |                                 |
              [Operational DB]                    [PII Vault]
              (Orders, products,                  (Names, emails,
               analytics - by ID)                  addresses - encrypted)

Padrão 2: Processamento baseado em consentimento

// Consent middleware
async function requireConsent(purpose: string) {
  return async (req: Request, res: Response, next: NextFunction) => {
    const consent = await consentService.check(req.user.id, purpose);
    if (!consent.granted) {
      throw new ForbiddenException(
        `Processing for "${purpose}" requires user consent`
      );
    }
    next();
  };
}

// Usage
@Get('recommendations')
@UseGuards(requireConsent('personalization'))
async getRecommendations(@Req() req: AuthenticatedRequest) {
  return this.recommendationService.getForUser(req.user.sub);
}

Padrão 3: Expiração Automática de Dados

// TTL-based data retention
const RETENTION_POLICIES = {
  supportTickets: { days: 1095, action: 'anonymize' },    // 3 years
  recruitmentData: { days: 730, action: 'delete' },        // 2 years
  analyticsEvents: { days: 365, action: 'aggregate' },     // 1 year
  sessionLogs: { days: 90, action: 'delete' },             // 90 days
  tempUploads: { days: 7, action: 'delete' },              // 7 days
};

---

Privacidade em integrações de terceiros

Cada integração de terceiros é um risco potencial à privacidade. Quando seu aplicativo envia dados do usuário para um serviço externo, você se torna responsável pela forma como esse serviço os trata.

Avaliação de privacidade de integração

Antes de integrar qualquer serviço de terceiros que processe dados do usuário:

Riscos comuns de privacidade de integração

Analytics: Google Analytics, Mixpanel e serviços semelhantes recebem dados comportamentais do usuário. Use análises do lado do servidor ou alternativas sem cookies (Plausible, Fathom) para minimizar a exposição de dados.

Processamento de pagamentos: Stripe, PayPal e serviços similares processam dados financeiros. Use seus formulários de pagamento hospedados (Stripe Elements) para evitar a expansão do escopo PCI-DSS. Nunca registre números completos de cartão de crédito.

Serviços de e-mail: SendGrid, Mailgun e serviços semelhantes processam endereços de e-mail e conteúdo de mensagens. Certifique-se de que o provedor de serviços de e-mail tenha um DPA assinado e não use os dados do destinatário para publicidade.

Suporte ao cliente: Zendesk, Intercom e serviços semelhantes armazenam conversas de clientes que podem conter PII. Configure a retenção de dados na plataforma de suporte e garanta que o DPA cubra todos os tipos de dados.

---

Lista de verificação do desenvolvedor

Para cada recurso relacionado aos dados do usuário

• Quais dados pessoais esse recurso coleta? (documente)
• Qual a base legal para cobrança? (Consentimento, contrato, interesse legítimo)
• Esses são os dados mínimos necessários? (Minimização de dados)
• Até quando vamos retê-lo? (Política de retenção)
• Quem tem acesso? (Mínimo privilégio)
• [] É criptografado em repouso e em trânsito? (Segurança)
• O usuário pode acessar, exportar e excluir seus dados? (Direitos)
• Está registrado para fins de auditoria? (Responsabilidade)
• Atravessa fronteiras? (Mecanismos de transferência)
• Uma DPIA foi concluída se for de alto risco? (Avaliação)

---

Perguntas frequentes

A privacidade desde a concepção é apenas para o GDPR?

Não. Embora o GDPR torne isso um requisito legal (artigo 25), a privacidade desde a concepção é uma prática recomendada reconhecida globalmente. A CPRA da Califórnia, a LGPD do Brasil e a DPDP da Índia incluem requisitos semelhantes para incorporar a privacidade no design do sistema. A implementação do Privacy by Design para conformidade com o GDPR satisfaz automaticamente os requisitos da maioria das outras jurisdições.

Como adaptamos a privacidade a um aplicativo existente?

Priorize: (1) Audite quais dados pessoais você possui e onde eles residem, (2) Implemente fluxos de trabalho de solicitação do titular dos dados (acesso, exclusão, exportação), (3) Adicione criptografia para dados confidenciais em repouso, (4) Implemente políticas de retenção e exclusão automatizada, (5) Adicione gerenciamento de consentimento onde estiver faltando. Isto não é ideal, mas aborda primeiro as lacunas de maior risco.

A privacidade desde a concepção significa que não podemos usar análises?

Não. Significa usar análises de forma responsável. Agregue dados em vez de rastreamento individual. Use análises sem cookies (Plausible, Fathom) para métricas do site. Para análise de produtos, colete eventos sem PII ou pseudônimo de identificadores. Para testes A/B, use atribuição do lado do servidor sem cookies de rastreamento do lado do cliente. Privacidade e análises são compatíveis com um design bem pensado.

Como implementamos o Privacy by Design no Odoo?

Odoo fornece vários recursos de privacidade integrados: grupos de acesso de usuários (controle de acesso por módulo), registro de auditoria (conversas em registros) e arquivamento de dados. Aprimore-os com: campos personalizados criptografados para dados confidenciais, regras de retenção automatizadas usando ações programadas, funcionalidade de exportação de dados GDPR usando relatórios personalizados e rastreamento de consentimento em registros de contato. Os serviços de personalização Odoo da ECOSIRE incluem implementação de privacidade desde o design.

---

O que vem a seguir

Privacy by Design é a disciplina de engenharia. Combine-o com políticas de retenção de dados para gerenciamento do ciclo de vida, implementação de consentimento de cookies para propriedades da web e privacidade de dados de funcionários para sistemas internos.

Entre em contato com a ECOSIRE para consultoria de privacidade desde o design e revisão de arquitetura de software.

---

Publicado pela ECOSIRE – ajudando as empresas a incorporar privacidade em cada linha de código.