Skip to content
Manos sujetando un teléfono móvil bajo luz roja y azul.

Blog

Tus datos de entrenamiento son tuyos: por qué no es obvio

· Chris · 11 min de lectura · Actualizado

En 2018, una filtración de datos afectó a 150 millones de cuentas de MyFitnessPal. Ese mismo año, el mapa de calor global de Strava hizo visibles patrones de movimiento en instalaciones militares. Y más adelante, la Comisión Federal de Comercio de Estados Unidos acusó a Flo Health de transmitir información sanitaria sensible a proveedores de análisis como Facebook y Google, pese a haber prometido lo contrario.

Son tres casos muy distintos, pero juntos muestran algo que se pierde con facilidad al comparar apps de entrenamiento:

No solo importan las funciones de una app. También importa qué datos necesita, dónde se encuentran y de qué depende tu acceso a ellos.

Qué pueden registrar realmente sobre ti las apps de fitness

Un análisis de Surfshark examinó en enero de 2026 las declaraciones de privacidad de 16 apps populares de fitness en la App Store de Apple.

En promedio, las apps declaraban 12 de los 35 tipos de datos posibles. La app que más datos utilizaba llegaba a 24.

Más importante aún es la formulación relativa a la transmisión: Surfshark informó de que el 75 % de las apps analizadas utilizaba al menos un tipo de dato para «seguimiento». Para Apple, esto incluye, entre otras cosas, vincular datos de una app sobre una persona o dispositivo con datos de otras empresas, por ejemplo, para publicidad personalizada, medición publicitaria o intermediarios de datos.

Esta descripción es más precisa que la afirmación simplificada «el 75 % vende tus datos de entrenamiento».

El estudio no afirma que todas estas apps recopilen los mismos datos ni que todas las transmisiones tengan el mismo fin. Muestra lo mucho que varía la minimización de datos dentro de una misma categoría de apps.

Según el producto, pueden tratarse, entre otros:

  • dirección de correo electrónico e identificador de usuario
  • identificador del dispositivo o publicitario
  • datos de ubicación aproximada o precisa
  • datos de entrenamiento y actividad
  • medidas corporales
  • frecuencia cardíaca u otros datos de sensores
  • fotos
  • compras e información sobre suscripciones
  • datos de uso y diagnóstico

Un diario sencillo de entrenamiento de fuerza no necesita ni mucho menos todo eso.

Tres casos muestran tres riesgos diferentes

Los problemas de privacidad se vuelven abstractos con facilidad. Los ejemplos siguientes muestran que no todos los riesgos son iguales.

MyFitnessPal: lo que está en un servidor puede formar parte de una filtración

Under Armour comunicó en marzo de 2018 que una persona no autorizada había obtenido datos de aproximadamente 150 millones de cuentas de MyFitnessPal.

Según la empresa, entre los datos afectados estaban:

  • nombres de usuario
  • direcciones de correo electrónico
  • contraseñas cifradas mediante hash

Under Armour indicó que no se vieron afectados los datos de pago ni los números de identificación oficiales.

La conclusión no es que almacenar datos en la nube sea automáticamente inseguro. Los servidores operados de forma profesional pueden estar muy bien protegidos.

La diferencia estructural es otra: los datos recopilados de forma centralizada constituyen un objetivo común para un ataque.

Strava: incluso los datos agregados pueden revelar más de lo previsto

El mapa de calor global de Strava visualizaba los datos de movimiento de muchas personas. En 2018 se hizo público que también permitía identificar patrones de carrera y movimiento alrededor de instalaciones militares.

Más adelante, el Departamento de Defensa de Estados Unidos restringió las funciones de geolocalización en zonas de operaciones.

En este caso, el problema principal no fue un ataque informático.

Los datos se habían recopilado para una función legítima. El problema surgió por lo que podía deducirse al combinar muchos puntos de ubicación aparentemente inofensivos.

Flo Health: las promesas de privacidad deben coincidir con los flujos reales de datos

La FTC acusó a Flo Health de transmitir información sensible de su app de ciclo y fertilidad a proveedores externos de análisis, aunque había dado a las usuarias otra impresión.

El caso terminó en 2021 con una orden vinculante de la FTC.

El ejemplo muestra un tercer tipo de riesgo: el robo de datos no es el único problema relevante. Los SDK legítimos de análisis y marketing también pueden crear problemas si llegan a ellos datos especialmente sensibles o si la política de privacidad no describe con claridad el flujo real de información.

¿Los datos de entrenamiento son automáticamente datos de salud según el RGPD?

Aquí conviene formular la respuesta con más precisión que un sí o un no generales.

El art. 4 n.º 15 del RGPD define los datos relativos a la salud como datos personales relacionados con la salud física o mental que revelan información sobre el estado de salud.

