Privacy Policy — Smartensity

1. Data controller

The controller of your personal data is Bartosz Kluczka, a natural person providing the Smartensity service in a private capacity (the “Controller” or “we”). The Controller is an individual and is not, for the purpose of operating this beta, a registered business; accordingly the Controller has no NIP, REGON, or business-register (KRS/CEIDG) number.

Contact for data-protection matters: support@smartensity.app. A postal contact address will be added before public launch.

Data Protection Officer (DPO): not appointed (the obligation under Art. 37 GDPR is not triggered at this beta scale).

2. What this document is

This document explains what personal data we collect in the Smartensity app, why, on what legal basis, to whom we disclose it, how long we keep it, and what rights you have. It satisfies the information obligation under Art. 13 and 14 GDPR (Regulation 2016/679).

Smartensity is an app that supports Functional Fitness training planning using artificial intelligence. Because of the nature of the service, we process information about your state of health (e.g. injuries, pain complaints), which the GDPR classifies as a special category of data (Art. 9 GDPR). This requires heightened care on our part and, on yours, your explicit consent.

3. What data we collect

3.1. Account data

Note on proof-of-consent metadata (IP + user-agent). When you accept the Terms and Privacy Policy and when you give explicit health-data consent, we record your IP address and browser user-agent on the consent record. Purpose: to demonstrate that and when consent was given — the accountability obligation under Art. 7(1) and Art. 5(2) GDPR (legal basis: Art. 6(1)(c) and/or our legitimate interest under Art. 6(1)(f) in being able to prove consent). This metadata is part of the consent tombstone: when you delete your account, the consent record is not deleted — your user_id is set to NULL but the proof-of-consent fields (including IP and user-agent) are kept. See the retention table in section 7.

3.2. Training profile (collected during onboarding)

3.3. Training-execution data

Automatic safety check (rule-based, no AI). When you report pain during or after a session, we run an automatic rule-based safety check on that report on our own server. It looks only for red-flag patterns (pain severity ≥ 7, or sharp / chest / dizziness / numbness) to decide whether to flag the session for review. This check uses data already stored in your account, uses no artificial intelligence, and sends nothing to any third party. Because its sole purpose is your safety, it runs even if you have not given — or have withdrawn — consent to AI processing of your health data; where it fires we store a minimal record of which rule fired and for which session in our AI-call ledger (see section 7). Any AI review of your plan on top of this runs only with your health-data consent.

3.4. AI conversation data

Audit note. Full AI request and response contents are stored in the ai_requests table to ensure transparency of algorithmic decisions and the ability to reproduce errors. This data contains fragments of the User's profile and pain flags. See: retention limits in section 7 and disclosure rules in section 5.

Note on coach surfaces (distinct from the onboarding form). The app has two coach surfaces that send your free-text questions and context to the AI and may carry special-category health data (Art. 9 GDPR):

• Plan coach-chat — the in-app conversation where you ask questions about your active training plan; turns are persisted as chat_conversations message rows (retained ≤ 30 days, hard-deleted).
• Session ask-coach — the per-workout coach accessible from the training log; your question plus the session context (movements, pain flags, RPE) are sent to the AI and stored in ai_requests.request_json / ai_requests.response_json (content NULLed after 90 days; see section 7).

Both surfaces are not onboarding (onboarding is a structured form — no AI conversation, see section 3.2). A single explicit health-data consent is required before either surface is accessible. That consent is recorded server-side in the health_data_consents table (auditable row with version, timestamp, IP, and user-agent), which the server checks before routing any coach request. Art. 9(2)(a) GDPR is the legal basis. A coach_chat_health_notice key in localStorage is also set as a supplementary “not medical advice” UI reminder — it is not the legal consent; the server-side record is. You can withdraw consent at any time under section 6, which disables both coach surfaces.

3.5. Technical and diagnostic data

