Conformidade com o RGPD em sites: o que é preciso, na prática, para construir um site conforme

A maior parte dos conselhos sobre o RGPD que se encontram online é escrita para juristas ou para quem anda à procura de um gerador de políticas de privacidade. Muito pouco é escrito para a pessoa que tem de abrir um editor e mudar alguma coisa.

Este guia é do segundo tipo. Percorre o que o Regulamento Geral sobre a Proteção de Dados exige a um site e aos sistemas por trás dele, traduzido em coisas que se desenvolvem, configuram ou apagam. Fazemos este trabalho para empresas que operam na UE desde que o regulamento começou a aplicar-se, em 2018, e o padrão do que corre mal quase não mudou desde então.

Uma coisa a dizer logo à partida: o RGPD não ficou mais fácil por terem chegado regulamentos mais recentes. Ficou mais importante, porque quase tudo na atual vaga de regras digitais da UE parte do princípio de que já tem os seus dados pessoais em ordem.

Comece por um inventário de dados honesto

Quase todos os projetos de RGPD falhados que herdámos falharam no mesmo ponto. A equipa escreveu primeiro a política e só depois descobriu os dados.

Antes de mais nada, faça o levantamento dos dados pessoais que o seu site recolhe de facto. Não o que a especificação do produto diz que recolhe. O que está na base de dados, nos registos, na plataforma de análise, no CRM, na ferramenta de suporte, nas ferramentas de automação de marketing, no rastreador de erros, nos registos da CDN e nos scripts de terceiros da página.

Na prática, isso significa:

• Percorrer o esquema da base de dados. Todas as colunas que possam identificar uma pessoa, diretamente ou em combinação com outra coluna.
• Ler o separador de rede num carregamento real da página. Cada pedido de saída para um domínio que não controla é uma potencial transferência de dados pessoais, porque um endereço IP mais um user agent são dados pessoais.
• Verificar o que o seu rastreador de erros captura. Os stack traces contêm regularmente endereços de email, tokens e corpos de pedidos.
• Verificar a conservação dos registos. Registos de acesso com IP guardados para sempre são uma das constatações mais comuns e uma das mais fáceis de corrigir.

Passe tudo a escrito como registo das atividades de tratamento. O artigo 30.º exige-o, de qualquer forma, à maioria das organizações, e a versão útil para os engenheiros é uma tabela com o sistema, os dados, a finalidade, o fundamento de licitude, o prazo de conservação e os destinatários.

Escolha um fundamento de licitude por finalidade, não por sistema

O artigo 6.º prevê seis fundamentos de licitude. O erro que vemos com mais frequência é escolher um para o produto inteiro.

É quase certo que tem várias finalidades a decorrer ao mesmo tempo. Cumprir uma encomenda é execução de contrato. As verificações antifraude assentam, em regra, em interesses legítimos ou numa obrigação jurídica. Conservar as faturas durante o prazo legal é obrigação jurídica. O email de marketing exige consentimento na maioria dos Estados-Membros. A análise não essencial exige consentimento, por força das regras de privacidade eletrónica sobre o acesso ao equipamento terminal e não do próprio RGPD.

A consequência prática é que o seu modelo de dados tem de saber a que finalidade serve cada registo. Se não conseguir separar o perfil de marketing do registo da encomenda, não consegue respeitar uma oposição ao marketing sem estragar o histórico de encomendas. Essa separação é uma decisão de esquema, e é penosa de introduzir a posteriori.

O consentimento tem de ser real e tem de ficar registado

Se se basear no consentimento, este tem de ser livre, específico, informado e inequívoco, e tem de o conseguir demonstrar mais tarde.

Em concreto:

• Nada que não seja essencial é ativado antes de o utilizador agir. Isso inclui o snippet de análise, o pixel de publicidade, o widget de chat, o tipo de letra carregado de uma CDN de terceiros e o script de testes A/B.
• Rejeitar tem de ser tão fácil como aceitar. A mesma camada, o mesmo destaque, o mesmo número de cliques. As autoridades tratam tudo o resto como um padrão enganador, e têm sido coerentes nisso.
• O consentimento é por finalidade. Um único interruptor para «análise, marketing e personalização» não é específico.
• Retirar o consentimento é tão fácil como dá-lo. Uma ligação permanente ou um botão flutuante, não um email para o suporte.
• Guarde a prova: um carimbo temporal, a cadeia de consentimento ou o estado de cada categoria, a versão do banner e o texto que foi mostrado ao utilizador. Sem a versão, não consegue defender um registo de consentimento com dois anos.

