MyHealth — Lista de Subprocessadores e Registro das Operações de Tratamento (ROPA)

Controlador (LGPD Art. 5º, VI / GDPR "controller"): BAS AI — BAS ARTIFICIAL INTELLIGENCE LTDA CNPJ: 64.106.409/0001-70 Site: www.bas-ai.com Encarregado / DPO (LGPD Art. 5º, VIII): Guilherme Bastian — dpo@bas-ai.com Produto: MyHealth — aplicativo iOS de prontuário pessoal de saúde e leitura educativa por IA (pt/en/es). Versão deste documento: 2.10 — 2026-07-19

Natureza do produto. O MyHealth organiza o seu histórico de saúde e oferece uma leitura educativa e prudente. Não é dispositivo médico, não faz diagnóstico e não prescreve. Toda observação da IA é marcada como "(a confirmar)" e deve ser validada com o seu médico. A IA não verifica interações medicamentosas, não verifica contraindicações e não cruza alergia com medicamento.

Distribuição. O MyHealth é distribuído na App Store em escala mundial, exceto na União Europeia/EEE e no Reino Unido no lançamento. Ainda assim, as proteções de padrão GDPR/UK são adotadas como base global aplicada a todos os titulares (denominador mais estrito).

Vigência. Este registro está em vigor a partir de 2026-06-23. Os contratos de tratamento (DPA/SCC) referidos adiante estão assinados e vigentes (ver Seção 3). A versão pública desta lista fica em https://www.bas-ai.com/myhealth/legal/subprocessadores; o histórico de versões fica publicado em https://www.bas-ai.com/myhealth/legal/versoes, e cada versão aceita permanece arquivada.

1. Como ler este documento

Este documento tem duas partes complementares:

• Parte A — Lista de Subprocessadores (Seção 3): todos os terceiros que tratam dados pessoais em nome da BAS AI, com papel, dados tratados, finalidade, localização/transferência internacional e salvaguardas.
• Parte B — Registro das Operações de Tratamento (ROPA, Seções 4 a 7): o inventário das atividades de tratamento (estilo GDPR Art. 30 / LGPD Art. 37), a matriz finalidade → base legal → retenção, a política de retenção e eliminação, e o procedimento de exclusão de conta/dados.

A BAS AI atua como controlador dos dados pessoais tratados no MyHealth. Os terceiros listados na Parte A atuam como operadores/suboperadores (LGPD Art. 5º, VII) / processors/sub-processors (GDPR Art. 28), tratando dados exclusivamente sob as instruções da BAS AI. São apenas três: Supabase, Anthropic e Resend. Plataformas e fontes que atuam como controladores independentes (Apple, Oura, WHOOP) não são subprocessadores e estão descritas na Seção 3.5.

1.1 Princípios que governam a cadeia de subprocessadores

• Minimização. Cada subprocessador recebe apenas o mínimo de dados necessário à sua função.
• Separação entre identidade e dados clínicos. Os identificadores diretos (PII) ficam cifrados em um cofre (identity_vault), apartados das tabelas clínicas, que referenciam o titular apenas por um identificador pseudônimo (profile_id). A cifra é criptografia de campo autenticada (AEAD) determinística via pgsodium (AES-256), aplicada a nome, e-mail de contato, telefone e documento nacional.
• Tarja on-device antes da IA (best-effort, não de-identificação). Antes de enviar um documento à IA, o app aplica no próprio aparelho uma tarja dirigida aos quatro identificadores diretos do titular (nome, CPF/documento, e-mail e telefone), e é a cópia tarjada que segue para a IA. Essa tarja é best-effort e não é uma de-identificação: quando a tarja roda e nenhum identificador casa, ou quando o cofre de identidade está vazio, o documento original pode seguir; além disso, um laudo pode conter outros identificadores impressos que a tarja não cobre. Por isso recomenda-se não inserir identificação em campos de texto livre.
• Não-treinamento. O fornecedor de IA está contratualmente proibido de usar os dados para treinar ou aprimorar modelos.
• Sem venda de dados. Nenhum dado pessoal é vendido a terceiros.
• Cadeia controlada. Nenhum subprocessador pode contratar novo subprocessador para tratar seus dados sem obrigação contratual equivalente e sem o nosso direito de objeção.

