RGPD en apps móviles: datos, base legal y derechos

Haz esta prueba antes de seguir leyendo. Abre tu app, busca la opción de borrar la cuenta y cronometra cuánto tardas en encontrarla, si es que existe. Después, lo que casi nadie comprueba: pídela y mira la base de datos. Si el registro sigue ahí con el estado cambiado, no has borrado a nadie: lo has desactivado. Pocas apps pasan esa prueba, y eso explica por qué el RGPD en aplicaciones móviles se lleva mal. No se incumple por mala fe, sino porque nadie ha recorrido el camino completo que hace un dato desde que entra hasta que debería salir.

En Docastix metemos esto en el desarrollo de apps móviles desde el diseño, y no por gusto legalista: el orden decide el coste. Fijar qué datos recoges y cuánto los guardas antes de escribir el esquema de base de datos son dos reuniones; hacerlo con cien mil registros y seis SDK dentro es un proyecto con presupuesto propio. La parte técnica —cifrado, notificación de incidentes, controles de las tiendas— está en el hub sobre seguridad en el desarrollo de apps móviles. Aquí va la otra mitad: el ciclo de vida del dato, contado para quien responde de él.

Respuesta rápida: ¿qué te exige el RGPD en aplicaciones móviles?

El RGPD no se cumple con una política de privacidad: te exige contestar seis preguntas sobre cada dato que toca tu app, enseñar el papel que lo demuestra y volcarlo en la política. La política es la salida visible de ese trabajo, y lo habitual es tener contestadas las fáciles y en blanco las que cuestan.

Si necesitas quedarte con tres ideas: la exención del registro de actividades para empresas pequeñas casi nunca alcanza a quien tiene una app; responder a un derecho tiene reloj, y la prórroga hay que comunicarla, no tomársela; y del dato que recoge un SDK que instalaste sin leer responde quien firma, no quien escribió el SDK.

Lo que recoges de verdad, incluido lo que recogen otros por ti

La primera pregunta parece la fácil y es donde se rompe el resto. Casi todo el mundo contesta con lo que el usuario teclea, y eso es la punta: una app recoge además identificadores de dispositivo, dirección IP, modelo, idioma, patrón de uso, a veces ubicación y, si hay compras, historial de transacciones. Buena parte de eso no lo ha escrito nadie de tu equipo. El inventario serio se hace en tres pasadas, ninguna de más de una tarde:

• La lista de dependencias. Todos los SDK de cada plataforma, incluidos los que entraron arrastrados por otro. Los sospechosos habituales: informe de fallos, analítica, publicidad, mapas, chat de soporte, push y pasarela de pago.
• Lo que declara cada uno. Qué recoge por defecto, qué solo si lo activas y qué identificadores usa. Lectura aburrida y llena de sorpresas: analíticas que cogen el identificador de publicidad salvo que lo desactives, informes de fallos que se llevan registros con datos.
• El tráfico real de una sesión. Con un proxy delante del móvil, recorre alta, acceso, acción principal, pago y baja, y mira a qué dominios habla.

La tercera no admite discusión: la documentación describe intenciones, el tráfico describe hechos. Y el hecho incómodo: el SDK que firmaste sin leer cuenta igual. Quien decide para qué se tratan esos datos eres tú, aunque los capture otro.

Sin inventario no puedes asignar bases legales ni plazos, ni saber qué sale del país, ni contestar a quien pide su copia. Por eso tiene sitio fijo en el proceso de desarrollo.

Una base legal por tratamiento, no una para toda la app

El segundo error estructural es tratar la app como un bloque: un «acepto» en la primera pantalla y a correr. La unidad no es la app, es el tratamiento, y el artículo 6 obliga a que cada uno tenga su base. Una app corriente tiene varios, con bases distintas, y la lista sale sola del inventario de la sección anterior.

