Privacy Policy — Smartensity
Last updated: 2026-06-09Version: 0.1
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: smartensity@gmail.com.
[UNCERTAIN — lawyer: a natural-person controller is identified under Art. 13/14 GDPR by name and contact details (provided above). Whether a postal/physical contact address must additionally be published — as opposed to an email being sufficient for an invite-only beta — should be confirmed before public/scale launch. Our working recommendation: email alone is acceptable for the closed beta; add a postal contact address before opening to the public. Do not invent an address — the Controller must supply a real one if required: <POSTAL_CONTACT_ADDRESS — to be supplied if a lawyer confirms it is required>.]
Data Protection Officer (DPO): not appointed. [UNCERTAIN — lawyer: an assessment of the obligation to appoint a DPO under Art. 37 GDPR is required before public/scale launch; large-scale processing of health data typically triggers the obligation. For the invite-only beta with a small user base our working view is that the obligation is not yet triggered, but this requires legal confirmation.]
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
| Category | Examples | Source |
|---|---|---|
| Identification / contact | email address, Supabase account identifier | from you, at registration |
First name (optional) (Art. 6(1)(b) GDPR [VERIFY]) | first name or nickname provided by the User (first_name) | from you |
| Authentication | password (hashed) — stored solely by Supabase Auth | from you |
| Account metadata | account creation date, accepted Terms version and acceptance date (consent_version, consented_at) | system |
| Medical-disclaimer acknowledgement | timestamp and version of the displayed medical disclaimer (disclaimer_acks.acked_at, .disclaimer_version) | system (at onboarding) |
| Proof-of-consent metadata | client IP address and user-agent captured at the moment you accept the Terms/Privacy and give health-data consent, stored on the consent record (consent_records) | system (at the consent moment) |
| Unit-of-measure preference (Art. 6(1)(b) GDPR) | “kg” or “lbs” (user_profiles.weight_unit) | from you, at onboarding or in settings |
Language preference (Art. 6(1)(b) GDPR [VERIFY]) | UI language setting (language) | from you or from the browser |
| Onboarding chat history | content of messages exchanged during the AI interview (chat_messages) — Art. 6(1)(b) GDPR | automatic (during onboarding) |
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_idis 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)
| Category | Examples | Database field |
|---|---|---|
| Experience level | beginner / intermediate / advanced / rx | user_profiles.level |
| Training goal | strength / endurance / weight_loss / general_fitness / ... | user_profiles.goal |
| Training age | years (with fractional precision) | user_profiles.training_age_years |
| Age | number of full years (minimum: 18) | user_profiles.age_years |
| Bodyweight | kg (optional) | user_profiles.bodyweight_kg |
| Sex (Art. 6(1)(b) GDPR — performance of a contract — load scaling; this is not health data within the meaning of Art. 9 GDPR) | male / female / prefer_not_to_say (optional) | user_profiles.sex |
| Injuries (health data, Art. 9 GDPR) | list, e.g. ["left_shoulder", "lower_back"] | user_profiles.injuries |
| Pain flags (health data, Art. 9 GDPR) | severity 1–10, nature (sharp / chest / dizziness / numbness), anatomical location | user_profiles.pain_flags, training_logs.pain_flag |
| Reference lifts (1RM) | squat, deadlift, overhead press — in kg | user_profiles.known_1rm |
| Skill baselines | measurable starting values for focus exercises, e.g. max pull-up reps | user_profiles.skill_baselines |
| Skills | list of skills (snatch, pull-up, double-under) | user_profiles.skills |
| Focus lifts | movements to strengthen (e.g. snatch, clean_and_jerk) | user_profiles.focus_lifts |
| Focus skills | skills to learn (e.g. muscle_up, handstand_walk) | user_profiles.focus_skills |
| Benchmark results | times / scores for standard metcons (e.g. Fran, Cindy) | user_profiles.benchmark_results |
| Available equipment | list of equipment | user_profiles.equipment |
| Availability | sessions per week, session duration | user_profiles.sessions_per_week, session_duration_minutes |
3.3. Training-execution data
| Category | Examples | Database field |
|---|---|---|
| Training logs | date, loads, reps, RPE, time, metcon score | training_logs.data |
| Readiness signals (sensitive data related to physical activity) | energy, sleep quality, soreness (DOMS), motivation — 1–10 scale | training_logs.data.readiness |
| Pain flags during a session (Art. 9 GDPR) | as in 3.2 | training_logs.pain_flag |
| Text notes | any text the User enters | training_logs.data.notes |
3.4. AI conversation data
| Category | Examples | Database field |
|---|---|---|
| Onboarding chat history | full message content during the interview | ai_requests.request_json (for the onboarding endpoint) |
| Coach Q&A chat history (may contain health data, Art. 9 GDPR) | the questions you ask the AI coach about your active plan and the assistant's replies — stored verbatim as you typed them; may include injury, pain, and training-load context | chat_conversations (one thread per User) and the per-turn message rows it owns (role / content rows linked to a chat_conversations thread) |
| AI-generated plans and reports | full model responses | ai_requests.response_json, training_plan_versions.plan_json, ai_reports.summary_json |
| AI-call metadata | model, prompt version, token count, cost, validation status | ai_requests (model, prompt_version, input_tokens, output_tokens, cost_usd, status, validation_status) |
Audit note. Full AI request and response contents are stored in the
ai_requeststable 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 the Coach Q&A chat (distinct from the onboarding chat). The Coach Q&A chat is the in-app conversation where you ask questions about your active training plan and receive AI-generated answers. It is a separate data store from the onboarding interview: onboarding messages are captured inside
ai_requests.request_json(see the first row above), whereas the Coach Q&A turns are persisted as their own conversation threads (chat_conversations) and message rows. Because you may mention injuries or pain in these questions, this content can include special-category health data (Art. 9 GDPR) and is treated accordingly: it falls under the same explicit health-data consent and is erased on account deletion (see sections 4, 6, and 7).[NEEDS LAWYER REVIEW — confirm the existing Art. 9(2)(a) explicit health-data consent given at onboarding adequately covers free-text health disclosures the User volunteers in the Coach Q&A chat, or whether a distinct consent / just-in-time notice is required at the chat surface.]
3.5. Technical and diagnostic data
| Category | Examples | Source |
|---|---|---|
| Server logs | IP address, user-agent, HTTP path, response code, timestamp | automatic |
| Error telemetry | stack traces, breadcrumbs (Sentry) | automatic |
| Product analytics | feature-usage events, experiments (PostHog) | automatic |
[UNCERTAIN — lawyer: Sentry and PostHog are optional (no-ops without configuration); a decision is needed on the hosting region (EU vs US) and on separate consent for analytics]
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:
| Category | Examples |
|---|---|
| Contact | email address |
| Consent timestamp | the moment you joined the waitlist (this is the record of when you gave consent) |
| Source (not PII) | optional landing-page/campaign label |
| Conversion flag | whether your entry has been turned into an invite code |
| Withdrawal timestamp | the moment you unsubscribed, if you did |
| Optional training-habit answers | a few optional questions you may answer (or skip) after joining: where you train, who programs your training, sessions per week, and a one-line equipment note |
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.
[NEEDS LAWYER REVIEW — #1726: confirm the light cohort-selection score stays outside Art. 22 GDPR and that this disclosure is sufficient transparency.]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.
[NEEDS LAWYER REVIEW — confirm consent-by-submission on the landing form is sufficiently specific and informed for both Art. 6(1)(a) GDPR and UŚUDE art. 10.]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 smartensity@gmail.com — on request we erase your entry under Art. 17 GDPR. Your optional answers live on the same record and are erased together with it.
4. Purposes and legal bases of processing
| Purpose | Legal basis (GDPR) | Explanation |
|---|---|---|
| Creating and operating the Account (authentication, feature access) | Art. 6(1)(b) — performance of a contract | Without an Account the service cannot be provided. |
| Collecting the training profile (including injuries and pain flags) | Art. 9(2)(a) — explicit consent + Art. 6(1)(b) — performance of a contract | Consent is voluntary; without it we cannot generate a personalized plan. You can withdraw it at any time (see section 6). |
| Generating plans and reports via AI | Art. 6(1)(b) — performance of a contract | Generation is the core of the service. Special-category content (injuries, pain) is part of the input — see the row above. |
| Operating and storing the Coach Q&A chat (so you can re-open past conversations) | Art. 6(1)(b) — performance of a contract; Art. 9(2)(a) — explicit consent for any health content you volunteer in a message | Persisting your coach conversations lets you continue a thread and review prior answers. Where a message contains health information, it relies on the same explicit health-data consent. [NEEDS LAWYER REVIEW — see the §3.4 note on consent coverage for volunteered chat health data.] |
| Logging completed training and readiness signals | Art. 6(1)(b) + Art. 9(2)(a) (for the health fields) | You log completed sessions; we store them so the AI can propose adjustments. |
| Security and abuse detection (server logs) | Art. 6(1)(f) — legitimate interest | Protecting the service and other Users. |
Auditing AI decisions (ai_requests) | Art. 6(1)(c) — legal obligation (GDPR accountability, Art. 5(2)) + Art. 6(1)(f) | We must be able to explain why the AI proposed a given plan. |
| Proof of consent (IP + user-agent on consent records) | Art. 6(1)(c) — legal obligation (accountability, Art. 7(1)/Art. 5(2)) + Art. 6(1)(f) — legitimate interest | We must be able to demonstrate that and when you consented. |
| Service communication (e.g. email confirmation, outage notice) | Art. 6(1)(b) or (f) | Necessary to provide the service. |
| Handling data-subject rights requests | Art. 6(1)(c) | Obligation under Art. 12–22 GDPR. |
| Own marketing (if introduced) | Art. 6(1)(a) — separate consent | [UNCERTAIN — not in the MVP; to be completed if introduced] |
5. Recipients of data and transfers to third countries
We disclose your data to the following categories of recipients:
| Recipient | Role | Location | Data categories |
|---|---|---|---|
| Supabase (Supabase Inc.) | Processor — authentication + Postgres database | EU region (<SUPABASE_REGION>) | All account, profile, and training-log data. |
| Anthropic, PBC | Processor — AI model (Claude) | USA | Prompt and response content including the profile and pain flags (special-category data). |
Railway / AWS / <HOSTING> | Processor — backend and worker hosting | <REGION> | All data processed by the app (in transit). |
| Sentry (Functional Software Inc. / Sentry GmbH) | Processor — error telemetry | EU or USA, depending on the plan | Stack traces, user ID, context fragments. [UNCERTAIN — region] |
| PostHog | Processor — product analytics | EU Cloud or self-hosted | Usage events, user ID. [UNCERTAIN — optional] |
| GitHub, Inc. | Processor — support / error-report ticket tracking (error telemetry is filed as issues in a private repository) | USA | Minimised support-ticket content: error type, technical context, and a pseudonymous reference. The pipeline does not collect raw personal or special-category (health) data into the ticket — no email, pain-flag, or injury content is gathered into the payload in the first place — and it additionally redacts any secrets or email addresses that happen to appear in an error string before filing. [NEEDS LAWYER REVIEW — confirm the redaction guarantee is sufficient and that no special-category data can leak into a ticket] |
Email provider (Supabase Email or <SMTP_PROVIDER>) | Processor — sending transactional email | <REGION> | Email address, email content. |
| Public authorities | Recipients (on a lawful request) | Poland / EU | Only on the basis of a legal obligation. |
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:
- The European Commission's adequacy decision — the EU–US Data Privacy Framework (implementing decision 2023/1795 of 10 July 2023), to the extent Anthropic is a certified participant in the framework.
[UNCERTAIN — lawyer: verify Anthropic's certification status as of the date of signing] - The European Commission's Standard Contractual Clauses (SCCs) of 4 June 2021 (decision 2021/914), as a fallback mechanism, together with Anthropic's Data Processing Addendum, if concluded.
- Additional technical and organizational safeguards (TLS in transit, restricted permissions, data minimization in prompts).
The content of your requests is not used by Anthropic to train their models, in line with the API access terms. [UNCERTAIN — lawyer: verify the current Anthropic Commercial Terms and any “no-training” toggle in the console]
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, technical context, and a pseudonymous reference. We rely on the same transfer mechanism as for Anthropic above: the EU–US Data Privacy Framework adequacy decision to the extent GitHub / Microsoft is a certified participant, with the European Commission's Standard Contractual Clauses (decision 2021/914) and GitHub's Data Protection Addendum as a fallback, plus encryption in transit and the private-repository access restriction. [NEEDS LAWYER REVIEW — verify GitHub/Microsoft DPF certification status and that the GitHub DPA / SCCs are in place as of the date of signing]
We provide the full list of our sub-processors, together with the current transfer mechanisms, on request at smartensity@gmail.com.
6. Your rights (Art. 15–22 GDPR)
At any time you have the right to:
- Access (Art. 15) — to obtain information about what data we process about you.
- Rectification (Art. 16) — to correct data that is inaccurate.
- Erasure / the “right to be forgotten” (Art. 17) — to request deletion of your account and associated data, subject to provisions that require retention.
- Restriction of processing (Art. 18) — in specified situations.
- Data portability (Art. 20) — to receive your data in a structured, commonly used format (e.g. JSON).
- Objection (Art. 21) — to processing based on legitimate interest.
- 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).
- 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. Generating a training plan via AI is a suggestion and requires the User to actively confirm (enable) it; in our view it does not qualify as a decision within the meaning of Art. 22 GDPR.
[UNCERTAIN — lawyer: this interpretation requires legal review; the reinforcing provisions in the EU AI Act should also be considered] - 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 smartensity@gmail.com (subject: “GDPR — [type of request]”). We respond within 30 days (Art. 12(3) GDPR), extended by up to 60 days in complex cases.
In the app we will provide (once implemented, see the issue) direct functions for data export (Art. 20) and account deletion (Art. 17). [UNCERTAIN — lawyer: requires implementation; currently not available]
7. Data retention period
We keep data no longer than is necessary to fulfil the purposes for which we collected it. Default periods:
| Category | Retention period | Justification |
|---|---|---|
| Account data (email, Supabase ID) | for the lifetime of the account + up to 3 years after deletion (for accountability and potential claims) | Art. 118 of the Polish Civil Code — the general limitation period for claims. [UNCERTAIN — lawyer: period to be agreed; conservatively, shorter is better] |
| Training profile (including injuries, pain flags) | for the lifetime of the account; after account deletion — anonymized within 30 days | minimization of special-category data (Art. 5(1)(c) and (e) GDPR) |
Training logs (training_logs) | for the lifetime of the account; after account deletion — anonymized within 30 days; aggregated statistics may be retained indefinitely | as above; logs are linked to immutable plan versions — see DATA_PROCESSING.md |
AI-call logs (ai_requests) | Until account deletion: data is fully deleted (HARD DELETE) as part of the Art. 17 procedure. Rows not owned by the deleted user: working retention [UNCERTAIN — lawyer: requires a decision and validation; a previous proposal of 12 months + pseudonymization was replaced by hard delete on account deletion] | Art. 17 GDPR (right to erasure) + Art. 9 (health data in payloads) — hard delete as the safer option [UNCERTAIN — lawyer] |
Consent records (consent_records), incl. proof-of-consent IP + user-agent | Retained as a tombstone: on account deletion the user_id is set to NULL and the record (including the captured IP and user-agent) is not deleted. Tombstone retention duration: [UNCERTAIN — lawyer] | proof that and when consent was given — Art. 7(1) accountability; consistent with the general limitation period for claims |
Medical-disclaimer acknowledgements (disclaimer_acks) | indefinitely as a tombstone (Art. 7 GDPR); on account deletion user_id is set to NULL, the row is not deleted | proof of consent to collecting health data; Art. 7(1) GDPR obligation |
AI reports (ai_reports) | for the lifetime of the account + 1 year | progress analysis |
Coach Q&A chat history (chat_conversations + its message rows) | for the lifetime of the account; on account deletion the conversation threads and all their message rows are fully deleted (HARD DELETE) as part of the Art. 17 erasure procedure (FK cascade). No fixed in-life retention ceiling is applied today — chat is kept while the account exists. [NEEDS LAWYER REVIEW — set an in-life retention ceiling (e.g. auto-purge coach-chat older than N months) given this store can carry Art. 9 health data; “kept for the lifetime of the account” may be longer than necessary under Art. 5(1)(e) storage-limitation.] | Art. 17 GDPR (erased on deletion) + Art. 5(1)(e) storage limitation for the in-life ceiling [UNCERTAIN — lawyer] |
Plan patches (plan_patches) | for the lifetime of the account + 1 year | consistency with plan immutability |
| Server / security logs | 90 days (rolling) | legitimate interest — security |
| Error telemetry (Sentry) | 90 days | as above |
| Complaint correspondence | 6 years from case closure | Art. 442(1) of the Polish Civil Code — the limitation period for tort claims. [UNCERTAIN — lawyer] |
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 /
<HOSTING>), - 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). [UNCERTAIN — lawyer: to be validated before the beta launch]
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 smartensity@gmail.com.
[UNCERTAIN — lawyer: this argument requires legal assessment; for paid plans or automated eligibility scoring, the classification may change]
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 — requires separate consent.
A detailed cookie policy and a consent banner will be implemented separately. [UNCERTAIN — lawyer: requires implementing a banner, see the cookie-banner issue]
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 <POLICY_URL>.
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: smartensity@gmail.com
- DPO: not appointed.
[UNCERTAIN — lawyer: confirm no DPO obligation under Art. 37 GDPR for the closed beta; large-scale processing of health data may trigger it as the user base grows] - Postal contact address: not published for the invite-only beta.
[UNCERTAIN — lawyer: confirm whether a natural-person controller must publish a postal contact address before public/scale launch; to be supplied by the Controller if required — <POSTAL_CONTACT_ADDRESS>]
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.