Personal health, fitness & sleep coach (wearables)

Smart watches, rings and phones record sleep, heart rate and activity around the clock, but most people only see dashboards of numbers they cannot interpret. An AI coach combines these time series with a language model: it explains what the data means, answers questions ("why was my HRV low this week?"), and adapts training and sleep habits to goals. It is a wellness tool, not a diagnostic one, and the line between the two is the central design and regulatory question.

Problem & value

• Today: wearable apps show scores (readiness, sleep score) with little explanation. Users combine several apps (fitness, sleep, nutrition) by hand, or pay a human coach. Generic training plans ignore illness, stress and travel.
• AI value: personalised explanations in natural language, a single view across devices, adaptive plans that react to recovery, and motivation through conversation.
• Evidence: Google researchers published a fine-tuned "Personal Health LLM" evaluated on sleep and fitness coaching case studies against expert-written answers, showing that domain-adapted models can reach expert-level answers on such tasks [1]. Real-world outcome benefits for consumers are still weakly documented; treat vendor claims on health outcomes with caution.

Variants

• Fitness and endurance coaching: load, recovery and race-plan adaptation (running, cycling).
• Sleep coaching: sleep hygiene, chronotype, shift-work scheduling; not sleep-disorder diagnosis (see HLTH-035 for clinical studies).
• Stress and recovery: HRV-based breathing and rest suggestions; wellbeing chat see CONV-009.
• Chronic-condition companion: glucose, blood pressure or heart-rhythm data, which moves into medical-device territory (see HLTH-007).
• Women's health: cycle-aware coaching, see PERS-021.
• Family and older adults: activity and fall-risk trends with consent of the monitored person.

How it works

1. wearables (watch/ring/phone)
2. vendor cloud API or on-phone health store
3. ingestion + normalisation (HealthKit / Health Connect / vendor APIs)
4. feature engineering (baselines, rolling HRV, sleep debt, training load)
5. statistical anomaly detection and rules (deterministic safety layer)
6. LLM coach with tool calls ("get_sleep(last 14 days)", "plan_week()") + user memory
7. guardrails (no diagnosis, red-flag escalation, tone)
8. app / chat / voice output; user feedback closes the loop

• Numbers come from code, not from the LLM: baselines, z-scores and load metrics are computed with classical time-series methods; the LLM calls these as tools and only narrates, which avoids invented values.
• Personal baselines: individual rolling windows matter more than population norms.
• Human-in-the-loop: the user approves plan changes; red-flag patterns (e.g. persistent resting heart-rate rise with symptoms, chest pain, fainting) trigger a "see a doctor" message, never a diagnosis. Optional sharing with a human coach or physician.

Data preparation

Data comes from wearables and phones (heart rate, HRV, sleep stages, steps, workouts), usually locked in the vendor's cloud or app, plus self-reported mood, nutrition and symptoms in notes or other apps. Typical gaps are sensor dropouts, differing definitions of sleep stages between devices, device changes that break baselines, different time zones, and missing context such as illness or travel. Preparation steps: pull data through Health Connect, Apple Health export, Gadgetbridge or the vendor's export into one local database; align timestamps and time zones; mark missing intervals instead of filling them silently; compute personal baselines over at least 2-4 weeks before any advice; and add simple tags (sick, travel, alcohol) so the coach can explain deviations. Numbers should be computed with SQL or pandas, not by the LLM. Access rights matter more than cleaning: grant each app only the data types it needs. Effort is medium, around 30-40 percent of the total, mostly the integration and baseline work. Linked preparation topics are PREP-005 for getting data out of closed systems, PREP-011 for tidy tables and PREP-022 for pseudonymisation before any cloud use.

Implementation paths

Which path for whom

• Private: A - established wearable ecosystems and coaching apps are mature and need no technical skills, but read their privacy and training-data terms first.
• Developer: C - health data is special-category data, and Gadgetbridge or Health Connect plus a local model on HW2 keeps it on own hardware; use B only for a prototype with consent and an EU region.

Path A — Buy (recommended for private users)