• Ejecución del contrato. Lo que la app hace y por lo que el usuario se dio de alta: crear la cuenta, guardar su progreso, cobrar la suscripción. No hace falta consentimiento y pedirlo confunde: si alguien lo retirara, ¿qué le queda?
• Consentimiento. Analítica, medición de campañas, publicidad, personalización: todo lo que no es imprescindible para prestar el servicio. Previo, específico por finalidad, informado y tan fácil de retirar como de dar. Previo significa exactamente eso, y aquí muerde una norma que no es el RGPD: el artículo 22.2 de la LSSI, que la AEPD aplica igual a webs y a apps, exige el consentimiento antes de leer o escribir en el dispositivo, salvo lo estrictamente necesario para prestar el servicio que la persona ha pedido —la sesión de quien acaba de entrar entra ahí; el identificador de publicidad, no—. En la práctica: el SDK no lee el identificador ni manda el primer evento hasta que la persona dice que sí. El de las notificaciones push tiene reglas propias, y lo tratamos en el artículo sobre notificaciones y su encaje legal.
• Interés legítimo. Seguridad de la cuenta, prevención del fraude, detección de abuso. Es válida y es la más maltratada: no es un comodín. Exige una ponderación escrita —qué interés persigues, por qué no lo consigues con menos datos y por qué el derecho de la persona no prevalece— que tienes que poder enseñar. «Por interés legítimo» en una casilla no vale nada.
• Obligación legal. Conservar facturación o atender requerimientos: afecta a poco, pero es la razón por la que borrar «todo» a petición no siempre es posible.

De ahí salen dos consecuencias. La primera: un único «acepto» al instalar no sirve para casi nada. Mezcla lo que no necesita consentimiento con lo que sí, impide retirar una finalidad sin las demás y no demuestra qué aceptó esa persona ni cuándo. La segunda es contraintuitiva: meterlo todo en consentimiento es peor, no más prudente. Si tratas los datos de cuenta con consentimiento, le das al usuario derecho a retirarlo sin perder el servicio y te creas una obligación que no tenías. Es la base más cara de mantener.

Cuánto tiempo lo guardas, y por qué «indefinidamente» no es un plazo

Es la etapa que nadie escribe. Los datos se conservan solo lo necesario para la finalidad que los justificó, y «lo necesario» hay que traducirlo a un número por categoría: la norma no da un plazo universal, da la obligación de fijarlo.

Una tabla decente separa al menos datos de cuenta, contenido del usuario, registros técnicos, analítica y documentación económica. El ejercicio útil no es copiar la de otro: es preguntarse, categoría por categoría, qué dejas de poder hacer si borras eso a los seis meses. Si la respuesta es «nada», ya tienes el plazo.

Al vencer hay dos salidas honestas: borrar o anonimizar, palabra que se usa muy a la ligera. Quitar el nombre y dejar el identificador de dispositivo, el hash de un correo —que no hace falta invertir: sirve de clave estable para volver a cruzar a esa persona entre conjuntos de datos— o un registro que solo puede ser de una persona no es anonimizar: es seudonimizar, y eso sigue siendo dato personal con todas sus obligaciones.

Y el detalle incómodo: tú no guardas los datos en un sitio, los guardas en cinco. La base de datos principal, las copias de seguridad, los registros del servidor, el almacén analítico donde volcaste eventos con identificadores y el buzón de soporte donde alguien pegó su historial. Borrar la fila principal y dejar los otros cuatro intactos no resiste una pregunta. Las copias tienen un matiz razonable —nadie espera que abras una cifrada para editar una fila—, pero sí que roten y que, al restaurar una, el borrado vuelva a aplicarse.

El registro de actividades: por qué probablemente sí te toca

Es el malentendido más extendido entre pymes con app. El artículo 30.5 del RGPD dice que las obligaciones de llevar un registro de actividades de tratamiento no se aplican a las empresas de menos de 250 personas. Hasta ahí llega todo el mundo, respira y cierra la página. Pero la frase no termina ahí: la exención decae si se da cualquiera de estas tres circunstancias —que el tratamiento pueda entrañar un riesgo para los derechos y libertades de los interesados, que no sea ocasional, o que incluya categorías especiales del artículo 9.1 o datos relativos a condenas e infracciones penales del artículo 10.

Fíjate en la segunda. Una app trata datos personales de forma continua: cada vez que alguien la abre, se registra o genera un evento. Eso no es ocasional bajo ninguna lectura razonable de la palabra. La exención de las 250 personas casi nunca alcanza a quien tiene una app en producción, por pequeña que sea la empresa. Un equipo de seis con una app de veinte mil descargas lleva registro. Con un matiz que juega a tu favor: el Grupo del 29 aclaró que en ese caso solo hay que registrar los tratamientos que disparan la excepción, no todos —lo puramente ocasional y sin riesgo puede quedar fuera—. En una app, eso deja fuera poco.

Obligatorio no significa caro. El registro es un documento —una hoja de cálculo sirve— con una fila por tratamiento: quién responde y sus datos de contacto, finalidad, categorías de interesados y de datos, base legal —que no la pide el artículo 30, pero la lleva la plantilla de la AEPD y es la que te hace pensar—, destinatarios, transferencias internacionales, plazo de conservación y una descripción general de las medidas de seguridad. Si ya hiciste el inventario y asignaste bases y plazos, se escribe en una tarde. Y es el primer papel que van a pedirte.