2. Categorias de dados tratados (glossário)

Para uso nas tabelas a seguir:

3. Parte A — Lista de Subprocessadores

3.1 Supabase — infraestrutura, banco de dados, armazenamento e autenticação

3.2 Anthropic — modelo de linguagem (Claude) para leitura educativa e extração de exames

Diário de saúde sensível — NÃO vai à Anthropic. Os registros diários de hábitos sensíveis (doses de álcool, contexto de estresse/álcool da noite — finalidade opt-in daily_journal) NÃO são compartilhados com a Anthropic. Permanecem armazenados no banco (Supabase, criptografados em repouso) e fora do contexto de análise (allow-list de kinds em analysis_core/wearable_context). Um eventual envio à IA exigiria um consentimento de IA separado e explícito do titular, inexistente nesta versão.

**Anotações de vestível (Oura enhanced tags) — texto livre descartado; só o código de categoria vai à Anthropic sob o Diário de saúde. O texto livre que o titular registra no app da Oura (nome personalizado e comentário — wearable_annotations, mig 0330) é descartado na importação e nunca chega a ser guardado (não vai ao prontuário, aos nossos registros nem aos logs). Guardamos apenas o código de categoria padronizado (o "tipo": café, álcool etc.), de leitura dono-só (RLS; fora do compartilhamento familiar read-only) e apagado na desconexão do provedor. Esse código padronizado — agregado por semana e nunca como texto livre — pode integrar o contexto enviado à Anthropic quando, e somente quando, o titular mantém o Diário de saúde sensível (daily_journal) ativo; sem esse consentimento, não é enviado à IA. O "consentimento separado e explícito" que a versão anterior descrevia como inexistente passa a existir**: é justamente o daily_journal.

3.3 Resend — envio de e-mails transacionais

RevenueCat NÃO é utilizado. A monetização do MyHealth roda por In-App Purchase nativo (StoreKit) — assinatura e pacotes avulsos (páginas/prompts) —, com a Apple como fornecedor responsável pela transação (merchant of record; ver 3.5). Não há intermediário de assinaturas de terceiros.

3.4 O que NÃO é subprocessador

• O que ocorre no iPhone. A leitura do HealthKit e o cache no aparelho não envolvem terceiros. A tarja dos identificadores do titular ocorre localmente, antes do envio à IA (best-effort — ver 1.1 e 3.2). Não há OCR local nem de-identificação no aparelho.
• Plataforma e fontes que são controladores independentes. Apple (plataforma/IAP/Sign in with Apple/HealthKit) e os provedores de wearable Oura e WHOOP atuam como controladores independentes das suas próprias plataformas — não como operadores da BAS AI (ver Seção 3.5).
• Sem SDK de tracking de terceiros. O app não embarca SDK de publicidade/rastreamento que veja dados de saúde. Hoje não usamos nenhuma ferramenta de analytics ou rastreamento de terceiros; se isso mudar, atualizaremos esta página e a Política de Privacidade antes da ativação, com novo aviso (ver Seção 9).
• Vocabulários/padrões abertos licenciados (LOINC® / UCUM). Para reconhecer o mesmo exame sob nomes/siglas/idiomas diferentes como um único parâmetro (catálogo canônico de marcadores) e padronizar unidades, o app embarca um dicionário de referência derivado do LOINC® (Regenstrief Institute, Inc.) e do UCUM. É conteúdo licenciado embarcado — funciona localmente como uma tabela de consulta. A Regenstrief Institute não recebe qualquer dado pessoal/clínico do titular, não trata dados em nome da BAS AI e não é subprocessadora; trata-se de obrigação de atribuição/licença de propriedade intelectual (cumprida na Política de Privacidade §6.4 e na tela de avisos do app), não de cadeia de tratamento de dados. A LOINC License é gratuita inclusive para uso comercial e exige atribuição visível e acompanhamento das atualizações (~2x/ano).

