La privacy by design móvil consiste en prever la protección de los datos desde la definición de una aplicación, no en añadirla antes de la puesta en línea. En la práctica, esto cambia vuestras pantallas de consentimiento, vuestras elecciones de SDK, vuestros costes de desarrollo y, a veces, vuestras funcionalidades. Bien aplicada, reduce el riesgo ante la CNIL y App Store sin degradar la experiencia de usuario.
Privacy by design móvil: lo que realmente cambia
El RGPD, aplicable desde 2018, ya impone este principio a través de su artículo 25: protección de datos desde el diseño y por defecto. El EDPB, el Comité Europeo de Protección de Datos, precisó esta lógica en sus directrices 4/2019 adoptadas en versión 2.0 el 20 de octubre de 2020.
Para una aplicación móvil, el reto es más sensible que para un sitio web corporativo. Un teléfono da acceso a la ubicación en tiempo real, a las fotos, a los contactos, al micrófono, a datos de salud y a identificadores publicitarios. La CNIL lo recuerda en su recomendación móvil adoptada el 18 de julio de 2024, publicada el 24 de septiembre de 2024 y posteriormente actualizada el 8 de abril de 2025 sin cambios de fondo.
La buena lectura de negocio es simple: cada dato solicitado debe tener una razón. Si no mejoraore claramente el servicio, sobre todo aumenta vuestro riesgo jurídico, vuestra complejidad técnica y la desconfianza del usuario.
Las decisiones que deben tomarse antes de la primera maqueta
La privacy by design móvil empieza antes del desarrollo. Desde los talleres de definición, hay que enumerar los datos recogidos, su finalidad, su plazo de conservación, los proveedores que acceden a ellos y el momento en que se informa al usuario. Este trabajo parece administrativo. En realidad, evita rediseños de pantallas costosos.
Un ejemplo habitual: una app de reservas quiere solicitar la geolocalización en el primer inicio. Mala idea en muchos casos. Si el usuario aún no ha encore comprendido el valor del servicio, rechaza más fácilmente la autorización. A menudo es mejor esperar a la pantalla en la que busca un punto de venta cerca de él.
En los proyectos que llevamos a cabo, vemos a menudo la misma trampa: instalar demasiado pronto SDK de terceros, esas bibliotecas listas para usar utilizadas para analytics, crash reporting, publicidad o pago. Cada SDK puede recopilar datos y debe estar documentado. Google Play recuerda además que el desarrollador sigue siendo responsable de las prácticas de datos de su app y de sus SDK de terceros en el formulario Data safety.
Si vuestra aplicación forma parte de una estrategia móvil más amplia, la definición técnica debe estar alineada con vuestros objetivos de producto. Un punto de partida útil consiste en acercar conformidad, performance y arquitectura, como en un enfoque de desarrollo móvil iOS y Android estructurado.
Autorizaciones, consentimiento y recorrido del usuario
Una autorización del sistema no es por sí sola un consentimiento RGPD. En iOS o Android, el usuario puede autorizar el acceso a la cámara, pero eso no dice necesariamente por qué se tratan los datos, cuánto tiempo se conservan ni con quién se comparten. Por tanto, hay que articular la pantalla nativa del sistema con una información clara dentro de la app.
Android recomienda las solicitudes de autorización en el momento del uso, la limitación del acceso hors del espacio aislado de la aplicación (zona aislada de la app), la reducción de la visibilidad de las demás apps instaladas, el uso de identificadores restablecibles y la solicitud de ubicación precisa o en segundo plano solo cuando sea necesario. Son buenos principios de UX tanto como de conformidad.
Por parte de Apple, desde el 1 de mayo de 2024, las nuevas apps y las actualizaciones afectadas deben integrar privacy manifests y declarar las required-reason APIs, es decir, determinadas interfaces técnicas sensibles utilizadas por una razón autorizada. Una app que utilice estas API sin declaración puede ser rechazada por App Store Connect. No es un detalle de final de proyecto.
- Solicitar un permiso únicamente cuando el usuario comprenda su beneficio inmediato.
- Prever una alternativa degradada si se rechaza el permiso.
- Evitar los SDK innecesarios antes de la puesta en producción.
- Documentar cada flujo de datos, incluidos analytics, support y notificaciones.
- Probar las pantallas de privacidad con usuarios reales, no solo con el equipo del proyecto.
Presupuesto y plazos: ¿cuánto cuesta una app conforme?
La confortidad tiene un coste, pero el coste de una corcción tardía es casi siempre superior. En Francia, para una aplicación pyme seria, el esforzo de privacidad representa a menudo desde unos pocos días hasta varias semanas según la sensibilidad de los datos, el número de SDK y las exigencias del negocio. Con este presupuesto, es mejor definir bien el alcance que pagar una refactorización tras el rechazo de store o una auditoría jurídica.
| Situación del proyecto | Esforzo de privacidad típico | Impacto presupuestario habitual en Francia | Riesgo si se descuida |
|---|---|---|---|
| App sencilla sin cuenta de usuario | 1 a 3 días de definición del alcance y verificación | Alrededor de 1 000 a 3 000 € según el proveedor | Menciones incompletas, permisos mal justificados |
| App con cuenta, analytics y notificaciones | 4 a 8 días incluyendo registro, pantallas, pruebas | Alrededor de 4 000 a 9 000 € | Formulario Google Play incoherente, consentimiento débil |
| App con localización, fotos o datos sensibles | 2 a 4 semanas con arbitrajes de producto y jurídicos | Alrededor de 10 000 a 25 000 € o más | Rechazo de store, control de la CNIL, pérdida de confianza |
Estos importes no son tarifas reguladas. Reflejan ordenes de magnitud observados en el mercado francés, hors el desarrollo completo de la app. El coste real depende sobre todo de una cuestión: ¿hay que cambiar el producto, o solo documentar y proteger mejor lo que ya existe?
La solución evidente a veces es la equivocada. Añadir un banner de consentimiento en todas partes puede tranquilizar internamente, pero fatigar al usuario y crear opciones jurídicamente confusas. Sinceramente, a menudo es mejor reducir la recopilación que multiplicar los pop-ups.
Stores, CNIL y pruebas: lo que hay que documentar
La conformidad móvil también se valora por las pruebas. Google Play exige un formulario Data safety y una política de privacidad. Apple solicita información sobre la privacidad de la app, y ciertos usos técnicos deben desorde ahora declararse mediante los privacy manifests. La CNIL ha anunciado que a partir de 2025 verificará la consideración de sus recomendaciones móviles en el marco de acciones de control.
Un expediente mínimo debe contener el mapa de datos, las finalidades, la base legal, los plazos de conservación, los encargados del tratamiento, los permisos del sistema y las capturas de las pantallas de información. Para los tratamientos más arriesgados, puede ser necesaria una AIPD, evaluación de impacto relativa a la protección de datos. Se trata de una evaluación estructurada de los riesgos para las personas.
La coherencia cuenta enormormente. Si su política de privacidad dice que no comparte ningún dato, pero un SDK analytics transmite identificadores técnicos a un proveedor, crea una discrepancia. Trabajos académicos recientes, como artículos de arXiv publicados en 2026 sobre las incoherencias entre Google Play Data Safety y las políticas de privacidad, muestran que este tema es cada vez más observable.
La seguridad técnica completa el privacy by design móvil: cifrado en tránsito mediante HTTPS/TLS, limitación de los accesos internos, alojamiento controlado, registro útil pero proporcionado. Los retos de seguridad no se detienen en el código de la app; también afectan a las API, los cortafuegos y la infraestructura, como recuerdan regularmente las vulnerabilidades en equipos expuestos, por ejemplo los riesgos en torno a cortafuegos mal protegidos.
Arbitrajes de producto: proteger sin romper la experiencia
Un buen privacy by design móvil no transforma la app en un formulario jurídico. La experiencia debe seguir siendo fluida, con explicaciones breves, situadas en el momento adecuado y redactadas en el idioma del usuario. La transparencia debe ayudar a decidir, no interrumpir cada acción.
Para una app de reparto, la localización precisa puede ser útil durante un pedido y luego innecesaria después. Para una app de medios, el identificador publicitario no es formamente necesario si basta con un modelo de suscripción o de medición agregada. Para una app B2B, los logs técnicos pueden ser indispensables para el supporte, pero su plazo de conservación debe estar acorado.
Desde el lado de la agencia, el reflejo es contrastar cada solicitud de datos con tres criterios: valor para el usuario, valor de negocio, riesgo. Si un dato aporta poco al usuario y mucho riesgo, debe desaparecer o sustituirse por un dato menos preciso. Una ciudad en lugar de una posición GPS exacta, por ejemplo.
Las tendencias móviles en París muestran hasta qué punto los usos son intensivos, lo que reforza la exigencia de confianza. Para situar un proyecto en su contexto de mercado, las cifras clave del móvil en París ofrecen referencias útiles sobre las expectativas y los volúmenes de uso. Y si su estrategia prevé una adopción sin fricción, formatos como App Clips e Instant Apps también pueden reducir la recopilación inicial al permitir un primer uso más ligero.
Un método simple para delimitar sin sobrecoste
Empiece con un taller de datos de dos horas con los responsables de producto, técnica, marketing y supporte. Enumere las pantallas, los datos solicitados, los SDK previstos y las razones de negocio. Luego elimine lo que no tenga una justificación clara.
Después, integre la privacidad en el backlog, es decir, la lista priorizada de tareas del proyecto. Las pantallas de permisos, la política de privacidad, los ajustes de cuenta, las exportaciones o supresiones de datos y las declaraciones App Store o Google Play no deben llegar después de las pruebas finales. Forman parte del producto.
Por último, prevea una revisión antes del envío a las stores. Verifica la coherencia entre la app, los permisos, los SDK, los manifests de Apple, el formulario Data safety de Google Play y los textos jurídicos. Esta jornada de control puede evitar varias semanas de bloqueo, sobre todo cuando una campaña de marketing depende de una fecha de lanzamiento.
Delimitar este tipo de proyecto con antelación evita la mayoría de las malas sorpresas: rechazo de store, recopilación excesiva, deuda técnica, pantallas mal aceptadas. A menudo es ahí donde una mirada externa ahorra tiempo, al conectar producto, conformidad y desarrollo sin sobrecargar innecesariamente la aplicación.
FAQ sobre el privacy by design móvil
¿Es obligatorio el privacy by design móvil?
Sí, el principio se deriva del artículo 25 del RGPD sobre la protección de datos desde el diseño y por defecto. Para una app móvil, se traduce en decisiones concretas sobre los permisos, los datos recopilados, los SDK y los ajustes predeterminados.
¿Hay que solicitar el consentimiento para todos los datos de una app?
No. El consentimiento es solo una base jurídica entre otras, junto con el contrato, la obligación legal o el interés legítimo según los casos. En cambio, el usuario debe ser informado claramente, y determinados datos o rastreadores sí requieren un consentimiento específico.
¿Puede una app ser rechazada por Apple o Google por un problema de privacidad?
Sí. Apple impone en particular declaraciones relacionadas con los privacy manifests y las required-reason APIs desde el 1 de mayo de 2024, mientras que Google Play exige un formulario Data safety coherente y una política de privacidad.
¿Cuánto tiempo hay que prever para verificar la conformité antes del lanzamiento?
Para una app sencilla, pueden bastar unos pocos días. Para una aplicación con geolocalización, datos sensibles o numerosos SDK, prevea más bien de dos a cuatro semanas para corregir las pantallas, las declaraciones y los flujos de datos.