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

Controller (LGPD Art. 5, VI / GDPR "controller"): BAS AI — BAS ARTIFICIAL INTELLIGENCE LTDA CNPJ (Brazilian company ID): 64.106.409/0001-70 Website: www.bas-ai.com Data Protection Officer (DPO) (LGPD Art. 5, VIII): Guilherme Bastian — dpo@bas-ai.com Product: MyHealth — iOS personal health-record app with an educational AI reading (pt/en/es). Document version: 2.11 — 2026-08-03

Nature of the product. MyHealth organizes your health history and offers an educational, prudent reading. It is not a medical device, does not diagnose, and does not prescribe. Every AI observation is marked "(to be confirmed)" and must be validated with your physician. The AI does not check drug interactions, does not check contraindications, and does not cross-check allergies against medications.

Distribution. MyHealth is distributed on the App Store worldwide, except in the European Union/EEA and the United Kingdom at launch. Even so, GDPR/UK-grade protections are adopted as a global baseline applied to every data subject (strictest common denominator).

Effective date. This record is in force as of 2026-06-23. The processing agreements (DPA/SCC) referenced below are signed and in force (see Section 3). 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:

• Part A — List of Subprocessors (Section 3): all third parties that process personal data on behalf of BAS AI, with role, data processed, purpose, location/international transfer, and safeguards.
• Part B — Record of Processing Activities (ROPA, Sections 4 to 7): the inventory of processing activities (GDPR Art. 30 / LGPD Art. 37 style), the purpose → legal basis → retention matrix, the retention and deletion policy, and the account/data deletion procedure.

BAS AI acts as the controller of the personal data processed in MyHealth. The third parties listed in Part A act as processors/sub-processors (LGPD Art. 5, VII / GDPR Art. 28), processing data solely under BAS AI's instructions. There are only three: Supabase, Anthropic, and Resend. Platforms and sources that act as independent controllers (Apple, Oura, WHOOP) are not subprocessors and are described in Section 3.5.

1.1 Principles governing the subprocessor chain

• Minimization. Each subprocessor receives only the minimum data necessary for its function.
• Separation of identity from clinical data. Direct identifiers (PII) are encrypted in a vault (identity_vault), kept apart from the clinical tables, which reference the data subject only by a pseudonymous identifier (profile_id). The cipher is authenticated, deterministic field-level encryption (AEAD) via pgsodium (AES-256), applied to name, contact email, phone, and national ID.
• On-device redaction before AI (best-effort, not de-identification). Before sending a document to the AI, the app applies — on the device itself — a redaction targeting the four direct identifiers of the holder (name, national ID, email, and phone), and it is the redacted copy that goes to the AI. This redaction is best-effort and is not de-identification: when the redaction runs and no identifier matches, or when the identity vault is empty, the original document may proceed; moreover, a report may contain other printed identifiers that the redaction does not cover. We therefore recommend not entering identifying information into free-text fields.
• No training. The AI provider is contractually prohibited from using the data to train or improve models.
• No data sale. No personal data is sold to third parties.
• Controlled chain. No subprocessor may engage a new subprocessor to process your data without an equivalent contractual obligation and without our right to object.

2. Categories of data processed (glossary)

For use in the tables that follow:

3. Part A — List of Subprocessors

3.1 Supabase — infrastructure, database, storage, and authentication

3.2 Anthropic — language model (Claude) for educational reading and exam extraction

Sensitive health journal — does NOT go to Anthropic. The daily records of sensitive habits (alcohol servings, night-time stress/alcohol context — opt-in purpose daily_journal) are NOT shared with Anthropic. They remain stored in the database (Supabase, encrypted at rest) and outside the analysis context (kind allow-list in analysis_core/wearable_context). Any transmission to the AI would require the holder's separate and explicit AI consent, which is not present in this version.

