Encurtadores de URL conformes com GDPR - o que procurar em 2026

Cada redirecionamento através de um encurtador de URL cria um evento de tratamento de dados. O evento de clique contém no mínimo um endereço IP, um timestamp e uma cadeia de agente de utilizador. Ao abrigo do Artigo 4(1) do GDPR, essa combinação pode constituir dados pessoais - o TJUE confirmou em Breyer (C-582/14, 2016) que os endereços IP dinâmicos são dados pessoais quando uma organização tem meios realistas de identificar o indivíduo por detrás deles. O seu encurtador tem esses meios: controla o registo de redirecionamentos.

Esta publicação é uma lista de verificação prática para avaliar se um encurtador de URL é genuinamente compatível com o GDPR. Vou percorrer o que o regulamento realmente exige, onde os fornecedores populares ficam aquém, o que procurar numa ferramenta conforme e as trocas envolvidas. As referências aos artigos são para o Regulamento (UE) 2016/679, o GDPR conforme alterado.

O que o GDPR exige de um encurtador de URL#

Um encurtador de URL situa-se no fluxo de dados entre a sua campanha e o seu cliente. Quando alguém clica numa ligação curta, o encurtador vê o clique antes de a página de destino o ver. Isso torna o encurtador um processador de dados ao abrigo do Artigo 4(8): processa dados pessoais em seu nome. Você é o responsável pelo tratamento; decide a finalidade e os meios do rastreamento. O encurtador executa a operação sob as suas instruções.

Essa divisão cria quatro obrigações concretas que precisa que o encurtador cumpra:

1. Um contrato escrito abrangendo o Artigo 28(3)

O Artigo 28(3) lista oito requisitos que qualquer contrato de processador deve incluir: tratamento apenas com base em instruções documentadas, confidencialidade, segurança adequada, divulgação de sub-processadores, assistência com os direitos dos titulares dos dados, assistência com obrigações de segurança e DPIA, eliminação ou devolução na rescisão e direitos de auditoria. Um encurtador sem um Acordo de Processamento de Dados (DPA) que aborde cada um destes não está pronto para aquisição para um deploy na UE.

2. Base jurídica para a camada de rastreamento de cliques

O próprio redirecionamento - receber um clique e encaminhar para o destino - é arguivelmente necessário para o serviço. A camada de análises no topo desse redirecionamento - registar o clique para atribuição, medição de campanhas, retargeting - é uma operação de tratamento separada que precisa da sua própria base jurídica ao abrigo do Artigo 6. A maioria das equipas B2B fundamenta as análises de campanha em interesse legítimo ao abrigo do Artigo 6(1)(f); se o encurtador injetar pixels de retargeting de terceiros no momento do redirecionamento, a base muda para consentimento ao abrigo do Artigo 6(1)(a), o que significa que precisa de um mecanismo de consentimento antes do primeiro clique.

3. Minimização de dados

O Artigo 5(1)(c) exige que a recolha de dados seja "adequada, pertinente e limitada ao que é necessário". Para um encurtador, este princípio aplica-se diretamente ao esquema de eventos de cliques. Precisa da geolocalização a nível de país, da categoria de dispositivo, do timestamp e de um identificador de clique. Não precisa do endereço IP completo após o momento do redirecionamento. Quase certamente não precisa da cadeia de agente de utilizador completa - um tuplo device.type / device.os analisado transporta o sinal de atribuição sem ser um vetor de fingerprinting.

4. Conformidade de transferência internacional

Se o encurtador armazenar ou processar eventos de cliques fora do EEE, aplicam-se o Artigo 44 e o Artigo 46. As transferências para os EUA requerem Cláusulas Contratuais Padrão (SCCs) mais uma Avaliação de Impacto da Transferência, ou participação no EU-US Data Privacy Framework, que é ele próprio objeto de litígio pendente. Um encurtador alojado na UE evita completamente este problema.

Onde os encurtadores populares ficam aquém#

Bitly#

