design para devs: o caso da multa do Google por GDPR

>Uma multa de 403 milhões de euros (cerca de R$ 2,37 bilhões) aplicada pela autoridade de proteção de dados da Irlanda ao Google acendeu um alerta que, na minha visão, deveria estar piscando na cabeça de todo desenvolvedor que mexe com dados de usuário: privacidade não é feature opcional, é responsabilidade técnica. O Google foi punido por rastrear localização em segredo entre 2018 e 2020, mantendo dados por mais tempo que o necessário e falhando em informar corretamente os usuários. Segundo o Olhar Digital, três funcionalidades específicas estão no centro da punição. Vou destrinchar o caso pelo olhar de quem constrói software.

O que o Google errou — e por que isso importa para quem programa

A Comissão de Proteção de Dados da Irlanda (DPC) identificou falhas em três produtos do Google: “Atividade na Web e de Apps”, “Histórico de Localização” e “Precisão de Localização”. O problema não foi coletar dados — o mundo inteiro coleta. O problema foi a forma: a empresa falhou em fornecer informações claras aos usuários e processou os dados de maneira inadequada, violando artigos do GDPR.

Para um dev, isso traduz em três conceitos concretos:

• Falta de transparência no consentimento: telas confusas, opt-out em vez de opt-in, linguagem ambígua.
• Retenção excessiva de dados: armazenar localização por mais tempo que o necessário para a finalidade declarada.
• Processamento fora do escopo informado: usar dados de localização para inferir interesses e direcionar anúncios sem o usuário saber.

Quando li essa notícia, a primeira coisa que pensei foi: “quantos sistemas que eu já ajudei a construir fazem exatamente isso?”. Spoiler: a maioria. E o pior é que ninguém é “Google demais” para escapar — a multa foi pesada justamente porque o precedente precisa existir.

Por que gigantes de tech falham nisso (e devs pequenos repetem o erro)

Existe um padrão cultural nas empresas de tecnologia que, na minha experiência, é o verdadeiro vilão: tratar dados de localização como commodity. A localização é uma das informações mais sensíveis que existem. Ela revela onde você mora, onde trabalha, com quem você se encontra, seus hábitos religiosos, sua rotina médica. Mesmo dados “anonimizados” de localização podem ser reidentificados com assustadora facilidade — há papers acadêmicos mostrando que 4 pontos de geolocalização são suficientes para identificar 95% das pessoas.

O Google provavelmente tinha a melhor equipe de compliance do mundo e ainda assim falhou. Isso mostra que o problema não é falta de competência técnica — é falta de princípio de privacidade desde o design (privacy by design, artigo 25 do GDPR).

O conceito de privacy by design na sua stack

Privacy by design não é um checklist que você aplica no fim do projeto. É uma decisão arquitetural que afeta desde o schema do banco até a escolha do provider de cloud. Significa:

1. Minimização: coletar apenas o que é estritamente necessário.
2. Finalidade: definir com clareza por que cada dado existe e rejeitar usos secundários sem novo consentimento.
3. Retenção limitada: dados pessoais devem ter data de expiração técnica, não política.
4. Transparência: o usuário deve entender o que acontece com seus dados sem precisar de um advogado.

Na Prática: implementando coleta de localização em conformidade com o GDPR

Vou mostrar um exemplo real de como eu estruturaria um endpoint que registra localização, pensando em conformidade desde o design. Usei Node.js + Express + PostgreSQL porque é o stack mais comum que vejo em produção, mas os princípios se aplicam a qualquer linguagem.

// locationService.js
// Serviço que registra localização com privacy by design

const { Pool } = require('pg');
const crypto = require('crypto');

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

// TTL para expiração automática (90 dias, conforme política declarada)
const RETENTION_DAYS = 90;

async function recordLocation({ userId, lat, lng, purpose, ip, userAgent }) {
  // 1. Verifica consentimento explícito para a finalidade
  const consent = await getActiveConsent(userId, purpose);
  if (!consent) {
    throw new Error('NO_CONSENT_FOR_PURPOSE');
  }

  // 2. Aplica precisão reduzida quando o consentimento é "aproximado"
  const finalLat = consent.precision === 'approximate' ? roundToGrid(lat, 3) : lat;
  const finalLng = consent.precision === 'approximate' ? roundToGrid(lng, 3) : lng;

  // 3. Hash do userId em vez de armazenar diretamente (pseudonimização)
  const pseudoUserId = crypto
    .createHash('sha256')
    .update(userId + process.env.SALT)
    .digest('hex');

  // 4. Registra com data de expiração automática
  const expiresAt = new Date(Date.now() + RETENTION_DAYS * 86400000);

  await pool.query(
    `INSERT INTO location_logs 
     (user_id_hash, lat, lng, purpose, expires_at, created_at, ip_hash) 
     VALUES ($1, $2, $3, $4, $5, NOW(), $6)`,
    [
      pseudoUserId,
      finalLat,
      finalLng,
      purpose,
      expiresAt,
      hashIp(ip)
    ]
  );
}

// Job que deleta registros expirados (rodar via cron)
async function purgeExpired() {
  const result = await pool.query(
    `DELETE FROM location_logs WHERE expires_at < NOW() RETURNING id`
  );
  console.log(`Removidos ${result.rowCount} registros expirados`);
}