**Wearable annotations (Oura enhanced tags) — free text discarded; only the category code goes to Anthropic under the Health Diary. The free text the holder records in the Oura app (custom name and comment — wearable_annotations, migration 0330) is discarded at import and never stored (it does not reach the record, our records, or our logs). We keep only the standardized category code (the "type": coffee, alcohol, etc.), which is owner-only read (RLS; excluded from read-only family sharing) and deleted on disconnection from the provider. That standardized code — aggregated by week and never as free text — may be part of the context sent to Anthropic when, and only when, the holder keeps the sensitive Health Diary (daily_journal) on; without that consent, it is not sent to the AI. The "separate and explicit consent" the previous version described as not present now exists**: it is precisely daily_journal.

3.3 Resend — transactional email delivery

RevenueCat is NOT used. MyHealth's monetization runs on native In-App Purchase (StoreKit) — subscription and add-on packs (pages/prompts) — with Apple as the merchant of record (see 3.5). There is no third-party subscription intermediary.

3.4 What is NOT a subprocessor

• What happens on the iPhone. HealthKit reading and on-device caching involve no third parties. The redaction of the holder's identifiers happens locally, before sending to the AI (best-effort — see 1.1 and 3.2). There is no local OCR or on-device de-identification.
• Platform and sources that are independent controllers. Apple (platform/IAP/Sign in with Apple/HealthKit) and the wearable providers Oura and WHOOP act as independent controllers of their own platforms — not as BAS AI processors (see Section 3.5).
• No third-party tracking SDK. The app does not embed any advertising/tracking SDK that sees health data. We currently use no third-party analytics or tracking; if that changes, we will update this page and the Privacy Policy before activation, with a new notice (see Section 9).
• Licensed open vocabularies/standards (LOINC® / UCUM). To recognize the same exam under different names/abbreviations/languages as a single parameter (canonical marker catalog) and to standardize units, the app embeds a reference dictionary derived from LOINC® (Regenstrief Institute, Inc.) and UCUM. It is embedded licensed content — it works locally as a lookup table. Regenstrief Institute does not receive any personal/clinical data, does not process data on behalf of BAS AI, and is not a subprocessor; this is an attribution/IP license obligation (met in the Privacy Policy §6.4 and in the app's notices screen), not a data-processing chain. The LOINC License is free, including for commercial use, and requires visible attribution and tracking of updates (~2x/year).

3.5 Platform and data sources — Apple, Oura, and WHOOP (independent controllers; NOT subprocessors)

These entities do not process data on behalf of BAS AI: each is an independent controller of its own platform. Apple is the distribution, optional authentication, push, and payment platform; Oura and WHOOP are data sources/originators connected by the data subject. The wearable flow is inbound only (from the provider into the user's record), via an OAuth connection authorized by the holder and source-specific consent (wearable_sync_oura / wearable_sync_whoop, dual basis LGPD Art. 11, I + GDPR Art. 9(2)(a), revocable). The provider does not receive record data.

Apple Inc. — distribution and OS-services platform, merchant of record for subscription and add-on-pack purchases via native In-App Purchase (StoreKit), provider of Sign in with Apple (when chosen) and push notifications. Read access to Apple Health (HealthKit) is optional and happens locally, on the device (consent wearable_sync_apple_health) — Apple does not take part in the transit of that data to our backend and does not receive MyHealth's clinical base. In payment, BAS AI does not receive or store card data. Compliance with Apple Guideline 5.1.3 (health data never used for marketing, third-party sharing, or AI training) and Guidelines 3.1.1/3.1.2 (digital purchases). Location: US / Apple's global infrastructure, under the Apple Developer Program License Agreement.

Apple Health (HealthKit) does not appear in the wearable network-traffic table because the reading is local, on the device — there is no data traffic between Apple and BAS AI's backend.

Receipt of wearable webhooks (Oura/WHOOP). To receive real-time update/deletion notices, we store a pseudonymous identifier of the holder's WHOOP profile (the numeric user_id the records already carry — never name or email) to route the webhook to the right connection. The webhook only signals a new sync (no clinical data travels in it), the HMAC signature is validated, and the provider's deletion event deletes the corresponding row in the record (deletion parity). Oura subscriptions never subscribe to daily_stress (minimization). The identifier lives in the already-declared Supabase — no new subprocessor and no new international transfer.

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

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

5. Purpose → Legal Basis → Retention Matrix

Clinical-core legal basis (decided). The primary basis of the entire clinical core (record organization, AI reading/extraction, assistant chat, international transfer, family sharing, and wearable sync) is specific, highlighted consent for sensitive data — LGPD Art. 11, I/II "a" / GDPR Art. 9(2)(a) — consistent with the "sovereign record" positioning and revocable at any time. As a subsidiary basis — limited to the security and integrity of processing, compliance with a legal obligation, and carrying out deletion itself — LGPD Art. 7, II and Art. 10 / GDPR Art. 6(1)(c) and (f) apply. The health-protection ground (LGPD Art. 11, II "f" / GDPR Art. 9(2)(h)) is not invoked: GDPR Art. 9(3) conditions that basis on processing by a professional bound by secrecy in the flow, and there is no physician in the loop in MyHealth — the assistant never communicates diagnosis, prognosis, or a therapeutic decision.

HIPAA does not apply. MyHealth is a B2C product under the data subject's own control; BAS AI is not a HIPAA covered entity or business associate. We therefore do not publish "BAA" or "HIPAA compliant".

6. Retention and Deletion Policy (dual-track)

1. General rule (clinical track). Record data (PHI/DEMO, documents, AI conversations, wearables, routine) is kept while the account exists and the holder wants to keep the record organized; it is deleted upon account deletion (Section 7).

1-A. Condensation of wearable series (minimization). Raw daily series of continuous wearable metrics (e.g., SpO2, steps, average walking HR — never manually entered measurements or clinical measurements such as weight, glucose, or blood pressure) may be condensed after 13 months into weekly rollups (minimum/mean/maximum/count) and, after 36 months, into monthly ones (migration 0231; parameters in wearable_condense_config). The raw DELETE only happens in the same transaction as the persisted rollup; condensation never triggers a paid analysis; account deletion also erases the rollups (cascade). Basis: minimization/storage limitation — LGPD art. 6, III; GDPR art. 5(1)(c)/(e).

1. Dual identity track. Direct identity (name/email, encrypted in the identity_vault) is retained only for those who TRANSACTED (subscribed or bought add-on packs), for the jurisdiction's fiscal period: 5 years (Brazil, US, and others), 6 years (UK, Canada), 10 years (EU). For minors and non-payers, identity is DELETED at the moment of deletion — there is no fiscal identity track.
2. Fiscal receipts. Billing/fiscal receipts (subscription and add-on-pack purchases) follow the same jurisdictional fiscal period above (Brazil: CTN, arts. 173 and 174), even if the account is deleted earlier.
3. Access logs. The access_log (audit/security metadata — who, when, which table, action, source IP and the request user-agent on synchronous user-facing accesses — edges analyze-exam/ai-assistant/access-ping, migration 0309; on asynchronous/cron inserts the user-agent is null by design) is kept for 6 months (Brazilian Internet Bill of Rights, art. 15). It is metadata with no clinical content; this term does not justify retaining record content.

4-A. Post-deletion forensic index (account_forensic_hold, migration 0308, applied 2026-07-17). At deletion, and for every account (including minors — DPO gate), a minimized index that survives erasure is kept, containing at most: search identifiers (email, Apple sub, phone, national ID) as HMAC-SHA256 with a dedicated pepper held in a vault (Vault), encrypted by a root key managed outside the database, never exposed (never readable text) + recent IPs in plaintext; and the pseudonymous account identifier (account_ref) with minimal custody metadata (account_id, creation/deletion dates, jurisdiction, term). No PHI, no readable name/email. The HMAC identifiers are PSEUDONYMIZED data — they remain personal data (LGPD Art. 12/13), retained under Art. 16, I; anonymization is NOT invoked (Art. 16, IV). Purpose: fraud prevention, exercise/defense of rights and response to a competent authority within the retention period. Term: applicable limitation period, set by default to the same duration as the fiscal retention period (item 2) for proportionality — not a "fiscal period" —, with automatic purging (purge_legal_retention); for minors, a REDUCED and proportionate term for fraud prevention (never the fiscal one, which does not apply to a minor who does not transact), subject to a proportionality assessment + DPO sign-off. Shielded table (RLS with no policies, no grant to admin_ops); access only via owner-gated SECURITY DEFINER RPCs that audit before resolving. Basis (by purpose): LGPD Art. 16, I (authority) + Art. 7, VI (defense of rights) + Art. 7, IX (fraud, under an LIA); GDPR Art. 6(1)(f) + Art. 17(3)(e). (Fiscal retention — GDPR Art. 6(1)(c)/Art. 17(3)(b) — belongs to account_legal_hold; the Brazilian Internet Bill of Rights Art. 15 governs the 6-month access_log, not this index.) Accounts deleted before this took effect have no hold.

1. AI processing. 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 retention required by law or for abuse prevention. The result incorporated into the record follows the general rule; assistant chat conversations are kept until the holder deletes them.
2. Technical telemetry. Stability/diagnostic telemetry (no PHI) is kept for up to ~12 months, by minimization self-limitation (LGPD art. 6, III) — the Controller's internal policy, not a legally imposed term.
3. Immutability and de-linking of records. The access_log is append-only (UPDATE/DELETE blocked by trigger). The consent_events are de-linked/pseudonymized (HMAC key kept outside the database) — not "anonymous": they preserve proof of when consent was granted/revoked without directly re-identifying the data subject. Revoking consent means inserting a new granted=false event; revocation does not retroactively erase processing already lawfully carried out, but stops future processing for that purpose.
4. Deletion on request. Deletion is carried out at the request of the holder (or legal guardian, in the case of minors), per the Section 7 procedure, within 30 days.

7. Account and Data Deletion Procedure

Account deletion is available in the app itself (Apple requirement) and can also be requested from the DPO (dpo@bas-ai.com).

1. Request. The holder (or legal guardian, for a minor dependent) initiates deletion in the app or by contacting the DPO.
2. Scope. Deletion erases all PHI, documents/reports in Storage, family-sharing links, wearable and routine data (sleep_sessions, daily_scores, health_events, med_intakes, measurements with provider/external_id), lifestyle facts (lifestyle_facts), AI assistant conversations (chat_messages/conversations), support communications (support_tickets/support_ticket_messages), AI service-usage records (ai_usage, credit_ledger and related, except the fiscal retention of purchase receipts), wearable connection data (wearable_connections, oauth_states — encrypted tokens), and account data. Clinical tables are deleted in cascade from profile_id (on delete cascade foreign keys).
3. Managed dependents. Account deletion also erases the data of managed dependents (minor profiles) under that account. Before deleting a minor, the app offers to MIGRATE guardianship of the minor to an existing co-guardian — in which case the minor's profile survives under the new guardian, rather than being deleted.
4. Identity (dual-track). If the holder transacted, their minimal identity (name/email) is retained encrypted only for the jurisdiction's fiscal period (Section 6). If they did not transact — and always for minors — identity is DELETED at the moment of deletion.
5. Effective deletion. Permanent, cascade removal of records and documents; clearing of cached data on the device at logout/deletion. Deletion is permanent, but destruction of encryption keys (crypto-shredding) and absolute irreversibility in backups are not claimed — any backups expire per the infrastructure's retention cycles.
6. Minimum legal retention. Even after deletion, the following are kept: (a) the minimum metadata the law requires (record that deletion occurred); (b) the access logs for the 6-month floor (art. 15) — metadata, no clinical content; (c) the fiscal track (receipts + minimal identity of those who transacted) for the jurisdiction's fiscal period (Section 6); and (d) the minimum forensic index (account_forensic_hold — item 4-A: search identifiers as HMAC + IPs + account_ref/custody metadata, no PHI), for the applicable limitation period (same duration as the fiscal retention period, by proportionality; for minors, a REDUCED term), for fraud prevention, exercise/defense of rights and response to a competent authority, under audited break-glass owner access. None of this reconstitutes the record, which is deleted.
7. Timeframe and confirmation. Deletion is an immediate operation in the database. No automatic receipt is issued; the holder may request confirmation of completion from the DPO — dpo@bas-ai.com — who responds based on the minimal deletion record (LGPD art. 6, X).
8. Subprocessors. Deletion is propagated to the infrastructure (Supabase). 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, as an independent controller) and Resend (email), the respective platform's deletion mechanisms apply to the data each one processes. RevenueCat is not used.
9. Wearable disconnection (selective per-provider purge, without deleting the account). Available on the Integrations screen. Disconnection: (a) revokes tokens at the provider (Oura: oauth/revoke; WHOOP: DELETE /v2/user/access); (b) deletes connection data (CONN); (c) writes consent_events granted=false for the source's purpose; (d) applies the imported-data policy — WHOOP: mandatory purge of all data with source='whoop' (contractual requirement, verifiable by zero count); Oura/HealthKit: the holder chooses to keep or delete. Connect/disconnect/purge events are recorded in the audit log.

8. Minimum age and minors' data

Protection of children and adolescents observes Brazil's Statute of the Child and Adolescent (Law 8.069/1990), Law 15.211/2025 (Digital ECA), LGPD Art. 14, GDPR Art. 8 (reference standard), and COPPA (US).

• Single age of 18 for one's own account, in any country (or the country's civil age of majority, if higher). This requirement relates to account ownership and is not the same as GDPR's age of autonomous digital consent (Art. 8, between 13 and 16 depending on the country). The age attestation (age_attestation) is recorded immutably, with a server timestamp; sign-up of an under-18 with their own account is blocked.
• The minor has no account or email of their own: they exist only as a managed profile (profiles.kind='minor', profiles.managed_by) within an adult guardian's account, who exercises the minor's rights (LGPD Art. 14).
• Multi-guardian. A profile may have more than one guardian: the primary one invites another adult via a time-limited invitation code. Each invitee receives a role — guardian (view and edit) or companion (read-only). Every authorization is verified on the server at each operation (protection against improper object access / IDOR). Consent relating to the minor is recorded identifying which adult granted it. On deletion of the primary guardian's account, the app offers to migrate guardianship of the minor to an existing co-guardian (see Section 7).
• Billing. Paid AI features require a guardian role and are billed to the responsible adult who performs the action; the dependent has no quota, pack, or payment method of their own. The usage record remains linked to the minor's profile for audit.
• Wearable and Apple Health data never follow a minor's profile — they are always recorded on the account's adult holder's profile.
• The same protections (PII encryption, identity separation, AI no-training) and the best interest of the child/adolescent apply to minors' data. The minor's identity is DELETED at the moment of deletion (Section 6).
• US (COPPA): MyHealth does not offer accounts to minors or collect data directly from children; any minor data is entered and controlled by a responsible adult, who exercises verifiable parental consent.