O plano de dados principal do Bitly está nos Estados Unidos. De acordo com a sua documentação pública, as transferências internacionais de dados do EEE dependem de Cláusulas Contratuais Padrão. O DPA está disponível, mas não está pré-assinado no contrato padrão - os clientes enterprise negociam-no separadamente, o que acrescenta tempo de aquisição. A residência de dados apenas na UE não é uma oferta padrão; é uma conversa de contrato personalizado.

Dois problemas menos discutidos: o painel de análises do Bitly integra-se com serviços de atribuição de terceiros, e alguns escalões de planos permitem a injeção de pixels de retargeting na camada de redirecionamento. Se os pixels de retargeting dispararem antes de o utilizador ter consentido, esse é um problema de conformidade do Artigo 6 para si enquanto responsável pelo tratamento. O encurtador é o processador, mas o responsável pelo tratamento suporta a responsabilidade primária por ter a base jurídica correta.

Rebrandly#

O Rebrandly está sediado em Dublin, o que soa favorável à UE, mas a questão operativa é onde os dados são processados, não onde a empresa está constituída. De acordo com o seu DPA (acedido em maio de 2026), as transferências de dados do EEE para os EUA dependem de SCCs. O tratamento apenas na UE está disponível para clientes enterprise em termos personalizados. O contrato padrão não vincula os dados à infraestrutura da UE. Para equipas que precisam de uma cláusula de residência contratualmente exequível de imediato, o Rebrandly requer uma negociação personalizada.

O Rebrandly também suporta pixels de retargeting de terceiros nativamente na maioria dos planos. O valor de marketing é real; a implicação de conformidade é que qualquer pixel que dispare no momento do redirecionamento para sujeitos da UE necessita de uma base de consentimento, não de uma base de interesse legítimo, porque a criação de perfis comportamentais para publicidade fica fora do limite do interesse legítimo para a maioria das interpretações das autoridades de supervisão.

TinyURL#

O TinyURL oferece um plano gratuito limpo e é um encurtador de consumo amplamente utilizado. Não publica uma lista de sub-processadores. Os termos padrão não incluem um DPA que cumpra o Artigo 28(3). A camada de análises é rudimentar e alojada nos EUA. Para equipas B2B ou de marketing com sujeitos da UE no seu público, o TinyURL não está pronto para aquisição.

O problema geral dos encurtadores alojados nos EUA#

Muitos fornecedores que operam principalmente para clientes dos EUA tratam a conformidade com o GDPR como uma caixa de verificação em vez de uma restrição arquitetónica. Os sinais a observar: um crachá "conformidade com GDPR" na página de preços sem ligação a um DPA, uma lista de sub-processadores que não nomeia regiões de alojamento (apenas nomes de hiperscalers sem regiões), um processo de apagamento que passa pelo suporte em vez de um endpoint de API documentado, e nenhuma menção de truncagem de IP ou predefinições de minimização de dados.

"Conformidade com GDPR" como afirmação de marketing não significa nada sem um DPA que mapeie para o Artigo 28(3), uma lista de sub-processadores que seja atual e específica por região, e evidência de que a postura padrão de recolha de dados aplica minimização em vez de exigir que opte por ela.

A lista de verificação de encurtadores compatíveis com GDPR#

Estas são as dez perguntas a colocar por escrito antes de assinar um contrato com um encurtador de URL que irá processar dados de cliques em sujeitos da UE.

1. Onde são processados os dados, e é esse um compromisso contratual?#

Peça a região do hiperscaler - não apenas o nome do fornecedor de nuvem. "AWS" não é uma resposta; uma região da UE nomeada como "AWS eu-central-1" é. Mais importante ainda, pergunte se essa região é uma cláusula vinculativa no contrato padrão ou uma prática operacional que pode mudar sem o seu consentimento. Ao abrigo do Artigo 44, as transferências fora do EEE precisam de uma base legal; quer o compromisso de residência no contrato para não ter de refazer a análise cada vez que o fornecedor atualiza a sua infraestrutura.

