Que é realmente unha DSAR

Unha solicitude de acceso da persoa interesada (DSAR) é o momento en que un usuario exerce os dereitos que o RGPD lle outorga sobre os seus datos persoais. Para un editor móbil, esa “persoa interesada” é un dos teus xogadores ou usuarios, e a solicitude pode chegar por correo electrónico, ticket de soporte, recensión na tenda de aplicacións ou formulario dentro da app. O desencadeante é simple: alguén quere saber que información tes sobre el — ou quere que actúes sobre ela.

É fundamental entender que unha DSAR non precisa mencionar o RGPD, usar a palabra “DSAR” nin seguir modelo ningún. Unha mensaxe dunha soa liña como “envíame os meus datos” ou “elimina a miña conta” pon en marcha o reloxo coa mesma firmeza ca unha carta legal formal. Tratar como válidas só as solicitudes con aparencia formal é unha maneira rápida de incumprir un prazo.

Os dereitos detrás da solicitude

As DSAR agrupan varios dereitos distintos, e unha mesma mensaxe pode invocar máis dun. Saber cal é cal determina o que realmente tes que facer.

• Acceso — o usuario pode pedir unha copia dos seus datos persoais máis o contexto: que recompilas, por que, con quen os compartes e canto tempo os conservas.
• Supresión (“dereito ao esquecemento”) — eliminación dos seus datos, incluídas as copias entregadas a socios de publicidade e analítica, salvo excepcións legais moi concretas.
• Portabilidade — os datos que che facilitou, devoltos nun formato estruturado e lexible por máquina como JSON ou CSV, para que poidan trasladarse a outro lugar.
• Rectificación — corrección de datos inexactos ou incompletos, por exemplo un correo electrónico ou unha rexión erróneos.

Dereitos relacionados — a oposición ao tratamento e a limitación — adoitan acompañar a estes, especialmente arredor da personalización publicitaria, onde un usuario pode retirar o consentimento en lugar de eliminar a súa conta por completo.

Os prazos son estritos

Debes responder sen dilación indebida e no prazo dun mes natural desde a recepción da solicitude. O reloxo comeza o día en que chega a solicitude, non o día en que alguén do teu equipo se dá conta. Podes amplialo dous meses máis en solicitudes xenuinamente complexas, pero só se llo comunicas ao usuario dentro dese primeiro mes e explicas o motivo.

As respostas son normalmente gratuítas. Só podes cobrar unha tarifa razoable ou negarte cando unha solicitude sexa manifestamente infundada ou excesiva, e a carga de demostralo recae sobre ti. Para a maioría dos editores, a suposición segura é: gratis e dentro dos trinta días. Incumprir o prazo é exactamente o tipo de fallo que os reguladores sinalan ao avaliar sancións.

Crear un fluxo de traballo escalable

Os editores que xestionan as DSAR con calma convertéronas nun proceso repetible en lugar dun simulacro de incendio. Un fluxo de traballo viable ten este aspecto:

• Recepción. Publica unha única canle anunciada — un formulario dentro da app ou un enderezo dedicado privacy@ — e dirixe todo a través dela para que nada se perda nas colas de soporte.
• Verifica a identidade. Confirma que quen solicita é o titular da conta, pero pide só o necesario. Esixir o escaneo dun pasaporte para buscar un ID dentro do xogo é en si mesmo un problema de cumprimento.
• Rexistra e marca a data. Anota a data de chegada de inmediato; é o teu punto de referencia para o prazo.
• Localiza os datos. Mantén un mapa de datos de cada almacén — o teu backend, rexistros de fallos, analítica, SDK publicitarios, CRM — que toque datos de usuario, indexado por un identificador estable.
• Atende e responde. Exporta, elimina ou corrixe segundo o solicitado, propaga as supresións aos encargados do tratamento e responde nunha linguaxe clara.
• Pecha o ciclo. Arquiva a solicitude e a túa resposta como proba de que actuaches a tempo.

Erros habituais

A maioría dos fallos son operativos, non legais. Vixía estes:

• Almacéns de datos esquecidos. Os SDK de publicidade e atribución, os provedores de notificacións push e os informadores de fallos almacenan datos de usuario. Unha supresión que os omita está incompleta.
• Recompilación excesiva durante a verificación, que converte unha solicitude de privacidade nun risco de privacidade.
• Tratar as mensaxes informais como non solicitudes e deixar que o mes transcorra.
• Falta de proba do consentimento. Se un usuario discute que algunha vez tiveches unha base legal para tratar os seus datos con fins publicitarios, precisas amosar a que consentiu e cando.

Como un CMP fai manexables as DSAR

Aquí é onde a túa capa de consentimento demostra o seu valor. Unha DSAR é moito máis fácil de responder cando podes amosar ao instante a que consentiu un usuario, cando e baixo que marco. FlexyConsent — un CMP certificado por Google compatible con IAB TCF 2.3 e Google Consent Mode v2 — almacena un rexistro de consentimento e un rastro de auditoría con marca de tempo para cada usuario. Cando chega unha solicitude de acceso, ese rexistro convértese nunha parte xa preparada da túa resposta: as finalidades aceptadas, os provedores implicados e a versión do aviso amosado. Cando chega unha solicitude de supresión ou oposición, ese mesmo rexistro demostra que detiveches os sinais de publicidade personalizada no momento axeitado. Combinar ese historial de consentimento co teu mapa de datos converte unha DSAR dun caos nunha simple consulta.

Este artigo é información xeral para editores e non constitúe asesoramento legal; consulta un profesional cualificado para a túa situación concreta.

Conclusións clave

• Calquera solicitude — por informal que sexa — pode ser unha DSAR, e o prazo dun mes, normalmente gratuíto, comeza o día en que chega.
• Mapea cada almacén de datos, incluídos os SDK de publicidade e analítica, para que o acceso e a supresión sexan realmente completos.
• Verifica a identidade de forma proporcionada e rexistra cada solicitude para probar que respondiches a tempo.
• Os rexistros de consentimento e o rastro de auditoría de FlexyConsent danche probas instantáneas e defendibles para atender solicitudes de acceso, supresión e oposición.