Los encargados que tienes sin saberlo

Todo proveedor que trata datos personales por cuenta tuya es un encargado del tratamiento, y el artículo 28 exige que esa relación esté regulada por contrato. Sin él, no hay cobertura.

Ese contrato tiene que decir: objeto, duración y finalidad; tipo de datos e interesados; que el encargado solo trata siguiendo tus instrucciones; seguridad y confidencialidad; régimen de subencargados; asistencia ante derechos e incidentes; que a tu elección devuelva o borre los datos al terminar, porque esa elección es tuya y no suya; y que te dé toda la información necesaria para demostrar que cumple, además de permitir auditorías e inspecciones. Esta última es la que más se negocia y la primera que desaparece de un anexo mal copiado. Si el tuyo no contesta a eso, no es un contrato de encargado aunque se llame así.

Aceptar unas condiciones en línea es firmar. El anexo de protección de datos que aceptaste con una casilla al abrir la cuenta del proveedor es tu contrato de encargado. Es buena noticia —existe— y mala: no lo has leído ni lo tienes archivado, y cuando te pregunten por él tendrás que enseñarlo con su versión y su fecha.

Y los subencargados cambian sin que te enteres. Tu proveedor de push se apoya en una nube que a su vez usa otros servicios. Esa cadena está en el anexo que aceptaste, con una cláusula que le permite cambiar de subencargado avisando en una página que no vas a mirar. Te has comprometido con la cadena entera y respondes ante tu usuario si algo pasa tres eslabones más abajo. Ese riesgo no se elimina, se gestiona, y tienes más palanca de la que parece: el artículo 28.2 exige que te informen de las altas y bajas dándote la oportunidad de oponerte. Úsala si hace falta, y revisa la lista una vez al año.

Todo esto se puede exigir por contrato a quien construye la app —lista de SDK con su función, nada de dependencias nuevas sin avisar, contratos de encargado archivados—, y es un criterio a valorar al elegir el equipo que desarrolla tu app.

Dónde acaban tus datos

Si tu app usa informe de fallos, analítica, push o autenticación de un proveedor estadounidense, hay datos personales tuyos saliendo de la Unión Europea. Es normal y no es ilegal: el RGPD exige que esa salida tenga cobertura, y hoy la más usada es la decisión de adecuación del marco UE-EE. UU., la Decisión de Ejecución (UE) 2023/1795. Con una condición que se salta casi todo el mundo: su artículo 1 declara adecuado el nivel de protección de los datos transferidos a las entidades estadounidenses que figuren en la lista del Marco de Privacidad de Datos, no de cualquier empresa por ser estadounidense. Comprobar si un proveedor está en esa lista son treinta segundos en dataprivacyframework.gov, y de los SDK de tu inventario es probable que alguno no esté. Para esos, el mecanismo no es la adecuación: son las cláusulas contractuales tipo, que desde Schrems II no se firman y se olvidan —hay que evaluar el destino y añadir garantías si la ley de allí impide cumplirlas—.

Conviene ser preciso, porque esto se presta al titular. El 31 de julio de 2026 el Comité Europeo de Protección de Datos escribió al comisario Michael McGrath pidiendo a la Comisión que «evalúe de cerca si este desarrollo afecta al funcionamiento de la Decisión de Ejecución (UE) 2023/1795». El desarrollo al que se refiere es la sentencia del Tribunal Supremo estadounidense en Trump v. Slaughter, que permite destituir sin restricciones a los comisionados de la Comisión Federal de Comercio. El problema es de fondo: la adecuación se construyó sobre la premisa de que hay autoridades de supervisión independientes al otro lado. En palabras del Comité, «la existencia y el funcionamiento efectivo de una o más autoridades de supervisión independientes en un país tercero, responsables de garantizar y hacer cumplir las normas de protección de datos, es uno de los elementos clave a tener en cuenta [al evaluar la adecuación del nivel de protección de un país tercero con arreglo al artículo 45.2.b) del RGPD]» (carta del EDPB, en inglés; la traducción es nuestra).

Y ahora, sin adornos: el marco sigue vigente. La Comisión no lo ha revocado y, hasta que lo haga, ampara tus transferencias; lo que ha ocurrido es que el Comité ha puesto el asunto sobre la mesa. No hay nada que migrar mañana, y quien te venda urgencia con esto te está vendiendo miedo.