2. O DPA está pré-assinado e cobre o Artigo 28(3) na íntegra?#

Um DPA que vem pré-assinado no contrato padrão sinaliza que o fornecedor trata a conformidade com o GDPR como uma linha de base, não uma negociação. Leia o DPA em relação aos oito sub-parágrafos do Artigo 28(3). Cada um deve ser abordado. Preste atenção particular ao parágrafo (d) - contratação de sub-processadores - e ao parágrafo (h) - direitos de auditoria. Linguagem genérica como "utilizamos práticas de segurança padrão do setor" em vez das obrigações concretas é um sinal de alerta.

3. Quantos sub-processadores existem, e estão nomeados com regiões?#

Cada sub-processador é uma ligação adicional na cadeia de transferência. Uma lista curta com regiões nomeadas (fornecedor de computação na UE na região da UE, fornecedor de e-mail em Leste dos EUA, etc.) é auditável numa única revisão. Uma lista longa com nomes vagos de fornecedores é um fardo de manutenção e um risco de residência. Ao abrigo do Artigo 28(2), cada sub-processador deve aceitar as mesmas obrigações de proteção de dados que o processador. Pergunte qual é o período de aviso para novos sub-processadores e se tem direito de objeção.

4. O encurtador trunca ou faz hash dos endereços IP antes de os armazenar?#

O armazenamento de endereços IP completos raramente é necessário para os casos de uso de análises que um encurtador suporta. A geolocalização a nível de país e a deteção de bots podem ser realizadas no momento do redirecionamento a partir do IP completo e o resultado armazenado; o IP bruto pode então ser descartado ou truncado. Ao abrigo do Artigo 5(1)(c), armazenar mais dados do que a finalidade exige é uma violação do princípio da minimização de dados. Pergunte se a truncagem ou hash de IP é a predefinição, ou se tem de optar por ela. A minimização por predefinição é a arquitetura correta; a minimização por opt-in transfere o risco de conformidade para si.

5. O redirecionamento injeta scripts ou pixels de terceiros?#

Alguns encurtadores oferecem injeção de pixels de retargeting como funcionalidade: quando um visitante clica na sua ligação curta, o encurtador carrega um Meta Pixel, Google Tag ou script de terceiros semelhante antes ou durante o redirecionamento. Para sujeitos da UE, carregar um script de rastreamento comportamental de terceiros sem consentimento prévio é uma violação do Artigo 6 e, dependendo se os cookies são definidos, da Diretiva ePrivacidade. Se o seu encurtador oferecer injeção de pixels, essa funcionalidade deve ser desativada ou condicionada ao consentimento para tráfego da UE. Se o fornecedor não puder confirmar que nenhum script de terceiros é carregado no momento do redirecionamento por predefinição, teste-o você mesmo com o separador de Rede aberto.

6. Existe um endpoint de API para pedidos de direito ao apagamento?#

O Artigo 17 concede aos titulares dos dados o direito de ter os seus dados pessoais apagados "sem demora injustificada" quando se aplicam condições específicas. Quando recebe um pedido de apagamento que se relaciona com dados de cliques que o seu encurtador detém, precisa de um mecanismo para agir sobre ele. Um endpoint de API que aceita um identificador de titular e elimina os eventos de cliques associados é a resposta operacionalmente correta. O apagamento via ticket de suporte não é "sem demora injustificada" na maioria das interpretações das autoridades de supervisão e não é um padrão escalável em qualquer volume de cliques significativo.

A complicação é que os eventos de cliques são frequentemente armazenados numa base de dados de análises colunar apenas de adição (por exemplo BigQuery ou Snowflake). Um fornecedor que armazena eventos de cliques desta forma precisa de demonstrar que a eliminação é real - um DELETE contra a partição relevante - não apenas um indicador de software. Pergunte pelo SLA do Artigo 17 do fornecedor e pelo mecanismo técnico por detrás dele.

7. Qual é o SLA de notificação de violação?#