Error telemetry (Sentry) is hosted in the EU region (Frankfurt); we rely on our legitimate interest in keeping the service secure and reliable (Art. 6(1)(f) GDPR), and health and directly-identifying data are stripped before any event is sent. Product analytics (PostHog) runs on EU Cloud and operates in two phases: (1) anonymous, cookieless measurement on public pages (home, waitlist, signup, onboarding) — nothing is written to or read from your device, no person profiles are created, and your account identifier is never sent; legal basis: our legitimate interest in measuring acquisition effectiveness (Art. 6(1)(f) GDPR); because no information is stored on or retrieved from your terminal equipment this phase does not require consent (Art. 5(3) ePrivacy Directive); (2) full capture after you grant consent via the in-app banner — legal basis: your consent (Art. 6(1)(a) GDPR). You can object to phase 1 or withdraw phase 2 consent at any time in Settings; both actions take effect immediately.

3.6. Beta waitlist (marketing-contact — only if you join it)

If — before you have an account — you submit your email address on the public landing page to join the closed-beta waitlist, we process the following, separately from any account data:

About the optional questions. Answering them is entirely optional — you can skip the step. We use them only to help us choose who to invite first to the limited closed beta. The equipment note is a free-text field intended for equipment only; please do not enter health or medical information there — we do not ask for it and you should not provide it at this stage.

Purpose — narrow and explicit. We use your waitlist email for one purpose only: to send you your Smartensity beta invite and launch updates. We do not use it for any broader marketing and we do not share it with third parties other than our email-sending processor (see section 5). To order the beta invite list, we apply a light, internal suitability score to the optional answers above. This score is used only by us, internally, to decide whom to invite first; it is never shown to you, it has no automated legal or similarly significant effect on you (a person makes the actual invite decision — Art. 22 GDPR does not apply), and it is not stored — it is recomputed on demand.

Legal basis. Your consent under Art. 6(1)(a) GDPR, given at the moment you submit the form (the landing-page notice states you agree we may email you about the beta invite and launch updates), together with Art. 10 of the Polish Act of 18 July 2002 on the provision of services by electronic means (UŚUDE), which requires consent before sending commercial information to an electronic address.

Retention. We keep an un-converted waitlist entry no longer than 12 months from sign-up (automatic purge), or until it is erased on your withdrawal request — whichever comes first. If your entry is converted into an account, the remaining record is governed by the account-data retention in section 7.

How to withdraw (no account needed). You can withdraw your consent / unsubscribe at any time, with no effect on the lawfulness of emails sent before withdrawal (Art. 7(3) GDPR), by clicking the one-click unsubscribe link included in every waitlist email (stops all further emails and flags your entry for erasure), or by emailing support@smartensity.app — on request we erase your entry under Art. 17 GDPR. Your optional answers live on the same record and are erased together with it.

3.7. Derived training-response profile (long-term injury-recurrence memory) — Art. 9 GDPR

On the basis of the pain / discomfort flags you record during sessions (special-category health data — Art. 9 GDPR; see sections 3.2 and 3.3), the App builds a durable derived profile that detects recurrences over time — for example, pain returning in the same body region across separate training blocks weeks or months apart. Internally these are stored as “athlete signals”.

What this profile is — and is NOT. The derived profile serves only as auxiliary narrative context for the AI-based plan generator and periodic reviews (see section 10). It is a hint, not a decision: on its own it never blocks, gates, or changes your plan — every generated plan still passes the deterministic safety validator (see section 10), and every signal is one you can review, contest, and dismiss yourself in your profile (the “Patterns” surface — “what the coach knows about you”). Dismissing a signal freezes it: it is never silently re-asserted by a later recompute.

Legal basis. The same explicit consent to the processing of health data (Art. 9(2)(a) GDPR) that covers the source pain flags; deriving and storing this profile is itself “processing” (Art. 4(2) GDPR) of special-category data. You may withdraw that consent at any time (see section 6). (needs lawyer review — confirm that the consent covering the source pain flags (Art. 9(2)(a) GDPR) also covers creating and storing this derived profile, and that no separate profiling-specific consent is required.)