3.5 Plataforma e fontes de dados — Apple, Oura e WHOOP (controladores independentes; NÃO são subprocessadores)

Estas entidades não tratam dados em nome da BAS AI: cada uma é controladora independente da sua própria plataforma. A Apple é a plataforma de distribuição, autenticação opcional, push e pagamento; Oura e WHOOP são fontes de dados/originadores conectadas pelo próprio titular. O fluxo de wearable é apenas de entrada (do provedor para o prontuário do usuário), mediante conexão OAuth autorizada pelo titular e consentimento específico por fonte (wearable_sync_oura / wearable_sync_whoop, base dupla LGPD Art. 11, I + GDPR Art. 9(2)(a), revogável). O provedor não recebe dados do prontuário.

Apple Inc. — plataforma de distribuição e serviços de SO, fornecedor responsável pela transação (merchant of record) das compras de assinatura e pacotes avulsos via In-App Purchase nativo (StoreKit), provedor de Sign in with Apple (quando escolhido) e de notificações push. O acesso de leitura ao Apple Health (HealthKit) é opcional e ocorre localmente, no dispositivo (consentimento wearable_sync_apple_health) — a Apple não participa do tráfego desses dados ao nosso backend e não recebe a base clínica do MyHealth. No pagamento, a BAS AI não recebe nem armazena dados de cartão. Conformidade com a Apple Guideline 5.1.3 (dados de saúde nunca usados para marketing, compartilhamento com terceiros ou treino de IA) e com as Diretrizes 3.1.1/3.1.2 (compras digitais). Localização: EUA / infraestrutura global da Apple, sob os termos do Apple Developer Program License Agreement.

O Apple Health (HealthKit) não consta da tabela de wearables com tráfego de rede porque a leitura é local, no dispositivo — não há tráfego de dados entre a Apple e o backend da BAS AI.

Recebimento de webhooks de wearable (Oura/WHOOP). Para receber avisos de atualização/exclusão em tempo real, guardamos um identificador pseudônimo do perfil do titular na WHOOP (o user_id numérico que os registros já trazem — nunca nome ou e-mail) para rotear o webhook à conexão certa. O webhook apenas sinaliza uma nova sincronização (nenhum dado clínico trafega nele), a assinatura HMAC é validada, e o evento de exclusão do provedor apaga a linha correspondente no prontuário (paridade de exclusão). As subscriptions da Oura nunca assinam daily_stress (minimização). O identificador vive na Supabase já declarada — sem novo subprocessador e sem transferência internacional nova.

4. Parte B — Registro das Operações de Tratamento (ROPA)

Inventário das atividades de tratamento (GDPR Art. 30 / LGPD Art. 37). Os consentimentos por finalidade ficam em registro append-only (consent_events), versionados por policy_version, e as Edge Functions verificam o consentimento em tempo de execução (gate has_active_consent).

5. Matriz Finalidade → Base Legal → Retenção

Base legal do núcleo clínico (decidida). A base primária de todo o núcleo clínico (organização do prontuário, leitura/extração por IA, chat assistente, transferência internacional, compartilhamento familiar e sincronização de wearables) é o consentimento específico e destacado para dado sensível — LGPD Art. 11, I/II "a" / GDPR Art. 9(2)(a) — coerente com o posicionamento de "prontuário soberano" e revogável a qualquer tempo. Como base subsidiária — restrita à segurança e integridade do tratamento, ao cumprimento de obrigação legal e à execução da própria exclusão de dados — aplicam-se LGPD Art. 7, II e Art. 10 / GDPR Art. 6(1)(c) e (f). NÃO se invoca a hipótese de tutela da saúde (LGPD Art. 11, II "f" / GDPR Art. 9(2)(h)): o GDPR Art. 9(3) condiciona essa base a tratamento por profissional sujeito a sigilo no fluxo, e não há médico no loop do MyHealth — o assistente nunca comunica diagnóstico, prognóstico nem decisão terapêutica.