O Artigo 33 exige que um responsável pelo tratamento notifique a sua autoridade de supervisão de uma violação de dados pessoais "sem demora injustificada e, sempre que possível, o mais tardar 72 horas após ter tido conhecimento da mesma". Para que esse relógio funcione, precisa que o seu processador o notifique a si materialmente mais depressa - a norma do setor é 24 horas desde a perceção até à notificação do responsável pelo tratamento. O seu DPA deve especificar este SLA. "Iremos notificá-lo prontamente" não é um número.

8. O encurtador usa análises sem cookies, de origem própria por predefinição?#

Muitos encurtadores constroem o seu próprio painel de análises em cima de uma ferramenta de análise de produto de terceiros (Mixpanel, Amplitude, Segment) que é alojada nos EUA e pode definir identificadores persistentes em cookies ou armazenamento local. Para as próprias análises de produto do encurtador (rastreamento do seu uso do painel), isso é um assunto separado. A questão relevante para o rastreamento de cliques é se o fluxo de redirecionamento define cookies ou identificadores persistentes no browser do visitante sem consentimento.

Um evento de clique sem cookies - um que deriva país, dispositivo e referenciador dos cabeçalhos do pedido sem definir nenhum estado do lado do cliente - não requer um mecanismo de consentimento para análises de origem própria ao abrigo da maioria das orientações das autoridades de supervisão, desde que os dados sejam processados com base em interesse legítimo e o aviso de privacidade seja acessível. Um redirecionamento que define um identificador persistente ou carrega uma tag de terceiros requer um portal de consentimento. Saiba qual é o que o seu encurtador usa.

9. Existe um aviso de transparência acessível aos destinatários de ligações?#

O Artigo 13 exige que os indivíduos cujos dados são recolhidos sejam informados do tratamento no momento da recolha, a não ser que se aplique uma exceção. Para o rastreamento de cliques numa ligação curta, a questão prática é: como é que a pessoa que clica na ligação sabe que o seu clique está a ser rastreado, e onde pode ler sobre isso?

A maioria dos deploys de encurtadores satisfaz isso através do aviso de privacidade do responsável pelo tratamento na página de destino ou num banner de cookies na página de campanha de origem. O encurtador como processador não precisa de exibir o seu próprio aviso ao clicador - mas você, como responsável pelo tratamento, precisa de um aviso de privacidade que cubra a cadeia de tratamento de rastreamento de ligações. Se a política de privacidade do encurtador for o único documento que descreve o tratamento, e for escrita da perspetiva do fornecedor e não do responsável pelo tratamento, tem uma lacuna.

10. Pode transferir e eliminar os seus próprios dados sem contactar o suporte?#

Este é um teste prático de se um fornecedor realmente operacionaliza os direitos dos titulares dos dados que afirma suportar. Deve ser capaz de: exportar todos os eventos de cliques de um espaço de trabalho num formato portátil, eliminar ligações individuais e o respetivo histórico de cliques, e encerrar a conta com eliminação documentada de todos os dados pessoais. Se algum destes requer um pedido de suporte em vez de uma ação API ou painel self-serve, peça o SLA e coloque-o no contrato.

As trocas envolvidas#

A arquitetura compatível com GDPR envolve trocas reais, e ser honesto sobre elas é mais útil do que fingir que as restrições de conformidade não têm custo.

Análises mais grosseiras. Um encurtador que trunca IPs para /24 e descarta a cadeia de agente de utilizador completa dá-lhe país, família de dispositivo e SO - mas não segmentação a nível de cidade, não a impressão digital individual do browser, e não a resolução de identidade entre sessões que os dados de resolução completa possibilitariam. Para a maioria dos casos de uso de atribuição de campanha, este nível de resolução é suficiente. Para retargeting ao nível individual, precisa de uma abordagem diferente - tipicamente encaminhamento de conversões do lado do servidor contra um identificador de origem própria que o utilizador já partilhou (endereço de email, ID de utilizador com sessão iniciada), que não requer que o encurtador rastreie o indivíduo na camada de redirecionamento.

