Requisitos de privacidad y permisos antes de publicar una aplicación móvil empresarial

Antes de enviar una aplicación móvil empresarial a App Store o Google Play, hay que comprobar que tres elementos describen exactamente lo mismo: el comportamiento real de la app, la documentación de privacidad y las declaraciones enviadas a cada tienda. Una política genérica o una ficha cumplimentada sin revisar los SDK, permisos y flujos reales puede resultar insuficiente y provocar rechazos o incoherencias.

La revisión no debe limitarse a los permisos de cámara o ubicación. Debe abarcar los datos que trata la aplicación, los proveedores conectados, los accesos internos, la creación y eliminación de cuentas, la conservación de la información y los mercados donde se distribuirá. Esta guía es una checklist técnica y organizativa; no sustituye el análisis de la base jurídica aplicable ni el asesoramiento especializado en protección de datos.

Qué hay que revisar antes de enviar una app empresarial

Empieza por reunir a producto, desarrollo, seguridad y la persona responsable de privacidad. El objetivo es documentar qué hace la app y contrastarlo con lo que se comunicará al usuario y a las plataformas.

Conviene separar tres capas que a menudo se confunden:

• Permiso técnico del dispositivo: autoriza o deniega el acceso de la app a un recurso como la cámara, el micrófono o la ubicación.
• Transparencia: explica de forma comprensible qué datos se tratan, para qué, con quién se comparten, durante cuánto tiempo y cómo puede ejercer sus derechos el usuario.
• Tratamiento de datos: exige revisar finalidad, minimización, seguridad, conservación y la base jurídica que corresponda. El RGPD recoge estos principios, incluida la responsabilidad proactiva.

Aceptar un aviso del sistema operativo no equivale, por sí solo, a resolver las obligaciones de protección de datos. Del mismo modo, que una funcionalidad sea útil para la empresa no justifica pedir un acceso si puede funcionar sin él o con una alternativa menos intrusiva.

1. Inventario de datos, permisos y flujos

El inventario debe reflejar lo que sucede en la versión que se va a publicar, no solo lo previsto en los requisitos iniciales. La AEPD advierte de que una app puede tratar información mediante sensores, almacenamiento del dispositivo, librerías de terceros y proveedores externos; por eso es necesario revisar los flujos completos.

Qué registrar para cada dato

• Qué dato se recoge o consulta: por ejemplo, identificadores de cuenta, datos de contacto, ubicación, fotografías o datos de autenticación.
• Cómo se obtiene: formulario, permiso del sistema, importación, sensor, API, SDK o integración con un sistema corporativo.
• Para qué función concreta se utiliza.
• Dónde se almacena y qué equipos, proveedores o terceros pueden acceder.
• Si se comparte o transfiere fuera de la app.
• Cuánto tiempo se conserva y qué ocurre al solicitar una baja o eliminación.

Revisa especialmente los accesos a cámara, micrófono, ubicación, contactos, fotos, archivos, notificaciones, biometría, salud, SMS y datos de autenticación. No todos serán pertinentes en una app empresarial, pero cada permiso incluido debe responder a una funcionalidad real y necesaria.

También deben formar parte del inventario los SDK de analítica, atribución, mapas, pagos, mensajería, autenticación, publicidad o inteligencia artificial. Apple exige que las prácticas de privacidad declaradas en App Store Connect representen de forma exacta el comportamiento de la app, incluidos los datos tratados por SDK y servicios de terceros. Google Play aplica el mismo criterio a la información de Data safety y atribuye al desarrollador la responsabilidad sobre las prácticas de los terceros integrados.

En una aplicación conectada a un ERP, CRM u otra plataforma corporativa, documenta qué campos se sincronizan, cuál es el sistema de origen y qué roles pueden verlos o modificarlos. La planificación de estos flujos debe estar alineada con las decisiones de integración; puede ayudarte esta guía sobre cómo integrar una aplicación con un ERP.

2. Documentación de privacidad que debe estar preparada

La documentación no debe redactarse al final como un texto aislado. Debe salir del inventario de datos y poder contrastarse con la aplicación. Como mínimo, prepara lo siguiente:

• Política de privacidad: accesible desde la ficha de la tienda y desde la propia app. Debe identificar a la entidad responsable y explicar los datos tratados, obtención, finalidades, terceros, conservación, derechos y vías para retirar el consentimiento o solicitar eliminación cuando corresponda.
• Registro de tratamientos e inventario de proveedores: incluyendo SDK, servicios externos y los datos a los que accede cada uno.
• Textos de propósito y divulgaciones dentro de la app: deben explicar de forma clara por qué se solicita un recurso protegido o se realiza un tratamiento que el usuario podría no esperar razonablemente.
• Evidencias y procedimiento operativo: define cómo se gestionarán las solicitudes de derechos, retirada del consentimiento, incidencias, bajas y eliminación.
• Proceso de conservación y eliminación: aclara qué datos se eliminan, qué pasos se aplican a proveedores y qué información debe conservarse por una obligación aplicable.

Apple exige una política de privacidad accesible tanto desde App Store Connect como desde la aplicación. Google Play también exige una política válida y accesible desde la ficha y desde la app. No basta con enlazar una página: su contenido debe corresponder a la implementación real.

