Seus dados de treino pertencem a você — por que isso não é garantido

150 milhões de contas do MyFitnessPal foram afetadas por um vazamento de dados em 2018. No mesmo ano, o mapa de calor global do Strava revelou padrões de movimentação em instalações militares. Mais tarde, a agência norte-americana FTC acusou a Flo Health de compartilhar informações sensíveis de saúde com fornecedores de análise, como Facebook e Google, apesar de promessas em contrário.

São três casos muito diferentes. Juntos, porém, mostram algo que pode passar despercebido ao comparar apps de treino:

Não são apenas os recursos de um app que importam. Também é decisivo saber quais dados ele precisa, onde esses dados ficam e de que depende seu acesso a eles.

O que os apps de fitness podem realmente registrar sobre você

Uma análise da Surfshark avaliou, em janeiro de 2026, as declarações de privacidade de 16 apps populares de fitness na App Store da Apple.

Em média, os apps declararam 12 dos 35 tipos de dados possíveis. O app que mais coletava dados chegou a 24.

Mais importante é a formulação sobre compartilhamento: a Surfshark informou que 75% dos apps analisados usam pelo menos um tipo de dado para “rastreamento”. Na definição da Apple, isso inclui vincular dados de um app sobre um usuário ou dispositivo a dados de outras empresas — por exemplo, para publicidade personalizada, medição de anúncios ou corretores de dados.

Isso é mais preciso do que a frase resumida “75% vendem seus dados de treino”.

A análise não diz que todos esses apps coletam os mesmos dados nem que todo compartilhamento tem a mesma finalidade. Ela mostra como a minimização de dados varia dentro de uma mesma categoria de apps.

Dependendo do produto, podem ser tratados, entre outros:

• endereço de e-mail e ID de usuário
• ID de dispositivo ou de publicidade
• localização aproximada ou precisa
• dados de treino e atividade
• medidas corporais
• frequência cardíaca ou outros dados de sensores
• fotos
• compras e informações de assinatura
• dados de uso e diagnóstico

Um diário simples de treino de força não precisa de tudo isso.

Três casos mostram três riscos diferentes

Problemas de privacidade podem parecer abstratos rapidamente. Os exemplos a seguir mostram que nem todo risco é igual.

MyFitnessPal: dados em um servidor podem fazer parte de um vazamento

A Under Armour informou, em março de 2018, que uma pessoa não autorizada havia obtido dados de cerca de 150 milhões de contas do MyFitnessPal.

Segundo a empresa, foram afetados, entre outros:

• nomes de usuário
• endereços de e-mail
• senhas armazenadas como hashes

De acordo com a Under Armour, dados de pagamento e números de identificação governamental não foram afetados.

O ponto não é dizer que armazenamento na nuvem seja automaticamente inseguro. Servidores administrados profissionalmente podem ser muito bem protegidos.

A diferença estrutural é outra: dados reunidos em um lugar central formam um alvo de ataque comum.

Strava: até dados agregados podem revelar mais do que o pretendido

O mapa de calor global do Strava visualizava dados de movimentação de muitos usuários. Em 2018, tornou-se público que ele também permitia identificar padrões de corrida e movimentação ao redor de instalações militares.

O Departamento de Defesa dos Estados Unidos respondeu posteriormente com restrições às funções de geolocalização em áreas de operação.

Não se tratava principalmente de uma invasão.

Os dados haviam sido coletados para uma função legítima. O problema surgiu pelo que era possível deduzir da combinação de muitos pontos de localização aparentemente inofensivos.

Flo Health: promessas de privacidade e fluxos reais de dados precisam coincidir

A FTC acusou a Flo Health de transmitir informações sensíveis do seu app de ciclo menstrual e fertilidade a fornecedores externos de análise, embora os usuários tivessem recebido uma impressão diferente.

O caso terminou, em 2021, com uma ordem vinculante da FTC.

O exemplo mostra um terceiro tipo de risco: não é apenas o roubo de dados que importa. SDKs legítimos de análise e marketing também podem gerar problemas quando informações especialmente sensíveis chegam a esses sistemas ou quando a política de privacidade não descreve corretamente o fluxo real de dados.

Dados de treino são automaticamente dados de saúde pelo RGPD?

Aqui, vale usar uma formulação mais precisa do que um sim ou não geral.

O art. 4, nº 15 do Regulamento Geral sobre a Proteção de Dados da União Europeia (RGPD) define dados de saúde como dados pessoais relativos à saúde física ou mental que revelam informações sobre o estado de saúde.