Age verification (Law 15.211/2025 — Digital ECA, in force since 2026-03-17). Age verification is done by self-declaration at sign-up, with the attestation recorded at acceptance (age_attestation, immutable, with a server timestamp).

9. Notice of new subprocessors and right to object

1. Prior due diligence and a DPA with equivalent obligations (minimum: no-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 for security/continuity urgency.
3. Right to object to the DPO (dpo@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. Data subject rights (multi-jurisdiction)

Regardless of jurisdiction, the data subject may, via the app or the DPO (dpo@bas-ai.com): access and export their data (FHIR R4/PDF portability), correct, delete (Section 7), revoke consent at any time, and object to processing based on legitimate interest.

• LGPD (Brazil): Art. 18 rights (confirmation, access, correction, anonymization/deletion, portability, information on sharing, revocation).
• GDPR (global reference standard): rights of access, rectification, erasure, restriction, portability, and objection (Arts. 15–21).
• US — CCPA/CPRA (California): right to know, delete, correct, and opt out of "sale"/"sharing" — BAS AI does not sell or share personal data for behavioral advertising; there are no third-party tracking signals.
• US — Washington My Health My Data (MHMDA): "consumer health data" is processed subject to consent; the data subject may withdraw consent and request deletion; BAS AI does not sell health data.
• Canada (PIPEDA + provincial laws): access, correction, and consent withdrawal, with 6-year fiscal retention where applicable.

11. Version history

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, does not diagnose, and does not replace a healthcare professional's assessment. The AI does not check drug interactions, contraindications, or cross-check allergies against medications. In an emergency, seek medical care immediately.