HIPAA não se aplica. O MyHealth é um produto B2C sob controle do próprio titular; a BAS AI não é covered entity nem business associate da HIPAA. Por isso não publicamos "BAA" nem "HIPAA compliant".

6. Política de Retenção e Eliminação (duplo-trilho)

1. Regra geral (trilho clínico). Os dados do prontuário (PHI/DEMO, documentos, conversas de IA, wearables, rotina) são mantidos enquanto a conta existir e o titular quiser manter o prontuário organizado; são eliminados na exclusão da conta (Seção 7).

1-A. Condensação de séries de vestível (minimização). Séries diárias brutas de métricas contínuas de vestível (ex.: SpO2, passos, FC média de caminhada — nunca medidas manuais nem medidas clínicas como peso, glicose ou pressão) podem ser condensadas depois de 13 meses em rollups semanais (mínimo/média/máximo/contagem) e, depois de 36 meses, em mensais (mig 0231; parâmetros em wearable_condense_config). O DELETE do bruto só ocorre na mesma transação do rollup persistido; a condensação nunca dispara análise paga; a exclusão de conta apaga também os rollups (cascata). Base: minimização/limitação de armazenamento — LGPD art. 6º, III; GDPR art. 5(1)(c)/(e).

1. Duplo-trilho de identidade. A identidade direta (nome/e-mail, cifrada no identity_vault) é retida apenas para quem TRANSACIONOU (assinou ou comprou pacotes avulsos), pelo prazo fiscal da jurisdição: 5 anos (Brasil, EUA e demais), 6 anos (Reino Unido, Canadá), 10 anos (UE). Para menores e para não-pagantes, a identidade é APAGADA no ato da exclusão — não há trilho fiscal de identidade.
2. Comprovantes fiscais. Os comprovantes de faturamento/fiscais (compra de assinatura e pacotes avulsos) seguem o mesmo prazo fiscal da jurisdição acima (Brasil: CTN, arts. 173 e 174), ainda que a conta seja excluída antes.
3. Logs de acesso. O access_log (metadado de auditoria/segurança — quem, quando, qual tabela, ação, IP de origem e user-agent do request nos acessos síncronos voltados ao usuário — edges analyze-exam/ai-assistant/access-ping, mig 0309; nos inserts assíncronos/cron o user-agent fica nulo por desenho) é guardado por 6 meses (Marco Civil da Internet, art. 15). É metadado sem conteúdo clínico; esse prazo não justifica reter prontuário.

4-A. Índice forense pós-exclusão (account_forensic_hold, mig 0308, aplicada 2026-07-17). No ato da exclusão, e para toda conta (inclusive menores — gate DPO), guarda-se um índice minimizado que sobrevive ao apagamento, contendo no máximo: identificadores de busca (e-mail, Apple sub, telefone, national_id) em HMAC-SHA256 com pepper dedicado guardado em cofre (Vault), cifrado por chave-raiz gerida fora do banco, nunca exposto (nunca texto legível) + IPs recentes em texto; e o identificador pseudônimo da conta (account_ref) com metadados mínimos de guarda (account_id, datas de criação/exclusão, jurisdição, prazo). Sem PHI, sem nome/e-mail legível. Os identificadores em HMAC são dado PSEUDONIMIZADO — permanecem dado pessoal (LGPD Art. 12/13), retidos sob o Art. 16, I; não se invoca anonimização (Art. 16, IV). Finalidade: prevenção a fraude, exercício/defesa de direitos e resposta a autoridade competente dentro do prazo de guarda. Prazo: prazo prescricional aplicável, fixado por padrão na mesma duração do prazo de guarda fiscal (item 2) por proporcionalidade — não "prazo fiscal" —, com expurgo automático (purge_legal_retention); para menores, prazo REDUZIDO e proporcional à prevenção a fraude (nunca o fiscal, que não se aplica a menor que não transaciona), sujeito a proporcionalidade + sign-off do DPO. Tabela BLINDADA (RLS sem policies, sem grant a admin_ops); acesso só via RPCs SECURITY DEFINER owner-gated que auditam antes de resolver. Base (por finalidade): LGPD Art. 16, I (autoridade) + Art. 7º, VI (defesa de direitos) + Art. 7º, IX (fraude, sob LIA); GDPR Art. 6(1)(f) + Art. 17(3)(e). (A guarda fiscal — GDPR Art. 6(1)(c)/Art. 17(3)(b) — é do account_legal_hold; o Marco Civil Art. 15 rege o access_log de 6 meses, não este índice.) Contas excluídas antes da vigência não têm hold.