Si la aplicación permite crear cuentas, Google Play exige una vía clara para solicitar su eliminación y la de los datos asociados desde la aplicación y mediante un recurso web externo indicado en Play Console. Desactivar o congelar una cuenta no equivale a eliminarla. Cuando existan obligaciones de conservación, la información al usuario debe explicar esa excepción sin presentar una eliminación parcial como una eliminación total.

La AEPD recomienda aplicar privacidad desde el diseño y por defecto: limitar los datos, el plazo de conservación y la accesibilidad a lo necesario. Antes de iniciar el tratamiento, procede realizar un análisis de riesgos. Si este puede implicar un alto riesgo para los derechos y libertades, debe valorarse si hace falta una evaluación de impacto relativa a la protección de datos. No es un requisito automático para cualquier app: depende del tratamiento y del riesgo concreto.

3. Diferencias prácticas entre App Store y Google Play

En iOS, los textos de propósito para cámara, micrófono, ubicación, contactos o datos de salud deben explicar claramente por qué la app necesita ese acceso. Los permisos deben estar vinculados a una función concreta y no utilizarse para forzar accesos innecesarios.

En Android, ciertos permisos sensibles o de alto riesgo, como SMS, registro de llamadas o determinados accesos especiales, pueden requerir una declaración y aprobación de Google Play antes de publicar o actualizar. La ubicación en segundo plano tiene una revisión específica y debe justificarse por una funcionalidad principal y relevante; Google puede pedir, entre otros elementos, una declaración, un vídeo demostrativo, una divulgación destacada y una política de privacidad accesible.

4. Permisos del sistema, consentimiento y RGPD no son lo mismo

Un permiso técnico responde a una pregunta concreta: si el sistema operativo permite a la aplicación acceder a un recurso. El RGPD exige, además, revisar la licitud, transparencia, finalidad, minimización, conservación, confidencialidad y responsabilidad del tratamiento. La base jurídica no se determina solo porque exista un cuadro de diálogo de iOS o Android.

Por ello, evita dos errores opuestos: asumir que todos los permisos exigen exactamente el mismo tipo de consentimiento para protección de datos, o entender que aceptar el permiso técnico resuelve todas las obligaciones. La respuesta depende del tratamiento concreto, de la función, de los datos y del contexto de uso.

La revisión debe reforzarse cuando intervienen datos de salud, biométricos, de menores, ubicación precisa, información financiera, autenticación, comunicaciones o datos laborales. En estos casos, incorpora desde el inicio a las personas responsables de privacidad y, cuando proceda, al delegado de protección de datos o a asesoramiento jurídico especializado.

5. Pruebas antes de publicar

La comprobación final debe hacerse sobre una compilación candidata a publicación, no solo leyendo requisitos o tickets. Si la app cambia, las declaraciones pueden quedar obsoletas.

1. Compara los datos y destinos observados en la app con la política de privacidad, App Store Connect y Data safety.
2. Comprueba que cada permiso se solicita en el momento en que el usuario activa una función relacionada, con una explicación comprensible y sin pedir accesos al arrancar sin contexto.
3. Prueba recorridos con permisos denegados y verifica que la app degrada la funcionalidad de forma razonable cuando sea posible.
4. Prueba alta de cuenta, cambios de rol, baja, solicitud de eliminación, retirada del consentimiento y manejo de errores.
5. Revisa manifiestos, configuraciones de iOS y Android, dependencias y SDK incluidos en la versión final.
6. Repite la revisión antes de cada actualización que añada un permiso, una integración, un proveedor o un nuevo uso de datos.

Las apps que funcionan sin conexión también merecen una comprobación específica: los datos locales, la cola de sincronización y los conflictos pueden alterar qué se conserva y cuándo se transmite. Esta guía sobre sincronización de datos en una aplicación .NET MAUI offline sirve para plantear esas decisiones técnicas antes de publicar.

6. Checklist final de publicación

• Existe un inventario actualizado de datos, permisos, flujos, SDK y proveedores.
• Cada permiso solicitado está asociado a una función real, explicada de forma clara y necesaria.
• La política de privacidad está disponible dentro de la app y en la ficha de cada tienda, y coincide con la implementación.
• Las declaraciones de App Store Connect y Google Play Data safety incluyen los tratamientos de SDK y terceros.
• La gestión de cuentas contempla una vía clara de eliminación cuando la aplicación permite crearlas.
• Se han definido conservación, eliminación, atención de derechos y responsables internos.
• Se ha realizado análisis de riesgos y se ha valorado una evaluación de impacto cuando el riesgo puede ser alto.
• La app se ha probado con permisos denegados, cambios de rol, bajas y escenarios de error.
• Se han revisado las políticas y pantallas actuales de App Store Connect y Play Console justo antes del envío.

Publica cuando la app y sus declaraciones sean coherentes

No envíes la aplicación hasta que producto, tecnología y privacidad puedan explicar de la misma manera qué datos se tratan, por qué, dónde terminan y qué control tiene el usuario. Si faltan la arquitectura, los manifiestos, los mercados de distribución o el detalle de proveedores, el resultado solo puede considerarse una revisión preliminar.

Una revisión técnica puede detectar permisos innecesarios, SDK no inventariados, flujos de datos inesperados o incoherencias entre la app y la documentación. La determinación de la base jurídica y la validación legal, en cambio, corresponde a la entidad responsable y a profesionales competentes.