A resposta mais comum que ouço dos DPOs quando o assunto dos pixels não autorizados surge é: "temos uma CMP, por isso estamos cobertos." Na prática, uma plataforma de gestão de consentimento apenas cobre as ferramentas que foram declaradas à mesma. Quando implementamos o cside num operador licenciado, encontramos rotineiramente disparos de pixels que a CMP não tem qualquer registo, frequentemente porque chegaram através de um script de afiliado ou de uma configuração de GTM container que é anterior à pilha de conformidade actual. O DPO normalmente descobre que isto está a acontecer quando lhe mostramos um rastreamento de sessão em tempo real, não antes.
Os operadores de jogo licenciados não podem anunciar no Facebook, TikTok, Instagram ou LinkedIn. As políticas de publicidade de todas as quatro plataformas proíbem promoções de jogo sem aprovação explícita da plataforma, e essa aprovação raramente é concedida. O que a maioria dos operadores não modelou completamente é o que acontece quando um pixel de uma dessas plataformas aparece no seu site sem o seu conhecimento. Acontece com mais frequência do que as equipas de conformidade percebem: no Q1 2025, o cside detectou mais de 300.000 sinais de ataque em sites de jogo e e-commerce monitorizados (cada um representando um comportamento anómalo distinto observado numa sessão real de jogador), sendo os disparos de pixels não autorizados uma das descobertas mais comuns. Quando isso acontece, o operador enfrenta dois problemas simultâneos que se compõem de formas difíceis de resolver rapidamente.
Como os Pixels Não Autorizados Chegam a Sites de Jogo Sem Conhecimento do Operador
Resposta Rápida: Os pixels de rastreamento não autorizados chegam às plataformas de jogo através de quatro vectores principais: scripts de afiliados comprometidos que injectam código sem o conhecimento do operador, shadow Google Tag Manager containers configurados por equipas de marketing sem revisão de segurança, plataformas de gestão de consentimento mal configuradas que carregam tags fora do seu âmbito pretendido, e compromissos da cadeia de fornecimento que afectam bibliotecas JavaScript a montante utilizadas em milhares de sites simultaneamente.
O pressuposto que a maioria dos operadores faz é que os pixels são coisas que instalam deliberadamente. Na prática, o cenário mais comum é que um pixel chega através de uma rota indirecta e passa despercebido porque o operador não tem visibilidade em runtime sobre o que está a executar nos browsers dos jogadores.
Os quatro vectores principais são:
- Scripts de afiliados: os parceiros afiliados recebem código de rastreamento que os operadores carregam nos seus sites. Quando o script de um afiliado é comprometido ou um afiliado injecta deliberadamente pixels adicionais, a plataforma do operador transporta o pixel sem o ter instalado
- Shadow GTM containers: as equipas de marketing frequentemente criam GTM containers adicionais ou adicionam tags a existentes sem passar por uma revisão de segurança. Um pixel instalado por um contratante há seis meses pode ainda estar a disparar em produção
- Má configuração de gestão de consentimento: as CMPs gerem o consentimento para ferramentas que são declaradas no fluxo de consentimento. Tags que são adicionadas a um GTM container após a CMP ter sido configurada, ou carregadas completamente fora da camada de consentimento, não são cobertas pelo mecanismo de consentimento
- Compromisso da cadeia de fornecimento: o ataque à cadeia de fornecimento do Polyfill.js em Junho de 2024 afectou mais de 100.000 sites simultaneamente através de uma única aquisição de biblioteca. Um ataque semelhante visando uma biblioteca de analytics ou afiliados amplamente utilizada poderia injectar pixels em todo um sector sem que qualquer operador tomasse uma acção deliberada
O factor comum em todos os quatro vectores é que o pixel dispara sem que o operador saiba. Os dados dos jogadores são enviados para o Facebook, TikTok ou LinkedIn. O operador é responsável.
A Responsabilidade ao Abrigo do GDPR: O Que Significam os Artigos 5, 28 e 33 para os Disparos de Pixels
Resposta Rápida: Ao abrigo do Artigo 5 do GDPR, os dados dos jogadores devem ser processados de forma lícita, leal e com uma base jurídica válida. Um pixel não autorizado a transmitir dados de jogadores para uma plataforma de redes sociais não tem base jurídica. Ao abrigo do Artigo 28, o operador é o responsável pelo tratamento de dados responsável por esse processamento. Ao abrigo do Artigo 33, se o disparo do pixel constituir uma violação de dados, o operador tem 72 horas para notificar a autoridade supervisora, independentemente de ter instalado o pixel.
O GDPR não oferece uma defesa de "não sabia" para os responsáveis pelo tratamento de dados. O regulamento estabelece a responsabilização como princípio fundamental: os operadores são responsáveis por demonstrar que todo o processamento de dados pessoais nas suas plataformas é lícito, documentado e controlado.
Aplicando isto a um cenário de pixel não autorizado:
O Artigo 5 exige que os dados pessoais sejam processados de forma lícita e para fins especificados, explícitos e legítimos. Um pixel a transmitir dados de jogadores para o Facebook serve os fins de optimização de publicidade do Facebook, não os interesses legítimos do operador como operador de jogo licenciado. Não existe base jurídica plausível para essa transferência. O consentimento não pode ser invocado porque o pixel não está no fluxo de consentimento. O interesse legítimo não pode ser invocado porque o operador não sabia que o pixel estava lá e não pode ter avaliado a sua proporcionalidade.
O Artigo 28 torna o operador um responsável pelo tratamento de dados responsável por garantir que qualquer terceiro que processe dados na sua plataforma tem um Acordo de Processamento de Dados documentado em vigor. Não existe DPA cobrindo um pixel não autorizado. A violação estrutural existe independentemente do dano causado.
O Artigo 33 requer notificação à autoridade supervisora no prazo de 72 horas após o operador tomar conhecimento de uma violação de dados pessoais. Se um pixel não autorizado constitui uma violação depende de se resultou na transmissão de dados pessoais sem autorização, e a resposta na maioria dos casos é sim. A penalização de £20M do ICO do Reino Unido contra a British Airways fornece o precedente mais claro: os scripts de terceiros que recolhiam dados de clientes do website de uma empresa foram considerados responsabilidade da empresa, e a falha em detectar e prevenir a recolha foi ela própria a falha regulatória.
A Responsabilidade de Política de Publicidade: Por Que as Penalizações das Plataformas Agravam o Problema
Resposta Rápida: O Facebook, TikTok, Instagram e LinkedIn proíbem a publicidade de jogo ao abrigo das suas políticas de plataforma. Quando um pixel de qualquer uma destas plataformas dispara num site de jogo, cria um registo de actividade que liga o domínio de jogo à conta da plataforma. Mesmo que o operador nunca tenha anunciado deliberadamente nessas plataformas, a actividade do pixel pode ser detectada e utilizada como fundamento para suspender as contas de anúncios do operador, colocar o seu domínio em lista negra, ou desencadear uma revisão de política.
Esta é a segunda dimensão, frequentemente ignorada, do problema de responsabilidade dupla. A fiscalização do GDPR é o risco mais amplamente discutido. O risco de política de publicidade é mais imediato e pode ter consequências comerciais directas.
A mecânica do risco é a seguinte. Quando um pixel dispara num site de jogo, envia um evento para a conta de publicidade associada. Se essa conta pertence ao operador de jogo, mesmo que nunca tenha sido utilizada para publicidade de jogo, a plataforma pode detectar a colocação do pixel num domínio de jogo. Isto pode resultar em:
- Suspensão da conta de publicidade associada ao pixel
- Inclusão em lista negra ao nível do domínio que impede a utilização futura da plataforma pelo operador ou pelos seus afiliados
- Revisão de política que afecta outros produtos ou contas ligadas à mesma entidade empresarial
- Utilização da actividade do pixel como evidência em procedimentos de fiscalização de política da plataforma
Se o pixel não pertence ao operador, o perfil de risco muda: o pixel pertence a um afiliado, a um fornecedor comprometido, ou a um terceiro desconhecido. Neste cenário, a responsabilidade do GDPR do operador é a mesma (são responsáveis por todo o processamento no seu domínio) mas o risco de política de publicidade pode ser dirigido a outro lugar. No entanto, o domínio do operador está agora associado a actividade de pixel de uma conta que não conseguem controlar, o que cria as suas próprias complicações.
O problema composto é que ambas as responsabilidades surgem simultaneamente. Enquanto a equipa de conformidade está a gerir a notificação de violação do GDPR e o envolvimento com o ICO, a equipa de marketing está a descobrir que as contas de anúncios estão suspensas ou os domínios estão sinalizados. Resolver uma não resolve a outra, e os processos para o fazer envolvem diferentes reguladores, diferentes calendários, e diferentes partes interessadas internas.
Por Que Razão as Plataformas de Gestão de Consentimento Não Detectam Isto
Resposta Rápida: As plataformas de gestão de consentimento gerem o consentimento para as ferramentas que são declaradas na camada de consentimento. Não detectam nem bloqueiam scripts que são injectados fora do fluxo de consentimento, adicionados a sistemas de gestão de tags após a configuração da CMP, ou carregados através de scripts de fornecedores comprometidos. Um pixel que chega através de um compromisso da cadeia de fornecimento ou de uma tag GTM não declarada vai disparar independentemente de o jogador ter dado consentimento para qualquer coisa.
Este é um equívoco crítico na forma como muitas equipas de conformidade pensam sobre as suas obrigações de processamento de dados. Uma CMP é uma interface de consentimento, não um inventário de scripts ou um monitor em runtime. Só consegue gerir o que foi declarado à mesma.
Uma CMP não vai detectar:
- Pixels injectados por um script de afiliado comprometido que carrega independentemente da camada de consentimento
- Tags adicionadas a um GTM container por um membro da equipa que não actualizou a configuração da CMP
- Scripts que se activam condicionalmente, por exemplo, para jogadores em certas regiões geográficas, em certas horas do dia, ou após acções específicas
- Compromissos da cadeia de fornecimento em bibliotecas a montante que injectam código de pixel em runtime sem modificar o URL ou hash de ficheiro do script anfitrião
O compromisso do Polyfill.js é instrutivo aqui. O ataque modificou o comportamento de uma biblioteca JavaScript que já estava carregada, permitida e, em alguns casos, declarada na camada de consentimento. Nenhuma CMP o teria sinalizado porque a origem e a função declarada do script não tinham mudado. O comportamento malicioso foi adicionado em runtime pela versão comprometida da biblioteca.
Para operadores de jogo, onde qualquer processamento de dados não autorizado cria risco tanto de GDPR como de política publicitária, uma CMP por si só não é suficiente. A questão não é apenas "o jogador deu consentimento para esta ferramenta?" mas "esta ferramenta está a fazer apenas o que foi declarado que faria, e é a única ferramenta a correr nesta sessão?"
Como o cside Detecta Cada Disparo de Pixel e o Mapeia para o Seu Destino de Dados
Resposta Rápida: O cside instrumenta 100% das sessões reais de jogadores no browser e observa cada pedido de rede feito por cada script a executar na página. Detecta disparos de pixels, incluindo os do Facebook, TikTok, LinkedIn e outras plataformas, independentemente de aparecerem no fluxo de consentimento, no sistema de gestão de tags, ou no inventário de scripts do operador. Cada disparo de pixel é mapeado para o seu destino, com timestamp, e registado para evidência de conformidade.
O desafio com os pixels não autorizados é que foram concebidos para não serem notados. São algumas linhas de JavaScript que fazem um pedido de rede de saída. Sem monitorização em runtime, são invisíveis.
O cside aborda isto instrumentando a camada de execução:
- Cada script a carregar em páginas voltadas para jogadores é identificado em sessões reais, incluindo os carregados dinamicamente, condicionalmente, ou através de chamadas de script aninhadas
- Cada pedido de rede de saída é capturado e mapeado para o seu destino, incluindo endpoints de pixel para o Facebook (facebook.com/tr), TikTok (analytics.tiktok.com), LinkedIn (px.ads.linkedin.com), e outros
- Os disparos de pixels são cruzados com a configuração de consentimento declarada do operador para identificar disparos que ocorrem fora do fluxo de consentimento ou de fontes não constantes no inventário de scripts
- Os alertas são desencadeados para cada disparo de pixel não declarado com contexto de sessão, timestamp, e mapeamento de destino
- Os perfis de permissão por fornecedor permitem aos operadores bloquear o acesso da Payment Request API e escrita de cookies para fornecedores de pixels e analytics ao nível do browser; esta imposição mantém-se mesmo que o código do fornecedor seja posteriormente comprometido, pelo que um script de analytics sequestrado não consegue aceder a campos de pagamento ou definir cookies de rastreamento independentemente do que o seu código tenta fazer
Isto fornece aos DPOs e equipas de conformidade as evidências de que precisam para demonstrar que a monitorização está em vigor, para investigar incidentes quando ocorrem, e para produzir documentação para inquéritos do ICO ou notificações de violação a autoridades supervisoras.
Ao contrário das ferramentas de camada de rede, que monitorizam tráfego no perímetro mas não conseguem ver o contexto em que um pixel disparou, ou das CMPs, que gerem ferramentas declaradas mas não conseguem detectar as não declaradas, o cside opera onde os dados são realmente processados: dentro do browser, na sessão do jogador.
Numa implementação num operador iGaming licenciado na UE (detalhes do operador anonimizados), o cside detectou um pixel do TikTok a disparar nas páginas de registo e confirmação de depósito do operador. O pixel tinha sido injectado por um script de parceiro afiliado que era carregado condicionalmente para jogadores referidos através de uma fonte de tráfego específica. A CMP do operador não tinha qualquer registo do mesmo. O pixel estava a disparar por um período desconhecido. Uma vez identificado, o operador conseguiu isolar o script de afiliado, calcular o âmbito dos dados transmitidos, e produzir uma avaliação de notificação preliminar para a sua autoridade supervisora no prazo de 24 horas. Esse prazo de resposta apenas foi alcançável porque os logs de sessão do cside forneciam um registo preciso de quando o pixel apareceu pela primeira vez e quantas sessões afectou.
Para operadores que gerem o risco de responsabilidade dupla da fiscalização do GDPR e das penalizações de plataformas publicitárias, a detecção de pixels em tempo real é o mecanismo que reduz tanto a probabilidade de exposição não detectada como o tempo de consciencialização quando um incidente ocorre.
| Método de detecção | Detecta pixels declarados | Detecta pixels não declarados | Trilha de evidência para o ICO |
|---|---|---|---|
| Plataforma de gestão de consentimento | Sim | Não | Parcial: apenas registos de consentimento |
| Auditoria de gestão de tags | Sim (no momento da auditoria) | Não | Não: apenas instantâneo num momento específico |
| Monitorização de camada de rede | Parcial | Parcial: sem contexto | Não: sem ligação a sessão |
| Monitorização em runtime do cside | Sim | Sim | Sim: logs de sessão com timestamp |
O Que Fazer a Seguir
Se a sua organização detém uma licença de jogo e actualmente não tem monitorização em runtime de actividade de pixels em sessões de jogadores, o ponto de partida é compreender o que está realmente a disparar. A solução Privacy Watch do cside fornece um inventário completo de pixels a partir de sessões reais de jogadores, cruzado com a sua configuração de consentimento, com alertas para cada destino não declarado. Para os DPOs que gerem obrigações de notificação de violação ao abrigo do Artigo 33 do GDPR, os logs de sessão que o cside gera são a base para uma submissão credível à autoridade supervisora. A capacidade de segurança do lado do cliente aborda os vectores de compromisso a montante que as CMPs e as ferramentas de rede não conseguem alcançar.