Superfície de funcionalidades mais pequena. Algumas das funcionalidades mais poderosas dos encurtadores - injeção de pixels de retargeting, rastreamento entre domínios, integração profunda com plataformas de anúncios de terceiros - são construídas em práticas de recolha de dados difíceis de reconciliar com a minimização de dados. Um encurtador compatível com GDPR tende a ter um redirecionamento mais limpo que faz menos na camada de redirecionamento e encaminha mais para a camada de eventos de conversão, onde o responsável pelo tratamento tem uma relação direta com o utilizador e pode fundamentar o rastreamento em consentimento.

Sobrecarga de aquisição. Escolher um encurtador alojado na UE com um DPA pré-assinado reduz o ciclo de aquisição em comparação com um fornecedor alojado nos EUA que requer um contrato personalizado para residência na UE. Não elimina o ciclo. Ainda precisa de rever o DPA, verificar a lista de sub-processadores, validar o SLA de apagamento e confirmar que as predefinições de truncagem de IP e de cookies correspondem ao seu aviso de privacidade. Estime duas a quatro horas de trabalho de aquisição para um encurtador compatível com GDPR versus duas a oito semanas para um fornecedor alojado nos EUA onde a residência na UE requer negociação de contrato personalizado.

Como o Elido aborda isto#

Onde é relevante para esta lista de verificação, aqui está o aspeto do deploy padrão do Elido.

Residência de dados. O Elido processa eventos de cliques em infraestrutura na UE na região da UE por predefinição. A residência é uma cláusula vinculativa no contrato padrão de cliente, não uma prática operacional. Os clientes Business+ podem fixar noutras regiões; a predefinição não transfere dados para fora do EEE.

Truncagem de IP. Os eventos de cliques armazenados no nosso armazenamento de análise contêm o prefixo de rede /24 (IPv4) ou /48 (IPv6), não o endereço IP completo. A geolocalização e a deteção de bots correm sobre o IP completo no momento do redirecionamento e o IP completo é descartado antes de o evento ser persistido. Esta é a predefinição; não precisa de a configurar.

Pixels de terceiros no momento do redirecionamento. O plano de redirecionamento não carrega nenhum script de terceiros. O encaminhamento de conversões do lado do servidor - enviar dados de atribuição para Meta CAPI, GA4 ou similares - é uma funcionalidade opcional, configurada separadamente, que usa dados de eventos de origem própria que envia para a API do Elido via POST, não um pixel injetado no momento do redirecionamento. Estes são arquiteturalmente diferentes: um dispara sem o conhecimento do visitante a partir do redirecionamento, o outro é uma chamada servidor a servidor indexada por dados que o visitante já partilhou consigo.

DPA. O DPA do Elido está pré-assinado no contrato padrão de cliente. Aborda todos os oito sub-parágrafos do Artigo 28(3). Os sub-processadores estão listados na página de confiança com regiões nomeadas. A página legal/privacy cobre a cadeia de tratamento visível para os destinatários de ligações.

Direito ao apagamento. Os pedidos de apagamento do Artigo 17 propagam-se para o armazenamento de eventos de cliques dentro de 24 horas. A eliminação é uma operação ao nível da partição, não um indicador de software.

Análises sem cookies. O plano de redirecionamento não define cookies. Os eventos de cliques são apenas do lado do servidor. O painel de análises que o Elido fornece internamente usa o Plausible em modo sem cookies para telemetria de produto; isso é separado do registo de eventos de cliques para as suas campanhas.

O que o Elido ainda não tem: SOC 2 Tipo II (em progresso, com objetivo para H2 2026), um modelo DPIA self-serve para clientes, e uma API de pedido de acesso de titular totalmente automatizada para cenários de direito de acesso menos comuns. Para detalhes sobre as atestações atuais, consulte a página de confiança.

Lista de verificação de migração para mudar de um encurtador fora da UE#