• Device-integrated coaches: Oura Advisor (Oura, Finland, EU), Whoop Coach, Fitbit/Google personal health coach (Gemini-based), Garmin Connect+, Samsung Health, Apple Health ecosystem.
• Third-party coaching apps: Withings (France, EU), Polar and Suunto (Finland, EU), Freeletics (Germany, EU), Runna, Ultrahuman. Check: where data is stored, whether data is used for model training, export and deletion, and whether the vendor claims medical purpose (CE-marked features are separate, e.g. ECG or AFib notifications).
• Choose A when: you want it to work today; accept the vendor's cloud and subscription.

Path B — Build on cloud APIs

• Data access: Apple HealthKit (on-device store, user-granted permissions) [2], Android Health Connect [3], vendor APIs such as Garmin Health API [4] and Oura Cloud API [5]; aggregation services exist but add a processor to your chain.
• Models: frontier LLMs with tool calling (Claude, Gemini, GPT, Mistral Large as EU provider) in EU regions where offered; send aggregated features rather than raw second-level streams.
• Pattern: compute features on the phone, send only summaries, pseudonymise identifiers, conclude a data processing agreement; no health data into model training.

Path C — Self-host (open source)

• Models: open-weight LLMs such as Qwen, Gemma, Mistral Small, Llama; medical-tuned MedGemma for health text; served with Ollama or llama.cpp / vLLM on a home server (see PERS-005).
• Data: Gadgetbridge (open-source Android app that syncs many wearables without vendor cloud), Home Assistant, a local SQLite or Postgres/TimescaleDB store, Grafana for dashboards.
• Hardware: HW1 for a small quantised model on a laptop or phone; HW2 for a comfortable 20–30B-class model. Small on-device models are enough because numbers are precomputed.
• Effort: a hobbyist weekend for a prototype; ongoing maintenance of device integrations.

Path D — Custom training

Worth it only for vendors with large consented datasets: fine-tuning on sleep and fitness case studies as in [1], or training sensor foundation models for activity and sleep staging. Needs longitudinal wearable data with ground truth (polysomnography labels, lab values), ethical approval and, for medical claims, clinical evidence. Not recommended for private users.

State of the art (2026)

• LLM plus sensor data: research models combine numeric wearable features with text reasoning and tool use; evaluation moves from multiple-choice quizzes to expert-rated coaching responses [1].
• Consumer rollout: wearable vendors have shipped LLM coaches (Oura Advisor, Whoop Coach, Fitbit/Gemini coach, Garmin Connect+), mostly as subscription features in a closed cloud.
• Open stack: on-device or home-server inference is feasible because the LLM only narrates precomputed metrics.
• Limits and failure modes:
• consumer sensors are noisy; sleep staging from wrist sensors is approximate and HRV depends on measurement conditions;
• LLMs may over-interpret noise, sound authoritative and give confident but wrong advice;
• sycophancy can reinforce unhealthy habits (over-training, calorie restriction, eating disorders);
• baselines break after illness, travel or device changes;
• no coach replaces diagnosis; orthosomnia (anxiety caused by sleep tracking) is a known risk.

Shared resources & combinations

• Same stack: time-series features and anomaly detection are shared with HLTH-007 (remote patient monitoring) and PERS-021 (cycle tracking); the LLM-on-own-data pattern with PERS-014 (lab result explainer) and PERS-005 (private home AI).
• Natural combinations: PERS-004 (nutrition and meals), PERS-017 (lifelogging context), VIS-024 (form and pose feedback from video), CONV-009 (wellbeing chat), HLTH-035 (clinical sleep studies, for referral rather than competition).
• Hardware: one HW2 home server can host this, PERS-005 and PERS-014 together.

Effort, cost & KPIs

• Path A: minutes to set up; monthly subscription typical for premium coaching features.
• Path B: 1–3 months for a polished app with integrations; costs are dominated by app development and compliance, not API tokens (summaries are small).
• Path C: a weekend for a prototype, ongoing upkeep of device sync; hardware cost of a workstation GPU or none on phone-class setups.
• KPIs: adherence (weekly active use, plan completion), subjective user ratings of insight usefulness, self-reported sleep and energy, rate of wrong or unsafe answers in red-team tests, data freshness and sync failure rate.

