La respuesta corta
Las dos tiendas obligan a declarar qué datos recoge tu app, y en las dos eres responsable también de lo que recogen los SDK de terceros que has integrado. No de lo que tú usas: de lo que ellos recogen.
Ese es el punto que suspende declaraciones. El equipo enumera lo que guarda en su base de datos, olvida la librería de analítica, el SDK de anuncios y el de login social, y firma una declaración incompleta.
Y las consecuencias no son teóricas. Google lo dice sin rodeos: cuando detecta una discrepancia entre el comportamiento de la app y la declaración, puede exigir correcciones, bloquear actualizaciones o retirar la app.
Google Play: la sección de seguridad de los datos
Todo desarrollador que publica en Play debe rellenarla, salvo servicios del sistema y apps privadas. Hay que declarar:
- Toda la recogida de datos de usuario, entendida como transmitirlos fuera del dispositivo —incluidos los que salen a través de SDK y de vistas web bajo control de la app.
- El compartir con terceros, que incluye transferencias servidor a servidor y también las que ocurren en el propio dispositivo hacia otra app.
- Prácticas de seguridad: si todo lo recogido viaja cifrado en tránsito.
- Si el usuario puede solicitar el borrado de sus datos.
- Qué hacen las librerías y SDK de terceros.
Son trece categorías —ubicación, información personal, financiera, salud y forma física, mensajes, fotos y vídeos, audio, ficheros, calendario, contactos, actividad en la app, navegación web e identificadores— con más de cuarenta tipos de dato concretos.
Lo que no hay que declarar también está acotado, y conviene conocerlo porque cambia decisiones de diseño:
- Procesamiento solo en el dispositivo.
- Datos con cifrado de extremo a extremo que tú no puedes leer.
- Proveedores que procesan en tu nombre.
- Requerimientos legales.
- Compartir iniciado por el usuario con consentimiento destacado.
- Datos totalmente anonimizados.
La primera excepción es una palanca de diseño real: lo que se procesa en el dispositivo no se declara, y además no se filtra, no hay que borrarlo y no aparece en la ficha.
App Store: las etiquetas de privacidad
Mismo principio y algunas reglas propias. Hay que declarar todo lo que recoge el desarrollador o sus socios terceros, salvo que se cumplan todas las condiciones de la excepción: que no se use para seguimiento, que no se use para publicidad ni marketing, que se recoja solo en casos ocasionales y opcionales fuera de la funcionalidad principal, y que el usuario lo aporte explícitamente con una divulgación clara cada vez.
Las tres categorías que ve el usuario:
- Datos usados para rastrearte: combinar datos de tu app con datos de terceros para publicidad segmentada o medición, compartir ubicación o listas de correo con intermediarios de datos, o compartir identificadores con redes publicitarias para retargeting. Y algo que sorprende a mucha gente: cuenta también si un SDK de terceros reutiliza los datos de tu app para publicidad segmentada en otras apps, aunque tú no lo uses para eso.
- Datos vinculados contigo: se consideran vinculados salvo que el desarrollador aplique desidentificación antes de la recogida y no vuelva a relacionarlos después.
- Datos no vinculados contigo: realmente anónimos.
Y una obligación operativa que casi nadie tiene en el calendario: hay que mantener las respuestas actualizadas, y se actualizan en App Store Connect sin necesidad de enviar una versión nueva cuando cambian las prácticas.
El inventario que hay que hacer antes de declarar
Esto es lo que convierte la declaración en un trámite de una tarde en vez de una adivinanza:
- Lista de todos los SDK integrados, con su versión.
- Qué recoge cada uno por defecto, no lo que tú le pides.
- Qué eventos manda tu analítica, con sus nombres y sus propiedades.
- Qué sale en los registros de errores — las trazas y los datos adjuntos también salen del dispositivo.
- Qué guardan las vistas web que abre la app.
- Con quién se comparte, incluido el paso servidor a servidor.
El punto tres es el que más veces revela una sorpresa: un evento llamado con el nombre de una condición médica o de un producto financiero es un dato sensible, aunque viva en una herramienta de producto. Lo tratamos con más detalle en datos de salud en una app.
Permisos: pedir menos, y pedirlos tarde
Independiente de la declaración, pero relacionado:
- Cada permiso hay que justificarlo ante el usuario y ante la tienda. Uno que la app no usa es una bandera roja gratuita.
- Pedirlos en contexto, cuando la función lo necesita, no en el arranque.
- Diseñar el «no»: qué hace la app si el usuario deniega. Si la respuesta es «no funciona», estás perdiendo usuarios que habrían aceptado más tarde.
- Los permisos sensibles tienen requisitos propios: el de ubicación en segundo plano, por ejemplo, exige petición incremental y aprobación de Play — está en app de seguro telemático.
Los errores que bloquean actualizaciones
- Olvidar un SDK. El más frecuente con diferencia.
- Declarar «no compartimos» y tener publicidad integrada.
- Marcar cifrado en tránsito sin comprobarlo en todos los endpoints, incluidos los de terceros.
- No ofrecer borrado de datos y declarar que sí.
- No actualizar la declaración cuando entra una funcionalidad nueva.
El último es traicionero: la declaración se hace bien en el lanzamiento y nadie la vuelve a mirar en dos años de evoluciones.
Antes de publicar
- ¿Tenemos el inventario de SDK y de lo que recoge cada uno?
- ¿Los nombres de nuestros eventos de analítica revelan algo sensible?
- ¿Todos los endpoints van cifrados, incluidos los de terceros?
- ¿Existe un mecanismo real de borrado y quién lo ejecuta?
- ¿Quién es responsable de actualizar la declaración cuando cambie la app?
La quinta necesita un nombre. Sin él, la declaración envejece sola.
Forma parte del trabajo de publicación en cualquier proyecto que hacemos, y es una de las cosas que revisamos en una auditoría técnica de app móvil.
Fuentes primarias, consultadas el 14 de agosto de 2026: Data safety en Google Play y App privacy details en el App Store.
