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: 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
| Category | Examples | Source |
|---|---|---|
| Identification / contact | email address, Supabase account identifier | from you, at registration |
| First name (optional) (Art. 6(1)(b) GDPR — performance of a contract) | 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 — performance of a contract) | UI language setting (language) | from you or from the browser |
| Onboarding form responses | the training-profile fields you fill in on the structured onboarding form (no AI is involved in onboarding) — the individual fields are listed in section 3.2 (user_profiles) — Art. 6(1)(b) GDPR | from you (on the onboarding form) |
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 form responses | onboarding is a structured form, not an AI conversation — the profile fields you enter are listed in section 3.2 and are not sent to the AI as a chat. No onboarding chat transcript is created. | user_profiles (see section 3.2) |
| 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 form). 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 not onboarding: onboarding is a structured form (no AI conversation, see section 3.2), 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. Coach Q&A messages are retained for no more than 30 days and then automatically hard-deleted, and are hard-deleted immediately on account deletion (see sections 4, 6, and 7).
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 |
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:
| 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.
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.
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 (for up to 30 days) lets you continue a thread and review prior answers. Where a message contains health information, it relies on the same explicit health-data consent. |
| 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. |
| Marketing | Art. 6(1)(a) — consent + Art. 10 UŚUDE | Not used in the MVP except for beta-invite and launch updates sent to waitlist sign-ups (see section 3.6). |
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 | 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). |
| Oracle Cloud Infrastructure (hosting provider) | Processor — backend and worker hosting | EU region | All data processed by the app (in transit). |
| Sentry (Functional Software Inc. / Sentry GmbH) | Processor — error telemetry | EU region (Frankfurt, ingest.de.sentry.io) | Stack traces, user ID, context fragments. Health and directly-identifying data are stripped before sending; events are retained no longer than 30 days. |
| PostHog | Processor — product analytics | EU Cloud | Phase 1 (anonymous, cookieless): anonymous event names + campaign context only — no cookies, no localStorage, no user ID, no person profiles; legal basis Art. 6(1)(f). Phase 2 (full capture): usage events + user ID; legal basis Art. 6(1)(a) consent. |
| 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, scrubbed error message and stack-trace frames, request path/method, app version, a coarse browser/OS label, 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. |
| Supabase (Supabase Inc.) — authentication email | Processor — sending account / authentication email (e.g. sign-up confirmation, password reset) | EU region | Email address, email content. |
| Resend (Plus Five Five, Inc.) | Processor — sending transactional / waitlist email (the beta-waitlist confirmation message) | USA (third country) | Your email address and the content of the transactional emails we send you — the beta-waitlist confirmation (with a one-click unsubscribe link) and the plan-ready notification (a service email telling you your training plan has finished generating). (needs lawyer review — confirm the Resend DPA is in force and the chosen US-transfer mechanism before the first production email is sent.) |
| 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 Standard Contractual Clauses (SCCs) of 4 June 2021 (decision 2021/914), together with Anthropic's Data Processing Addendum (DPA).
- 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.
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:
- 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. 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.
- 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:
| Category | Retention period | Justification |
|---|---|---|
| Account data (email, Supabase ID) | for the lifetime of the account + 3 years after deletion (for accountability and potential claims) | Art. 118 of the Polish Civil Code — the general limitation period for claims. |
| 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) | On account deletion the rows are fully deleted (HARD DELETE) as part of the Art. 17 procedure. For non-deleted users the rows are retained for the lifetime of the account; no separate purge is applied in the current beta. | Art. 17 GDPR (right to erasure) + Art. 9 (health data in payloads) — hard delete as the safer option. |
Consent records (consent_records), incl. proof-of-consent IP + user-agent | Retained as an anonymised 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: for the claims-limitation period. | proof that and when consent was given — Art. 7(1) accountability; retention for the establishment, exercise, or defence of legal claims (Art. 17(3)(b) GDPR), 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) | Retained no more than 30 days and then hard-deleted by an automated purge; and hard-deleted immediately on account deletion (Art. 17 erasure, FK cascade). | Art. 17 GDPR (erased on deletion) + Art. 5(1)(e) storage limitation (the 30-day ceiling) given this store can carry Art. 9 health data |
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, EU/Frankfurt) | 30 days | as above; health/PII stripped before sending |
| Complaint correspondence | 6 years from case closure | Art. 442(1) of the Polish Civil Code — the limitation period for tort claims. |
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.
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.