La sección Data Safety de Google Play pide al desarrollador declarar, con bastante detalle, qué tipos de datos recopila su app, con qué finalidad, si se comparten con terceros y si el usuario puede solicitar su eliminación. Es un formulario largo y específico, y rellenarlo bien al final del desarrollo, cuando ya no se recuerda con precisión qué hace cada parte del código con los datos del usuario, es una receta segura para cometer errores por omisión. En el desarrollo de Caladero, que todavía está en curso, he adoptado la costumbre de mantener un registro de esto desde el principio, no como un trámite de última hora antes de publicar.

Qué es Data Safety y por qué importa hacerlo bien

Data Safety es la sección de la ficha de Google Play donde cada app declara su comportamiento respecto a los datos que recopila y comparte. No es un texto libre como la política de privacidad; es un formulario estructurado con categorías predefinidas (ubicación, información personal, información financiera, fotos y vídeos, entre otras) donde hay que marcar exactamente qué se recopila y con qué propósito declarado por Google (funcionalidad de la app, analítica, publicidad, prevención de fraude, entre otros). La documentación oficial y actualizada sobre cómo completar esta sección está en support.google.com, y conviene revisarla directamente porque el formulario y sus categorías han ido cambiando con el tiempo.

Lo que hace complicado este formulario no es su formato, sino la precisión que exige: declarar mal, por exceso o por defecto, qué datos recopila la app puede generar una incoherencia con el comportamiento real de la app que Google puede detectar y que, en cualquier caso, no sería una declaración honesta hacia el usuario.

Por qué dejarlo para el final es un error

Cuando se llega al final del desarrollo y hay que rellenar el formulario de una sola vez, el desarrollador tiene que reconstruir de memoria todo lo que la app hace con los datos: qué SDKs de terceros están integrados y qué datos leen, qué permisos se piden y para qué se usa cada uno realmente, qué se guarda localmente y qué se envía a algún servidor. Cuantas más funcionalidades tenga la app, más probable es olvidar algún detalle en ese ejercicio de memoria, especialmente si parte de esas decisiones se tomaron meses atrás.

El registro que mantengo desde el principio

En vez de intentar reconstruir todo esto al final, mantengo un archivo simple, actualizado a medida que añado o modifico funcionalidades que tocan datos del usuario. No es más que una tabla en Markdown dentro del propio repositorio del proyecto:

| Dato               | Se recopila | Dónde se almacena | Se comparte | Finalidad          |
|--------------------|-------------|--------------------|--------------|---------------------|
| Ubicación precisa  | Sí          | Local (Room)       | No           | Guardar punto exacto |
| Ubicación aproximada | Sí        | No se persiste      | No           | Centrar el mapa      |
| Fotos              | Sí          | Local (almacenamiento propio de la app) | No | Ilustrar un punto guardado |
| Identificador de cuenta | Pendiente | -              | -            | Pendiente de diseño de cuentas |

Cada vez que implemento una funcionalidad nueva que toca algún dato del usuario, la primera pregunta que me hago, antes de escribir código, es si esa funcionalidad cambia alguna fila de esta tabla. Esto convierte la actualización de Data Safety en un hábito continuo en vez de en una tarea puntual y estresante justo antes de publicar.

Un ejemplo concreto de cómo esto evita errores

Cuando implementé la funcionalidad de añadir una foto a un punto guardado usando el Photo Picker del sistema (que explico con detalle en el artículo sobre Android Photo Picker sin permiso de galería), pude actualizar la tabla en el momento: la app recopila la imagen que el usuario elige explícitamente, se almacena localmente en el almacenamiento propio de la app, y no requiere declarar acceso amplio a medios porque técnicamente la app nunca obtiene ese acceso. Si hubiera dejado esta anotación para el final del desarrollo, es fácil que hubiera terminado declarando un permiso de acceso a medios más amplio del que realmente se usa, simplemente por no recordar el detalle técnico de que el Photo Picker no requiere ese permiso.

Cómo esto se conecta con la política de privacidad

El registro de datos que mantengo internamente no es un documento público; es la base sobre la que después redacto y actualizo la política de privacidad pública de la app, que trato en detalle en el artículo sobre qué debe explicar la política de privacidad de una app Android. Mantener ambos documentos alineados es mucho más sencillo cuando ambos se actualizan desde la misma fuente de información interna, en vez de redactarse por separado y de memoria en momentos distintos del desarrollo.

Qué pasa con apps que todavía no están publicadas

En el caso de FishMind, que está pendiente de validación y todavía no está publicada en Google Play, el registro de datos cumple una función adicional: sirve como base para preparar el formulario de Data Safety con tiempo, antes de que llegue el momento de enviar la app a revisión, en vez de improvisarlo bajo la presión de un plazo de publicación. Esto es especialmente relevante porque el formulario de Data Safety se rellena antes de la publicación, no después, y cualquier imprecisión en esa fase puede retrasar el proceso de revisión de la app.

Errores que he evitado con este hábito

El error más frecuente que he visto (y que estuve cerca de cometer yo mismo antes de adoptar este hábito) es olvidar declarar un dato que recopila un SDK de terceros integrado en la app, como una librería de mapas o de analítica, simplemente porque ese SDK no forma parte del código propio y es fácil no pensar en él al repasar mentalmente "qué datos recopila mi app". Mantener el registro actualizado obliga a revisar explícitamente, cada vez que se integra una librería externa nueva, qué datos toca esa librería y añadir esa fila a la tabla en el mismo momento de la integración, no después.

Otro error que evito es declarar una finalidad genérica como "mejora del producto" cuando la finalidad real es más específica, como "prevención de fraude" o "personalización". El formulario de Data Safety permite y espera esa especificidad, y una declaración vaga no ayuda ni al usuario que la lee ni al propio desarrollador a la hora de auditar más adelante si el comportamiento de la app sigue coincidiendo con lo declarado.

Conclusión

Tratar Data Safety como un formulario de última hora es la forma más segura de rellenarlo mal, por olvido más que por mala intención. Mantener un registro simple y actualizado de qué datos toca cada funcionalidad, desde el primer commit relevante, convierte ese formulario en un ejercicio de copiar información ya verificada, en vez de en un ejercicio de memoria bajo presión de tiempo. Es un hábito que cuesta muy poco mantener día a día y que ahorra bastante trabajo e incertidumbre justo antes de publicar una app.