Skip to content

MyHealth — List of Subprocessors and Record of Processing Activities (ROPA)

Controller (LGPD Art. 5, VI / GDPR "controller"): BAS AI — BAS ARTIFICIAL INTELLIGENCE LTDA CNPJ: 64.106.409/0001-70 Website: www.bas-ai.com Officer / DPO (LGPD Art. 5, VIII): privacy@bas-ai.com — Rua Gomes de Carvalho, 911, Vila Olímpia, São Paulo/SP, ZIP 04547-003, Brazil Product: MyHealth — iOS app for a personal health record and educational AI reading (pt/en/es). Version of this document: 2.0 — Last updated: June 22, 2026

Nature of the product. MyHealth organizes your health history and offers an educational, prudent reading. It is not a medical device, it does not diagnose, and it does not prescribe. Every observation by the AI is marked as "(to be confirmed)" and must be validated with your doctor.
Effectiveness and contracts. The effective force of this record follows the signature of the DPAs/SCC referred to below; until then, it serves as an operational record of the design in production. The contractual instruments are listed by vendor in Section 3. The relationship with Anthropic and with Resend is already governed by a DPA and Standard Contractual Clauses (SCC) IN EFFECT (incorporated into each provider's commercial terms); the Supabase DPA is in effect (signed 2026-06-18; Supabase Pte. Ltd); the terms of the wearable sources (Oura/WHOOP) and of the Apple Developer Program follow the status indicated in each item. The public version of this list is at https://www.bas-ai.com/myhealth/legal/subprocessadores; the version history is published at https://www.bas-ai.com/myhealth/legal/versoes, and each accepted version remains archived.

1. How to read this document

This document has two complementary parts:

BAS AI acts as the controller of the personal data processed in MyHealth. The third parties listed in Part A act as operators/sub-operators (LGPD Art. 5, VII) / processors/sub-processors (GDPR Art. 28), processing data exclusively under the instructions of BAS AI.

1.1 Principles governing the subprocessor chain


2. Categories of data processed (glossary)

For use in the tables that follow:

AbbreviationCategoryExamples
PIIDirect identification (encrypted in the identity_vault)Name/display name, email, phone, document/tax ID
PHIHealth / sensitive dataLab results and markers; conditions/systems; medications; allergies; vaccines; appointments; vital signs and bioimpedance (weight, body fat, blood glucose, blood pressure, heart rate); symptoms and complaints; physical activity (incl. wearable workouts); sleep (sessions and stages — sleep_sessions); continuous wearable metrics (resting HR, HRV, VO2max, steps, energy, skin temperature); providers' proprietary scores (Oura readiness/sleep/stress/resilience; WHOOP recovery/strain — daily_scores); device events (ECG — only the classification and metadata, never the raw trace/waveform; irregular rhythm; high/low HR; atrial fibrillation burden; fall detection — health_events); medication intake records (med_intakes); daily wellbeing check-in; menstrual cycle and reproductive health (flow, intermenstrual bleeding, ovulation test, cervical mucus, pregnancy test — imported from HealthKit into cycle_entries; sexual activity is not imported); self-declared lifestyle habits (smoking — incl. years of smoking —, alcohol, activity, sleep perception, and menopause status — self-declared opt-in, not imported from HealthKit — lifestyle_facts); conversations with the AI assistant (persisted questions and answers — chat_messages/conversations); documents/reports; family history; care team
DEMOPseudonymous clinical-demographic profileBiological sex and date/age on the test date (in profiles, without PII)
LOCOptional locality and languageCountry (country_code — sent to the AI, see 3.2, to regionalize the educational guidance)/state/city; language (locale)
ACCOUNTAccount, authentication, and consentAccount identifier, Sign in with Apple email/identifier, session tokens, MFA factor (TOTP), versioned consent events
TECHTechnical and usage metadataAccess logs (metadata, without clinical content), de-identified usage data, failure/performance telemetry
PAYSubscription billingSubscription status, receipt/transaction (payment processing is done by Apple; BAS AI does not receive card data)
CONNWearable connection dataOAuth connections (wearable_connections: status, scopes, access/refresh tokens encrypted AES-256-GCM server-side, sync cursors) and anti-CSRF states (oauth_states). These are not health data — they are connection data, deleted upon disconnection of the source

3. Part A — List of Subprocessors

3.1 Supabase — infrastructure, database, storage, and authentication

FieldDetail
SubprocessorSupabase Pte. Ltd — the contracting entity and the address are those stated in the signed DPA (Document Ref IUEMY-WMWYS-MIWD9-XVTSF)
RoleOperator/sub-operator (backend hosting)
PurposeHost the MyHealth infrastructure: database (PostgreSQL), document/report storage, account authentication, and edge functions. It supports the clinical_processing purposes and, in AI routing, ai_processing.
Data processedStructured PHI and documents/reports (referenced by the pseudonymous profile_id); PII encrypted field by field (XChaCha20-Poly1305 via pgsodium) in the identity_vault; DEMO; LOC; ACCOUNT (incl. MFA/TOTP factor and consent_events); TECH (access logs access_log). Supabase operates the infrastructure but does not access in clear text the PII in the identity_vault in the normal course of operation (decryption only via a secure function, under the user's own identity).
Location / international transferRegion sa-east-1 (São Paulo, Brazil) — data residency in Brazil. Auxiliary administrative processing (e.g., support) may involve access from other jurisdictions by the subprocessor's personnel, under the safeguards below. For security, the project's ref and the anon/JWT key are not publicly exposed on this page or in external materials.
SafeguardsDPA in effect (signed 2026-06-18; Supabase Pte. Ltd) — includes EU SCCs + transfer safeguards (UK/Switzerland), governed by GDPR + Swiss law + US law; an equivalent mechanism under the LGPD for any transfers; SOC 2 Type 2 + ISO 27001 (Supabase provider certifications); daily backups (14 days); 28-day log retention; encryption in transit (TLS 1.3, with certificate pinning in the app) and at rest; additional field encryption (pgsodium) under our key management; isolation via Row-Level Security (RLS) per verb; audit trail (access_log append-only / pgaudit best-effort); NON-TRAINING clause.

3.2 Anthropic — language models for educational reading and lab extraction

FieldDetail
SubprocessorAnthropic, PBC — the contracting entity and the address will be those stated in Anthropic's DPA, in effect via the Commercial Terms (anthropic.com/legal/data-processing-addendum)
RoleOperator/sub-operator (AI processing)
PurposeProcess, via the Anthropic API, the user's own content to: (a) extract/structure documents and lab results; (b) generate an educational, NON-diagnostic reading (longitudinal analysis of the health record); and (c) respond to the educational assistant chat. It maps to the ai_processing purposes and, when there is an outflow from Brazil, intl_transfer. Web search exists only in the assistant chat: the model is instructed to use only generic clinical terms, without values, dates, age, names, or user identifiers — protection by instructing the model, not by an infallible technical filter; the search is run by Anthropic's infrastructure. The health-record analysis and document-extraction functions do not perform web search.
Data processedThe user's own clinical content (PHI), sent upon consent for AI processing. The minimization applied removes the direct identifiers (name, tax ID, email, phone — replaced by sex and age) and does not send the contacts from the emergency card, but it is not an on-device de-identification: in the health-record analysis, the AI receives clinical content that is identifiable by sex + age (lab markers and trends, measurements and bioimpedance, medications, vaccines, allergies, symptoms, appointments and notes, family history, physical activity, sleep and wearable scores, device events — ECG classification, irregular rhythm, fall, never the raw trace, menstrual cycle and reproductive data, self-declared lifestyle habits — smoking (incl. years of smoking)/alcohol/activity/sleep/menopause status, country (country_code, to regionalize the educational guidance), blood type, and the observations from the emergency card); in document extraction, it receives the raw image/PDF, which may contain a name/tax ID printed on the report. The chat conversations (questions and answers) also travel. When there is a connected wearable source (Section 3.5), the data enters as aggregates in the context of the longitudinal analysis (sleep trends, resting HR, HRV always with the SDNN/rMSSD method, steps, energy, and the provider's scores labeled by brand, without recalculation); raw continuous series are not sent (server-side aggregation, limit of 90 points per metric). Anthropic does not receive the direct PII encrypted in the identity_vault, account data, or connection tokens (CONN). Transient processing; retention limited by the subprocessor (see Safeguards).
Location / international transferProcessing via the Anthropic API, with infrastructure in the United States. International transfer of sensitive personal data from Brazil, carried out only with the specific consent of the data subject.
SafeguardsDPA in effect (Anthropic Commercial Terms); NON-TRAINING clause (inputs and outputs are not used to train or improve models — a contractual commitment); limited retention by the subprocessor (as a rule, deletion within ~30 days, except for retention required by law or to prevent abuse) — there is no contracted "zero retention"/ZDR; EU SCC (Modules 2/3) + UK IDTA + Swiss addendum; an equivalent mechanism under the LGPD; TIA/transfer impact assessment (Schrems II) to be documented before any real data is on the US path; transmission over TLS 1.3 with certificate pinning of api.anthropic.com; strict payload validation; safeguards against prompt injection (instruction fence); no clinical body in the logs of our Edge Functions.

3.3 Apple — App Store, Sign in with Apple, push, HealthKit, and payment (In-App Purchase)

FieldDetail
Subprocessor / platformApple Inc. — the applicable contracting entity by jurisdiction is the one defined in the terms of the Apple Developer Program License Agreement
RoleDistribution platform and OS services; operator to the extent it processes data on our behalf (push, HealthKit); and merchant of record in the processing of payment for subscriptions and add-on packs via native In-App Purchase (StoreKit).
Purpose(a) Distribution of the app (App Store); (b) authentication via Sign in with Apple, when chosen by the user; (c) push notifications; (d) read access to Apple Health (HealthKit) data — implemented, optional, only with the user's explicit authorization and the wearable_sync_apple_health consent (the reading occurs locally, on the device; Apple does not participate in the traffic of that data to our backend); (e) payment processing for the subscription and AI usage packs via native In-App Purchase, as merchant of record.
Data processedACCOUNT (Sign in with Apple identifier, push token); PAY (processing of the subscription and packs payment via App Store / In-App Purchase — BAS AI does not receive or store card data; no health content in the payment flow). The HealthKit PHI is read on the iPhone itself upon granular iOS authorization and written into the user's health record; Apple does not receive MyHealth's clinical base. Compliance with Guideline 5.1.3 (never marketing, third parties, or AI training).
Location / international transferUS and Apple's global infrastructure, in accordance with the applicable terms of the Apple Developer Program. International transfer.
SafeguardsApple Developer Program / Apple Developer Program License Agreement terms; Apple Developer Program terms in effect (accepted); applicable DPA per those terms; SCC to be entered into/equivalent mechanism; Apple Guideline 5.1.3: HealthKit data never used for marketing, sharing with third parties, or model training; Apple Guidelines 3.1.1/3.1.2 for digital purchases; just-in-time permissions; session tokens protected on the device.

3.4 Resend — sending transactional emails

FieldDetail
SubprocessorResend — the contracting entity and the address will be those stated in Resend's DPA in effect (acceptance of terms); EU-US Data Privacy Framework + UK extension certification; SCC
RoleOperator/sub-operator (transactional email provider)
PurposeDeliver the account's transactional emails: authentication access code/OTP and operational account notices. It does not participate in any clinical or AI flow.
Data processedOnly the recipient's email and the email content (code/notice). No health content (PHI), no sensitive account data beyond what is needed for sending, no clinical PII.
Location / international transferUS / global; the effective processing region is stated in Resend's DPA. International transfer.
SafeguardsResend's DPA in effect (acceptance of terms); EU-US Data Privacy Framework + UK extension certification; SCC; equivalent mechanism; non-training/no secondary-use clause; minimization (no health data is shared); TLS in transit.
RevenueCat is NOT used. MyHealth's monetization runs through native In-App Purchase (StoreKit) — subscription and add-on packs —, with Apple as the merchant of record (see 3.3). There is no third-party subscription intermediary.

3.5 Wearable data sources — Oura and WHOOP (originators; NOT subprocessors)

When the user connects a wearable, the provider acts as a data source/originator (independent controller of its own platform), not as an operator of BAS AI: the data flow is inbound only (from the provider into the user's health record), upon an OAuth connection authorized by the data subject and specific consent per source (wearable_sync_oura / wearable_sync_whoop, dual basis LGPD Art. 11, I + GDPR Art. 9(2)(a), revocable). The provider does not receive data from the health record.

FieldOuraWHOOP
EntityOura Health Oy (Finland / EEA) — the address will be the one stated in the API Agreement; the API terms will be accepted upon creation of the developer account, before the integration operatesWHOOP, Inc. (US) — the address will be the one stated in the Developer Terms; the API terms will be accepted upon creation of the developer account, before the integration operates
RoleData source connected by the data subject (independent controller)Data source connected by the data subject (independent controller)
Data collected (per authorized scopes)Sleep (sessions/stages), daily scores (readiness, sleep, activity, stress, resilience), metrics (resting HR, HRV rMSSD, temperature, SpO2, VO2max), daily activity, workoutsSleep (sessions/stages), daily scores (recovery, strain), metrics (resting HR, HRV rMSSD, SpO2, skin temperature), workouts
Connection data (CONN)Encrypted OAuth tokens (AES-256-GCM) only on the server; the app never sees tokens; deleted upon disconnectionSame
Location / international transferCollection from the Oura API (Finland/EEA) → storage in Brazil (sa-east-1)Collection from the WHOOP API (US) → storage in Brazil (sa-east-1)
Disconnection / purgeToken revocation at the provider + consent_events granted=false; the data subject chooses to keep or delete the data already importedRevocation (DELETE /v2/user/access) + consent_events granted=false + mandatory purge of all data originating from WHOOP (the provider's contractual requirement — no option to keep)
Safeguards / contractsOura API Terms/Agreement to be accepted upon creation of the developer account, before the integration operates (with assessment, upon approval, of the 60-day cache clause and the international transfer basis); mandatory brand attribution; scores never recalculated/combinedWHOOP Developer Terms to be accepted upon creation of the developer account, before the integration operates (approval requires a Privacy Policy URL and compliance with the brand guidelines); brand attribution; prohibition on deriving scores
Apple Health (HealthKit) does not appear in this table because the reading is local, on the device (see 3.3 and 3.6) — there is no data traffic between Apple and the BAS AI backend.

3.6 What is NOT a subprocessor


4. Part B — Record of Processing Activities (ROPA)

Inventory of processing activities (GDPR Art. 30 / LGPD Art. 37). The consents per purpose are kept in an append-only record (consent_events), versioned by policy_version, and the Edge Functions verify the consent at runtime (the has_active_consent gate).

#ActivityData categoriesCategories of data subjectsRecipients / subprocessorsInternational transfer
1Registration, authentication, and account security (MFA TOTP)ACCOUNT, PII (encrypted)Adult users; legal guardiansSupabase; Apple (Sign in with Apple); Resend (email/OTP)No (BR), except Sign in with Apple and Resend (US/global)
2Health-record organization (extraction, timeline, trends; daily routine — medication intake med_intakes and wellbeing check-in; lifestyle habits lifestyle_facts)PHI, DEMO, documents/reportsData subjects and dependents (minors)SupabaseNo (BR)
3Educational reading and document extraction by AI (incl. wearable aggregates, cycle, habits, and device events in the context of the longitudinal analysis — see 3.2)PHI (the user's own content, identifiable by sex+age); raw document/image in extractionData subjects and dependentsAnthropicYes — US
4Educational AI assistant chat (questions/answers persisted in chat_messages/conversations; web search only with generic terms — see 3.2)PHI (the user's own content); conversationsData subjects and dependentsAnthropic; Supabase (persistence)Yes — US (Anthropic); persistence BR
5Family sharing (opt-in, read-only)PHI, DEMOData subject and linked family memberSupabaseNo (BR)
6Apple Health (HealthKit) sync — optional, local on-device reading, continuous (background delivery)PHI (measurements, continuous metrics, sleep, workouts, device events, cycle/reproductive)Data subjectsLocal reading (iPhone); Supabase storageNo (local reading; storage BR)
7Portability / export (FHIR R4, PDF) — includes wearable data, habits, AI conversations, and routine recordsPHI, DEMO, PIIData subjects and dependentsGenerated in the app/backend; delivered to the data subjectNo
8Account, subscription, and add-on packs (native In-App Purchase / StoreKit); usage telemetry and AI billing (ai_usage, credit_ledger)ACCOUNT, PAY, TECH (no PHI in the payment flow)Subscribers; guardians (a minor's billing)Apple (merchant of record); SupabaseYes — Apple (US/global); persistence BR
9Security, audit, and abuse preventionTECH (access metadata, no PHI)All usersSupabaseNo (BR)
10Stability / diagnostics telemetryTECH (no PHI)All usersBAS AI — today with no observability third party; if adopted, it will be listed on this page before activationNo (BR) — today with no third party
11Management of versioned consentsACCOUNT (consent_events)All usersSupabaseNo (BR)
12Age attestation (age_attestation) — declaration of 18+; blocking of minor registration; immutable record with server date/timeACCOUNTAll usersSupabaseNo (BR)
13Oura sync — OAuth connection, collection via API and webhook (sleep sleep_sessions, scores daily_scores, metrics, workouts)PHI (wearable), CONNData subjectsOura Health Oy (source/originator — see 3.5); SupabaseYes — collection from Finland/EEA → BR
14WHOOP sync — OAuth connection, collection via API and webhook (sleep, recovery/strain, metrics, workouts)PHI (wearable), CONNData subjectsWHOOP, Inc. (source/originator — see 3.5); SupabaseYes — collection from the US → BR
15Wearable connection management (encrypted tokens, OAuth state, revocation, and purge upon disconnection)CONNData subjectsSupabase (access restricted to service_role; the app never reads tokens)No (BR)

5. Purpose → Legal Basis → Retention Matrix

PurposeLGPD legal basisGDPR legal basisRetention
Clinical processing (clinical_processing) — organize the health recordArt. 7, I and Art. 11, I (specific and prominent consent for sensitive data)Art. 6(1)(a) + Art. 9(2)(a) (explicit consent)As long as the account exists; removed on request (Section 7)
AI processing (ai_processing) — document extraction, educational reading, and assistant chatArt. 7, I and Art. 11, I (specific consent)Art. 6(1)(a) + Art. 9(2)(a)Transient processing at Anthropic, with limited retention by the subprocessor (as a rule, deletion within ~30 days) — no contracted "zero retention"/ZDR; the result is kept in the health record as long as the account exists; chat conversations persisted until deletion by the data subject
International transfer (intl_transfer) — outflow to Anthropic/US in AI processingArt. 7, I; Art. 11, I; Art. 33Art. 6(1)(a) + Art. 9(2)(a); Arts. 44–49Transient; limited retention at the destination (~30 days), per Anthropic's terms; SCC in effect (Anthropic DPA) + TIA to be documented
Family sharing (family_sharing) — opt-in, read-onlyArt. 7, I and Art. 11, I (consent)Art. 6(1)(a) + Art. 9(2)(a)Active link until revocation; the invitation expires in 7 days
Wearable sync (wearable_sync_apple_health / wearable_sync_oura / wearable_sync_whoop) — specific consent per source, recorded before any reading/pullArt. 7, I and Art. 11, I (specific and prominent consent; revocable)Art. 6(1)(a) + Art. 9(2)(a) (explicit consent; revocable)Imported data: general rule (as long as the account exists). On disconnection: tokens/connection (CONN) always deleted; WHOOPmandatory purge of the imported data (the provider's contractual requirement); Oura/HealthKit — the data subject chooses to keep (under active consent) or delete
Data of minors in careArt. 14 (best interest; guardian's consent)Art. 6(1)(a)/Art. 8 + Art. 9(2)(a), exercised by the guardianAs long as the guardian's account exists; removed on request
Age attestation (age_attestation) — declaration of 18+ at registrationArt. 14 + Law 15.211/2025 (Digital ECA)Art. 8Immutable record as long as the account exists (proof of compliance)
Account, subscription, and packs (In-App Purchase) — maintain the account and process the subscription and AI usage packs (measured in pages and prompts); a minor's AI consumption is charged to the guardianArt. 7, V (performance of a contract); Art. 7, II and Art. 16, I (mandatory tax record-keeping of receipts)Art. 6(1)(b); Art. 6(1)(c) (tax record-keeping)Account: as long as it exists. Tax/billing receipts: 5 years (CTN, Arts. 173 and 174 — tax lapse and limitation periods), regardless of account deletion
Security, audit, and abuse preventionArt. 7, II (legal obligation) and Art. 10 (legitimate interest) — not Art. 11, II "f" (health protection)Art. 6(1)(c) (legal obligation) and Art. 6(1)(f) (legitimate interest) — not Art. 9(2)(h)Access logs (date/time + IP, metadata without clinical content): minimum of 6 months (Brazilian Internet Civil Framework, Law 12.965/2014, Art. 15 — legal retention floor). This floor refers to the access log, which is not health data and does not justify retaining health-record content
Technical telemetry / stabilityArt. 7, IX (legitimate interest)Art. 6(1)(f)Up to ~12 months, by self-limited minimization (LGPD Art. 6, III) — an internal policy of the Controller, not a period imposed by law; no PHI
Legal basis of the clinical core (decided). The primary basis of the entire clinical core (health-record organization, AI reading/extraction, assistant chat, international transfer, family sharing, and wearable sync) is the specific and prominent consent for sensitive data — LGPD Art. 11, I/II "a" / GDPR Art. 9(2)(a) — consistent with the "sovereign health record" positioning and revocable at any time. As a subsidiary basis — restricted to the security and integrity of the processing, to compliance with a legal obligation, and to the execution of the data deletion itself — LGPD Art. 7, II and Art. 10 / GDPR Art. 6(1)(c) and (f) apply. We do NOT invoke the health protection ground (LGPD Art. 11, II "f" / GDPR Art. 9(2)(h)): GDPR Art. 9(3) conditions that basis on processing by a professional bound by confidentiality in the flow, and there is no doctor in the loop of MyHealth — the assistant never communicates a diagnosis, prognosis, or therapeutic decision.

6. Retention and Disposal Policy

  1. General rule. Data is kept as long as the account exists and the data subject wants to keep the health record organized.
  2. Legal periods. Billing/tax data (receipts for the purchase of the subscription and add-on packs) is kept for 5 years to comply with tax obligations (CTN, Arts. 173 and 174 — lapse and limitation), even if the account is deleted earlier. The access logs (audit/security metadata — who, when, which table, action, source IP) are kept for at least 6 months, under Art. 15 of Law 12.965/2014 (Brazilian Internet Civil Framework) — this is the legal retention floor, and the access log is not clinical content, so this period does not justify retaining the health record. The audit logs never contain clinical content.
  3. AI processing. The content sent to Anthropic is transient; the subprocessor retains it for a limited period and then deletes it (as a rule, within ~30 days), except for retention required by law or to prevent abuse — there is no contracted "zero retention"/ZDR. The result incorporated into the health record follows the general rule; the assistant chat conversations are kept until the data subject deletes them.
  4. Technical telemetry. The stability/diagnostics telemetry (no PHI) is kept for up to ~12 months, by self-limited minimization (LGPD Art. 6, III) — this is an internal policy of the Controller, not a period imposed by law.
  5. No automatic purging due to inactivity. Today there is no routine for automatic deletion due to prolonged inactivity or due to a maximum period per category — and this document does not assert any such routine is in effect. When the time-based retention policy / maximum period per category is defined — in keeping with the storage-limitation principle (GDPR Art. 5(1)(e)) —, it will be stated here and in the Privacy Policy.
  6. Deletion on request. Deletion is carried out at the request of the data subject (or the legal guardian, in the case of minors), under the procedure in Section 7, within 30 days.
  7. Immutability of the records. consent_events and access_log are append-only (UPDATE/DELETE blocked by a trigger): revoking consent is inserting a new granted=false event; revocation does not retroactively erase the processing already lawfully carried out, but it halts the future processing of that purpose.

7. Account and Data Deletion Procedure

Account deletion is available directly in the app (an Apple requirement) and can also be requested from the Officer (privacy@bas-ai.com).

  1. Request. The data subject (or the legal guardian, in the case of a dependent minor) initiates the deletion in the app or by contacting the Officer.
  2. Scope. The deletion covers: the structured health-record data (PHI/DEMO), the documents/reports in Storage, the encrypted PII in the identity_vault, the family-sharing links, the wearable and routine data (sleep_sessions, daily_scores, health_events, med_intakes, measurements with provider/external_id), the lifestyle habits (lifestyle_facts), the conversations with the AI assistant (chat_messages/conversations), the AI usage records and quota balance (pages/prompts) (ai_usage, credit_ledger, and related — except for the tax retention of purchase receipts), the wearable connection data (wearable_connections, oauth_states — encrypted tokens), and the account data. The clinical tables are deleted in cascade from the profile_id (foreign keys on delete cascade).
  3. Effective deletion. Permanent, cascade removal of the records and documents; clearing of the data cached on the device on logout/deletion. The deletion is permanent, but we do not claim destruction of encryption keys (crypto-shredding) or absolute irreversibility in backups — any backup copies expire according to the infrastructure's retention cycles.
  4. Minimum legal retention. Even after deletion, the following are kept: (a) the minimum metadata that the law requires (a record that the deletion occurred); (b) the access logs for the 6-month floor (Internet Civil Framework, Art. 15) — metadata, without clinical content; and (c) the billing/tax receipts for 5 years (CTN, Arts. 173 and 174). None of this reconstitutes the health record, which is deleted.
  5. Timeframe and confirmation. The deletion is an immediate operation in the database. There is no automatic receipt issued; the data subject may request confirmation of completion from the Officer (DPO)privacy@bas-ai.com — who responds based on the minimum deletion record (LGPD Art. 6, X).
  6. Subprocessors. The deletion is propagated to the infrastructure (Supabase). The content sent to Anthropic is transient and retained for a limited period (~30 days) and then deleted by the subprocessor, per its terms. For Apple (incl. purchase/subscription data via In-App Purchase) and Resend (email), the deletion mechanisms of the respective platform apply to the data each one processes. RevenueCat is not used.
  7. Wearable disconnection (selective purge per provider, without deleting the account). Available on the Integrations screen. The disconnection: (a) revokes the tokens at the provider (Oura: oauth/revoke; WHOOP: DELETE /v2/user/access); (b) deletes the connection data (CONN); (c) records consent_events granted=false for the source's purpose; (d) applies the imported-data policy — WHOOP: mandatory purge of all data with source='whoop' (a contractual requirement, verifiable by a zero count); Oura/HealthKit: the data subject chooses to keep or delete. Connect/disconnect/purge events are recorded in the audit trail.

8. Minimum age and minors' data

The protection of children and adolescents follows the Statute of the Child and Adolescent (Law 8.069/1990), Law 15.211/2025 (Digital ECA), Art. 14 of the LGPD, Art. 8 of the GDPR (EEA), and COPPA (US).

Age verification (Law 15.211/2025 — Digital ECA, in effect since 03/17/2026). Today, age verification is done by self-declaration, with the attestation recorded at acceptance (age_attestation, immutable, with the server's date/time); reinforced age-verification mechanisms are under assessment to fully comply with the "effective age-verification mechanism" required by the Digital ECA.

9. Notification of new subprocessors and the right to object

  1. Prior due diligence and a DPA with equivalent obligations (at a minimum: non-training; international transfer safeguards — Standard Contractual Clauses / SCC and an equivalent mechanism under the LGPD; contractual retention limits where applicable).
  2. Prior notice with a 30-day objection window before the new subprocessor processes data, except in cases of security/continuity urgency.
  3. Right to object to the Officer (privacy@bas-ai.com); where the purpose depends on consent (ai_processing, intl_transfer, family_sharing, wearable_sync_*), the new processing does not occur without the recorded consent.

10. Version history

| Version | Date | Change |

1.52026-06-11Publication: all review markers removed (text 100% publishable); public URLs filled in (subprocessors and version history at www.bas-ai.com/myhealth/legal); deletion corrected (immediate, with no automatic receipt — confirmation via the DPO); on-device PII redaction recorded.
1.0— (archived version; see the published history)Initial publication. Active subprocessors: Supabase (BR, sa-east-1) and Anthropic (AI). Apple as platform/operator (App Store, Sign in with Apple, push, future HealthKit). RevenueCat then planned (not active) — later dropped in 1.3.
1.12026-06-10Wearable integrations: new PHI categories (sleep, continuous metrics, proprietary scores, device events, med_intakes, check-in, menstrual cycle coming soon) and the CONN category; Apple HealthKit implemented (local reading); Oura Health Oy and WHOOP, Inc. as sources/originators (Section 3.5); ROPA activities 11–13; wearable_sync_* purposes (LGPD Art. 11 + GDPR Art. 9); wearable aggregates in the AI context; purge on disconnection (WHOOP mandatory).
1.32026-06-11Factual correction and synchronization with the code in production: Anthropic = infrastructure in the US (international transfer), with limited retention (~30 days) — any claim of "zero retention/ZDR" and of "BAA" removed; honesty about what the AI receives (content identifiable by sex+age in analysis; raw image/PDF in extraction; chat conversations; no on-device de-identification); menstrual cycle and lifestyle habits already in production and sent to the AI; device events only as classification (ECG without the raw trace); RevenueCat removed (not used) and replaced by native In-App Purchase with Apple as merchant of record; new subprocessor Resend (transactional email); assistant chat as its own activity (persisted conversations); multi-guardian minors with billing of the triggering guardian and server-side authorization verification; age_attestation and a fixed age of 18 (ownership ≠ GDPR Art. 8 digital consent); broadened deletion/portability scope (lifestyle_facts, conversations, ai_usage/credits, IAP); crypto-shredding claim removed; security note (do not expose the ref/anon JWT); controller/DPO updated. DPA/SCC/TIA marked as to be signed/documented.
1.42026-06-11Concrete retention periods in the ROPA (synchronized with the Policy): access logs — 6-month floor (Internet Civil Framework, Law 12.965/2014, Art. 15), metadata without clinical content; tax/billing receipts — 5 years (CTN, Arts. 173 and 174); telemetry — ~12 months by self-limited minimization (LGPD Art. 6, III), an internal policy, not a legal period; recorded honestly (not as a routine in effect) the absence of automatic purging due to inactivity (GDPR Art. 5(1)(e)). Legal basis decided: clinical core = primary consent (LGPD Art. 11, II "a" / GDPR Art. 9(2)(a)); subsidiary basis for security, legal obligation, and deletion = LGPD Art. 7, II and Art. 10 / GDPR Art. 6(1)(c) and (f); health protection rejected (LGPD Art. 11, II "f" / GDPR Art. 9(2)(h)) because there is no doctor in the loop (GDPR Art. 9(3)).
1.52026-06-12Canonical catalog of markers (LOINC®/UCUM): recorded the embedded reference dictionary that recognizes the same test under different nomenclatures as a single parameter — licensed content, NOT a subprocessor (Regenstrief receives no personal data); attribution fulfilled in the Privacy Policy §6.4 and in the app's notices screen (Section 3.6). No new personal data collected and no new international transfer → does not trigger re-consent.
1.62026-06-14Factual alignment (reproductive health and AI context) — with no new subprocessor chain and no new international transfer: (a) made explicit that the HealthKit pregnancy test is written into cycle_entries (ROPA activity 6, already existing — local on-iPhone reading, Apple is not a subprocessor of that flow); (b) recorded as self-declared opt-in data in lifestyle_facts (NOT imported from HealthKit) the menopause status and the years of smoking (smoking_years), which form part of the AI context under the already-consented ai_processing; (c) confirmed that country (country_code) and the self-reported observations from the emergency card (emergency_info.notes) now form part of the context sent to Anthropic (ROPA activity 3, an already-existing flow — the country_code is used to regionalize the educational guidance for emergency/crisis and to contextualize the reading; see the LOC glossary and Section 3.2): no new subprocessor, no new destination — the same ai_processing/intl_transfer regime already declared. The retention of reproductive data is reconfirmed (general PHI rule; cascade deletion; ~30 days transient at Anthropic). Does not trigger re-consent (categories and flows already consented; it is a more precise description, not new processing — policy_version remains 1.6). Post-Dobbs reproductive risk incorporated into the DPIA (R-19).
1.72026-06-17Anthropic's and Resend's DPA/SCC described as in effect (previously "to be signed"); removal of draft caveats; translation corrections + created the EN/ES versions.
1.92026-06-21Monetization: migration from the credits model to a service quota (pages/prompts) + add-on packs that do not expire; generalization of the AI model name (Anthropic retained as subprocessor).
2.02026-06-22Price update for the plan and the add-on packs; no new subprocessor chain and no new international transfer. Triggers re-consent (a new versioned acceptance in the app) due to the price change.

The version history is published at https://www.bas-ai.com/myhealth/legal/versoes; each accepted version remains archived.


Non-diagnosis note. MyHealth organizes your health history and offers an educational, prudent reading. It is not a medical device, it does not diagnose, and it does not replace the assessment of a health professional. In an emergency, seek medical care immediately.