// Função utilitária: arredonda coordenadas para uma grade de privacidade
function roundToGrid(value, decimals = 3) {
  // 3 casas decimais ≈ 110m de precisão — suficiente para analytics, sem expor endereço
  return Math.round(value * 10 ** decimals) / 10 ** decimals;
}

function hashIp(ip) {
  return crypto
    .createHash('sha256')
    .update(ip + process.env.SALT)
    .digest('hex');
}

module.exports = { recordLocation, purgeExpired };

O código acima implementa quatro pilares que o Google ignorou ou tratou de forma ambígua:

• Verificação de consentimento por finalidade: cada uso (analytics, recomendação, segurança) precisa de consentimento separado.
• Precisão dinâmica: se o usuário aceita apenas localização aproximada, você reduz a granularidade automaticamente.
• Pseudonimização: o ID real nunca toca o banco de analytics.
• Expiração técnica: não existe “ficou guardado porque ninguém lembrou de apagar”.

Erros comuns que devs cometem (e que podem gerar multa de 4% do faturamento)

Depois de revisar dezenas de sistemas ao longo da minha carreira, percebi que certos erros se repetem com frequência impressionante. Vou listar os piores:

1. Confundir “ter política de privacidade” com “estar em conformidade”

Política de privacidade é documento legal. Conformidade é implementação técnica. Se sua política diz “coletamos localização para melhorar a experiência” mas seu código coleta latitude e longitude em todo request da API, você tem um problema de R$ 2,37 bilhões esperando para acontecer.

2. Usar cookies de analytics antes do consentimento

Quantas vezes vi o Google Analytics ou Facebook Pixel rodando antes do banner de cookies aparecer? Isso é prática comum e ilegal sob o GDPR. A regra é clara: nenhum script de tracking carrega até o consentimento explícito. Use um CMP (Consent Management Platform) como Cookiebot, OneTrust ou implemente um próprio.

3. Armazenar IP como log “técnico” e esquecer que é dado pessoal

IP é dado pessoal sob o GDPR. Aquele log gigante que você guarda “para debug” precisa de política de retenção, base legal e, idealmente, anonimização. Já vi empresas receberem multas exatamente por isso.

4. Não documentar a finalidade do dado

O GDPR exige que você saiba por quê cada campo existe. Se um devjunior adicionar um campo user_location “porque pode ser útil no futuro”, você está criando passivo regulatório. Campos em banco sem finalidade declarada são minas de ouro para auditores.

5. Esquecer o direito ao esquecimento

Quando o usuário pede exclusão, você precisa deletar todos os dados, incluindo logs, backups recentes, data lake, e cópias em serviços de terceiros. Muitos devs esquecem que uma vez que o dado vazou para o Slack, Stripe, Sentry, DataDog etc., o “esquecimento” virou um projeto de semanas.

O impacto real no seu trabalho como dev

Se você trabalha em startup europeia ou tem clientes europeus (o que é comum até para devs brasileiros, dado o mercado remoto), esse caso do Google redefine o piso de qualidade esperado. Não dá mais para entregar MVP com tracking genérico e “ajeitar a privacidade depois”. O “depois” pode custar o fechamento da empresa.

Na minha prática, quando inicio um projeto que envolve dados pessoais hoje, eu pergunto três coisas antes de escrever uma linha de código:

1. Qual a base legal para esse processamento? (consentimento, contrato, legítimo interesse, obrigação legal)
2. Onde os dados residirão fisicamente? (LGPD brasileira, GDPR europeia, outras jurisdições têm regras de transferência)
3. Qual o plano de exclusão? (criptografia, retenção, direito ao esquecimento)

Essas três perguntas já eliminam 80% dos problemas antes deles existirem.

Comparativo rápido: as três funcionalidades problemáticas do Google

FAQ — Perguntas que devs realmente fazem

O GDPR se aplica a empresas brasileiras?

Sim, se você processar dados de cidadãos da UE. Empresas brasileiras que atendem clientes europeus, oferecem produtos em português para a Europa, ou monitoram comportamento de europeus (analytics, remarketing) estão dentro do escopo. A multa pode ser executada via cooperação internacional.

Qual a diferença prática entre LGPD e GDPR?

São parecidas, mas o GDPR tem multas maiores (até 4% do faturamento global ou €20 milhões) e exige DPO (Data Protection Officer) obrigatório em mais casos. A LGPD brasileira está caminhando para se alinhar cada vez mais — seguir o padrão mais rígido (GDPR) costuma ser estratégia inteligente.

Como sei se preciso pedir consentimento para uma feature?

Sempre que o dado for pessoal, sensível, ou usado para finalidade diferente daquela declarada na coleta. Na dúvida, peça consentimento granular e registe o timestamp + versão da política. Existem bibliotecas prontas em vários frameworks que facilitam isso.

Vale a pena usar Google Analytics, Meta Pixel e similares?

Sim, mas com consentimento prévio e configuração correta. Não basta instalar — você precisa configurar o modo de consentimento (consent mode v2 do Google, por exemplo), anonimizar IPs quando possível, e respeitar o sinal do banner. Já vi empresas multadas por rodar Analytics sem consentimento e usar os dados para remarketing.

Quanto custa se adequar de verdade?

Menos que a multa. Ferramentas como Cookiebot custam a partir de ~€12/mês para sites pequenos. Para empresas maiores, investir entre R$ 30k e R$ 100k em adequação completa (DPO, política, implementação técnica) é razoável. Comparado com 4% do faturamento, é seguro barato.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.