Se está atualmente a usar um encurtador alojado nos EUA e precisa de passar para um alojado na UE, aqui está uma lista de verificação operacional comprimida.

Antes de assinar o novo contrato:

1. Leia o DPA do novo fornecedor em relação ao Artigo 28(3). Confirme que todos os oito pontos estão cobertos explicitamente.
2. Verifique a lista de sub-processadores. Confirme que as regiões de alojamento estão nomeadas, não apenas os fornecedores de nuvem.
3. Confirme a predefinição de truncagem de IP. Peça confirmação escrita se não estiver na documentação do produto.
4. Confirme o SLA do Artigo 17 e o mecanismo técnico.
5. Verifique se os pixels de retargeting disparam no momento do redirecionamento. Se sim, confirme que podem ser desativados completamente ou estão condicionados ao consentimento.

Durante a migração:

6. Exporte as suas ligações curtas existentes como CSV. Verifique que os slugs personalizados são preservados pela nova plataforma antes de tocar no DNS.
7. Provisione todas as ligações na nova plataforma sob o mesmo domínio personalizado e slugs antes de redirecionar o CNAME.
8. Aguarde 24–48 horas para a propagação do DNS após a mudança do CNAME. Ambas as plataformas irão servir respostas válidas durante esta janela se os slugs corresponderem.
9. Não migre dados históricos de cliques da plataforma antiga - a cadeia de custódia para os eventos de cliques antigos fica com o processador antigo até exercer os direitos de eliminação.

Após a migração:

10. Emita um pedido de apagamento ao fornecedor antigo para todos os dados pessoais associados ao seu espaço de trabalho. Confirme a receção e o calendário de eliminação.
11. Atualize o seu aviso de privacidade para refletir o novo processador, os seus sub-processadores e a nova residência de dados.
12. Reveja quaisquer banners de cookies ou mecanismos de consentimento que referenciavam as funcionalidades de rastreamento do encurtador antigo. Ajuste o âmbito se a recolha padrão da nova plataforma for mais limitada.

O manual de migração do Bitly cobre as mecânicas técnicas da importação de ligações e a transição DNS com mais detalhe.

O que verificar antes de confiar numa afirmação GDPR#

Qualquer encurtador pode colocar "conformidade com GDPR" numa página de preços. A afirmação não está regulamentada e não tem peso legal por si só. Os artefactos que têm peso são:

• Um DPA que mapeia para o Artigo 28(3) sub-parágrafo por sub-parágrafo.
• Uma lista de sub-processadores que nomeia fornecedores, regiões e as categorias de dados partilhados.
• Um aviso de privacidade acessível aos destinatários de ligações que descreve a cadeia de tratamento - isso satisfaz o Artigo 13.
• Tratamento de IP documentado que confirma truncagem ou hash antes da persistência.
• Um SLA de apagamento do Artigo 17 com um mecanismo técnico nomeado.
• Atestação independente (ISO 27001 é o mínimo; SOC 2 Tipo II acrescenta garantia para aquisição nos EUA/internacional).

Se um fornecedor não puder fornecer todos estes por escrito dentro de um dia útil, a afirmação "conformidade com GDPR" é cópia de marketing em vez de uma postura de conformidade documentada.

---

Para a análise legal ao nível do artigo por detrás desta lista de verificação, o cornerstone GDPR para encurtadores de URL cobre os Artigos 3, 6, 28, 30, 32 e 35 em profundidade com citações de autoridades de supervisão. Artefactos voltados para aquisição: a política de privacidade do Elido, os termos de serviço e os preços - o DPA está incluído no contrato padrão em cada escalão pago.

Relacionados no blog#

• Residência de dados da UE para ferramentas de marketing: o que o seu DPO realmente pergunta
• Schrems II e pixels de rastreamento: onde o DPF o deixa em 2026
• Atribuição de cliques após o Safari ITP: o que ainda funciona em 2026
• SCIM e SSO para ferramentas de marketing: o que o IT empresarial realmente pergunta