Redactar la política de privacidad de una app suele tratarse como un trámite final, algo que se rellena con una plantilla genérica sacada de internet justo antes de publicar. Mientras preparaba la documentación de Caladero, que sigo desarrollando, y pensando también en FishMind, que está pendiente de validación y todavía no está publicada en Google Play, entendí que ese enfoque de plantilla genérica no sirve de nada si el texto no refleja exactamente lo que la app hace con los datos. Una política de privacidad que no coincide con el comportamiento real de la app no protege a nadie, ni al usuario ni al propio desarrollador.
Por qué una plantilla genérica no es suficiente
El problema de copiar una plantilla es que suele incluir cláusulas sobre datos que la app ni siquiera recopila, y omitir detalles sobre datos que sí recopila pero que el autor de la plantilla no previó. Google Play exige que la política de privacidad sea coherente con la sección de Data Safety declarada en la ficha de la app (algo que trato con más detalle en el artículo sobre cómo preparo Data Safety), así que cualquier incoherencia entre lo que dice la política y lo que la app hace de verdad es, además de un problema ético, un problema de cumplimiento.
Qué datos se recopilan y con qué finalidad
La primera sección que cualquier política de privacidad debería cubrir, con precisión y sin ambigüedad, es qué datos se recopilan exactamente y para qué se usa cada uno. No basta con decir "recopilamos datos para mejorar el servicio", esa frase no informa de nada. Hay que ser específico: si la app guarda la ubicación de puntos marcados por el usuario, hay que decirlo así, explicando si esa ubicación se queda en el dispositivo o se envía a algún servidor, y en qué circunstancias.
En el caso de Caladero, dado que el almacenamiento de puntos guardados es local en el dispositivo por diseño (el enfoque que explico en el artículo sobre desarrollo local-first), la política de privacidad debe reflejar exactamente eso: que los puntos guardados no salen del dispositivo salvo que el propio usuario decida exportarlos o compartirlos explícitamente, y no puede afirmar, por ejemplo, que existe sincronización en la nube si esa funcionalidad todavía no existe.
Con quién se comparten los datos, si es que se comparten
Una política de privacidad honesta debe explicar si los datos se comparten con terceros, y con cuáles. Esto incluye servicios de análisis, proveedores de publicidad si los hubiera, o servicios de infraestructura como los que sirven mapas o teselas. Si una app usa un SDK de un proveedor externo que recibe datos del dispositivo, como puede pasar con ciertos servicios de mapas o de estadísticas de uso, ese hecho debe aparecer explícitamente, no darse por sobreentendido porque "es lo normal en cualquier app".
Si una app, como Caladero en su estado actual, no comparte datos de usuario con terceros porque no tiene integraciones de ese tipo activas todavía, la política debe decir eso mismo, en vez de incluir una cláusula genérica sobre "posibles terceros" que no aplica a la realidad del momento.
Cuánto tiempo se conservan los datos
Otra sección que muchas plantillas genéricas dejan vaga es la de retención de datos: cuánto tiempo se guardan, y qué pasa con ellos cuando el usuario deja de usar la app o solicita su eliminación. Esto conecta directamente con la funcionalidad de eliminación de cuenta, que trato en profundidad en el artículo sobre por qué la eliminación de cuenta no conviene dejarla para el final. Si la app ofrece eliminación de cuenta, la política de privacidad debe explicar qué ocurre exactamente al ejercer esa opción: si los datos se borran de inmediato, si quedan copias de seguridad temporales, y durante cuánto tiempo.
Derechos del usuario sobre sus propios datos
Dependiendo de la jurisdicción desde la que se ofrezca la app, existen derechos legales concretos sobre los datos personales: acceso, rectificación, eliminación, portabilidad. Una política de privacidad debe explicar, de forma práctica, cómo puede un usuario ejercer esos derechos: a través de una funcionalidad dentro de la propia app, escribiendo a un correo de contacto, o ambas cosas. No basta con enumerar los derechos en abstracto sin decir cómo se ejercen en la práctica.
Un ejemplo de estructura que uso
La estructura que sigo, adaptada a cada app concreta, es aproximadamente esta:
- Qué datos recopila la app, sección por sección de funcionalidad, no en un bloque genérico.
- Dónde se almacenan esos datos (local, servidor propio, servicio de terceros).
- Con quién se comparten, si es el caso, y con qué propósito concreto.
- Cuánto tiempo se conservan y qué pasa al eliminar la cuenta.
- Cómo puede el usuario ejercer sus derechos sobre sus datos.
- Datos de contacto reales para consultas de privacidad.
- Fecha de la última actualización del documento.
Este orden no es casualidad: va de lo más concreto (qué datos, exactamente) a lo más general (cómo contactar), porque lo primero que un usuario preocupado por su privacidad quiere saber es qué se recopila, no un preámbulo legal genérico.
Errores que quiero evitar
El error que más me preocupa evitar es la política de privacidad "aspiracional": redactar el documento pensando en funcionalidades futuras que todavía no existen, como si ya estuvieran implementadas. Si en algún momento Caladero incorpora sincronización en la nube, la política de privacidad se actualizará entonces, describiendo esa funcionalidad real, con fecha de actualización visible. Hasta ese momento, el documento debe describir el estado actual del desarrollo, no un roadmap.
Lo mismo aplica a FishMind: mientras esté pendiente de validación y no publicada en Google Play, cualquier documentación de privacidad asociada debe dejar claro ese estado, sin dar a entender que la app está disponible o en uso activo por parte de usuarios reales cuando todavía no es el caso.
Otro error común, que he visto en otras apps, es no actualizar la política de privacidad cuando cambia el comportamiento real de la app. Añadir una funcionalidad nueva que recopila un dato distinto sin actualizar el documento deja la política desactualizada desde el mismo momento en que se publica esa nueva versión, lo cual además de ser un problema de transparencia, puede generar inconsistencias con la sección de Data Safety de la ficha de Google Play.
Conclusión
Una política de privacidad útil no es un documento legal genérico copiado de una plantilla, es una descripción precisa y actualizada de lo que la app hace realmente con los datos de sus usuarios, en cada momento de su desarrollo. Redactarla bien exige conocer con detalle el comportamiento actual de la app, no el que se planea tener en el futuro, y actualizarla cada vez que ese comportamiento cambia. Es, en el fondo, el mismo principio de honestidad que debería aplicarse a cualquier comunicación sobre el estado real de un proyecto en desarrollo.