El Comité Europeo de Protección de Datos señala que este concepto debe interpretarse de forma amplia.

Pero eso no significa automáticamente lo siguiente:

Toda la información de una app de fitness es siempre un dato de salud conforme al art. 9 del RGPD.

Lo decisivo es qué puede deducirse de los datos sobre la salud de una persona identificable.

Algunos ejemplos evidentes son:

  • datos de frecuencia cardíaca y electrocardiograma
  • información sobre enfermedades, lesiones o medicación
  • datos corporales de los que se derive información sanitaria concreta
  • datos de actividad cuando, en el contexto correspondiente, permitan extraer conclusiones sobre un estado de salud

En cambio, una entrada aislada como «press de banca, 80 kg × 8» puede revelar mucho menos sobre la salud según el contexto.

Esta distinción es importante para quienes desarrollan apps: cuanto más sensibles sean los datos y más información sanitaria pueda deducirse de ellos, mayores serán los requisitos relativos a la base jurídica, la transparencia, la limitación de finalidad y la protección.

Una cuenta no es automáticamente un problema de privacidad

Muchas apps de entrenamiento utilizan cuentas para ofrecer sincronización entre dispositivos, funciones sociales, entrenamiento dirigido o acceso web.

Para esos fines, registrarse puede tener sentido desde el punto de vista técnico.

El problema aparece más bien cuando el registro no es necesario para la función esencial, pero la persona tampoco puede continuar sin una cuenta. En la literatura sobre experiencia de usuario, este patrón se conoce como registro forzado o patrón oscuro.

Por eso, para un diario local de entrenamiento resulta útil una pregunta sencilla:

¿Qué función concreta necesita mi identidad?

Si la respuesta es «ninguna», un modelo local sin cuenta puede ser la arquitectura que menos datos recopile.

En cambio, si quieres un feed comunitario, acceso para un entrenador o sincronización automática entre varios dispositivos, la app necesita alguna forma de identidad y estado en el servidor.

Por tanto, privacidad no significa «nube mala, local bueno».

Es una cuestión de minimización de datos y finalidad.

¿Qué ocurre si desaparece el proveedor?

Además de la privacidad, el software en la nube plantea un segundo asunto: la dependencia del servicio.

Jawbone es un ejemplo ilustrativo.

La empresa fue liquidada en 2017. Los dispositivos UP dependían en gran medida de la app y el servicio del servidor correspondientes. En 2018, la app dejó de funcionar, con lo que los dispositivos existentes ya no podían cumplir de forma útil su función principal. Algunas tiendas siguieron vendiendo unidades restantes aunque el servicio central ya se había interrumpido.

Es un ejemplo extremo, pero el principio es más general:

Si solo puedes acceder a tu historial mediante un servidor propietario, tu acceso depende de que:

  • el servicio siga funcionando,
  • tu cuenta continúe operativa,
  • la app siga siendo compatible
  • y permanezca disponible una exportación.

Un buen servicio en la nube puede reducir mucho estos riesgos mediante exportaciones, copias de seguridad y vías de migración claras.

Offline-first adopta otro enfoque: la función principal no debería existir únicamente gracias a un servidor activo.

Offline-first es más que «funciona en modo avión»

Martin Kleppmann, Adam Wiggins, Peter van Hardenberg y Mark McGranaghan describieron en 2019 el concepto de software local-first.

La idea central es que la copia local no sea solo una caché temporal de un servidor, sino la copia de trabajo principal. Los servicios en la nube pueden añadir sincronización y copias de seguridad, pero el software no depende por completo de ellos.

En una app de entrenamiento, esto tiene varias consecuencias prácticas.

El entrenamiento no espera al servidor

En un gimnasio con mala cobertura debería dar igual que una API esté disponible en ese momento.

Marcar una serie, cambiar el peso, iniciar el temporizador o guardar una marca personal son acciones que pueden realizarse localmente.

Menos datos tienen que salir del dispositivo

Si el análisis y el almacenamiento funcionan de forma local, no es necesario transmitir cada serie a un servidor central para ofrecer la función básica.

Esto reduce la cantidad de datos que deben tratarse externamente.

Una caída del servidor no bloquea automáticamente el historial

Si la base de datos local es la copia principal, los entrenamientos anteriores siguen disponibles en el dispositivo.

Es un modo de fallo distinto al de un software cuya interfaz completa solo muestra datos almacenados a distancia.

Local-first tampoco garantiza automáticamente la privacidad

En teoría, una app que funciona offline puede seguir incluyendo SDK de seguimiento o transmitir datos en cuanto haya conexión.

Además, los datos locales pueden perderse si se rompe el dispositivo y no existe una copia de seguridad.

Por eso, offline-first no sustituye una buena política de privacidad ni un sistema de copias de seguridad.