Retention — an important nuance. A signal persists for the lifetime of your account. After 180 days with no new qualifying flag a signal stops being taken into account when generating a plan (it “expires”), but this only hides it — it does not delete the row. The signal and its change log are fully erased (HARD DELETE) when you delete your account (see section 7). (needs lawyer review — storage-limitation (Art. 5(1)(e)): confirm account-lifetime retention of this derived Art. 9 profile is justified or set a deletion ceiling; the 180-day “expiry” is a visibility cut-off, not erasure. This mirrors the pain_flag_audit retention-asymmetry question, #2412.)

Upcoming scope (#2644). A forthcoming read-only signal-bundle endpoint (GET /api/athlete/signals) will expose the same derived signals to additional in-app surfaces (e.g. a capability view and coach insights). It reuses the same source data, the same Art. 9(2)(a) consent basis, the same dismiss / correction right, and the same account-deletion erasure described here — no new category of data is created — so this disclosure is written to cover it in advance.

Cross-cycle performance profile (#2389). Alongside the injury-recurrence memory above, the App also derives a cross-cycle performance profile at the end of each completed training block: progression rate per lift (e.g. a lift that has stalled or is trending down across blocks), volume tolerance (how you respond to higher-volume blocks), engine-vs-strength balance (a persistent gap between conditioning and strength capability), and consistency trend (whether your training adherence is improving or declining over time). This is derived from your reference-lift (1RM) bests, a capability-level snapshot, and your adherence per completed block — see the table above. Like the injury-recurrence profile, it is fed into plan generation as narrative context only (see section 10) under the same explicit health-data consent (Art. 9(2)(a) GDPR) that covers the source data, and is fully erased (HARD DELETE) when you delete your account (see section 7). (needs lawyer review — same open questions as the injury-recurrence profile above: whether the Art. 9(2)(a) consent on the source data covers creation/storage of this derived profile without a separate profiling consent, and storage-limitation (Art. 5(1)(e)) given account-lifetime retention with no deletion ceiling before account deletion.)

4. Purposes and legal bases of processing

5. Recipients of data and transfers to third countries

We disclose your data to the following categories of recipients:

5.1. Transfer to a third country (Anthropic, USA)

As part of providing the service, we transfer the content of requests to the Claude model to Anthropic, PBC, based in the United States. These requests contain fragments of your profile, including special-category data (injuries, pain flags).

The basis for this transfer is:

1. The European Commission's Standard Contractual Clauses (SCCs) of 4 June 2021 (decision 2021/914), together with Anthropic's Data Processing Addendum (DPA).
2. Additional technical and organizational safeguards (TLS in transit, restricted permissions, data minimization in prompts).

Support-ticket AI triage (Anthropic). When you send a support message, its text — after a deterministic health pre-filter (any suspected injury/pain/medical content is escalated to a human and never leaves to the AI) and secrets/email scrubbing — is sent to the Claude model to classify the ticket and, for how-to questions, to draft a candidate reply. No reply is ever sent automatically: a human reviews every draft before anything reaches you, so this is not automated decision-making under Art. 22 GDPR. Same US-transfer mechanism as above (SCCs + Anthropic DPA, no model-training).

The content of your requests is not used by Anthropic to train their models, in line with the API access terms.

GitHub, Inc. (USA) — support / error-report tickets. To diagnose and fix faults, our error-handling pipeline files RODO-redacted support tickets as issues in a private GitHub repository operated by GitHub, Inc., based in the United States. Before a ticket is filed, the pipeline removes raw personal and special-category data (e.g. email address, raw injury and pain-flag content); the ticket body carries only: the error type, the scrubbed error message, scrubbed stack-trace frames, the request path and method, the app version, a coarse browser/OS label derived from your browser's User-Agent header, and a pseudonymous user reference (a short hash — not reversible to your account). We rely on the same transfer mechanism as for Anthropic above: the European Commission's Standard Contractual Clauses (decision 2021/914) and GitHub's Data Protection Addendum, plus encryption in transit and the private-repository access restriction.

Resend (USA) — transactional / waitlist email. If you join the beta waitlist, we send your confirmation email through Resend (Plus Five Five, Inc.), an email-delivery provider based in the United States. To send it, we transmit your email address and the content of that email (the waitlist confirmation message and its one-click unsubscribe link) to Resend. No profile, training, or special-category (health) data is sent to Resend. We rely on the same kind of transfer mechanism as for Anthropic and GitHub above: the European Commission's Standard Contractual Clauses (decision 2021/914) and Resend's Data Processing Addendum, and/or the EU–US Data Privacy Framework to the extent Resend is a certified participant, plus encryption in transit. (Needs lawyer review — confirm Resend's DPF certification status and that its DPA / SCCs are in force before the first production email is sent.)

We provide the full list of our sub-processors, together with the current transfer mechanisms, on request at support@smartensity.app.

6. Your rights (Art. 15–22 GDPR)

At any time you have the right to:

1. Access (Art. 15) — to obtain information about what data we process about you.
2. Rectification (Art. 16) — to correct data that is inaccurate.
3. Erasure / the “right to be forgotten” (Art. 17) — to request deletion of your account and associated data, subject to provisions that require retention.
4. Restriction of processing (Art. 18) — in specified situations.
5. Data portability (Art. 20) — to receive your data in a structured, commonly used format (e.g. JSON).
6. Objection (Art. 21) — to processing based on legitimate interest.
7. Withdrawal of consent (Art. 7(3)) — at any time, without affecting the lawfulness of processing carried out before withdrawal. Withdrawing consent to the processing of health data means you can no longer use personalized plan generation (consent is necessary to provide the service in that respect).
   Concretely, there are two routes today: delete your account in Settings — this erases your profile, injuries, pain flags, plans and logs in one operation, so the consent and the data it covered end together — or email us at support@smartensity.app and we will respond within 30 days. There is no separate in-app “withdraw consent” toggle that keeps the account alive — a deliberate decision, not a missing feature: this service is built around personalising training to your injuries and reported pain, and an account for which we have no basis to process that data is one we do not operate. Before deleting, you can export your data — your profile, plans, sessions, logs, reports and plan changes — from Settings.
   You can also clear the injuries and pain flags in your profile without deleting your account: Settings → Your data → “Clear my injuries & pain flags” empties both lists. This is deliberately not gated on holding a valid consent, because erasing data is a right, not a new act of collection. It stops those profile entries shaping your future plans.
   What clearing does not cover. It is not a withdrawal of consent, and it does not end every use of health data. These deliberately survive it and are erased only when the account is: the pain you report during sessions, which we keep collecting and rule-checking for your safety on a separate basis; the advisories and cross-cycle patterns derived from it, which keep informing plan generation (individual ones can be dismissed under Patterns); the append-only record that the change happened — note that clearing itself writes one, containing what was removed; and the copies frozen inside plan versions already generated for you. See sections 3 and 7.
8. Not to be subject to a decision based solely on automated processing (Art. 22) — including profiling, where that decision produces legal effects or similarly significantly affects you. Training plans are suggestions, not automated decisions producing legal or similarly significant effects: a deterministic validator and a needs-human review path apply, and the User must actively confirm a plan before following it. Accordingly, plan generation does not qualify as a decision within the meaning of Art. 22 GDPR.
9. Lodge a complaint with the supervisory authority — the President of the Personal Data Protection Office (UODO), ul. Stawki 2, 00-193 Warsaw, https://uodo.gov.pl.

How to exercise your rights: email support@smartensity.app (subject: “GDPR — [type of request]”). We respond within 30 days (Art. 12(3) GDPR), extended by up to 60 days in complex cases.

The app provides direct functions for data export (Art. 20) and account deletion (Art. 17). The export delivers your account, profile (your onboarding form responses), Coach Q&A chat history, training logs, plans, reports, and AI-request metadata in a machine-readable JSON format.

7. Data retention period

We keep data no longer than is necessary to fulfil the purposes for which we collected it. Default periods:

A detailed mapping of data, storage locations, and the deletion process is in the internal document docs/legal/DATA_PROCESSING.md.

8. Data security

We apply technical and organizational measures appropriate to the risk, including:

• encryption in transit (TLS 1.2+),
• encryption at rest (provided by Supabase and our hosting provider),
• access-permission minimization (“least privilege”) for the team,
• environment separation (dev / staging / prod),
• JWT verification (Supabase Auth, HS256) on every API request,
• security logging and monitoring,
• regular dependency updates and security reviews (audits by the cybersecurity-agent).

In the event of a personal-data breach that may result in a risk to the rights or freedoms of natural persons, we report it to UODO within 72 hours of becoming aware (Art. 33 GDPR) and, where the risk is high, we inform the affected data subjects directly (Art. 34 GDPR).

9. Children and minors

The App is intended for persons who are 18 years of age or older (full legal capacity). The minimum age of 18 is required per owner decision #870 (2026-06-05) and is enforced by the profile validator (age_years ≥ 18).

We do not knowingly collect data from persons under 18. If we determine that an account belongs to a person under that age, we will delete it without undue delay.

10. Profiling and automated decisions (Art. 22 GDPR)

In generating the training plan we use automated processing (the Anthropic Claude AI model + a deterministic validator). The output of that processing is a suggestion, not a decision producing legal effects. The User actively accepts the plan and independently decides whether to follow it. For that reason, in our view, plan generation does not qualify as automated decision-making within the meaning of Art. 22(1) GDPR.

Regardless, you have the right to obtain human intervention in the process — email support@smartensity.app.

Derived training-response profile (AthleteSignal). As described in section 3.7, we derive a long-term injury-recurrence profile from your pain-flag history and feed it into plan generation as narrative context only. This does not change the assessment above: the derived signals are an input hint — they never automatically gate, block, or alter your plan (the deterministic safety validator is the only hard gate, and it is not driven by these signals), the plan output remains a suggestion you actively accept, and you can review, contest, and dismiss any individual signal in the “Patterns” area of your profile — a meaningful, self-service human-in-the-loop correction. (needs lawyer review — confirm that narrative-input profiling which the User can inspect and dismiss, feeding a suggestion that is not automatically implemented, stays outside Art. 22(1); the EU AI Act transparency provisions should also be considered. This argument requires legal assessment; for paid plans or automated eligibility scoring, the classification may change.) The cross-cycle performance profile described alongside it in section 3.7 works the same way as narrative-only input to the same non-decision, but with one difference: it has no per-item dismiss / correction affordance of its own — it is a raw computed substrate (per-block lift/capability/adherence figures), not an individually asserted claim like an injury-recurrence signal. Here the human-in-the-loop safeguard is the plan-level accept / regenerate / reject path described above, together with the deterministic safety validator, rather than a per-item dismissal. (needs lawyer consultation — confirm that this weaker, plan-level (rather than individual-entry-level) form of correction is sufficient in the context of Art. 22 GDPR for this substrate.)

11. Cookies and similar technologies

The App uses cookies and the browser's localStorage mechanisms to:

• maintain the authentication session (cookie / JWT token — essential),
• remember a draft training session (localStorage — functional),
• (optionally) PostHog product analytics cookies/localStorage — requires separate consent (phase 2 only; phase 1 is cookieless).

Essential authentication cookies are required to provide the service and do not require a consent banner. PostHog operates in two phases: phase 1 is anonymous and cookieless (no device storage access, no consent required under Art. 5(3) ePrivacy); phase 2 uses cookies/localStorage and is enabled only if you opt in via the in-app analytics consent banner. You can object to phase 1 or withdraw phase 2 consent at any time in Settings.

12. Changes to this Privacy Policy

We may update this Policy if the law, the app's functionality, or our sub-processors change. We will inform you of material changes by email and by an in-app message at least 14 days before they take effect. The current version is always available at /legal/privacy.

Version: 0.1 (date: 2026-06-09). The version number and date are recorded in the User's Account at the moment of acceptance.

13. Contact

For matters related to the processing of your personal data, contact us:

• Controller: Bartosz Kluczka (a natural person)
• Email: support@smartensity.app
• DPO: not appointed (the obligation under Art. 37 GDPR is not triggered at this beta scale).
• Postal contact address: not published for the invite-only beta; a postal contact address will be added before public launch.

At any time you may lodge a complaint with the President of the Personal Data Protection Office (UODO), ul. Stawki 2, 00-193 Warsaw, https://uodo.gov.pl.