People & change

For private use, involve a doctor whenever the coach flags a persistent anomaly; it must never replace medical advice. Developers or companies offering such a coach need the DPO and legal-compliance from the start: health data is a special category under Art. 9 GDPR, so explicit consent, a DPIA (Art. 35 GDPR) and an AVV (Art. 28 GDPR) with every processor are expected, and medical-purpose claims can bring the product under medical-device rules. A works council is not involved for private use. If an employer offers it in a wellness programme, §87(1) no. 6 BetrVG (system suited to monitor employees) would apply and participation must be voluntary. AI literacy: AI Act Art. 4 asks organisations to support staff literacy; users should understand that insights are estimates. Communicate limits plainly: wearables are not diagnostic devices. Typical concerns are data leaving the device and over-interpretation of numbers; address them with local processing, clear consent and cautious wording. Pilot with a few weeks of own data before acting on advice. Humans stay in control: the coach suggests, the user decides. See GUIDE-005, GUIDE-006 and GUIDE-014.

Risks, regulation & compliance

• EU AI Act: usually minimal or limited risk for pure wellness coaching (chatbot transparency, Art. 50: users must know they talk to an AI). If the software has a medical purpose (diagnosis, monitoring or treatment of disease) it is a medical device under MDR and may be high-risk under the AI Act (Art. 6 with Annex I) [6][7]. Intended purpose in marketing and UI decides; MDCG 2019-11 guides qualification of software [8]. Emotion inference from biometric data in workplace or school contexts is prohibited under Art. 5; a coach used by an employer or insurer is a different case.
• GDPR: health data is special-category data (Art. 9) and needs explicit consent; privacy by design, data minimisation, deletion and export rights, no use for advertising, DPIA for vendors at scale. Insurer or employer access to coach data (wellness programmes, bonus schemes) raises discrimination and coercion concerns.
• Data Act: since 12 September 2025 users of connected products have rights to access their device data and to share it with third parties, which supports portability to independent coaches [9].
• EHDS: the European Health Data Space regulation addresses wellness apps that claim interoperability with electronic health record systems [10].
• Safety: eating-disorder and over-training risks, minors, mental-health crises; add safe-messaging rules, escalation texts and hard blocks on diagnosis and medication advice.
• Mitigations: on-device processing, aggregated summaries, clear scope statement, red-flag rules outside the LLM, logging for audit without sensitive content, regular red-teaming.

Getting started

1. Define goals (sleep, running, weight, stress) and decide what you will not accept (no diagnosis).
2. Export a month of data from your device; check the quality and gaps.
3. Try one Path A coach with a free trial and read its privacy policy and training-data terms.
4. For Path C, sync with Gadgetbridge or Health Connect into a local database, compute baselines and let a local LLM answer questions via tool calls.
5. Write a short safety test set (red-flag symptoms, extreme diets) and run it on every model change.

Sources

1. Khasentino, J. et al. — A personal health large language model for sleep and fitness coaching, Nature Medicine (2025) — https://www.nature.com/articles/s41591-025-03888-0
2. Apple — HealthKit documentation — https://developer.apple.com/documentation/healthkit
3. Android — Health Connect — https://developer.android.com/health-and-fitness/health-connect
4. Garmin — Health API — https://developer.garmin.com/gc-developer-program/
5. Oura — Cloud API documentation — https://cloud.ouraring.com/docs
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
8. MDCG 2019-11 — Guidance on qualification and classification of software — https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_11_guidance_qualification_classification_software_en_0.pdf
9. Regulation (EU) 2023/2854 (Data Act) — https://eur-lex.europa.eu/eli/reg/2023/2854/oj
10. Regulation (EU) 2025/327 (European Health Data Space) — https://eur-lex.europa.eu/eli/reg/2025/327/oj
11. Gadgetbridge project — https://gadgetbridge.org