Privacy Policy

Version of 28 August 2026 · Scope: milewise.de, app.milewise.de, admin.milewise.de, the Milewise apps for iOS and Android, and the controller's electronic communication · The German version is authoritative; this is a non-binding courtesy translation.

1. Controller

The controller within the meaning of Art. 4(7) of Regulation (EU) 2016/679 (General Data Protection Regulation, “GDPR”) is:

A data protection officer has not currently been appointed. All data-protection enquiries should be directed to the contact details above.

2. General information and terms

Milewise is an AI-assisted training coach. Users connect their own training accounts (intervals.icu, Polar, Suunto and/or Strava) and may additionally share Apple Health in the iOS app; on this basis, an AI system produces individual training plans, assessments and feedback. The processing also concerns health data and thus special categories of personal data within the meaning of Art. 9(1) GDPR.

Personal data are processed exclusively in accordance with the GDPR, the German Federal Data Protection Act (BDSG) and the German TDDDG, in particular pursuant to the principles of Art. 5 GDPR (lawfulness, purpose limitation, data minimisation, storage limitation, integrity and confidentiality). No analytics, tracking or advertising services are used. Personal data are not disclosed to third parties for advertising purposes, not used for advertising profiling, and not sold. The terms used in this policy (such as “personal data”, “processing”, “processor”, “data subject”) correspond to the definitions in Art. 4 GDPR.

Whether and to what extent providing personal data is required, and what follows from not providing it, is set out separately in section 15 (Art. 13(2)(e) GDPR).

3. Overview of legal bases