O Comitê Europeu de Proteção de Dados ressalta que esse conceito deve ser interpretado de forma ampla.

Isso, porém, não significa automaticamente:

Toda informação em um app de fitness é sempre um dado de saúde pelo art. 9 do RGPD.

O que importa é o que se pode deduzir dos dados sobre o estado de saúde de uma pessoa identificável.

Exemplos claros incluem:

• dados de frequência cardíaca e ECG
• informações sobre doenças, lesões ou medicamentos
• dados corporais dos quais se deduzem informações concretas de saúde
• dados de atividade, quando permitem conclusões sobre o estado de saúde naquele contexto

Já um registro isolado como “supino 80 kg × 8” pode, dependendo do contexto, revelar bem menos sobre a saúde.

Essa diferença importa para quem desenvolve apps: quanto mais sensíveis os dados e quanto mais informações de saúde se pode deduzir deles, maiores as exigências de base legal, transparência, limitação à finalidade e proteção.

Uma conta não é automaticamente um problema de privacidade

Muitos apps de treino usam contas para oferecer sincronização entre dispositivos, recursos sociais, orientação de treino ou acesso pela web.

Nesses casos, o login pode fazer sentido tecnicamente.

O problema tende a aparecer quando o cadastro não é necessário para a função principal, mas o usuário ainda assim não consegue continuar sem uma conta. Na literatura de experiência do usuário, esse padrão é discutido como cadastro obrigatório ou padrão manipulativo, conhecido como dark pattern.

Para um diário local de treino, uma pergunta simples ajuda:

Qual função concreta precisa da minha identidade?

Se a resposta for “nenhuma”, um modelo local sem conta pode ser uma arquitetura que exige menos dados.

Se, por outro lado, você quer um feed de comunidade, acesso para um treinador ou sincronização automática entre vários dispositivos, o app precisa de alguma forma de identidade e de informações mantidas no servidor.

Privacidade, portanto, não significa “nuvem ruim, local bom”.

É uma questão de minimização de dados e finalidade.

O que acontece se o fornecedor desaparecer?

Além da privacidade, existe uma segunda questão no software em nuvem: a dependência do serviço.

A Jawbone é um exemplo claro.

A empresa foi liquidada em 2017. Os rastreadores UP dependiam bastante do app e do serviço de servidor correspondentes. Em 2018, o app ficou inutilizável; com isso, os dispositivos existentes deixaram de cumprir adequadamente sua função principal. Alguns lojistas ainda vendiam o estoque restante, embora o serviço central já tivesse parado.

É um exemplo extremo, mas o princípio é mais geral:

Se seu histórico de treino só pode ser acessado por um servidor proprietário, o acesso depende de que:

• o serviço continue sendo operado,
• sua conta continue funcionando,
• o app continue recebendo suporte
• e a exportação continue sendo possível.

Um bom serviço na nuvem pode reduzir bastante esses riscos com exportação, backups e caminhos claros de migração.

Offline-first segue outro caminho: a função principal não deve existir apenas porque um servidor continua operando.

Offline-first é mais do que “funciona no modo avião”

Martin Kleppmann, Adam Wiggins, Peter van Hardenberg e Mark McGranaghan descreveram, em 2019, o conceito de software local-first, que dá prioridade à cópia local.

A ideia central é que a cópia local não seja apenas um cache temporário de um servidor. Ela deve ser a cópia principal de trabalho. Serviços na nuvem podem acrescentar sincronização e backup, mas o software não fica totalmente dependente deles.

Isso tem algumas consequências práticas para um app de treino.

O treino não espera pelo servidor

Em uma academia com sinal ruim, não deveria importar se uma API está acessível naquele momento.

Marcar uma série como concluída, mudar a carga, iniciar o timer, salvar um recorde — tudo isso pode acontecer localmente.

Menos dados precisam sair do dispositivo

Quando análises e armazenamento funcionam localmente, não é necessário enviar cada série a um servidor central para a função básica.

Isso reduz a quantidade de dados que precisa ser tratada externamente.

Uma falha de servidor não torna o histórico inacessível automaticamente

Quando a base de dados local é a cópia principal, os treinos anteriores continuam disponíveis no dispositivo.

É um tipo de falha diferente do que ocorre em software cuja interface inteira é apenas uma visualização de dados remotos.

Local-first ainda não é uma garantia automática de privacidade

Um app utilizável offline pode, em teoria, continuar contendo SDKs de rastreamento ou enviar dados assim que houver internet.

