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: 1.7 — Last updated: June 17, 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:

• Part A — List of Subprocessors (Section 3): all third parties that process personal data on behalf of BAS AI, with their role, the data processed, the purpose, the location/international transfer, and the 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 disposal 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 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

• Minimization. Each subprocessor receives only the minimum data necessary for its function.
• Separation between identity and clinical data. The direct identifiers (PII) are kept encrypted in a vault (identity_vault), separated from the clinical tables, which refer to the data subject only by a pseudonymous identifier (profile_id).
• Non-training and minimization in the AI. The AI provider is contractually prohibited from using the data to train or improve models. The effective minimization consists of: removing the direct identifiers (name, tax ID, email, phone — which remain encrypted in the identity_vault and are not sent), replacing them with sex and age; not sending the contacts from the emergency card; and applying safeguards against prompt injection (instruction fence). This minimization is not an on-device de-identification: in the health-record analysis, the AI receives clinical content that is identifiable by sex + age; in document extraction, it receives the raw image/PDF, which may contain a name/tax ID printed on the report. Free-text notes may contain names, which is why we recommend not entering identifying data in text fields.
• No sale of data. 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 lab extraction

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

3.4 Resend — sending transactional emails

RevenueCat is NOT used. MyHealth's monetization runs through native In-App Purchase (StoreKit) — subscription and credits —, 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.

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

• What happens on the iPhone. The reading from HealthKit and the cache on the device do not involve third parties. (There is, today, no on-device de-identification or local OCR before sending to the AI — see 1.1 and 3.2.)
• Data sources connected by the data subject. Oura and WHOOP (Section 3.5) are data originators under the data subject's control, not operators of BAS AI.
• No third-party tracking SDK. The app does not embed any advertising/tracking SDK that sees health data. Today we use no analytics or third-party tracking tool; 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 test under different names/abbreviations/languages as a single parameter (canonical catalog of markers) and to standardize units, the app embeds a reference dictionary derived from LOINC® (Regenstrief Institute, Inc.) and from UCUM. It is embedded licensed content — it works locally as a lookup table. Regenstrief Institute does not receive any personal/clinical data of the data subject, does not process data on behalf of BAS AI, and is not a subprocessor; this is an intellectual-property attribution/license obligation (fulfilled 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 keeping up with the updates (~2x/year).

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).

5. Purpose → Legal Basis → Retention Matrix

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 credits) 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 credit balance (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).

• A single age of 18 for a self-owned account, in any country (or the country's age of civil majority, if higher). This requirement refers to account ownership and is not to be confused with the GDPR's age of autonomous digital consent (Art. 8, between 13 and 16 years old depending on the country). The age attestation (age_attestation) is recorded immutably, with the server's date/time; the registration of a self-owned account by someone under 18 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 rights on the minor's behalf (LGPD Art. 14).
• Multi-guardian. The profile may have more than one guardian: the primary guardian invites another adult via an invitation code with an expiration date. Each invitee receives a role — guardian (views and edits) or companion (read-only). Every authorization is verified on the server on each operation (protection against improper object access / IDOR). The consent relating to the minor is recorded identifying which adult granted it.
• Billing. Paid AI features require the guardian role and are charged to the responsible adult who triggers the action; the dependent has no balance or means of payment of their own. The usage record remains linked to the minor's profile for audit purposes.
• The wearable and Apple Health data never follows a minor's profile — it is always recorded in the adult account holder's profile.
• The same protections apply to minors' data (PII encryption, identity separation, AI non-training) and the best interest of the child/adolescent.
• US (COPPA): MyHealth does not offer accounts to minors and does not collect data directly from children; any minor's data is entered and controlled by a responsible adult, who exercises verifiable parental consent.

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 |

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.