Política de privacidad para una app: qué revisar antes de publicarla

La exigencia de las tiendas no termina en una URL

Apple pide un enlace público a la política en App Store Connect y un acceso sencillo dentro de la aplicación. Además, la ficha de App Privacy resume qué tipos de datos se recogen, para qué se usan, si se vinculan con una identidad y si sirven para seguimiento. Las respuestas deben incluir la actividad de los servicios de terceros integrados en la app.

Google Play exige la política tanto en la ficha como dentro del producto. También obliga a completar la sección Seguridad de los datos. Su política de Datos de Usuario deja claro que el desarrollador responde por la información recogida directamente y por la que tratan sus bibliotecas o proveedores.

Por tanto, no basta con que el texto parezca completo. La aplicación publicada, la política, los formularios de las tiendas, los avisos previos a un permiso y las opciones de privacidad deben contar la misma historia.

El inventario que debe existir antes de redactar

Conviene reunir a quien conoce el producto, el servidor y las aplicaciones móviles. La conversación no debería empezar por artículos del RGPD, sino por recorridos concretos: registro, compra, reserva, chat, geolocalización, asistencia y cierre de cuenta.

Para cada fila, anota finalidad, categoría de datos, origen, base jurídica prevista, proveedor, país o región de alojamiento, personas con acceso, plazo de conservación y forma de borrado. Si nadie puede explicar para qué sirve un campo, la solución más prudente suele ser no recogerlo.

La AEPD, en su nota técnica sobre apps móviles, insiste en que la información debe ajustarse a las particularidades del entorno móvil. Sensores, identificadores y permisos convierten una app en algo distinto de una simple página web.

Qué debería explicar una política comprensible

El usuario debe saber quién decide sobre sus datos. Incluye la razón social, los datos de contacto y, cuando corresponda, el delegado de protección de datos o representante. La identidad debe ser coherente con la empresa que aparece como desarrolladora en la tienda.

Después, separa los datos por grupos reconocibles. No mezcles en una frase genérica el nombre, la ubicación, una grabación de voz y un historial médico. Explica si los facilita la persona, los obtiene el teléfono, los crea el servicio o llegan desde un tercero.

Cada finalidad necesita una explicación concreta y su base jurídica. “Mejorar la experiencia” no permite entender nada. Es más útil decir que se conserva una reserva incompleta durante siete días, que la posición del repartidor se muestra durante un pedido activo o que se emplean datos de errores para corregir una versión concreta.

La política también debe informar de destinatarios y encargados, transferencias internacionales, plazo o criterio de conservación, medidas de seguridad descritas sin promesas absolutas, derechos y canal para ejercerlos, reclamación ante la autoridad de control y fecha de vigencia.

El RGPD, especialmente sus artículos 13 y 14, marca buena parte de estas obligaciones para usuarios de la Unión Europea. El texto final debe reflejar además la normativa sectorial y nacional aplicable al servicio.

Política, permiso del móvil y consentimiento no son sinónimos

La política informa del conjunto de tratamientos. La ficha de una tienda ofrece un resumen estructurado antes de instalar. El permiso de iOS o Android abre o bloquea técnicamente el acceso a cámara, micrófono, fotos o ubicación. El consentimiento, cuando sea la base adecuada, debe referirse a una finalidad concreta.

Aceptar el permiso de cámara para subir una foto no autoriza a analizar el rostro para publicidad. Del mismo modo, rechazar analítica opcional no debería impedir una reserva que funciona sin ella. La pantalla previa al permiso debe explicar el beneficio justo cuando la persona intenta utilizar esa función.

Esta diferencia cambia el diseño. Puede hacer falta un centro de preferencias, un historial de consentimientos, una opción para descargar datos o un recorrido para eliminar la cuenta. Todo ello debe entrar en la planificación del producto y en las pruebas. La guía de autenticación y cuentas ayuda a definir ese ciclo completo.

Los SDK pueden contradecir un texto aparentemente correcto

Un SDK es una pieza de software externa integrada para resolver analítica, mapas, pagos, atribución, chat, publicidad o informes de errores. Puede acceder a identificadores y enviar información sin pasar por la base de datos principal de la empresa.

Apple obliga a declarar las prácticas de los socios tecnológicos y utiliza manifiestos de privacidad para numerosos SDK habituales. Google también exige incluir en Seguridad de los datos lo que recogen o comparten las bibliotecas. El propietario de la aplicación sigue siendo responsable de revisar esa actividad.

Crea un registro de dependencias con versión, función, permisos, categorías de datos, destinos, configuración, opción de exclusión y persona responsable dentro del equipo. Comprueba una compilación de lanzamiento, porque una versión de desarrollo puede enviar eventos distintos.

