Seguridad de los datos y privacidad en las tiendas: cómo declarar lo que hace tu app

«Pero nuestra app ni siquiera pide una cuenta»

Imagina una aplicación para reservar citas. El cliente consulta horarios sin registrarse y llama al establecimiento desde una ficha. Parece razonable pensar que no hay datos personales que declarar. Sin embargo, la app puede enviar diagnósticos, identificadores del dispositivo o eventos de uso a servicios externos.

Ese es el primer cambio de perspectiva que conviene hacer. El formulario de la tienda no describe solo lo que el cliente escribe. Describe también prácticas que ocurren detrás de la pantalla. Si nadie ha revisado esa parte, elegir «no recopilamos datos» sería una suposición.

Vamos a preparar las respuestas desde un ejemplo de reservas, no desde una plantilla para copiar. Es un caso ilustrativo, no un proyecto atribuido a Appfyl. Tampoco sustituye el asesoramiento jurídico que pueda requerir tu actividad o mercado.

Reparte las preguntas entre quienes conocen las respuestas

La persona que tiene acceso a Play Console suele acabar persiguiendo información por distintos chats. Desarrollo conoce los servicios instalados; marketing sabe qué campañas se miden; soporte utiliza los mensajes del cliente. Cada equipo puede tener una parte correcta y, aun así, faltar la visión completa.

Antes de abrir el formulario, reúne esas piezas en un documento compartido. Pide respuestas concretas: no «tenemos analítica», sino «enviamos este evento con estos campos a este servicio». Añade quién confirmó cada dato y qué queda pendiente.

Nos parece más sensato publicar con una duda resuelta que con una casilla elegida por intuición. Cuando alguien no sabe la respuesta, la acción es investigar el flujo, no pedirle que reformule la incertidumbre con más seguridad.

Una referencia útil es la sesión de Apple sobre cómo crear la etiqueta de privacidad. El vídeo tiene transcripción y propone partir de las funciones del producto. Es una forma accesible de organizar la conversación, aunque las reglas vigentes deben consultarse en la documentación actual.

Sigue una reserva desde la pantalla hasta su destino

Recorre la aplicación como lo haría un cliente: consultar disponibilidad, reservar, recibir un aviso y pedir ayuda. En cada paso, averigua si la información se queda en el dispositivo o sale de él. Después pregunta dónde se conserva y con qué otros registros puede relacionarse.

La tabla no asigna categorías oficiales. Sirve para descubrir qué hay que clasificar. Un identificador técnico puede seguir vinculado a una cuenta, aunque no muestre el nombre del cliente. Del mismo modo, un mensaje de error puede contener información que nadie pretendía incluir.

Anota también la versión de la app y el entorno revisado. Una captura de pruebas no explica necesariamente lo que recibe un usuario real. Si ciertas opciones se activan a distancia, deben quedar dentro del inventario: la recogida puede cambiar sin que aparezca una nueva versión en la tienda.

La política, los permisos y la ficha no son intercambiables

La política de privacidad de la app explica las prácticas del producto en un documento más amplio. La ficha de la tienda las presenta dentro de sus categorías. Un permiso del sistema autoriza un acceso concreto. Y las obligaciones sobre consentimiento requieren una evaluación propia.

Piensa en una foto enviada a soporte. Poder seleccionar la imagen no explica quién la recibe después ni cuánto tiempo permanece en el servicio de atención. El permiso tampoco convierte cualquier uso posterior en una decisión válida.

Por eso conviene revisar la coherencia entre estas superficies, sin tratarlas como documentos idénticos. Si el producto cambia, quizá haya que actualizar varias. Completar una ficha no es una certificación de cumplimiento legal.

Apple y Google hacen preguntas diferentes

Utiliza un inventario común, pero responde por separado. Apple distingue, entre otras cosas, datos vinculados al usuario y datos utilizados para rastreo. Google define recopilación y compartición con sus propias condiciones y excepciones. Las palabras se parecen más de lo que se parecen algunas reglas.

El tratamiento temporal es un buen ejemplo. En el formulario de Google hay que evaluar también el procesamiento efímero; bajo determinadas condiciones puede no mostrarse de la misma manera en la etiqueta pública. «No lo guardamos en nuestra base de datos» no basta para saltarse esa evaluación. Consulta la ayuda de Seguridad de los datos.