• Art. 6(1)(a) GDPR: consent (waitlist, transmission of planned sessions, read access to a connected Google Calendar under section 8.1, transmission of a mobile device's calendar under section 8.3);
• Art. 9(2)(a) in conjunction with Art. 6(1)(a) GDPR: explicit consent to the processing of health data (training coaching, including the values transmitted from Apple Health under section 8; and calendar entries from a connected Google Calendar or from a mobile device's calendar in so far as they contain such information, sections 8.1 and 8.3);
• Art. 6(1)(b) GDPR: performance of a contract or pre-contractual measures (provision of the application, account management, handling of enquiries, pairing the Milewise app with the account under section 7, and handling a subscription);
• Art. 6(1)(c) GDPR: legal obligations, in particular tax-law retention duties for payment records (section 16);
• Art. 6(1)(f) GDPR: legitimate interests (technical operation, system security, defence against misuse including the control that the free trial is granted only once per connected integration (section 12)).

The applicable legal basis is stated with the respective processing operation in this policy.

4. Hosting and server log data

The services are hosted on a server operated by the controller at Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany, in a data center in Germany. A data-processing agreement pursuant to Art. 28 GDPR is in place with Hetzner Online GmbH.

On each access, the web server automatically processes the following log data: the IP address of the accessing device, date and time of access, the requested resource, the HTTP status code, the volume of data transferred, the referrer URL, and the browser and operating-system identifier. This processing serves technical operation, system security and the defence against abusive access; the legal basis is Art. 6(1)(f) GDPR. The web server's log files are rotated daily and deleted after 14 days; the application's own log output is likewise retained for 14 days. A copy of that output additionally reaches the server's general system log, which is rotated weekly and where entries are therefore held for up to five weeks before deletion. Log data are not merged with other data sets.

Independently of the web-server logs described above, the application maintains a security log (audit log). It records security-relevant events only: successful and failed sign-ins, the outcome of checking a second authentication factor, refused requests, triggered lockouts, and administrative actions. The data processed are the time, the type of event, the IP address, the route requested, the request method, a short non-secret note about the event and, where applicable, the identifier of the acting account. Passwords, credentials, session cookies and content data are not stored. The sole purpose is detecting and investigating attacks against users' accounts; the legal basis is Art. 6(1)(f) GDPR (cf. Recital 49) in conjunction with the obligation to implement appropriate technical measures under Art. 32 GDPR. Entries are deleted automatically after 30 days. If an account is deleted, the link to that account is removed from the entries (Art. 17 GDPR); the then-pseudonymous security record remains until the 30 days elapse, so that deleting an account cannot also erase the traces of an attack. What is removed is the account identifier alone; the IP address, the route, the request method and the short event note remain for the rest of the 30 days, which is why the entry is pseudonymous and not anonymous. No profiling or behavioural analysis takes place.

Alongside that log, the application keeps a short operational alert record of the notifications it sends the controller about the state of the service (a failed background job, a burst of refused requests, a sign-in to the administration interface, a deleted account). Stored per notification are its subject line, its text, its priority, a deduplication key and the time. That deduplication key can contain an IP address (for the burst notification and the one about a sign-in to the administration interface) or an account identifier (for the two notifications about a deleted account); it is what produces one notification per source rather than one per event. It exists only on the controller's own server and is never transmitted. Entries are deleted automatically after 30 days. This record has no account column, so it is not covered by the deletion that happens when an account is deleted and it is not part of the data export; what bounds it is that automatic deletion after 30 days, which is the reason the period exists. The legal basis is Art. 6(1)(f) GDPR (interest in operating the service reliably and in noticing attacks). The notification actually sent to the controller's phone carries no identifying element at all: it states what happened and refers to the administration interface, where the full entry is. It is delivered by a push service (ntfy), which therefore receives no personal data of the data subject.

Domain name resolution is provided by Cloudflare's DNS service; the content traffic of the website and the application is not routed through Cloudflare.

5. Visiting the website milewise.de

The public website is static. It sets no cookies, uses no analytics, tracking or advertising services, and loads no third-party content (third-party fonts, scripts or embedded media); this is enforced server-side by a Content Security Policy, which permits a connection to no host other than the controller's own application origin described further below.

Merely viewing the pages generates only the server log data referred to in section 4. In addition, the homepage carries a single input field that processes nothing until a visitor actively uses it: the waitlist form (section 6). It sends its input to the controller's own server, not to a third party.

The website stores no information on the visitor's device and reads none from it: it sets no cookies and uses neither localStorage nor sessionStorage. As matters stand at the date of this version, no consent pursuant to sec. 25(1) TDDDG is therefore required and no consent banner is displayed. That statement concerns the website only as it is currently built; it is reviewed and amended as soon as that changes. For the application's strictly necessary cookies, see section 7.

If the visitor already has a session in the application, the page replaces its “Request an invite” button with “Open app”. To establish this, the browser sends a single request to app.milewise.de, an origin of the same controller, transmitting the existing first-party session cookie; the response discloses only whether a session exists. No third party is involved, no additional data are stored, and if the request fails the invite button simply remains. The legal basis is Art. 6(1)(f) GDPR (interest in showing signed-in visitors the correct entry point).

6. Waitlist

Via a form on the website, the data subject may join a waitlist for access to the application. The email address, the main sport, a price preference and the language of the sign-up (“de” or “en”, taken from the page used or from the browser's language setting) are processed. The purposes are the management and allocation of access invitations and the determination of appropriate pricing for the future offering; the language is stored because the confirmation email and the later invitation email are sent in it, and there is no account and no later request of the data subject's from which it could be derived.

Registration uses a double opt-in procedure: it only becomes effective once the data subject activates the confirmation link sent by email. The time of confirmation is recorded as evidence of consent. The legal basis is consent pursuant to Art. 6(1)(a) GDPR. Confirmation and invitation links expire after 14 days, are single-use, and are stored server-side solely as a cryptographic hash (SHA-256).

Consent may be withdrawn at any time with effect for the future, and deletion of the entry may be requested (section 18). Unconfirmed entries are not contacted again; declined or archived entries are deleted automatically no later than twelve months after archiving.

7. Registration and sign-in

The application is currently available by invitation only. Registration and sign-in take place via the identity services Google, Apple (“Sign in with Apple”) or Strava using the OAuth 2.0 procedure. The controller receives and stores: from Google, the verified email address, display name and account identifier; from Apple, an account identifier that stays the same towards Milewise, the verified email address, and the name, the last of these only at the very first sign-in with that Apple account; from Strava, the athlete identifier and name. No separate password is collected. No Apple access token is stored. The authorisation scope requested from Google for the sign-in remains limited to establishing identity (“openid”, email address and profile). Access to the data subject's personal Google Calendar is not requested there; it is the subject of a separate, optional consent, given only when the data subject expressly starts it in the application, and it covers the scope “https://www.googleapis.com/auth/calendar.readonly”. That scope permits reading only; nothing is ever written to the data subject's personal calendar. Details are set out in section 8.1. Sign-in via Strava additionally requests read access to the activities of the Strava account (including private activities), and the account is simultaneously connected as a training-data source within the meaning of section 8; the access token required for this is stored in encrypted form. The legal basis for the sign-in is Art. 6(1)(b) GDPR; section 8 applies to the training data.

Sign in with Apple: two particulars, stated plainly. Where the “Hide My Email” option is chosen at Apple, Apple supplies an app-specific relay address (ending “@privaterelay.appleid.com”) instead of the person's own address. That address is stored like any other verified address and is also, for as long as no separate contact email address has been saved, the address the controller writes to. Second, a Google and an Apple sign-in that assert the same verified email address are attached to the same Milewise account, so that one person does not end up with two accounts; a relay address matches no other address, so in that case a separate account is correct. Only the sign-in identities are linked in this way; no training or health data are transmitted to Apple.

For account management, the time of last use of the application is also stored (a single timestamp per account, refreshed at most once an hour). It serves exactly one purpose: accounts that have not been used for some time no longer receive the daily automated training analysis (section 9) in advance, but only when the application is next opened. This confines the processing of health data to the periods in which it is actually used (data minimisation, Art. 5(1)(c) GDPR). There is no further evaluation of usage behaviour, no tracking of individual page views and no profiling. The legal basis is Art. 6(1)(b) GDPR; the timestamp is deleted together with the account.

Independently of the sign-in service, the data subject may save a contact email address to their profile within the application. This address is stored for the purpose of account communication (in particular sending the data export under section 18) and can be changed or removed at any time in the application. The legal basis is Art. 6(1)(b) GDPR (performance of the service).

To maintain the session, a technically necessary sign-in cookie is set (HttpOnly; validity 30 days; scope .milewise.de). During the sign-in procedure an additional short-lived security cookie (validity no more than ten minutes) is set to prevent sign-in abuse (login CSRF). Both cookies are strictly necessary within the meaning of sec. 25(2) no. 2 TDDDG. Invitation identifiers are held client-side solely in the session-bound storage (sessionStorage) of the browser and are discarded when the tab is closed.

Pairing the Milewise app. When the app for iOS or Android is connected to the account, the device receives an access credential of its own (a device token) with which the app identifies its requests. Pairing is started either in the web application, which requires a sign-in there, or directly in the app through Sign in with Apple, in which case no sign-in in the browser is required. The token itself is not stored, only its SHA-256 hash. Stored alongside it are a device name reported by the device (for example “Apple iPhone 15”), the time of pairing and the time of last use. Signing out ends every session of the account and thereby also renders paired devices ineffective; if the app itself signs out, its record is deleted. These details are deleted together with the account. The legal basis is Art. 6(1)(b) GDPR.

8. Training and health data (Art. 9 GDPR)

The core of the service is the processing of the training data the data subject provides through their own connected accounts at intervals.icu, Polar (Polar Flow / AccessLink), Suunto (Suunto Cloud API) and/or Strava. In the Milewise app for iOS, Apple Health can additionally be shared as a source; what is transmitted from there is set out in its own paragraph further down in this section. The connection is established by the data subject themselves using the OAuth 2.0 procedure and can be disconnected again at any time in the application. In particular, the data that the data subject's wearable (e.g. a Garmin, Polar or Suunto watch) transmits to those services are retrieved:

• Activity data: sport, distance, duration, pace or power, heart rate, cadence, caloric expenditure, training load, the data subject's own descriptions and notes, and GPS route data;
• Recovery and wellness data: sleep including sleep stages, heart-rate variability (HRV), resting heart rate, oxygen saturation (SpO2), subjective condition (mood, fatigue, soreness), injury information, body weight and body-fat percentage, and nutrition and fuelling records; with Polar additionally that service's recovery values (“Nightly Recharge”), daily activity and continuous heart-rate measurement; with Suunto, activity summaries (sport, start time, duration, distance, ascent, average and maximum heart rate, energy expenditure) plus, from the corresponding FIT file, GPS track, laps, power and cadence, and since 12 August 2026 also sleep and recovery data (sleep duration and stages, sleep score, heart-rate variability, lowest heart rate, oxygen saturation, recovery values). Suunto transmits those to Milewise of its own accord, and Milewise additionally retrieves them from Suunto’s 24/7 interface where that interface is enabled for Milewise; by that route, data from before the connection was made may also be processed. Where retrieval is not available, only what is transmitted after the connection was made is held. Sleep and recovery data are stored only where explicit consent to the processing of health data has been given;
• Performance profile: heart-rate zones, maximum and resting heart rate, sport-specific reference values (FTP, lactate-threshold heart rate, critical swim speed), training goals including free-text information on constraints, and strength-training records;
• the message content entered by the data subject in the coach dialogue.

Which of these are actually available depends on the source and on the data subject's device; not every source supplies every category.

Apple Health (Milewise app for iOS only, optional, off by default). The health store of an iPhone (HealthKit) cannot be read by a server: it answers only the app on the device. Where the feature is switched on in the app and the operating system's permission request is confirmed, the device itself therefore reads the following values from Apple Health and transmits them to the controller's server: sleep (total sleep, time in bed, and the split into deep, REM, core and awake phases), heart-rate variability as an SDNN value, the resting heart rate and the respiratory rate, each as one value per night. Workouts from Apple Health are not transmitted, and no location data of any kind; the raw HealthKit samples themselves never leave the device. Nights within the last 120 days are accepted; where the same night is transmitted again it replaces the value already held. Storage takes place only where the explicit consent to the processing of health data described below has been given; without it the transmission is discarded. These values are health data within the meaning of Art. 9(1) GDPR and they are included in the data export under Art. 15 GDPR. They are not currently placed before the AI coach: they are stored, but no evaluation reads them yet. Should that change, this version will be amended beforehand. Where the feature is switched off again in the app, every night transmitted by this route is deleted; the same happens when the account is reset and when it is deleted. The permission itself is granted in the device's settings and can be withdrawn there at any time.

When an intervals.icu account is connected, the athlete name held there is additionally stored so that the connected account remains recognisable within the application; the names obtained from the sign-in services are described in section 7. Independently of this, the data subject may set a freely chosen display name in the application. Towards intervals.icu and Polar, the application uses an internal, non-descriptive account number for attribution (in the form “milewise-123”); no name is transmitted for that purpose. The legal basis for these account details is Art. 6(1)(b) GDPR.

These data predominantly constitute health data within the meaning of Art. 9(1) GDPR. They are processed exclusively on the basis of two separate explicit consents pursuant to Art. 9(2)(a) in conjunction with Art. 6(1)(a) GDPR, each collected via a separate, unticked consent declaration inside the application (never bundled with the Terms of Use); the time and text version of every grant and withdrawal are logged. (1) Activity and training data (workouts, routes, heart rate during training, training zones from the connected accounts, and the maximum and resting heart rate the data subject has themselves configured in their connected account as the anchors those training zones are computed from): this consent is collected at first sign-in; its sole purpose is displaying the data subject's own dashboard, activities and trends. (2) Measured wellness and recovery data (sleep, HRV, the nightly measured resting heart rate, respiratory rate, stress, body metrics), including its transmission to the AI processors named below to operate the AI coach: this consent is collected before the first wellness source is connected, at every tier including the free one. In the web application it is asked at the Connect button for Polar, Suunto and intervals.icu, and again in the setup that follows first sign-in; it can be granted and withdrawn at any time under “You” → “Your data & privacy”. In the mobile app no Apple Health measurement and no phone calendar entry is stored without it: the server refuses the upload until the consent has been granted in that same place. When a subscription is concluded, the order page asks for it only if it is not already held; otherwise the field there is already satisfied. Measured wellness and recovery data is not collected before that consent exists; the corresponding retrievals are blocked server-side. Consents granted before 11 August 2026 covered both categories and continue to apply unchanged. Menstrual-cycle data is not processed; the separate opt-in previously provided for it was removed on 29 July 2026 and the processing discontinued entirely. Each of the two consents may be withdrawn at any time with effect for the future inside the application (You → Your data & privacy): withdrawing the wellness consent stops the AI coach, the recovery features and all automated analyses. Withdrawal also deletes the data that rested on that consent alone: the sleep, HRV, resting-heart-rate and respiratory-rate values pushed from a watch or phone (from every source, not just one) and the calendar entries pushed from a phone. This is permanent, because Apple Health and the Suunto push cannot send past nights again. The record of the consent itself (when it was given, in which version, and whether it was granted or withdrawn) is kept, because it is the evidence that the withdrawal was honoured. Withdrawing the training-data consent ends use of the application altogether until consent is given again. The lawfulness of processing carried out prior to withdrawal remains unaffected. The sole purpose of the processing is the data subject's personal training coaching. Use requires a minimum age of 18, checked at first sign-in (only the year of birth is stored). US consumers: see also the separate Consumer Health Data Privacy Policy.

8.1 Personal Google Calendar (optional, separate consent, read-only)

The data subject may additionally connect their own Google Calendar so that the AI coach can plan training around their actual commitments (exam weeks, travel, or busy periods at work, for example). This connection is optional and is not established by default. It comes about only through a separate consent, expressly started by the data subject in the application, and is separate from the sign-in described in section 7. The only additional scope requested is “https://www.googleapis.com/auth/calendar.readonly”; alongside it the identity scopes already named in section 7 (“openid”, email address and profile) are requested again, so Google's consent screen names those as well. That calendar scope is read access only: nothing is ever written to the data subject's personal calendar, and no entry there is created, changed or deleted. The transmission of planned training sessions described in section 11 concerns the calendar of the intervals.icu account only and is a separate feature.

What is read, per event: the calendar name, the event title, the date, start and end time, and whether the event is an all-day event. Events without a title appear as “(busy)”. Cancelled events, events marked as “free” (birthdays and holidays, for example), events the data subject has themselves declined, and events Google classifies as birthday or working-location entries are not evaluated. Structured information about other attendees (names, email addresses and their acceptances or refusals) is not collected: an event's attendee list is evaluated solely to establish whether the data subject themselves accepted or declined, and it does not leave Google. An event title can nonetheless name other people; see “Information about other people in event titles” below. Retrieval covers the coming 14 days by default, 90 days at most, and no more than 120 events per retrieval.

No store of Google Calendar data, but part of the conversation transcript. The calendar entries are retrieved from Google live, as and when a request to the coach requires it; each read happens at the moment the coach needs the information. For the Google Calendar no separate store is created: the entries read there are not written to a table of their own, and calendar entries are not written to the response cache. That does not hold for a mobile device's calendar: that one is stored, because it cannot be read any other way, and section 8.3 describes it in full. An automated read does take place once a day, without any action by the data subject: where the daily morning briefing is switched on, it reads the calendar for that one day so it can take the day’s commitments into account. Only the resulting free and busy times enter the briefing; the entries themselves are not stored, and where the briefing is switched off no automated read occurs. One exception must be named: where a saved training session falls on a day the calendar leaves no room for, or begins too shortly before the following day's first commitment, an internal note is written to the controller's coach event log recording the date, the planned session and the times concerned, without any event title. It is held while it remains among the most recent entries of that log, is included in the data export under Art. 15 GDPR and is deleted with the account; deleting a single conversation does not reach it, and the retention period for conversations does not apply to it. The entries that were read, event titles included, do however become part of the transcript of the conversation in which they were retrieved, exactly like every other result the coach looks up. They are stored there for as long as that conversation exists, they are included in the data export under Art. 15 GDPR, and they are therefore present in backups of that database (section 16). There is no separate retention period for calendar data; the retention period for conversations under section 16 applies. Deleting the conversation in the application deletes the entries it contains along with it, as does deletion of the account. Not all of the information listed above is passed on to the AI processor active at the time under section 9, but only what the planning requires: the entries retrieved are first reduced, per day, to how many hours are committed and which time windows are actually free for training. What is then transmitted is those daily figures (date, committed hours, free windows, the start of the following day) together with the event titles, the latter capped at eight titles per day plus four all-day entries. The calendar name is not transmitted; it is named only where a selected calendar could not be read. The individual entries are not passed on as such: their start and end times feed only into the calculation of committed hours and free windows, from which the timing of commitments may nonetheless be inferred indirectly, and the sole time transmitted expressly is the start of the following day's first commitment. The purpose is to let the coach build the training plan around those commitments; otherwise the statements made in section 9 apply, including those on storage for abuse detection. The AI providers are contractually barred from using these data for their own purposes and from training models on them.

Control by the data subject. The application lets the data subject choose which calendars of the connected account the coach may read; without such a choice it is all calendars of that account. The connection can be disconnected at any time in the application. Disconnecting deletes the stored authorisation, the calendar selection and the record of which Google account was connected, and at the same time revokes the authorisation at Google, so that it no longer exists in the data subject's own Google account either; the same happens automatically before a Milewise account is deleted. Revocation at Google is performed by calling an interface Google provides, and is an obligation of conduct, not of result: deletion on the Milewise side happens in every case; the revocation request is sent once, provided a revocable token is still stored for the connection, its outcome is not checked technically and not repeated, and the data subject is not separately notified of a failure. Should Google not act on it, the authorisation can remain listed in the data subject's own Google account, and it can be removed there at any time (Google Account → Security → Your connections to third-party apps and services). For as long as the connection exists, all that belongs to it is the encrypted authorisation (token), the calendar selection and the email address of the connected Google account; a separate store of Google Calendar entries is not part of it. Disconnecting stops all future reads, but it does not retroactively remove event titles that are already present in past conversation transcripts; those are deleted when the conversation in question, or the account, is deleted (previous paragraph and section 16).

Stated plainly: event titles can contain special categories of personal data. A calendar entry can name a doctor's appointment, a therapy session, a religious observance or a meeting with a lawyer, and thus contain information within the meaning of Art. 9(1) GDPR that is not entered by the data subject but taken from a third-party source. There is no prior screening of content, no redaction of event titles and no keyword filtering; the choice of which calendars are shared is the means by which the data subject determines the scope. The legal basis for reading the calendar is the separate consent under Art. 6(1)(a) GDPR, initiated in the application and declared on Google's consent screen; it can be withdrawn at any time with effect for the future by disconnecting. Reading additionally presupposes the explicit health-data consent given under section 8: without it the AI coach carries out no processing at all and therefore reads no calendar, so withdrawing that consent ends calendar reading together with all other coaching. In so far as an entry contains information within the meaning of Art. 9(1) GDPR, connecting the calendar in knowledge of the above is the explicit consent under Art. 9(2)(a) GDPR covering it.

Information about other people in event titles. This paragraph applies to both calendars, the Google Calendar under this section and a mobile device's calendar under section 8.3. The title of an event is written by whoever created it, and it frequently names other people (“Appointment Dr. Schmidt” or “Anna's wedding”, for example). To that extent Milewise also processes personal data of people who did not provide those data themselves. As described above, an event's attendee list is not collected, so neither email addresses nor those people's acceptances or refusals are processed; a name given in the title may nonetheless be transmitted. Notifying those people under Art. 14 GDPR is not possible for Milewise: no contact details are held, a person cannot be identified from a free-text fragment (Art. 11 GDPR), and establishing their identity would require considerably more data than are processed at all. Milewise therefore relies on Art. 14(5)(b) GDPR and makes the information required there available through this publicly accessible statement. Anyone wishing to limit the scope can use the calendar selection to determine which calendars are read, or disconnect the connection.

8.2 Limited Use: statement on the use of Google Workspace data

Milewise affirms: “The use of raw or derived user data received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements.”

For the calendar data read pursuant to section 8.1 this means, concretely:

• They are used solely to provide the feature the data subject asked for, namely placing training around their actual commitments.
• They are not used, transferred or sold to create, train or improve artificial intelligence or machine learning models. This applies expressly to the processors named in section 9: the data are processed there as context at the moment of the request and are not used for training.
• Storage for abuse detection is the exception, described separately and in full in section 9. With the Azure OpenAI Service, content flagged as potentially abusive may be placed in a segregated store and reviewed by authorised Microsoft personnel; the controller can neither inspect nor delete that store. This happens solely for security purposes and never for training, and it therefore falls within the security exception Google expressly permits.
• They are not used for advertising and are not sold to third parties.
• Humans do not read them, other than in the cases Google permits: with the data subject's prior affirmative agreement, where necessary for security purposes (for example investigating a bug or abuse, see the abuse detection above), where necessary to comply with applicable law, or where the data are aggregated and used for internal operations.

8.3 A mobile device's calendar (Milewise app only, optional, off by default)

Why this calendar is stored and the Google Calendar is not. An iPhone's calendar cannot be read by a server: the operating system answers only the app on the device. So that the coach still knows when the data subject has time hours after the app was last opened, the app transmits the entries to the server, and there they are stored. For the Google Calendar this is not necessary, because it can be retrieved at the moment of the request (section 8.1). The feature is optional, off by default, and additionally requires the operating system's calendar permission, which can be withdrawn in its settings at any time.

What is stored. Per entry: the date, start and end, whether it is an all-day entry, and the event title. These items are held in a table of their own in the coach database. What is not transmitted: locations, attendees, descriptions, organisers and conferencing links. Transmitted are the entries from every calendar the app is allowed to access on the device and that has not been deselected as described in the next paragraph, from the current day and by default 14 days, at most 90 days ahead, and no more than 400 entries per transmission.

Also transmitted and stored: the list of calendars. So that the choice of which calendars are shared can be offered in a browser and not only on the phone, the app transmits, separately from the entries, a list of the calendars it can see on the device. Stored per calendar are the name of the calendar (“Personal”, “Work”, or the name of a shared family calendar for example) and the identifier assigned by the operating system, which is meaningless to us, for at most 60 calendars. No entries are contained in it. These items are held in the account's settings, not in the table of entries. A calendar name, too, is free text written by third parties and can itself suggest information within the meaning of Art. 9(1) GDPR; here as well there is no prior screening of content.

Choosing which calendars are shared. From that list, the application lets the data subject choose which calendars of the device may be read. Without such a choice it is every calendar the app is allowed to access; an empty choice means none. The choice takes effect the next time the app is opened and transmits, because only the device can read its calendar; the entries of a deselected calendar fall away with that next transmission.

Every transmission replaces, it does not add. For each day the app reports, what is held for that day is deleted first. An entry deleted on the device therefore disappears here with the next transmission. Future entries remain stored until the next transmission replaces them, until the feature is switched off in the app, or until the account is reset or deleted. Past days are deleted automatically: a sweep that runs once a day removes every day more than three days old. Those three days are not a retention interest but a tolerance for a shifted clock, a late transmission and a date line crossed since the last synchronisation; a past day is never read in any case.

Erasure and access. Switching the feature off, in the app or in the web application, deletes every stored entry immediately and in full, and with it the list of calendars and the choice; the same happens when the consent under section 8 is withdrawn, when the account is reset and when it is deleted. The stored entries are included in the data export under Art. 15 GDPR and are therefore also present in backups of the database (section 16).

What the AI coach receives from it. Both calendars are summarised in the same way before anything is transmitted to the AI processor under section 9: what is transmitted is, per day, the date, the committed hours, the free windows and the start of the following day's first commitment, together with the event titles, the latter capped at eight titles per day plus four all-day entries. Where the daily morning briefing is switched on, the stored entries for that day are used for it in the same summarised form; no retrieval from the device takes place for this, because the entries are already stored here. As with every other result the coach looks up, the information used becomes part of the transcript of the conversation in which it was used (sections 8.1 and 16).

Legal basis. An event title can contain information within the meaning of Art. 9(1) GDPR, a doctor's or therapy appointment or a religious observance for example, and it can name other people; the paragraph “Information about other people in event titles” in section 8.1 applies unchanged. There is no prior screening of content, no redaction and no keyword filtering. Entries are therefore stored only where the explicit consent to the processing of health data under section 8 has been given: the legal basis is Art. 9(2)(a) in conjunction with Art. 6(1)(a) GDPR. Without that consent a transmission of entries is discarded and no entry is stored. This does not apply to the list of calendars: it contains no entries and is stored without that consent as well, because the choice would otherwise have to be made from an empty list. Its legal basis is Art. 6(1)(b) GDPR (performance of the contract of use, namely making that choice usable) and Art. 6(1)(f) GDPR (the legitimate interest in offering the same choice on both surfaces); it is erased as set out under “Erasure and access”. Withdrawal is effected by switching the feature off in the app or by withdrawing the consent in the application; it takes effect for the future and leaves the lawfulness of the processing carried out until then unaffected.

9. AI coach and automated processing

The coaching outputs are generated by a large language model run by one or more of the processors listed below. All of these providers are bound by data-processing terms pursuant to Art. 28 GDPR and are connected exclusively via service routes with data-residency guarantees in the European Union; endpoints or regions without such guarantees are not technically permitted. Which of the listed providers are actually used depends on the controller's configuration; at present only Mistral AI SAS and Microsoft Ireland Operations Ltd. (Azure OpenAI Service) receive data. For Amazon Web Services EMEA SARL and Google Cloud EMEA Ltd. access credentials are held, but neither is currently assigned any model, so no data flow to them.

• Mistral AI SAS, 15 rue des Halles, 75001 Paris, France (“la Plateforme”): processing takes place on servers within the European Union by default. Mistral notes that, depending on the feature used, data can be temporarily transferred to sub-processors established outside the European Union; such transfers take place on the basis of standard contractual clauses (Art. 46(2)(c) GDPR).
• Microsoft Ireland Operations Ltd. (Azure OpenAI Service, deployment type “Data Zone Standard”/EU): prompts and outputs are processed exclusively within the Microsoft EU Data Boundary (the European Union plus Norway and Switzerland; both countries are covered by adequacy decisions pursuant to Art. 45 GDPR).
• Amazon Web Services EMEA SARL (AWS Bedrock, EU inference profile): processing and storage take place exclusively in regions in EU member states (Frankfurt, Stockholm, Milan, Spain, Ireland, Paris).
• Google Cloud EMEA Ltd. (Vertex AI, EU multi-region): ML processing stays within the European Union (EU member states only).

Storage for abuse detection. Two of the processors store inputs and outputs for a limited time under defined conditions in order to detect misuse of their services. With the Azure OpenAI Service, every request is classified automatically in real time without being stored; only content flagged as potentially abusive in that process may be placed in a separate, customer-segregated store, where authorised Microsoft employees may review it. That store is located inside the Microsoft EU Data Boundary, and for models deployed in the European Economic Area the reviewing personnel are located in the European Economic Area. Switching this abuse monitoring off requires Microsoft-managed enterprise customer status and is therefore not available to the controller; a corresponding application was denied on 29 July 2026. With Mistral AI, Zero Data Retention has been activated for the interfaces we use (since 29 July 2026): inputs and outputs are not stored or logged for longer than strictly necessary to generate the response. Without it the default would be 30 rolling days. With Amazon Web Services (AWS Bedrock), inputs and outputs are not stored by default and are not accessible to service operators. The controller can neither inspect these provider-side processes nor delete the content held there; they serve security and abuse prevention only and are not used to train the models.

Depending on the request, the following are transmitted to the processor active at the time: the conversation history, the performance profile, active training goals, the training plan, coach notes, the training and health data retrieved by the coach's tools pursuant to section 8, and contextual information such as weather data, the approximate location pursuant to section 10 where available, and, where a personal Google Calendar is connected, the calendar entries read pursuant to section 8.1. An internal, non-descriptive account number is used for attribution; name and email address are not transmitted.

In the dialogue, the data subject always communicates with an AI system and never with a human; this notice is provided in implementation of Art. 50 of Regulation (EU) 2024/1689 (AI Act).

The following processing operations are triggered automatically, without direct action by the data subject:

• a daily morning readiness assessment based on sleep, HRV and resting-heart-rate values; it can be disabled in the settings;
• automatic feedback on completed activities retrieved from the connected data sources (push notification from Strava or intervals.icu, or periodic retrieval);
• an internal daily evaluation of readiness and training load, and the automatic naming of conversations.

No decision based solely on automated processing that produces legal effects concerning the data subject or similarly significantly affects them (Art. 22 GDPR) takes place; all of the coach's recommendations are non-binding and may be ignored or amended at any time. Milewise does not provide medical advice; medical advice should be sought for health complaints or questions.

10. Location estimation, weather and maps

To provide location-based weather data and the correct time zone, the application determines an approximate location of the data subject. It is estimated from the start points of the retrieved activities; alternatively, the data subject may set a position manually. An approximate home area is also derived from the activity data. The determined location can be viewed in the application's settings; automatic updating can be disabled and a manual position set instead. No positioning via third-party services or browser permissions takes place. The legal basis is consent pursuant to Art. 9(2)(a) in conjunction with Art. 6(1)(a) GDPR (section 8), as the location is derived from the activity data.

• For weather and time zone, rounded coordinates without any name or account reference are transmitted to MET Norway (api.met.no, Norway/EEA) and Open-Meteo; for the display of a place name, rounded coordinates are transmitted to OpenStreetMap Nominatim.
• Map displays in the web application load map tiles directly from servers of OpenFreeMap (Hyperknot Software Kft., Hungary); the map server thereby technically receives the data subject's IP address and the map section displayed. The map data shown come from OpenStreetMap. Until 27 August 2026 these tiles were obtained from CARTO Inc. (USA).
• In the apps it is different: the iOS app displays maps through the operating system's own map component, so the map data there come from Apple and not from OpenFreeMap. The Android app draws an activity's route on the device itself from its coordinates and loads no map for that. The map used to choose a home location does, however, use the operating system's map component there too, which obtains its map data from Google.

11. Transmission of planned training sessions (optional, enabled by default once intervals.icu is connected)

While the setting “Send workouts to your watch” is enabled, the application transmits planned training sessions to the calendar of the data subject's intervals.icu account; from there, intervals.icu synchronises the sessions to a connected Garmin watch. Since 5 August 2026 that setting is enabled by default from the moment the intervals.icu account is connected, and no longer disabled by default as it was before: connecting is itself the deliberate act, and the intervals.icu consent screen names the calendar write permission (“CALENDAR:WRITE”) expressly. The default does not apply in three cases: where the data subject has already operated the setting themselves, in either direction (so reconnecting does not change their decision); where the calendar write permission was not granted; and where intervals.icu reported no permissions at all. It can be disabled in the application at any time, whereupon transmitted future sessions are removed again. The legal basis is the consent (Art. 6(1)(a) GDPR) given by connecting the intervals.icu account including the calendar write permission, which may be withdrawn at any time with effect for the future by disabling the setting.

11.1 The other outbound writes (training settings, Polar registration, SuuntoPlus guides)

The planned-workout push above is not the only write Milewise makes to an external service. There are several, and the other three that are always available are:

• Planned sessions written to Suunto (“SuuntoPlus guides”). Where a Suunto account is connected and “Send workouts to your watch” is enabled for Suunto, Milewise sends a planned session to the data subject’s Suunto account as a structured workout template. Only the session name, its date, the sport and the step sequence with durations and heart-rate ranges are transmitted; no further personal content is sent, in particular no health data and no internal notes. The transfer to the watch itself is not automatic: it happens only when the data subject selects the template in the Suunto App and synchronises it with their watch. The setting can be switched off at any time, and Milewise deletes the template again when the session is completed, removed or deleted.
• Training settings written to intervals.icu (heart-rate zones and FTP). Milewise computes the data subject’s training zones itself from their maximum and resting heart rate and writes those five zone boundaries onto the sport settings of their intervals.icu account (permission “SETTINGS:WRITE”, requested on the same consent screen as the calendar write). Since 12 August 2026 the setting “Sync my HR zones and FTP” is enabled by default from the moment the intervals.icu account is connected; it is not enabled where the data subject has already operated it themselves, in either direction. This overwrites the zone configuration held there and is repeated by the periodic background job whenever the computed zones change. Under the same setting, a functional threshold power (FTP) value is also written to those sport settings, but only where the data subject entered it themselves in the application; an FTP value that was read from intervals.icu in the first place is never written back. It can be switched off in the application, whereupon nothing further is written; values already written are not reverted. The legal basis is the consent given by connecting the intervals.icu account including that permission (Art. 6(1)(a) GDPR).
• Registration and de-registration with Polar. Connecting a Polar account requires registering the data subject with Polar’s AccessLink service; Milewise transmits only an internal, non-descriptive account number (for example “milewise-123”) for this purpose, never a name or an email address. Disconnecting Polar, and deleting the Milewise account, de-register that number again. The legal basis is the performance of the contract (Art. 6(1)(b) GDPR).

Beyond these three, data are written to a connected training service only through the two settings described in section 11.4, namely sending an activity on and naming an activity from the training plan. Both are off by default and take effect only once switched on. Every other connection to such a service is read-only. Processing by the AI providers (section 9) and the email delivery provider (section 13) is unaffected and is described there.

11.2 The calendar subscription (optional, off by default)

Data subjects may switch on a calendar subscription: a personal, read-only link that their own calendar application can subscribe to, containing their completed workouts and their planned sessions. It is disabled by default and exists only after it has been switched on in the application.

Two consequences follow, and they are stated here because they are the point of the feature. First, the calendar application the data subject uses fetches that link from its own servers; where that application is operated by a third party (for example Google or Apple), that provider thereby receives the workout titles, times and distances contained in the link, as a consequence of the data subject’s own decision to subscribe. Milewise transmits nothing to it and has no relationship with it. Second, the link itself is the credential: anyone who has it can read that calendar. It can be replaced with a new one, or switched off entirely, at any time in the application, which immediately invalidates the previous link. Only a cryptographic fingerprint of the link is stored, so it cannot be shown again after it is created. Activities that originate solely from Strava are excluded from the link. The legal basis is consent (Art. 6(1)(a) GDPR), given by switching the subscription on and withdrawable by switching it off.

11.3 Workout files uploaded by the data subject

The data subject may upload a workout file (FIT, TCX or GPX, up to 16 MB, also gzipped) in the application. In that case Milewise stores the file itself, unchanged, together with the training data read out of it (sport, start time, duration, distance, elevation, heart rate, cadence, power and, where the file contains one, the route). The file and the data read from it are stored in the application database, are included in the data export under Art. 15/20 GDPR, and are erased together with the account. Uploading the same file a second time updates the existing activity instead of creating a second one; the activity is identified by a cryptographic fingerprint of the file.

Such an activity differs from the others in one legally relevant respect: it does not reach Milewise through a platform’s interface and is therefore not subject to that platform’s terms. It may accordingly be used by the AI coach, may be combined with the same session recorded elsewhere, and may – only if the data subject switches the corresponding setting on – be transmitted to another service. The legal basis is the consent given by uploading (Art. 6(1)(a) and Art. 9(2)(a) GDPR, the latter because a workout file regularly contains heart-rate data), withdrawable at any time by deleting the activity or the account.

11.4 Transmission of activities to another service, and naming them (both off by default)

Two further settings exist per connected service, both disabled by default.

• Sending activities on. While enabled, a workout held by Milewise is uploaded to that service if it is not already present there. Whether it is already present is checked first, including for copies that reached the service through the data subject’s own synchronisation between two platforms, so that no duplicate is created. Only services whose interface accepts a workout can receive one; at present these are intervals.icu and Strava. Strava can receive an activity but can never be the source of one, because Strava’s API terms prohibit passing their data to a third party; this is enforced in the software and not by a setting. In practice, therefore, the activities transmitted are those the data subject uploaded themselves (11.3).
• Naming activities from the training plan. While enabled, an activity that completed a planned session is renamed on that service to the title of that session, and its description is set to the training steps of that session followed by a line naming Milewise. If the data subject subsequently renames or rewrites the activity themselves, Milewise does not overwrite it again. Where no planned session applies, the name and description of the recording service are carried over to the copies on the other services.

For Strava both settings additionally require a separate permission to edit activities (“activity:write”). Connecting or signing in with Strava requests this permission together with the others, on Strava’s own consent screen, where it is listed separately and can be declined. It is requested at that point so that switching a setting on later does not require a second trip through Strava. Granting it does not switch anything on: both settings are off unless the data subject switches them on, and no activity is written to Strava before that. Declining it leaves everything Milewise reads from Strava unaffected; only these two settings remain unavailable. Milewise records, for each activity, on which services a copy exists, whether that copy was created by Milewise or was already there, and what text was last written to it. A copy that Milewise did not create is never deleted by Milewise. The legal basis for both is consent (Art. 6(1)(a) GDPR, and Art. 9(2)(a) GDPR in so far as the transmitted workout contains heart-rate data), given by switching the setting on and withdrawable at any time by switching it off, with effect for the future. Data already transmitted remains with the receiving service and can be deleted there.

12. Payment processing, subscription and free trial

As at the date of this version, the ordering process is open in the application. Where an order is placed, payment data are processed from that moment on by the entities named below. Without an order being placed, no payment data about the data subject arise at those entities. What follows sets out in full what happens when an order is placed, so that the decision can be taken in knowledge of it.

Payments are processed exclusively through Stripe using its “Managed Payments” arrangement. Two entities are involved, with different roles:

• Stripe Technology Europe, Limited, 25/28 North Wall Quay, Dublin 1, Ireland (Irish company registration number 0599050): the controller's contracting party for the payment account and the operator of the payment processing.
• “Sold through Link, LLC”, United States of America: the merchant of record and therefore the seller of the subscription to the customer. This is why the receipt and the bank statement show “Sold through Link” and the descriptor “LINK.COM* MILEWISE.DE”.

On the roles, stated plainly. Stripe's own data-processing terms are expressly split: for part of the payment services Stripe acts as a processor under Art. 28 GDPR, and for another part (in particular fraud prevention, anti-money-laundering and regulatory duties, and its own accounting) as an independent controller with its own purposes. In so far as “Sold through Link, LLC” acts as the seller of the subscription, the controller takes the view that this entity is an independent controller within the meaning of Art. 4(7) GDPR for the sale itself, and not the controller's processor. This is stated here because it makes a difference to the data subject's rights: matters concerning that part of the processing must also be raised directly with that entity. The allocation of data-protection roles under “Managed Payments” is not settled in every respect; it is kept under review and this policy will be corrected if required.

Data processed. The data required for payment arise at Stripe: name, email address, billing address and country, the payment-method details, amount, time and status of the subscription, and technical data for fraud prevention (including IP address and device information). Full payment-method details (such as card numbers) are entered directly with Stripe and are not visible to the controller. The controller receives only what it needs for accounting and for unlocking the service: the status and period of the subscription, a customer identifier and the invoice details. No training or health data are transmitted to Stripe or to Link, LLC.

The legal bases are Art. 6(1)(b) GDPR (performance of the subscription contract), Art. 6(1)(c) GDPR (tax-law retention duties, section 16) and Art. 6(1)(f) GDPR (fraud prevention and securing payment).

Third-country transfer (Art. 13(1)(f) GDPR). As “Sold through Link, LLC” is established in the United States, the transaction data are transferred to a third country. The transfer relies on the adequacy decision concerning the EU-U.S. Data Privacy Framework (Art. 45 GDPR), in which Stripe participates as a certified organisation; in so far as a transfer is not covered by it, the standard contractual clauses under Art. 46(2)(c) GDPR contained in Stripe's data-protection agreement apply. A copy of, or evidence of, those safeguards can be requested at contact@milewise.de.

12.1 The free trial: the record that prevents repeat use

The free trial (the details are in section 9 of the Terms of Use) may be taken only once per connected integration. An integration here means every connected data source and additionally the account used to sign in (Google, Apple or Strava, section 7). The trial requires at least one connected data source; without one there is nothing to bind the one-time rule to. So that the limit cannot be circumvented by deleting the Milewise account and creating a new one, one record per connected integration survives deletion of the account. What that record contains, what it does not contain, and what can be done with it is set out in full below.

What is stored. Where an order is completed and a trial was in fact granted with it, one record is written for each integration connected at that moment, consisting of exactly three items:

• a one-way value (salted hash, HMAC-SHA256) of the identifier of that integration, that is, the identifier under which the account is held at intervals.icu, Strava, Polar or Suunto (their athlete identifier, for instance), or under which the sign-in with Google, Apple or Strava takes place;
• the name of the integration (intervals.icu, Strava, Polar, Suunto, Google or Apple);
• the date on which the trial was granted, to the calendar day and without a time.

The record is written only when the ordering process is completed, not when it begins: anyone who abandons the order leaves no such record behind, and neither does anyone who orders without a trial.

What is not stored. The record contains no Milewise account identifier, no email address, no name, no IP address and no training or health data. It is not linked to any other stored item.

What it can and cannot do. The one-way value cannot be computed back into the identifier it was derived from; the secret additional value used in the calculation (the “salt”) never leaves the server, which prevents the set from being reproduced from a list of other people's identifiers. The record can answer exactly one question: “has this integration already had a trial?” It is answered by recomputing the value from a currently connected integration and comparing it with the set. If any of the connected integrations has already had a trial, no further trial is granted, but a subscription can still be taken out exactly as before. It is pseudonymous, not anonymous: a one-way hash of a stable account identifier could in principle be re-checked against a known identifier, so we treat it as personal data and rely on Art. 6(1)(f). What it cannot do is identify or contact anyone by itself: it holds no contact detail, and once the account has been deleted the controller no longer holds the corresponding identifier, so there is nothing left against which the value could be resolved. Stated plainly, that holds with one qualification: where the same person later signs in again with the same Google, Apple or Strava account, or connects the same data source again, the value can be recomputed from the identifier then available again and matched against the set. The record itself still holds no content and no contact detail; it is computed and compared solely for this one check, not for advertising, not for profiling and not for any analysis of usage behaviour, and it is disclosed to no one.

Legal basis and balancing (Art. 6(1)(f) GDPR). The legal basis is the legitimate interest in preventing repeated use of a one-time free service. The balancing is disclosed here rather than merely asserted:

• The interest is the prevention of abuse; recital 47 names fraud prevention expressly as a legitimate interest. Every trial causes real AI processing costs. Without the limit, the same person could use the paid service free of charge without end, and a trial could not be offered at all.
• Necessity: there is no less intrusive means that is equally effective. If the record were deleted with the account, the limit would be worthless, because a new account can be created with the same integration any number of times. Tying the limit to the email address would be both more identifying and easier to evade. Keeping the integration's identifier in the clear is not necessary for the purpose, which is why only the one-way value is stored. This is the most data-minimising implementation that achieves the purpose at all.
• The impact on the data subject is minimal: the record holds no content, is not attributable to a person by itself (for the qualification where someone signs in again, see above), is evaluated for no other purpose, and restricts nobody's use of the service. Anyone who creates a new account after deleting one can use Milewise in full and take out a subscription; the only consequence is that the free trial is not granted a second time for the same integration. That a one-time trial is in fact one-time also corresponds to the data subject's reasonable expectations (recital 47).

Right to object. Processing based on Art. 6(1)(f) GDPR is subject to the right to object under Art. 21(1) GDPR. For as long as the integration concerned is connected, the controller can locate the corresponding record and examine an objection on its facts; once the account has been deleted that is no longer possible, because the identifier from which the value is calculated is no longer held. An objection can then only be dealt with if the same integration is connected, or used to sign in, again.

Exception to the right to erasure (Art. 17 GDPR). Section 16 promises that all associated data are removed when the account is deleted. This record is excepted from that, for two reasons, both of which are stated. First, Art. 17(1)(a) GDPR requires that the data are no longer necessary for the purposes for which they were collected; for its purpose, the one-time grant, the record remains necessary permanently, because otherwise it would evidence nothing. Second, in so far as the record is regarded as personal data despite not being attributable, the exception in Art. 17(3)(e) GDPR applies (establishment, exercise or defence of legal claims): the record is the only evidence that a free trial has already been provided for a given integration and that there is no entitlement to a further one. All other data of the account are deleted in full, unchanged.

Not in the data export. The record is not included in the data export under section 18. That is not an omission but a consequence of its content: the export outputs the personal data stored for the account, and this record deliberately holds nothing attributed to the account, only the one-way value, the name of the integration and a date. Anyone who wishes to know whether a trial is already recorded for a particular, currently connected integration can obtain that information on request at contact@milewise.de.

Retention. For this record, and for this processing alone in this policy, no fixed period is stated, and the reason is stated openly: a period would turn the limit into its opposite, because once it expired the same integration could receive another free trial; “once per integration” can only be implemented by storage that does not expire. That does not make it unlimited in the sense of “without end”: it is tied to its purpose and ends with it. If the free trial is discontinued, or its one-time character given up, the entire set is deleted in full; the controller reviews annually whether the purpose still exists. Because the record itself names no one, the risk to the data subject does not grow with the length of storage either.

13. Email communication

The controller operates its own email server in Germany. Outgoing system emails (sender address noreply@send.milewise.de) are delivered via the processor Mailjet SAS, Paris, France. Those sent are: the waitlist confirmation, the registration invitation, the confirmation of a contact address, the notice to the previous address when that address is changed, the confirmation link for deleting the account, the confirmation that the deletion has been carried out, and the delivery of the data export under Art. 15 and Art. 20 GDPR. The data export is attached to that email as a ZIP file and therefore passes through this delivery service in full; it is sent only to the confirmed contact address and contains the entire archive of the account, including the coach conversations, the sleep and HRV values, the routes, the titles of transmitted calendar entries and the workout files uploaded by the data subject. Where the data subject sends emails to the controller, the information provided is processed to handle the enquiry; the legal basis is Art. 6(1)(b) or Art. 6(1)(f) GDPR.

14. Recipients and international transfers

Personal data are transmitted only to the recipients listed below and only to the extent required for the provision of the service:

Strava usage data. Strava may monitor and collect data about how Milewise uses the Strava API (their “Usage Data”), and may use it for any business purpose of its own, including improving its platform, supporting developers and users, and checking that we comply with its API terms. This happens on Strava’s side, independently of us and under their own privacy policy; we do not receive it and cannot switch it off. Once you disconnect Strava, we stop calling Strava on your behalf.

Where data are transferred to third countries, this takes place in accordance with Chapter V GDPR: transfers to Google LLC and to Apple Inc. rely on the adequacy decision concerning the EU-U.S. Data Privacy Framework (Art. 45 GDPR); the same applies to the payment processing via “Sold through Link, LLC” (section 12), supplemented by standard contractual clauses under Art. 46(2)(c) GDPR in so far as the adequacy decision does not cover a transfer. The data subject sets up the connection to Strava as their own service; the transfer is necessary for the provision of the requested service and relies on the safeguards provided by Strava (standard contractual clauses, Art. 46(2)(c) GDPR). When map tiles are loaded client-side, the IP address is transmitted to the provider of the map tiles. Since 27 August 2026 this is OpenFreeMap, operated by Hyperknot Software Kft. (Hungary, EU); the provider does not state where its servers are located and refers to the possible use of a content delivery network, so a transfer to a third country cannot be ruled out. In so far as such a transfer takes place, it is necessary for the display of the map requested by the data subject (Art. 49(1)(b) GDPR). The same applied until 27 August 2026 to the previous provider CARTO Inc. (USA). Storage of the training and health data by the controller takes place entirely within the European Union. The AI processing takes place exclusively via service routes with EU data-residency guarantees (section 9); where Microsoft Azure is used, processing within the EU Data Boundary may also take place in Norway or Switzerland (adequacy decisions, Art. 45 GDPR), and Mistral AI SAS may temporarily transfer data to sub-processors outside the EU (standard contractual clauses, Art. 46(2)(c) GDPR).

15. Whether you have to provide personal data

This section fulfils the information duty under Art. 13(2)(e) GDPR. There is no statutory obligation to provide personal data; nobody is obliged to use Milewise. Whether a given item is required depends on the service concerned:

• Waitlist: the email address is required in order to be able to send an invitation; sport and price preference are optional. Without an email address no entry can be made. There is no obligation to sign up.
• Account: the details supplied by the sign-in service (section 7) are required for entering into and performing the user relationship; without them no account can be created. Confirming the minimum age of 18 is a condition of use; if it is not given, the account stays locked and can only be deleted.
• Training and health data (section 8): providing them rests on voluntary explicit consent. It may be refused and withdrawn at any time. The only consequence of refusal or withdrawal is that the AI coach and the automated analyses cannot be provided, because they then have no data to work from; no further disadvantage, and in particular no contractual penalty, follows. Likewise, connecting at least one training data source is necessary for any analysis or coaching to be possible at all.
• Optional features: transmitting planned sessions to the watch (section 11), connecting the personal Google Calendar (section 8.1), transmitting a mobile device's calendar (section 8.3), sharing Apple Health in the iOS app (section 8), storing a contact email address, and location estimation (section 10) are optional; without them only those features are unavailable. Without a connected calendar, the coach simply plans without knowing the data subject's commitments.
• Paid subscription (section 12): the payment and billing data are required in order to enter into the contract; without them no subscription can come about. Payment records are additionally subject to a statutory retention duty (section 16).

16. Retention and erasure

• Account and coaching data are stored for the duration of the account's use. Conversations, connections to data sources, location information and coach notes may additionally be deleted or disconnected individually in the application. When a data source is disconnected, the data subject decides at that moment whether the stored activities and the recovery data that came from it are to be deleted; where they make no such choice, those data are kept. With Strava there is no such choice: the activities obtained through the Strava interface are always deleted on disconnection, because Strava's API terms require it. Independently of that, those activities are in any event deleted automatically no later than seven days after the date of the activity, likewise at Strava's requirement.
• A mobile device's calendar (section 8.3): past days are deleted automatically once they are more than three days old. What is held for future days is replaced for the days reported on every transmission, and deleted in full as soon as the feature is switched off in the app, and when the account is reset or deleted.
• Values from Apple Health (section 8): there is no fixed period. They are deleted in full as soon as the feature is switched off in the app, and when the account is reset or deleted.
• Upon deletion of the account, all associated data, including cached raw data, are removed from the controller's server; planned sessions previously transmitted to the watch are removed from the intervals.icu calendar. There are four exceptions, set out separately below: the pseudonymised security records, the backups, payment records that tax law requires to be retained, and the pseudonymous record of a free trial already granted.
• Cached raw data from the connected sources. Answers from intervals.icu, Strava, Polar and Suunto are held in a response cache so that the same request does not have to be made again. A sweep that runs once a day deletes every entry older than six days. Six rather than seven is deliberate: the sweep runs only once a day, so a seven-day limit would let an entry live for almost eight, and Strava's interface terms cap their data at seven. Independently of that, the cache of an account is cleared when a source is connected or disconnected, on a manual refresh, on a reset, and when the account is deleted.
• Security log: 30 days; on account deletion the account identifier is removed and the pseudonymous record expires with those 30 days (section 4). Operational alert record: 30 days, and it has no account column (section 4). Server log data: 14 days, and up to five weeks for the copy in the server's general system log (section 4). Waitlist: section 6.
• Backups are held encrypted in Germany and are overwritten on a rolling basis, after six months at the latest. Until then a backup may still contain data of an account that has already been deleted; it is used solely to restore service after an incident.
• Payment and invoice records (statutory retention duty). Once a paid subscription exists, the promise of complete erasure does not extend to the tax-relevant records it generates: they must be retained under sec. 147 of the German Fiscal Code (AO). Sec. 147(3) sentence 1 AO provides that accounting vouchers must be kept for eight years, books, records, inventories and financial statements for ten years, and the other documents subject to retention for six years; each period begins at the end of the calendar year in which the document came into existence (sec. 147(4) AO). For as long as that duty applies, a right to erasure is excluded to that extent under Art. 17(3)(b) GDPR; the data concerned are blocked for any other purpose and held solely to comply with the retention duty. Such records arise only once an order has been completed.
• Record of a free trial already granted. The record described in section 12.1 (one-way value of the identifier, name of the integration, date) survives deletion of the account, because the limit of one trial per integration would otherwise be worthless. It contains no directly identifying field and no contact detail. No fixed period is therefore provided for; the storage is tied to its purpose and ends with it (section 12.1).

17. Data security

The controller implements technical and organisational measures pursuant to Art. 32 GDPR to protect the processed data against loss, destruction, access, alteration and dissemination by unauthorised persons. These include in particular: transport encryption of all connections (TLS/HTTPS including HSTS), encrypted storage of the access credentials and connection tokens of the connected services, restriction of all server access to the controller, encrypted backups, and the exclusive operation of all systems on servers within the European Union. The measures are continuously adapted to the state of the art.

To administer the service, the controller operates a protected administration interface (admin.milewise.de). It shows, per account: the account identifier, the display name, the confirmed email address, which training services are connected together with the name held there, the time of last use, the assigned plan, and the costs incurred by use of the AI coach. An email address that has not yet been confirmed is not displayed there. Chat histories with the AI coach, and the training and health data of user accounts, cannot be retrieved through this interface. Access is reserved to the controller alone and is secured by a separate password, an administration session limited to twelve hours, lockouts after failed sign-in attempts and rate limiting; in addition, two-factor authentication (time-based one-time codes or a passkey under the WebAuthn standard) is available for that sign-in. Administrative actions are recorded in the security log described in section 4. The legal bases are Art. 6(1)(b) GDPR (performance of the user relationship) and Art. 6(1)(f) GDPR (abuse and cost control).

18. Rights of the data subject

Subject to the statutory requirements, the data subject has the following rights vis-à-vis the controller:

• the right of access to the personal data processed (Art. 15 GDPR);
• the right to rectification of inaccurate data or completion of incomplete data (Art. 16 GDPR);
• the right to erasure (Art. 17 GDPR);
• the right to restriction of processing (Art. 18 GDPR);
• the right to data portability (Art. 20 GDPR);
• the right to object to processing based on Art. 6(1)(f) GDPR on grounds relating to the data subject's particular situation (Art. 21 GDPR);
• the right to withdraw any consent given, at any time with effect for the future (Art. 7(3) GDPR).

An informal message to contact@milewise.de suffices to exercise these rights. Requests are answered within the period of Art. 12(3) GDPR, at the latest within one month. In addition, account deletion and a data export can be carried out directly in the application under “Your data & privacy”: a full data export (delivered by email; Art. 15/20 GDPR) and the permanent deletion of the account and all associated data (Art. 17 GDPR, subject to the limits in section 16). Both are free of charge. The export does not contain the record of a free trial already granted, because that record holds nothing attributed to the account; the details are in section 12.1.

19. Right to lodge a complaint with a supervisory authority

Without prejudice to any other administrative or judicial remedy, the data subject has the right to lodge a complaint with a data-protection supervisory authority (Art. 77 GDPR), in particular in the Member State of their habitual residence, place of work or the place of the alleged infringement. The supervisory authority competent for the controller (based in Karlsruhe, Baden-Württemberg) is:

20. Currency and amendment of this privacy policy

This privacy policy will be amended as soon as changes to the service or to the legal situation so require, in particular where the paid offering changes (section 12). Existing users will be informed separately before such a change (Art. 13(3) GDPR). The version published here at any given time applies. The German version is binding; this English version is a non-binding translation.