Lo que sí cambia es cómo pensarlo: tu cobertura depende de una decisión administrativa que está siendo examinada, y los dos marcos anteriores que cumplieron esa función acabaron anulados. Eso recomienda tres cosas baratas: saber qué sale y si cada destino está en la lista, tener las cláusulas contractuales tipo firmadas —para un proveedor que no esté en la lista no son un plan B, son el único mecanismo; para el resto sí lo son, y muchos ya las ofrecen en su anexo— y saber si tu proveedor tiene región europea y qué costaría usarla. No para cambiarte hoy, sino para no averiguarlo con prisa el día que algo se mueva.

Cuando alguien ejerce sus derechos, el reloj corre

Un día llega un correo: alguien pide copia de sus datos, o su borrado. Desde ahí corre el plazo del artículo 12.3 del RGPD: sin dilación indebida y, como tope, un mes desde la recepción de la solicitud —el mes es el techo, no una franquicia—, prorrogable otros dos cuando haga falta, teniendo en cuenta la complejidad y el número de solicitudes.

El matiz que se salta casi todo el mundo, y que convierte un retraso normal en incumplimiento: la prórroga hay que comunicarla dentro del primer mes, explicando los motivos. No se activa sola porque el caso sea complicado. Si dejas pasar el mes en silencio y contestas el día cuarenta, no te has prorrogado: has incumplido. Avisar a tiempo es un correo de cinco líneas.

Pero el plazo no es el problema de fondo. Lo decide todo una pregunta operativa: ¿puede tu sistema exportar y borrar los datos de un usuario concreto, o hace falta que alguien entre a mano en la base de datos? Si es lo segundo, no tienes un proceso: tienes un favor. Aguanta una petición al trimestre y se cae cuando llegan cinco a la vez. Y falla siempre igual: se borra de la tabla de usuarios y se olvidan el almacén analítico, el soporte y los proveedores que tienen copia.

Un procedimiento que aguanta tiene cuatro piezas:

• Un canal declarado y vigilado, con registro de qué entra y cuándo: la fecha de recepción arranca el reloj.
• Verificación de identidad proporcionada. Exigir documentación desmedida para ganar tiempo se ve venir de lejos.
• Una función técnica que recorra todos los sitios. Exportación legible y borrado que alcance base de datos, almacén analítico, registros, copias y proveedores.
• Una respuesta escrita. Qué se ha hecho, qué no y por qué: lo que hay que conservar por obligación legal se explica, no se oculta.

Montarlo en un proyecto nuevo son unas jornadas; sobre una app de tres años cuesta bastante más, y aparece sin avisar en el mantenimiento de la app. Igual que con la normativa europea de accesibilidad, lo barato es entrar a tiempo.

Los cinco fallos que nos encontramos una y otra vez

Se repiten en apps de todos los tamaños y ninguno es caro de arreglar.

• El SDK se inicializa antes del consentimiento. La pantalla de permisos aparece, pero la analítica ya mandó el primer evento con el identificador de dispositivo. Dos minutos de tráfico lo delatan.
• Un único «acepto» para todo. Contrato, analítica, publicidad y comunicaciones comerciales en la misma casilla: no permite retirar una finalidad sin las otras ni demuestra qué aceptó cada persona.
• Ningún plazo de conservación escrito. Nadie decidió cuánto dura cada categoría, así que dura para siempre. El fallo más silencioso.
• El borrado que en realidad es una desactivación. La cuenta desaparece de la app y el registro sigue completo, con su copia en el almacén analítico y en soporte.
• Sin contrato de encargado con el proveedor de push o de soporte. Con la nube y la pasarela de pago suele estar; con el chat de soporte y las notificaciones casi nunca.

Conclusión

El RGPD en una app no se demuestra con una política de privacidad larga ni con un banner bien diseñado, sino con seis respuestas y los documentos que las sostienen: el inventario, las bases legales por tratamiento, los plazos de conservación, los contratos de encargado, el mapa de transferencias con su cobertura y un procedimiento de derechos que no dependa de que alguien abra la base de datos a mano. El registro de actividades no es una séptima respuesta: es el papel donde se juntan casi todas. Ese es el expediente que te van a pedir, y en ese orden se construye.

Nada de esto es urgente, pero sí acumulativo: cada mes hay más datos que inventariar. No somos abogados y este artículo no sustituye el criterio de uno al validar el resultado, pero lo que falla casi siempre no es jurídico: es que nadie ha recorrido el ciclo de vida del dato de punta a punta. Si quieres que lo recorramos sobre tu app, cuéntanos qué app tienes y en qué stack está. Y si buscas la mitad técnica, empieza por el hub de seguridad en apps móviles.