Solo desplaza el punto de partida técnico a favor del control local.

Cómo lo implementa hitPR

Yo desarrollo hitPR. La arquitectura está diseñada deliberadamente para que el entrenamiento en sí no dependa de un servidor de hitPR.

Los detalles figuran en la política de privacidad. Para el entrenamiento diario importan sobre todo los puntos siguientes.

Los datos de entrenamiento permanecen en el dispositivo

Los ejercicios, las series, los pesos, los planes y las marcas personales se guardan localmente en el dispositivo. La app funciona sin una cuenta de hitPR y sin una conexión permanente a internet.

Los informes de estadísticas y fallos son opcionales

No hay SDK publicitarios ni se crean perfiles a partir del contenido de tus entrenamientos. Las señales estadísticas y de fallos están desactivadas por defecto; si las activas, solo se procesan las señales anónimas técnicas o de uso previstas para ese fin.

Así, las series y pesos concretos no deberían convertirse en un perfil central del usuario.

La copia de seguridad en la nube es opcional

Quien activa una copia utiliza su propio espacio en la nube: iCloud o Google Drive.

La copia se cifra en el dispositivo mediante AES-256-GCM. El código de recuperación permanece en poder del usuario. hitPR no opera un servidor central de datos de entrenamiento en el que yo pueda leer tu historial.

La contrapartida también forma parte de la transparencia: quien pierde el código de recuperación pierde también la posibilidad de descifrar una copia cifrada.

Las funciones principales no necesitan la nube

El registro, el temporizador, los 8 sistemas de progresión, el mapa muscular, la detección de marcas personales, la calculadora de discos y los planes de entrenamiento funcionan localmente. Pro añade, entre otras cosas, periodos de análisis más amplios, copias de seguridad y el Watch Companion.

La exportación forma parte del control de los datos

Una copia de seguridad te permite seguir usando la misma app. Una exportación tiene otra función: sacar tus datos de la app.

Ambas son importantes.

Si una app almacena tu historial durante años, la pregunta no debería ser solo cómo introducir los datos, sino también cómo volver a extraerlos.

Cinco preguntas que dicen más que una etiqueta de privacidad

Antes de acumular varios años de entrenamiento en una app, yo comprobaría estos puntos:

  1. ¿Dónde está la copia principal de mis datos de entrenamiento? ¿En el dispositivo, en la nube o en ambos?
  2. ¿Qué funciones necesitan una cuenta y por qué?
  3. ¿Puedo exportar mi historial completo? ¿En un formato documentado y reutilizable?
  4. ¿Qué datos se envían a servicios de análisis, publicidad o fallos? ¿Son opcionales esas funciones?
  5. ¿Qué pasa si mañana desaparecen el proveedor o el servidor? ¿Puedo seguir accediendo a mis datos?

Una buena política de privacidad debería responder a estas preguntas con más claridad que un eslogan de marketing como «respetuosa con la privacidad».

Conclusión

Una app de entrenamiento no tiene que funcionar totalmente offline para tratar los datos de forma responsable. La sincronización en la nube, las funciones sociales y el entrenamiento dirigido pueden ser buenos motivos para usar servidores y cuentas.

Lo importante es otra cosa:

Una app solo debería tratar los datos que sus funciones necesitan realmente y explicar con transparencia dónde se encuentran y cómo puedes recuperarlos.

Offline-first no es un sello mágico de privacidad. Pero en un diario de entrenamiento personal es un principio de arquitectura potente: el entrenamiento funciona localmente, el historial permanece en tu dispositivo y las funciones en la nube son un complemento, no un requisito.

Más información:


Fuentes

Preguntas frecuentes

Compartir

Artículos relacionados

Próximamente

Próximamente para Android e iOS. No te pierdas el lanzamiento.

Al enviar, aceptas recibir un único aviso en el lanzamiento (puedes revocarlo cuando quieras). Política de privacidad

Análisis del sitio web

Con tu consentimiento guardamos identificadores aleatorios en tu dispositivo durante un máximo de 30 días y analizamos qué páginas se abren, de dónde vienen las visitas y cómo se usa el sitio web. Así lo mejoramos.

Detalles del análisis

Con tu consentimiento medimos páginas vistas, fuentes, clics, tiempo visible y desplazamiento para mejorar contenidos y navegación. Usamos identificadores temporales de navegador y sesión. Cloudflare procesa los datos para nosotros. El tratamiento también puede tener lugar en EE. UU., amparado por el Marco de Privacidad de Datos UE-EE. UU. y, en su defecto, por cláusulas contractuales tipo. Es voluntario y puedes retirarlo en Ajustes de análisis. El sitio funciona sin análisis.

Voluntario y revocable en cualquier momento. El sitio también funciona sin ello.