Dados locais também podem se perder se o dispositivo quebrar e não existir um backup.

Por isso, offline-first não substitui uma boa política de privacidade nem um plano de backup.

Ele apenas muda o ponto de partida técnico a favor do controle local.

Como o hitPR coloca isso em prática

Eu desenvolvo o hitPR. Sua arquitetura foi pensada para que o treino em si não dependa de um servidor hitPR.

Os detalhes estão na política de privacidade. Para o treino do dia a dia, estes pontos são especialmente relevantes.

Os dados de treino ficam armazenados localmente

Exercícios, séries, cargas, planos e recordes são armazenados localmente no dispositivo. O app funciona sem conta hitPR e sem conexão permanente com a internet.

Relatórios de estatísticas e falhas são opcionais

Não há SDKs de publicidade nem criação de perfis a partir do conteúdo dos seus treinos. Sinais de estatísticas e falhas ficam desativados por padrão; se você os ativar, só são tratados os sinais anônimos técnicos ou de uso previstos para isso.

As séries e cargas concretas não devem, com isso, formar um perfil central de usuário.

O backup na nuvem é opcional

Quem ativa o backup usa seu próprio armazenamento na nuvem — iCloud ou Google Drive.

A cópia é criptografada no dispositivo com AES-256-GCM. O código de recuperação fica com o usuário. O hitPR não mantém um servidor central de dados de treino no qual eu pudesse ler seu histórico.

O outro lado faz parte da transparência: quem perde o código de recuperação também perde a possibilidade de descriptografar uma cópia criptografada.

As funções principais não precisam da nuvem

Registro de treino, timer, 8 sistemas de progressão, Mapa de Calor Muscular, reconhecimento de recordes, Calculadora de Anilhas e planos de treino funcionam localmente. O Pro acrescenta, entre outras coisas, análises mais longas, backup e o Watch Companion.

A exportação faz parte do controle dos dados

Um backup mantém você operando dentro do mesmo app. Uma exportação tem outra tarefa: permitir retirar seus dados do app.

Os dois são importantes.

Se um app de treino guarda seu histórico por anos, a pergunta não deve ser apenas como entrar nele — mas também como sair depois.

Cinco perguntas que dizem mais do que uma declaração de privacidade da loja

Antes de acumular vários anos de treino em um app, eu verificaria estes pontos:

1. Onde fica a cópia principal dos meus dados de treino? Localmente, na nuvem ou nos dois?
2. Quais funções precisam de uma conta — e por quê?
3. Posso exportar meu histórico completo? Em um formato documentado que permita continuar usando os dados?
4. Quais dados são enviados a serviços de análise, publicidade ou relatórios de falha? Essas funções são opcionais?
5. O que acontece se o fornecedor ou servidor desaparecer amanhã? Consigo continuar acessando meus dados?

Uma boa política de privacidade deve responder a essas perguntas com mais clareza do que um slogan de marketing como “respeita sua privacidade”.

Conclusão

Um app de treino não precisa ser totalmente offline para tratar os dados de forma responsável. Sincronização na nuvem, recursos sociais e orientação de treino podem ser bons motivos para usar servidores e contas.

O ponto importante é outro:

Um app deve tratar apenas os dados de que suas funções realmente precisam — e explicar com transparência onde eles ficam e como você pode retirá-los depois.

Offline-first não é um selo mágico de privacidade. Mas, para um diário pessoal de treino, é um princípio de arquitetura forte: o treino funciona localmente, o histórico fica no seu dispositivo e os recursos na nuvem se tornam complementos, não condições para usar o app.

Para continuar lendo:

• Como medir o progresso no treino: 5 métodos úteis
• App de treino de força sem assinatura: ainda existe?
• Como registrar o treino: por que um diário importa

Fontes

• Surfshark (2026): Fitbit tops fitness apps in user data collection
• Under Armour / SEC (2018): MyFitnessPal data security issue
• Departamento de Defesa dos EUA (2018): dispositivos vestíveis e mapa de calor do Strava
• Departamento de Defesa dos EUA (2018): política de geolocalização em áreas de operação
• Federal Trade Commission (2021): Flo Health
• EUR-Lex: Regulamento Geral sobre a Proteção de Dados, art. 4, nº 15 e art. 9
• EDPB (2020): Guidelines 03/2020 on data concerning health
• Kleppmann M, Wiggins A, van Hardenberg P, McGranaghan M. (2019): Local-First Software
• The Guardian / Which? (2018): rastreadores Jawbone após o encerramento do app