1. Processamento por IA. O conteúdo enviado à Anthropic é transiente; o subprocessador o retém por período limitado e então o exclui (em regra, em até ~30 dias), salvo retenção exigida por lei ou para prevenção de abuso. O resultado incorporado ao prontuário segue a regra geral; as conversas do chat assistente ficam guardadas até o titular apagá-las.
2. Telemetria técnica. A telemetria de estabilidade/diagnóstico (sem PHI) é mantida por até ~12 meses, por autolimitação de minimização (LGPD art. 6º, III) — política interna do Controlador, não prazo imposto por lei.
3. Imutabilidade e de-vinculação dos registros. O access_log é append-only (UPDATE/DELETE bloqueados por trigger). Os consent_events são de-vinculados/pseudonimizados (chave HMAC mantida fora do banco) — não "anônimos": preservam a prova de quando o consentimento foi concedido/revogado sem reidentificar diretamente o titular. Revogar consentimento é inserir um novo evento granted=false; a revogação não apaga retroativamente o tratamento já realizado licitamente, mas interrompe o tratamento futuro daquela finalidade.
4. Eliminação a pedido. A eliminação é executada a pedido do titular (ou do responsável legal, no caso de menores), conforme o procedimento da Seção 7, em até 30 dias.

7. Procedimento de Exclusão de Conta e de Dados

A exclusão de conta está disponível no próprio app (exigência da Apple) e pode também ser solicitada ao Encarregado (dpo@bas-ai.com).

