O que é realmente um DSAR

Um pedido de acesso do titular dos dados (DSAR) é o momento em que um utilizador exerce os direitos que o RGPD lhe concede sobre os seus dados pessoais. Para um publisher móvel, esse “titular dos dados” é um dos seus jogadores ou utilizadores, e o pedido pode chegar por e-mail, ticket de suporte, avaliação na loja de aplicações ou formulário dentro da app. O gatilho é simples: alguém quer saber o que tem sobre ele — ou quer que atue sobre isso.

É fundamental perceber que um DSAR não precisa de mencionar o RGPD, usar a palavra “DSAR” nem seguir qualquer modelo. Uma mensagem de uma só linha como “envie-me os meus dados” ou “elimine a minha conta” aciona o relógio com a mesma firmeza que uma carta jurídica formal. Tratar como válidos apenas os pedidos com aparência formal é uma forma rápida de falhar um prazo.

Os direitos por trás do pedido

Os DSAR agrupam vários direitos distintos, e a mesma mensagem pode invocar mais do que um. Saber qual é qual determina o que tem efetivamente de fazer.

• Acesso — o utilizador pode pedir uma cópia dos seus dados pessoais mais o contexto: o que recolhe, porquê, com quem os partilha e durante quanto tempo os conserva.
• Apagamento (“direito a ser esquecido”) — eliminação dos seus dados, incluindo as cópias entregues a parceiros de publicidade e de análise, sujeita a exceções legais muito restritas.
• Portabilidade — os dados que ele lhe forneceu, devolvidos num formato estruturado e legível por máquina como JSON ou CSV, para que possam ser transferidos para outro lugar.
• Retificação — correção de dados inexatos ou incompletos, por exemplo um e-mail ou uma região errados.

Direitos relacionados — a oposição ao tratamento e a limitação — costumam acompanhar estes, especialmente em torno da personalização publicitária, onde um utilizador pode retirar o consentimento em vez de eliminar totalmente a sua conta.

Os prazos são rigorosos

Tem de responder sem demora indevida e no prazo de um mês de calendário a contar da receção do pedido. O relógio começa no dia em que o pedido chega, não no dia em que alguém da sua equipa repara nele. Pode prolongar por mais dois meses em pedidos genuinamente complexos, mas apenas se informar o utilizador dentro desse primeiro mês e explicar porquê.

As respostas são normalmente gratuitas. Só pode cobrar uma taxa razoável ou recusar quando um pedido for manifestamente infundado ou excessivo, e o ónus de o provar recai sobre si. Para a maioria dos publishers, o pressuposto seguro é: gratuito e dentro de trinta dias. Falhar o prazo é exatamente o tipo de lapso que os reguladores apontam ao avaliar coimas.

Criar um fluxo de trabalho escalável

Os publishers que lidam com os DSAR com calma transformaram-nos num processo repetível em vez de um exercício de combate a incêndios. Um fluxo de trabalho viável tem este aspeto:

• Receção. Publique um único canal divulgado — um formulário dentro da app ou um endereço dedicado privacy@ — e encaminhe tudo por ele para que nada se perca nas filas de suporte.
• Verifique a identidade. Confirme que quem pede é o titular da conta, mas peça apenas o necessário. Exigir a digitalização de um passaporte para procurar um ID dentro do jogo é, em si, um problema de conformidade.
• Registe e marque a data. Anote a data de chegada de imediato; é o seu ponto de referência para o prazo.
• Localize os dados. Mantenha um mapa de dados de cada repositório — o seu backend, registos de falhas, análise, SDK de publicidade, CRM — que toque dados de utilizador, indexado por um identificador estável.
• Satisfaça e responda. Exporte, elimine ou corrija conforme pedido, propague os apagamentos aos subcontratantes e responda em linguagem clara.
• Feche o ciclo. Arquive o pedido e a sua resposta como prova de que atuou a tempo.

Erros comuns

A maioria das falhas é operacional, não jurídica. Esteja atento a estas:

• Repositórios de dados esquecidos. Os SDK de publicidade e de atribuição, os fornecedores de notificações push e os relatores de falhas armazenam todos dados de utilizador. Um apagamento que os ignore está incompleto.
• Recolha excessiva durante a verificação, transformando um pedido de privacidade num risco de privacidade.
• Tratar mensagens informais como não-pedidos e deixar o mês expirar.
• Falta de prova de consentimento. Se um utilizador contestar que alguma vez teve um fundamento legal para tratar os seus dados para publicidade, precisa de mostrar a que ele consentiu e quando.

Como um CMP torna os DSAR geríveis

É aqui que a sua camada de consentimento prova o seu valor. Um DSAR é muito mais fácil de responder quando consegue mostrar instantaneamente a que um utilizador consentiu, quando e sob que enquadramento. O FlexyConsent — um CMP certificado pela Google compatível com IAB TCF 2.3 e Google Consent Mode v2 — armazena um registo de consentimento e um rasto de auditoria com data e hora para cada utilizador. Quando chega um pedido de acesso, esse registo torna-se uma parte já pronta da sua resposta: as finalidades aceites, os fornecedores envolvidos e a versão do aviso apresentado. Quando chega um pedido de apagamento ou de oposição, esse mesmo registo prova que parou os sinais de publicidade personalizada no momento certo. Juntar esse histórico de consentimento ao seu mapa de dados transforma um DSAR de uma correria numa simples consulta.

Este artigo é informação geral para publishers e não constitui aconselhamento jurídico; consulte um profissional qualificado para a sua situação específica.

Principais conclusões

• Qualquer pedido — por mais informal que seja — pode ser um DSAR, e o prazo de um mês, normalmente gratuito, começa no dia em que chega.
• Mapeie cada repositório de dados, incluindo os SDK de publicidade e análise, para que o acesso e o apagamento sejam realmente completos.
• Verifique a identidade de forma proporcional e registe cada pedido para provar que respondeu a tempo.
• Os registos de consentimento e o rasto de auditoria do FlexyConsent dão-lhe provas instantâneas e defensáveis para satisfazer pedidos de acesso, apagamento e oposição.