GDPR para Programadores | O Que Realmente Precisa de Implementar
Um guia de GDPR focado em programadores. Cobre os requisitos tecnicos, padroes de tratamento de dados e decisoes ao nivel do codigo que precisa de tomar.
O GDPR esta em vigor desde 2018, mas a maioria dos guias para programadores ainda se foca na teoria juridica. Este guia e diferente. Cobre os requisitos tecnicos, o codigo que precisa de escrever e as decisoes arquiteturais que tornam a conformidade pratica em vez de penosa.
Se o seu software armazena, processa ou toca em dados pessoais de pessoas na UE, isto aplica-se a si. Nao importa onde a sua empresa esta sediada.
Visao Geral do GDPR para Programadores
Ignore os 99 artigos. Eis o que o GDPR significa para a sua base de codigo:
- Recolha apenas o que precisa. Nao armazene dados “por precaucao.”
- Informe os utilizadores sobre o que faz com os seus dados. E obtenha a permissao deles quando necessario.
- Permita que os utilizadores acedam, exportem e apaguem os seus dados. Precisa de endpoints de API para isto.
- Mantenha os dados seguros. Encriptacao, controlos de acesso, registos de auditoria.
- Reporte violacoes rapidamente. Tem 72 horas para notificar as autoridades apos descobrir uma violacao.
- Documente tudo. As suas atividades de processamento, as suas medidas de seguranca, os seus fluxos de dados.
Este e o resumo pratico. O resto deste guia mostra como implementar cada requisito.
Os 7 Requisitos Tecnicos Principais
1. Gestao de Consentimento
O consentimento deve ser dado livremente, especifico, informado e inequivoco. Caixas pre-marcadas nao contam. Consentimento agrupado (“concordar com tudo”) nao conta. A revogacao deve ser tao facil como a concessao do consentimento.
O Que Construir
Um sistema de consentimento precisa de tres componentes:
- Um armazenamento de registos de consentimento. Para cada utilizador, registe a que consentiram, quando e como.
- Um mecanismo de verificacao de consentimento. Antes de processar dados para um fim especifico, verifique se o utilizador tem consentimento ativo.
- Um mecanismo de revogacao. Permita que os utilizadores revoguem o consentimento atraves da sua interface, e pare o processamento imediatamente.
Esquema de Base de Dados
CREATE TABLE user_consents (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL REFERENCES users(id),
consent_type VARCHAR(100) NOT NULL,
granted BOOLEAN NOT NULL,
granted_at TIMESTAMPTZ,
revoked_at TIMESTAMPTZ,
ip_address INET,
user_agent TEXT,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_user_consents_lookup
ON user_consents (user_id, consent_type, granted);
Armazene o historico completo. Nunca apague ou sobrescreva registos de consentimento. Quando um utilizador revoga o consentimento, insira uma nova linha com granted = false e defina revoked_at. Isto da-lhe um rasto de auditoria.
Middleware de Verificacao de Consentimento
Eis um middleware Express que verifica o consentimento antes de processar um pedido:
import { Request, Response, NextFunction } from "express";
import { db } from "./database";
interface ConsentRequirement {
type: string;
required: boolean;
}
function requireConsent(consentType: string) {
return async (req: Request, res: Response, next: NextFunction) => {
const userId = req.user?.id;
if (!userId) {
return res.status(401).json({ error: "Authentication required" });
}
const consent = await db.query(
`SELECT granted FROM user_consents
WHERE user_id = $1 AND consent_type = $2
ORDER BY created_at DESC
LIMIT 1`,
[userId, consentType]
);
if (!consent.rows[0]?.granted) {
return res.status(403).json({
error: "Consent required",
consentType,
message: `You must grant "${consentType}" consent to use this feature.`,
consentUrl: `/settings/privacy`,
});
}
next();
};
}
// Usage
app.post(
"/api/newsletter/subscribe",
requireConsent("marketing_emails"),
subscribeHandler
);
app.post(
"/api/analytics/track",
requireConsent("usage_analytics"),
trackHandler
);
2. Acesso e Exportacao de Dados (Direito de Acesso)
Os utilizadores tem o direito de solicitar uma copia de todos os dados pessoais que possui sobre eles. Deve fornecer num formato de uso comum e legivel por maquina. JSON ou CSV funciona.
O Que Construir
Um endpoint que recolhe todos os dados pessoais de um utilizador em todas as tabelas e servicos, e depois empacota-os num ficheiro descarregavel.
interface DataExport {
exportedAt: string;
user: {
profile: Record<string, unknown>;
activity: Record<string, unknown>[];
consents: Record<string, unknown>[];
communications: Record<string, unknown>[];
};
}
app.get("/api/me/data-export", authenticate, async (req, res) => {
const userId = req.user.id;
const [profile, activity, consents, communications] = await Promise.all([
db.query("SELECT id, email, name, created_at FROM users WHERE id = $1", [
userId,
]),
db.query(
"SELECT action, metadata, created_at FROM user_activity WHERE user_id = $1 ORDER BY created_at DESC",
[userId]
),
db.query(
"SELECT consent_type, granted, granted_at, revoked_at FROM user_consents WHERE user_id = $1 ORDER BY created_at DESC",
[userId]
),
db.query(
"SELECT type, sent_at, subject FROM communications WHERE user_id = $1 ORDER BY sent_at DESC",
[userId]
),
]);
const exportData: DataExport = {
exportedAt: new Date().toISOString(),
user: {
profile: profile.rows[0],
activity: activity.rows,
consents: consents.rows,
communications: communications.rows,
},
};
res.setHeader("Content-Type", "application/json");
res.setHeader(
"Content-Disposition",
`attachment; filename="data-export-${userId}.json"`
);
res.json(exportData);
});
Este endpoint deve cobrir todas as tabelas que contem dados do utilizador. Audite o seu esquema minuciosamente. Uma tabela em falta significa uma exportacao incompleta, o que e uma falha de conformidade.
3. Direito a Eliminacao (Direito ao Esquecimento)
Os utilizadores podem solicitar que apague todos os seus dados pessoais. Deve cumprir a menos que tenha uma obrigacao legal de os reter (como registos fiscais ou prevencao de fraude).
O Que Construir
Um endpoint de eliminacao que remove ou anonimiza dados do utilizador em todas as tabelas. Isto e mais dificil do que parece devido a restricoes de chaves estrangeiras e dados de que outros sistemas dependem.
app.delete("/api/me/account", authenticate, async (req, res) => {
const userId = req.user.id;
const client = await db.getClient();
try {
await client.query("BEGIN");
// Anonymize data that must be retained for business records
await client.query(
`UPDATE orders
SET customer_name = 'deleted', customer_email = 'deleted'
WHERE user_id = $1`,
[userId]
);
// Delete data that can be fully removed
await client.query("DELETE FROM user_activity WHERE user_id = $1", [
userId,
]);
await client.query("DELETE FROM user_consents WHERE user_id = $1", [
userId,
]);
await client.query("DELETE FROM communications WHERE user_id = $1", [
userId,
]);
await client.query("DELETE FROM sessions WHERE user_id = $1", [userId]);
// Anonymize the user record instead of deleting
// This preserves referential integrity
await client.query(
`UPDATE users SET
email = 'deleted-' || id || '@removed.invalid',
name = 'Deleted User',
phone = NULL,
address = NULL,
deleted_at = NOW()
WHERE id = $1`,
[userId]
);
await client.query("COMMIT");
// Trigger deletion in external systems
await Promise.allSettled([
emailService.deleteSubscriber(userId),
analyticsService.deleteUser(userId),
searchIndex.removeUser(userId),
]);
res.json({ message: "Account and personal data deleted" });
} catch (error) {
await client.query("ROLLBACK");
throw error;
} finally {
client.release();
}
});
Decisoes chave:
- Apagar vs. anonimizar. Registos necessarios para contabilidade (encomendas, faturas) devem ser anonimizados. Apague tudo o resto.
- Sistemas externos. Dados enviados a servicos de terceiros devem ser apagados la tambem.
- Timing. O GDPR diz “sem atraso injustificado.” Complete a eliminacao em 30 dias. Para a maioria dos sistemas, torne-a imediata.
4. Minimizacao de Dados
Recolha e armazene apenas os dados de que realmente precisa para um fim declarado. Se pede um numero de telefone mas nunca liga aos utilizadores, nao devia estar a recolhe-lo.
Regras Praticas
- Audite cada campo de formulario. Para cada campo, pergunte: “Que funcionalidade especifica deixa de funcionar se o removermos?” Se a resposta e nada, remova-o.
- Defina periodos de retencao. Nao guarde dados para sempre. Defina quanto tempo cada tipo de dados e necessario, e depois apague-os automaticamente.
- Minimize os logs. Retire dados pessoais das entradas de log. Registe IDs de utilizador, nao nomes ou emails.
-- Automatic data retention with PostgreSQL
-- Run this as a scheduled job (e.g., pg_cron)
DELETE FROM user_activity
WHERE created_at < NOW() - INTERVAL '2 years';
DELETE FROM session_logs
WHERE created_at < NOW() - INTERVAL '90 days';
DELETE FROM password_reset_tokens
WHERE created_at < NOW() - INTERVAL '24 hours';
5. Encriptacao
O GDPR exige “medidas tecnicas adequadas” para proteger dados pessoais. A encriptacao e a mais importante.
Em Repouso
- Encripte o disco da sua base de dados. Todos os principais fornecedores de cloud suportam isto. Ative e verifique.
- Para campos altamente sensiveis (numeros de seguranca social, dados de saude), adicione encriptacao ao nivel da aplicacao por cima.
- Encripte backups. Um backup nao encriptado e uma violacao a espera de acontecer.
Em Transito
- TLS em todo o lado. Cada ligacao entre servicos, bases de dados e utilizadores. Sem excecoes.
- Force HTTPS. Redirecione HTTP. Defina cabecalhos HSTS.
- Use TLS para ligacoes a base de dados. PostgreSQL suporta isto nativamente.
// PostgreSQL connection with TLS
import { Pool } from "pg";
const pool = new Pool({
host: process.env.DB_HOST,
port: 5432,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
ssl: {
rejectUnauthorized: true,
ca: fs.readFileSync("/path/to/server-ca.pem").toString(),
},
});
6. Notificacao de Violacao
Se dados pessoais forem comprometidos, deve notificar a Autoridade de Protecao de Dados relevante em 72 horas. Se a violacao representar um risco elevado para os individuos, deve tambem notificar os utilizadores afetados.
O Que Construir
- Registo de auditoria. Rastreie cada acesso a dados pessoais. Quem acedeu, quando e de onde.
- Detecao de anomalias. Alerte sobre padroes de acesso invulgares (exportacoes de dados em massa, acesso a partir de novos IPs, acesso fora do horario de trabalho).
- Um plano de resposta a incidentes. Documente quem faz o que quando uma violacao e detetada. Isto nao e codigo. E uma checklist que a sua equipa pratica.
CREATE TABLE data_access_log (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL,
accessed_by UUID NOT NULL,
access_type VARCHAR(50) NOT NULL,
resource_type VARCHAR(100) NOT NULL,
resource_id UUID,
ip_address INET,
user_agent TEXT,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_data_access_log_user
ON data_access_log (user_id, created_at);
CREATE INDEX idx_data_access_log_accessor
ON data_access_log (accessed_by, created_at);
7. Privacidade por Design
O GDPR diz que a privacidade deve ser integrada nos sistemas desde o inicio, nao adicionada depois. Na pratica, isto significa tornar a privacidade o predefinido.
- Predefinido como privado. Novas funcionalidades devem recolher dados minimos e exigir opt-in para qualquer coisa alem da funcao central.
- As definicoes predefinidas sao a opcao mais privada. Utilizadores que nunca tocam nas suas definicoes devem ter a maior protecao de privacidade.
- Separe preocupacoes. Nao misture dados de analitica com dados funcionais. Nao reutilize tokens de autenticacao para rastreamento.
Anonimizacao vs. Pseudonimizacao
Nao sao a mesma coisa, e a distincao importa.
- Pseudonimizacao substitui informacao identificativa por um token reversivel. Exemplo: hash de enderecos de email. Se tem a funcao de hash e o email original, pode re-identificar a pessoa. O GDPR continua a aplicar-se porque a re-identificacao e possivel.
- Anonimizacao remove informacao identificativa permanentemente. Exemplo: analitica agregada (“1.247 utilizadores visitaram a pagina de precos”) sem forma de identificar quais utilizadores. O GDPR nao se aplica a dados verdadeiramente anonimizados.
A verdadeira anonimizacao e dificil. Se o seu conjunto de dados “anonimo” inclui um timestamp, uma cidade e um tipo de dispositivo, essa combinacao pode identificar alguem de forma unica. Seja conservador.
Consentimento de Cookies
Se o seu website usa cookies alem do estritamente necessario, precisa de consentimento antes de os definir.
Requer consentimento: cookies de analitica, pixels de publicidade, widgets de redes sociais, qualquer script de rastreamento de terceiros.
Nao requer consentimento: cookies de sessao, cookies de carrinho de compras, tokens CSRF, o proprio cookie de preferencia de consentimento.
O seu banner de consentimento deve bloquear cookies nao essenciais ate o consentimento ser dado, oferecer escolhas granulares e tornar “rejeitar todos” tao facil como “aceitar todos.” Nao construa isto de raiz. Ferramentas como Cookiebot tratam da complexidade. A regra chave: nenhum script de rastreamento dispara antes do consentimento ser concedido.
Processadores de Dados de Terceiros
Cada servico de terceiros que trata os dados dos seus utilizadores e um “processador de dados” ao abrigo do GDPR. Voce e responsavel pela conformidade deles.
O Que Verificar
Antes de integrar qualquer servico de terceiros que toque em dados pessoais:
- Tem um DPA? Um Acordo de Processamento de Dados e obrigatorio. A maioria dos fornecedores SaaS publica o seu publicamente.
- Onde armazenam os dados? Se fora da UE, verifique a base legal para a transferencia.
- A que dados acedem? Minimize o que envia. Se o servico so precisa de um email, nao envie o perfil completo.
- Pode apagar dados dos seus sistemas? Os pedidos de eliminacao de utilizadores devem propagar-se para todo o lado.
- Como lidam com violacoes? O DPA deles deve especificar prazos de notificacao.
Processadores de Terceiros Comuns a Rever
- Servicos de email (Resend, SendGrid, Mailchimp)
- Analitica (Google Analytics, Mixpanel, Amplitude)
- Rastreamento de erros (Sentry, Bugsnag)
- Processamento de pagamentos (Stripe, Adyen)
- Alojamento cloud (AWS, Google Cloud, Vercel)
- Ferramentas de suporte ao cliente (Intercom, Zendesk)
- APIs de IA (OpenAI, Anthropic, Google AI)
Mantenha uma lista de todos os processadores. Reveja-a trimestralmente.
Politicas de Retencao de Dados
Nao guarde dados pessoais mais tempo do que o necessario. Defina periodos de retencao para cada tipo de dados.
| Tipo de Dados | Retencao Sugerida | Razao |
|---|---|---|
| Dados de conta de utilizador | Ate pedido de eliminacao | Necessario para o servico |
| Registos de sessao | 90 dias | Seguranca e depuracao |
| Registos de atividade do utilizador | 1-2 anos | Analitica de produto |
| Tickets de suporte | 3 anos | Qualidade do servico |
| Registos financeiros | 7 anos | Obrigacoes fiscais/legais |
| Tokens de redefinicao de password | 24 horas | Seguranca |
| Tentativas de login falhadas | 90 dias | Monitorizacao de seguranca |
Implemente jobs de limpeza automatizados. Nao dependa de alguem se lembrar de executar um script.
Checklist GDPR para Programadores
Use isto como ponto de partida ao construir ou auditar um sistema.
Recolha de Dados
- Cada campo de formulario tem um fim declarado
- Nao sao recolhidos dados desnecessarios
- A politica de privacidade esta ligada a cada ponto de recolha de dados
- O consentimento e recolhido antes do processamento (quando necessario)
- Os registos de consentimento sao armazenados com timestamps
Armazenamento de Dados
- A encriptacao de base de dados em repouso esta ativada
- TLS e forcado para todas as ligacoes
- Campos sensiveis tem encriptacao ao nivel da aplicacao
- Os backups sao encriptados
- O acesso a dados de producao e restrito e registado
Direitos dos Utilizadores
- O endpoint de exportacao de dados existe e cobre todas as tabelas
- O endpoint de eliminacao de conta existe e trata todos os dados
- Os utilizadores podem ver e revogar consentimento nas suas definicoes
- A eliminacao propaga-se para servicos de terceiros
- Todos os pedidos de direitos dos utilizadores sao respondidos em 30 dias
Cookies e Rastreamento
- O banner de consentimento de cookies esta implementado
- Os cookies nao essenciais sao bloqueados antes do consentimento
- As opcoes de consentimento sao granulares (nao tudo-ou-nada)
- “Rejeitar todos” e tao proeminente como “Aceitar todos”
Terceiros
- Todos os processadores de dados estao documentados
- DPAs estao assinados com cada processador
- Os dados enviados a terceiros sao minimizados
- A eliminacao de dados de terceiros e possivel
Seguranca
- Os registos de auditoria rastreiam o acesso a dados pessoais
- Alertas de anomalias estao configurados
- O plano de resposta a incidentes esta documentado
- O processo de notificacao de violacao esta definido (prazo de 72 horas)
Retencao
- Os periodos de retencao estao definidos para todos os tipos de dados
- Jobs de limpeza automatizados estao agendados
- Os dados expirados estao realmente a ser apagados (verifique isto)
Consideracoes Finais
A conformidade com o GDPR nao e um projeto unico. E um conjunto de praticas integradas na forma como constroi software. O trabalho tecnico e direto: armazenamento de consentimento, exportacao de dados, endpoints de eliminacao, encriptacao, registo de auditoria. Engenharia padrao.
A parte dificil e ser minucioso. E facil esquecer aquele ficheiro de log, aquele evento de analitica ou aquela integracao de terceiros que armazena emails de utilizadores. Audite regularmente. Teste o seu endpoint de eliminacao. Verifique que as suas exportacoes estao completas. Integre a privacidade no seu processo desde o inicio.
Precisa de ajuda a construir software compativel com o GDPR ou a auditar os seus sistemas existentes? Contacte-nos. Construimos aplicacoes com privacidade em primeiro lugar para empresas europeias e empresas que servem utilizadores da UE.