1. Solicitação. O titular (ou responsável legal, no caso de dependente menor) inicia a exclusão no app ou por contato com o Encarregado.
2. Escopo. A exclusão apaga toda a PHI, os documentos/laudos no Storage, os vínculos de compartilhamento familiar, os dados de wearables e rotina (sleep_sessions, daily_scores, health_events, med_intakes, medidas com provider/external_id), os hábitos de vida (lifestyle_facts), as conversas com o assistente de IA (chat_messages/conversations), as comunicações de suporte (support_tickets/support_ticket_messages), os registros de uso do Serviço de IA (ai_usage, credit_ledger e correlatos, ressalvada a retenção fiscal de comprovantes de compra), os dados de conexão de wearables (wearable_connections, oauth_states — tokens cifrados) e os dados de conta. As tabelas clínicas têm exclusão em cascata a partir do profile_id (chaves estrangeiras on delete cascade).
3. Dependentes geridos. A exclusão da conta também apaga os dados dos dependentes geridos (perfis de menores) sob aquela conta. Antes de apagar um menor, o app oferece MIGRAR a guarda do menor a um co-responsável existente — nesse caso, o perfil do menor sobrevive sob o novo responsável, em vez de ser apagado.
4. Identidade (duplo-trilho). Se o titular transacionou, sua identidade mínima (nome/e-mail) é retida cifrada apenas pelo prazo fiscal da jurisdição (Seção 6). Se não transacionou — e sempre para menores — a identidade é APAGADA no ato da exclusão.
5. Eliminação efetiva. Remoção permanente, em cascata, dos registros e dos documentos; limpeza dos dados em cache no dispositivo no logout/exclusão. A eliminação é permanente, mas não se alega destruição de chaves de cifra (crypto-shredding) nem irreversibilidade absoluta em backups — eventuais cópias de segurança expiram conforme os ciclos de retenção da infraestrutura.
6. Retenção mínima legal. Mesmo após a exclusão, mantêm-se: (a) o mínimo de metadado que a lei exige (registro de que a exclusão ocorreu); (b) os logs de acesso pelo piso de 6 meses (Marco Civil, art. 15) — metadado, sem conteúdo clínico; (c) o trilho fiscal (comprovantes + identidade mínima de quem transacionou) pelo prazo fiscal da jurisdição (Seção 6); e (d) o índice forense mínimo (account_forensic_hold — item 4-A: identificadores de busca em HMAC + IPs + account_ref/metadados de guarda, sem PHI), pelo prazo prescricional aplicável (mesma duração do prazo de guarda fiscal, por proporcionalidade; para menores, prazo REDUZIDO), para prevenção a fraude, exercício/defesa de direitos e resposta a autoridade competente, sob acesso break-glass owner auditado. Nada disso recompõe o prontuário, que é eliminado.
7. Prazo e confirmação. A exclusão é uma operação imediata na base de dados. Não há emissão de recibo automático; o titular pode solicitar a confirmação da conclusão ao Encarregado (DPO) — dpo@bas-ai.com — que responde com base no registro mínimo de exclusão (LGPD art. 6º, X).
8. Subprocessadores. A exclusão é propagada à infraestrutura (Supabase). O conteúdo enviado à Anthropic é transiente e retido por período limitado (~30 dias) e então excluído pelo subprocessador, conforme seus termos. Para a Apple (incl. dados de compra/assinatura via In-App Purchase, como controladora independente) e a Resend (e-mail), aplicam-se os mecanismos de exclusão da respectiva plataforma quanto aos dados que cada uma trata. RevenueCat não é utilizado.
9. Desconexão de wearable (purge seletivo por provedor, sem excluir a conta). Disponível na tela de Integrações. A desconexão: (a) revoga os tokens junto ao provedor (Oura: oauth/revoke; WHOOP: DELETE /v2/user/access); (b) elimina os dados de conexão (CONEX); (c) grava consent_events granted=false para a finalidade da fonte; (d) aplica a política de dados importados — WHOOP: purge obrigatório de todos os dados com source='whoop' (exigência contratual, verificável por contagem zero); Oura/HealthKit: o titular escolhe manter ou apagar. Eventos de connect/disconnect/purge são registrados em auditoria.

8. Idade mínima e dados de menores

A proteção de crianças e adolescentes observa o Estatuto da Criança e do Adolescente (Lei 8.069/1990), a Lei 15.211/2025 (ECA Digital), o Art. 14 da LGPD, o Art. 8 do GDPR (padrão de referência) e a COPPA (EUA).