A fiscalização, aqui, não é teórica. Em setembro de 2025, a autoridade francesa de proteção de dados aplicou no mesmo dia coimas de 325 milhões de euros à Google e de 150 milhões de euros à Shein por práticas relacionadas com cookies. Os dois casos giraram em torno da mecânica e não do texto das políticas: cookies colocados antes de qualquer interação e botões de rejeição que não rejeitavam de facto.

As regras nesta matéria também estão a mudar. A proposta Omnibus Digital da Comissão transferiria o consentimento relativo ao equipamento terminal para o próprio RGPD e tornaria vinculativos os sinais emitidos pelo browser. O Conselho vai no sentido oposto: segundo o que foi noticiado, o seu projeto de texto de negociação de 2 de outubro de 2026 mantém o consentimento para cookies no artigo 5.º, n.º 3, da Diretiva Privacidade Eletrónica e deixa cair os dois novos artigos do RGPD. A 10 de outubro de 2026, o Conselho ainda não tinha adotado essa posição, e as negociações com o Parlamento ainda não tinham começado. Explicámos o que a proposta da Comissão mudaria em consentimento para cookies depois do Omnibus Digital.

Construa cedo a maquinaria dos direitos dos titulares

Os artigos 15.º a 22.º dão às pessoas o direito de acesso, retificação, apagamento, limitação, portabilidade e oposição. Tem um mês para responder, prorrogável até três nos casos complexos.

As equipas tendem a tratar os primeiros pedidos à mão, o que funciona até ao dia em que deixa de funcionar. O que convém ter, bem antes de o volume chegar:

Um mecanismo que encontra uma pessoa em todos os sistemas. A partir de um endereço de email, devolve tudo: a conta, as encomendas, os pedidos de suporte, o perfil de marketing, o identificador de análise, os registos. Se for preciso alguém lembrar-se de que há uma plataforma de avaliações de terceiros com dados, mais cedo ou mais tarde alguém se vai esquecer.

Um circuito de apagamento que respeita as obrigações de conservação. O apagamento não é absoluto. As faturas têm normalmente de sobreviver por razões fiscais. O que precisa é de eliminação lógica com eliminação física delimitada por finalidade, para poder remover o perfil de marketing e manter o registo contabilístico, e para que o próprio registo contabilístico expire no prazo previsto.

Uma exportação portável. Estruturada, de uso corrente e de leitura automática. JSON serve. Um PDF de uma página HTML renderizada não serve.

Um indicador de oposição que todo o sistema lê. Opor-se à definição de perfis tem de parar efetivamente a definição de perfis, incluindo na tarefa em lote que corre às 3 da manhã e não verifica o indicador.

A conservação é uma tarefa, não uma linha numa política

A limitação da conservação é o princípio mais violado por sistemas que, de resto, estão bem construídos, porque apagar dados exige que alguém escreva e agende uma tarefa que ninguém pede.

Atribua a cada categoria de dados uma duração definida e depois implemente-a. Registos de acesso, registos de sessão, carrinhos abandonados, inscrições não verificadas, pedidos de suporte fechados, cópias de segurança antigas e dados brutos de análise precisam todos de prazo de validade. As cópias de segurança merecem atenção especial: se o seu processo de reposição ressuscitar dados pessoais apagados, o seu apagamento está incompleto, e a resposta habitual é uma rotação documentada das cópias de segurança com uma idade máxima, mais a reaplicação dos apagamentos depois de qualquer reposição.

Transferências, subcontratantes e onde corre realmente a sua infraestrutura

As transferências para fora do EEE precisam de um mecanismo legal, normalmente o Quadro de Privacidade de Dados UE-EUA para destinatários norte-americanos certificados, ou as cláusulas contratuais-tipo mais uma avaliação de impacto da transferência nos restantes casos.

A perspetiva da engenharia é mais simples do que a jurídica: saiba onde estão fisicamente os seus dados. Isso quer dizer a região de cloud de cada serviço, a localização das cópias de segurança, a região da base de dados gerida, a configuração dos pontos de presença da CDN e, sobretudo, o modelo de suporte de cada ferramenta SaaS que usa. Um fornecedor alojado em Frankfurt cuja equipa de suporte acede à produção a partir de fora do EEE continua a ser uma transferência.

Em geral, recomendamos manter os dados pessoais em regiões da UE quando não haja uma razão forte para o contrário. Elimina uma categoria inteira de discussões, e a diferença de custo é normalmente irrelevante.

Mantenha uma lista de subcontratantes e mantenha-a atualizada. O artigo 28.º exige um contrato de tratamento escrito com cada um, e a lista é também o que os seus clientes lhe vão pedir na due diligence.

