Quando eu leio uma notícia do tipo “desativa e perde seus dados”, eu já sei que o problema não é só jurídico ou de privacidade. É engenharia de produto, consentimento e arquitetura de sincronização. Segundo o Sapo.pt, a Samsung vai ligar o Samsung Health ao treino de modelos de IA e, quem tentar desativar, pode acabar com eliminação do histórico. Para quem desenvolve (e para quem integra apps), isso acende um alerta enorme: como você preserva dados, revoga consentimento e mantém consistência entre dispositivos e contas?
O que a Samsung está fazendo (e por que isso pega em todo mundo)
O Sapo.pt descreve que a Samsung adicionou uma opção no Samsung Health chamada “Consentimento para a utilização de dados de saúde para treino e modelação de IA”. A lógica apresentada é: se você desativar, o app não sincroniza dados de saúde com sua conta Samsung; e “todas as informações serão eliminadas”, a menos que a lei obrigue a empresa a manter algum registro.
Na prática, isso significa três decisões técnicas importantes:
- Consentimento é gate de sincronização: não é “só para treino”. É “se não consentir, o ecossistema para de ter cópia na nuvem”.
- Revogação pode virar delete: a revogação do usuário não só interrompe coleta futura, mas pode acionar exclusão de dados já armazenados.
- Compartilhamento de estado entre versões/dispositivos: o consentimento também se aplica a outras versões do Samsung Health logadas na mesma conta.
Eu já vi esse padrão em vários domínios (fintech, ads, health). Ele costuma vir com boa intenção (“respeitar consentimento”), mas a execução pode ser perigosa quando a eliminação não é granular, não tem retenção mínima e não deixa claro o que fica no dispositivo local vs. o que some do servidor.
Consentimento como “feature flag” de dados: o lado técnico escondido
Do ponto de vista de sistema, o app provavelmente implementa um “flag” de consentimento que afeta:
- o pipeline de ingestão (coletores/relatórios)
- a persistência no backend (tabelas/documentos e índices)
- o job de treino (amostragem e rotulagem para modelos)
- processos de limpeza (GDPR-style delete/erasure)
O detalhe que costuma ser ignorado por quem só lê headline: “revogar” quase nunca é instantâneo. Sistemas reais têm filas, backups, replicação e caches. Então quando a Samsung fala em “será eliminado”, pode significar “será marcado para exclusão e removido do dataset principal”, mas com latência e rastros temporários (ex.: logs de auditoria, backups com retenção, métricas operacionais).
Para o usuário, “vai apagar” soa como “apaga totalmente agora”. Para o dev do lado do backend, “apagar” geralmente é “enfileirar deleção” e lidar com consistência eventual.
O que está sendo coletado (e por que isso é sensível do ponto de vista de dados)
Segundo a descrição do Sapo.pt, entram no pacote:
- padrões de sono
- registos de medicação
- histórico médico
- dados do ciclo menstrual
- nutrição e atividade (passos, medidas corporais)
- prescrições e dosagens
- para registros médicos: diagnósticos, prognósticos e resultados de exames anteriores
Se você programa, percebe rápido por que isso é “categoria especial de dados”. Não é só porque é saúde. É porque esses dados têm forte correlação temporal (mudanças ao longo do tempo) e alto poder preditivo (sono + medicação + exames → inferências clínicas). Isso aumenta as exigências de governança: criptografia, controle de acesso, segregação por tenant/conta e trilhas de auditoria.
Comparação com alternativas reais: como outras abordagens evitam o “delete total”
Na minha experiência, existem alguns modelos arquiteturais que reduzem o risco de “ou você consente, ou você perde tudo”. Exemplos de padrões que eu esperaria ver:
- Modelo A: consentimento só afeta o treino, não o armazenamento
Você continua sincronizando e preserva histórico, mas impede que dados sejam usados em pipelines de IA. Isso exige separar “armazenar” de “usar para treino”. - Modelo B: retenção mínima + delete assíncrono controlado
Ao revogar, você remove dos datasets de IA e minimiza o que vai para treinamento, mas mantém cópias operacionais/necessárias por compliance. O usuário não perde o histórico funcional. - Modelo C: local-first + sync opcional
O app mantém dados localmente e só sincroniza para nuvem se o usuário permitir. Aqui, “desativar” pode realmente impedir a cópia, mas não deveria retroativamente destruir o que já estava local. - Modelo D: dados compartimentalizados (data partitioning)
“Treino” e “histórico do usuário” ficam em partições/consentment-bound buckets diferentes. Revogação apaga só a partição de IA, mantendo a partição de histórico.
O ponto é: o comportamento descrito pelo Sapo.pt parece mais próximo do Modelo A “mal feito” ou do Modelo B “com remoção agressiva”. Se a revogação remove toda sincronização e apaga histórico, a empresa está tratando “consentimento para treino” como “consentimento para armazenar sincronizado”. Isso confunde as expectativas do usuário e aumenta atrito.
Na Prática: como um dev deve modelar consentimento sem destruir a experiência
Se eu estivesse implementando esse recurso num app (ou auditando uma API), eu desenharia consentimento com dois domínios: armazenamento e uso para IA.
Passo a passo (modelo mental para código)
- Separar flags: crie consent_health_storage e consent_health_ai_training (mesmo que a UI mostre um único texto, internamente você não deve acoplar tudo).
- Persistência independente: se o usuário tem consentimento de armazenamento/sync, continue sincronizando histórico. Se só negou treino, bloqueie apenas pipelines de IA.
- Revogação com remoção seletiva: ao desativar treino, rode um job que remove:
- feature stores
- datasets de treinamento
- vetores/embeddings derivados para IA
- Auditoria e consistência: registre quando o delete foi solicitado e quando foi efetivamente aplicado (com status).
- Backups e retenção: defina retenção curta para backups e aplique políticas de expiração; se não der, informe de forma transparente.
- UX explícito: na UI, deixe claro “isso bloqueia treino e remove dados derivados para IA, mas seu histórico permanece na conta (ou não é afetado)”.
Exemplo funcional (API) com bloqueio apenas do “treino”
async function ingestHealthEvent({ userId, event, consent }) {
// 1) Armazenar sempre que houver consentimento de sync/armazenamento
if (consent.healthStorage !== true) {
return { ok: false, reason: "healthStorage_denied" };
}
await healthEventsRepo.insert({
userId,
event,
createdAt: new Date().toISOString()
});
// 2) Treinar/derivar features apenas se consentimento de IA estiver ok
if (consent.aiTraining === true) {
// derive features e dispare pipeline de treino
await featureStoreRepo.upsertFromEvent(userId, event);
await queue.publish("health-ai-train", { userId });
}
return { ok: true };
}O “porquê” aqui é simples: você evita acoplar sincronização (funcionalidade principal do usuário) com uso de IA (finalidade adicional). Isso reduz a chance de uma decisão de privacidade virar “perdi meu histórico”.
Erros Comuns: o que devs e times de produto fazem (e por que dá ruim)
1) Acoplar consentimentos na camada errada
O erro típico é tratar um consentimento (treino) como se fosse consentimento de “sync” e “retenção”. Isso cria efeitos colaterais: a pessoa desativa por privacidade e perde o histórico que usava no dia a dia.
2) Implementar delete síncrono “prometendo apagamento total imediato”
Deletar em tempo real em ambientes distribuídos é difícil. Você pode marcar para exclusão e esperar workers processarem. Se a UI/comunicado não refletir isso, vira disputa.
3) Não ter “data lineage” (linhagem do dado)
Sem rastrear de onde veio e para onde foi (ex.: event → feature → embedding → treino), você não consegue remover seletivamente derivados. Aí o time acaba apagando mais do que precisava.
4) Cache e logs confundirem “sumiu” com “não existe mais”
Logs de auditoria e métricas operacionais podem manter identificadores por um tempo. Se isso vazar para “usuário final vê como ainda existe”, a sensação é de que “não apagaram”.
5) Não definir políticas de retenção e backup com clareza
Backup quase sempre viola a promessa de “apagamento completo imediato”. Se a política não for consistente, a empresa entra em não conformidade ou em comunicação enganosa.
Implicações práticas para quem programa (e para quem depende de saúde/dados)
Mesmo sendo um caso de consumidor, ele impacta devs por causa do padrão de consentimento que está virando comum:
- Integrações precisam lidar com mudanças de consentimento sem quebrar a experiência.
- Front-end deve refletir o que realmente muda: treino é diferente de sincronização.
- Backend precisa ser desenhado para “revogação seletiva”, não para delete nuke.
- Teste de regressão: consentimento precisa ser testado como cenário de estado (tanto revogar quanto reconsentir).
Eu testei fluxos assim em produção e uma coisa fica clara: revogação de consentimento é um “estado” que deve ser modelado no domínio. Se você trata como simples toggle, inevitavelmente vai ter inconsistência entre dispositivo, cache, filas e banco.
FAQ
1) Se a pessoa desativar, ela perde tudo no dispositivo também?
Depende do design. Pelo que o Sapo.pt descreve, o risco aparece ligado à sincronização com a conta Samsung. Em um bom sistema, o histórico local deveria ficar intacto; o problema costuma ser quando o app decide “limpar tudo” para manter coerência com a conta.
2) “Treinar a IA” exige necessariamente apagar histórico?
Não. Você pode impedir uso em pipelines de IA e manter o histórico do usuário. Apagar tudo geralmente é escolha de produto/arquitetura, não requisito técnico inevitável.
3) Como devs podem provar que revogação remove derivados (e não só eventos brutos)?
Com data lineage e jobs de remoção seletiva (feature store, embeddings, datasets de treino). Sem isso, você só “para de coletar” e não garante que os dados derivados já preparados foram apagados.
4) O que testar para não quebrar o fluxo de consentimento?
Teste: (a) consentir → sincronizar → desativar treino → verificar backend (datasets/feature store) e (b) reativar → garantir que pipelines retomem corretamente sem duplicar ou misturar dados.
Conclusão: consentimento não pode virar apagamento invisível
Segundo o Sapo.pt, a Samsung pode eliminar o histórico sincronizado quando o usuário não consentir o treino de IA. Eu entendo a necessidade de respeitar a vontade do usuário. Mas acoplar consentimento de treino a sincronização e retenção é uma forma de criar risco de perda de valor: a pessoa queria limitar IA, não necessariamente destruir o histórico que usa para saúde e acompanhamento.
Se você trabalha com software, trate isso como um caso de estudo. Consentimento é arquitetura de dados. Não é checkbox. E revogação é cenário de falha que você precisa desenhar para funcionar — sem efeito colateral destrutivo.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.