La lista de seguridad para Android sirve para revisar permisos, registros, secretos y dependencias. La guía de analítica móvil ayuda a evitar eventos con información personal innecesaria.

El borrado de la cuenta debe funcionar de verdad

Apple exige que las aplicaciones con creación de cuenta permitan iniciar su eliminación desde la propia app. Google Play pide una ruta interna y, además, un recurso web externo desde el que solicitar el borrado.

No equivale a cerrar sesión, suspender el perfil o ocultarlo. Hay que decidir qué ocurre con pedidos abiertos, suscripciones, contenido publicado, conversaciones, facturas, reclamaciones, prevención del fraude y copias de seguridad. Cuando exista un motivo legítimo para conservar algo, la política debe explicar qué se mantiene, por qué y durante cuánto tiempo.

El recorrido necesita mensajes claros, confirmación de identidad proporcional al riesgo, cancelación de cargos futuros cuando proceda, comprobante de la solicitud y un estado que el equipo de soporte pueda seguir. La explicación oficial de Google sobre eliminación de cuentas permite convertir la regla en criterios de aceptación.

Incluye esta prueba en la lista de lanzamiento de una app, junto con los enlaces públicos y los accesos para la revisión de la tienda.

Cómo cambia la política según el producto

En una app de citas para un salón de belleza pueden bastar nombre, contacto, reservas y estado del anticipo. Hay que explicar recordatorios, acceso del personal y conservación de citas. Añadir cláusulas sobre biometría o contactos cuando no existen solo vuelve el documento más confuso.

Una aplicación de reparto requiere más detalle. Dirección del cliente, posición del repartidor, fotografía de entrega y panel del coordinador responden a finalidades distintas. La ubicación durante un pedido no debería describirse como si fuese un seguimiento permanente.

En salud o educación pueden aparecer datos especialmente protegidos o usuarios menores. Aquí una plantilla genérica resulta insuficiente. Roles, acceso profesional, exportación, incidentes y contratos con proveedores deben estar resueltos antes de desarrollar. La lista general de seguridad móvil complementa la parte técnica.

Revisión práctica antes de enviar la app

1. Cierra el inventario de la versión. Usa la compilación candidata y registra funciones, permisos, servicios externos, paneles internos y exportaciones.
2. Dibuja las rutas de los datos. Incluye lo que ocurre antes del registro, los registros de errores, soporte, notificaciones y copias.
3. Redacta para el mercado real. Prepara información clara en el idioma del usuario y solicita revisión jurídica cuando el riesgo lo justifique.
4. Completa las tiendas desde el mismo inventario. Compara cada respuesta de Apple y Google con la política.
5. Prueba las decisiones del usuario. Rechaza permisos, retira opciones, solicita acceso y elimina una cuenta de prueba.
6. Asigna mantenimiento. Guarda versión, fecha, responsable y motivos que obligarán a revisar el documento.

La documentación no debería quedarse en el ordenador de una sola persona. La guía de entrega de documentación muestra qué debe recibir el propietario del producto al cambiar de proveedor.

Mantener la política después del lanzamiento

Una política puede quedar desactualizada aunque nadie toque su página. Basta con instalar un nuevo servicio de medición, habilitar grabación de sesiones, cambiar de proveedor de mapas o pedir un documento adicional en soporte.

Añade una pregunta de privacidad a cada cambio de producto: qué dato nuevo entra, quién lo recibe, cuál es la finalidad, si cambia el permiso o la opción del usuario y cómo llega el borrado al proveedor. La tarea no se considera terminada hasta decidir si deben actualizarse la política y las fichas de las tiendas.

Conserva versiones anteriores y fechas de entrada en vigor. Informa de los cambios relevantes de forma proporcional, sin convertir cada corrección tipográfica en una pantalla obligatoria.

Cómo lo incorpora Appfyl al alcance del proyecto

En Appfyl empezamos por los recorridos y los roles. Identificamos qué necesita el usuario, qué consulta el equipo en el panel de administración, qué servicios externos participan y qué debe ocurrir cuando una persona retira un permiso o elimina su cuenta.

Este inventario permite estimar trabajo que suele quedar oculto: ajustes de privacidad, borrado en servidor, permisos, registro de solicitudes, cambios en el panel de administración y pruebas. También ofrece una base común para el equipo técnico y la revisión legal, sin pedir al abogado que adivine el comportamiento de la aplicación.

Puedes incluir datos, integraciones, roles y borrado en el brief interactivo de Appfyl. Para valorar el desarrollo completo, consulta Appfyl.

¿Quieres ver cómo Appfyl convierte el alcance en productos lanzados? Ver casos de Appfyl.

Preguntas frecuentes