Segurança por defeito, expressa como configuração

O artigo 32.º pede medidas técnicas e organizativas adequadas. É deliberadamente vago, mas o mínimo para um site em 2026 não é:

• TLS em todo o lado, HSTS ativado, sem conteúdo misto.
• Palavras-passe com hash através de uma função moderna exigente em memória, e autenticação multifator disponível para contas que guardam dados pessoais.
• Cifragem em repouso das bases de dados e das cópias de segurança.
• Acesso aos dados pessoais de produção limitado por função e registado, com revisões que acontecem de facto.
• Pseudonimização sempre que possível: aplique um hash ao identificador na análise e mantenha a tabela de correspondência separada e com acesso controlado.
• Uma reposição testada, não apenas uma cópia de segurança.

A proteção de dados desde a conceção e por defeito, prevista no artigo 25.º, significa que a opção que protege a privacidade é a que se obtém sem fazer nada. A caixa da newsletter por assinalar. A visibilidade do perfil em privado. Os campos opcionais, opcionais.

A notificação de violações precisa de um runbook

Setenta e duas horas entre o conhecimento e a notificação à autoridade de controlo não é muito tempo, sobretudo se a violação for descoberta numa sexta-feira à noite. Note que a proposta Omnibus Digital alargaria esse prazo para noventa e seis horas, embora ainda não seja lei.

Prepare-se com antecedência: quem declara um incidente, quem avalia se foram afetados dados pessoais, quem contacta a autoridade, o que contém a notificação e como informa as pessoas afetadas se o risco for elevado. Escreva-o como um runbook com funções atribuídas a pessoas concretas e ensaie-o uma vez. A primeira vez que o usar não deve ser a primeira vez que o lê.

A superfície visível do site

Parte do RGPD vê-se na página, e vale a pena acertar nos pormenores, porque é isso que as pessoas denunciam.

O seu aviso de privacidade tem de indicar a identidade e os contactos do responsável pelo tratamento, as finalidades e os fundamentos de licitude, os destinatários e as categorias de destinatários, os mecanismos de transferência, os prazos de conservação, a lista completa de direitos, incluindo o direito de apresentar reclamação a uma autoridade de controlo, e se existem decisões automatizadas. Escreva-o numa linguagem que uma pessoa comum consiga acompanhar. Os avisos por camadas, com uma versão curta que remete para o pormenor, funcionam melhor do que uma parede de texto.

Os formulários devem recolher apenas o necessário. Cada campo é uma justificação que pode ter de dar. Se a caixa de consentimento para marketing estiver no mesmo envio que a encomenda, tem de vir por assinalar e com redação própria.

Os conteúdos incorporados de terceiros são a falha silenciosa. YouTube no modo de privacidade melhorada, mapas por trás de um marcador que só carrega com um clique, tipos de letra alojados no próprio servidor em vez de vindos de uma CDN de terceiros. Cada um destes passos é uma pequena alteração, e cada um elimina uma constatação.

O que vemos correr mal com mais frequência

Depois de auditorias suficientes, a mesma lista curta continua a aparecer:

1. Ferramentas de análise que carregam antes do consentimento, normalmente porque o gestor de tags foi configurado pelo marketing e nunca revisto pela engenharia.
2. Botões de rejeição que acabam por ativar o consentimento por causa do comportamento por omissão de um script de terceiros.
3. Nenhuma tarefa de conservação, em nenhuma tabela.
4. Apagamentos que deixam de fora as cópias de segurança, os registos e o CRM.
5. Um aviso de privacidade que descreve um fluxo de dados que mudou há dezoito meses.
6. Listas de subcontratantes que ficam pelos três fornecedores óbvios.
7. Registos de consentimento sem a versão do texto que foi mostrado.

Nenhum destes problemas é difícil. São apenas trabalho que não foi atribuído a ninguém.

Obter ajuda

Se quiser um segundo olhar sobre um site existente, fazemos auditorias técnicas de RGPD que resultam numa lista de tarefas priorizada e não num relatório: o que corrigir, por que ordem, com uma estimativa para cada ponto. Se está a construir algo novo, sai bastante mais barato acertar desde o início no modelo de dados e na arquitetura de consentimento.

Tratamos também do resto da conformidade europeia, incluindo a acessibilidade e a entrada no mercado europeu. Contacte-nos através de office@c9group.dev.

Desenvolvemos software. Não damos aconselhamento jurídico, e a interpretação de qualquer requisito concreto cabe ao seu advogado. O que podemos fazer é garantir que o sistema faz o que o seu advogado diz que deve fazer.