Otra confusión frecuente es equiparar un valor transformado con información anónima. Si el equipo puede volver a relacionarlo con una cuenta o un dispositivo, todavía hay una vinculación que investigar. Las definiciones de Apple son la referencia para responder a sus preguntas.

Deja anotado por qué dos respuestas difieren entre plataformas. Así, quien revise el documento más adelante no intentará igualarlas solo para que resulten visualmente consistentes.

Revisa las bibliotecas y sus ajustes, no solo sus nombres

Un SDK es una biblioteca que añade una función a la app, por ejemplo, notificaciones o diagnóstico de errores. Su comportamiento depende de los productos instalados, la versión, la configuración y los campos que tu equipo haya añadido.

La guía de Firebase para declaraciones en Apple ayuda a identificar prácticas de sus servicios. No analiza tu aplicación concreta. El desarrollador debe contrastarla con lo que está habilitado y con la información que envía el código propio.

Este trabajo también puede descubrir datos innecesarios. Para saber cuántas reservas se completan quizá baste un evento de confirmación. Añadir el texto de las observaciones del cliente requiere otra justificación y aumenta lo que debe revisarse. Primero aclara la pregunta del negocio; después decide qué información hace falta.

Las pruebas de eventos en GA4 y Firebase permiten observar una parte del recorrido. No prueban por sí solas todos los usos posteriores del dato ni reemplazan la revisión del servidor.

Comprueba qué ocurre cuando el usuario dice que no

Si presentas una función como opcional, prueba su rechazo. Empieza con una instalación nueva, observa el comportamiento antes de elegir y repite el recorrido después de desactivarla. Revisa también el cambio posterior desde los ajustes.

Importa el momento de la elección. Puede haber operaciones pendientes que se prepararon antes y se ejecutan después. El equipo necesita decidir cómo se tratan y demostrarlo; de lo contrario, dos pruebas breves podrían producir resultados distintos sin que nadie entienda la causa.

Utiliza cuentas de prueba y ejemplos sin información real de clientes. Guarda la versión, los pasos y el resultado para que otra persona pueda repetirlo. No hace falta llenar una carpeta de evidencias con conversaciones privadas.

Una grabación de red sin envíos visibles durante unos segundos no demuestra ausencia total de recogida. Revisa también las funciones poco frecuentes, los procesos diferidos y los servicios del servidor. Las pruebas observadas y la documentación se complementan.

Lleva al formulario un expediente pequeño y claro

Quien complete la ficha debería recibir el inventario acordado, las configuraciones relevantes, el enlace a la política y las dudas ya resueltas. En App Store Connect se trabaja en Privacidad de la app; en Play Console, en Seguridad de los datos dentro del contenido de la aplicación. Los nombres exactos de los menús pueden variar.

Antes de dar la tarea por terminada, revisa cómo queda la información para el público. No solo interesa que el formulario acepte las respuestas. Interesa que un cliente encuentre una explicación coherente entre la tienda, el producto y su política.

Conserva una copia de lo presentado y la fecha de revisión. Si aparece una discrepancia, podrás distinguir si cambió la aplicación, la configuración o la declaración. Esa trazabilidad evita reconstruir decisiones antiguas a partir de recuerdos.

Cuando aparece un problema, corrige la causa

Una advertencia de revisión no se resuelve necesariamente marcando más casillas. Primero identifica el flujo señalado. Si la app envía información necesaria que no estaba declarada, habrá que corregir la declaración. Si envía algo que no debería, habrá que modificar el producto. A veces hacen falta ambas cosas.

Aplica el mismo criterio a las promesas de borrado. Una opción para eliminar la cuenta debe corresponder a un proceso real y considerar los sistemas conectados. Es una experiencia que se prueba, no una frase tranquilizadora.

Para el siguiente lanzamiento, asigna un responsable de revisar los cambios en servicios y finalidades. «Revisado, sin cambios» es una conclusión útil. «Nadie lo miró porque las pantallas eran iguales» no lo es.

Si necesitas organizar esta preparación con Appfyl, puedes utilizar el brief del proyecto y adjuntar la lista de servicios y preguntas abiertas. No hace falta conocer de antemano todas las respuestas: hace falta saber cuáles faltan.

Preguntas frecuentes