• Idade única de 18 anos para conta própria, em qualquer país (ou a maioridade civil do país, se superior). Esse requisito refere-se à titularidade da conta e não se confunde com a idade de consentimento digital autônomo do GDPR (Art. 8, entre 13 e 16 anos conforme o país). A atestação de idade (age_attestation) é registrada de forma imutável, com data/hora do servidor; o cadastro de menor de 18 com conta própria é bloqueado.
• O menor não possui conta nem e-mail próprios: existe apenas como perfil gerenciado (profiles.kind='minor', profiles.managed_by) dentro da conta de um responsável adulto, que exerce os direitos em nome do menor (LGPD Art. 14).
• Multi-guardião. O perfil pode ter mais de um responsável: o principal convida outro adulto por código de convite com prazo de validade. Cada convidado recebe um papel — responsável (vê e edita) ou acompanhante (somente leitura). Toda autorização é verificada no servidor a cada operação (proteção contra acesso indevido a objeto / IDOR). O consentimento relativo ao menor é registrado identificando qual adulto o concedeu. Na exclusão da conta do responsável principal, o app oferece migrar a guarda do menor a um co-responsável existente (ver Seção 7).
• Cobrança. Recursos pagos de IA exigem papel de responsável e são cobrados do adulto responsável que executa a ação; o dependente não tem cota, pacote nem meio de pagamento próprios. O registro de uso permanece vinculado ao perfil do menor para auditoria.
• Os dados de vestíveis e do Apple Saúde nunca seguem o perfil de um menor — são sempre gravados no perfil do titular adulto da conta.
• Aos dados de menores aplicam-se as mesmas proteções (cifra de PII, separação de identidade, não-treinamento da IA) e o melhor interesse da criança/adolescente. A identidade do menor é APAGADA no ato da exclusão (Seção 6).
• EUA (COPPA): o MyHealth não oferece contas a menores nem coleta dados diretamente de crianças; qualquer dado de menor é inserido e controlado por um adulto responsável, que exerce o consentimento parental verificável.

Verificação etária (Lei 15.211/2025 — ECA Digital, em vigor desde 17/03/2026). A verificação de idade é feita por autodeclaração no cadastro, com a atestação registrada no aceite (age_attestation, imutável, com data/hora do servidor).

9. Notificação de novos subprocessadores e direito de objeção

1. Due diligence prévia e DPA com obrigações equivalentes (mínimo: não-treinamento; salvaguardas de transferência internacional — cláusulas contratuais-padrão / SCC e mecanismo equivalente sob a LGPD; limites contratuais de retenção quando aplicável).
2. Aviso prévio com janela de objeção de 30 dias antes de o novo subprocessador tratar dados, salvo urgência de segurança/continuidade.
3. Direito de objeção ao Encarregado (dpo@bas-ai.com); onde a finalidade depende de consentimento (ai_processing, intl_transfer, family_sharing, wearable_sync_*), o novo tratamento não ocorre sem o consentimento registrado.

10. Direitos do titular (multi-jurisdição)

Independentemente da jurisdição, o titular pode, pelo app ou pelo Encarregado (dpo@bas-ai.com): acessar e exportar seus dados (portabilidade FHIR R4/PDF), corrigir, eliminar (Seção 7), revogar consentimento a qualquer tempo e opor-se a tratamentos baseados em legítimo interesse.

• LGPD (Brasil): direitos do Art. 18 (confirmação, acesso, correção, anonimização/eliminação, portabilidade, informação sobre compartilhamento, revogação).
• GDPR (padrão de referência global): direitos de acesso, retificação, apagamento, limitação, portabilidade e oposição (Arts. 15–21).
• EUA — CCPA/CPRA (Califórnia): direito de saber, excluir, corrigir e de opt-out de "venda"/"compartilhamento" — a BAS AI não vende nem compartilha dados pessoais para publicidade comportamental; não há sinais de rastreamento de terceiros.
• EUA — Washington My Health My Data (MHMDA): os "dados de saúde do consumidor" são tratados mediante consentimento; o titular pode retirar o consentimento e solicitar exclusão; a BAS AI não vende dados de saúde.
• Canadá (PIPEDA + leis provinciais): acesso, correção e retirada de consentimento, com retenção fiscal de 6 anos quando aplicável.

11. Histórico de versões

O histórico de versões fica publicado em https://www.bas-ai.com/myhealth/legal/versoes; cada versão aceita permanece arquivada.

Nota de não-diagnóstico. O MyHealth organiza seu histórico de saúde e oferece uma leitura educativa e prudente. Não é dispositivo médico, não faz diagnóstico e não substitui a avaliação de um profissional de saúde. A IA não verifica interações medicamentosas, contraindicações nem cruza alergia com medicamento. Em emergência, procure atendimento médico imediatamente.