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): privacy@bas-ai.com — Rua Gomes de Carvalho, 911, Vila Olímpia, São Paulo/SP, CEP 04547-003, Brasil Produto: MyHealth — aplicativo iOS de prontuário pessoal de saúde e leitura educativa por IA (pt/en/es). Versão deste documento: 1.4 — Última atualização: 11 de junho de 2026

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.

Documento sujeito a revisão jurídica humana antes do lançamento. Os pontos marcados com «DECISÃO DO FUNDADOR» dependem de decisão de negócio do Controlador (advogado) ou da execução/assinatura de contratos (DPA, SCC, termos de provedor).

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.

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).
• Não-treinamento e minimização na IA. O fornecedor de IA está contratualmente proibido de usar os dados para treinar ou aprimorar modelos. A minimização efetiva consiste em: remover os identificadores diretos (nome, CPF, e-mail, telefone — que permanecem cifrados no identity_vault e não são enviados), substituindo-os por sexo e idade; não enviar os contatos do cartão de emergência; e aplicar salvaguardas anti-injeção (cerca de instrução). Essa minimização não é uma de-identificação no aparelho: na análise do prontuário, a IA recebe conteúdo clínico identificável por sexo + idade; na extração de documento, recebe a imagem/PDF bruta, que pode conter nome/CPF impressos no laudo. Anotações livres podem conter nomes, por isso recomenda-se não inserir identificação em campos de texto.
• 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

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

3.4 Resend — envio de e-mails transacionais

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

3.5 Fontes de dados de wearables — Oura e WHOOP (originadores; NÃO são subprocessadores)

Quando o usuário conecta um wearable, o provedor atua como fonte de dados/originador (controlador independente da sua própria plataforma), não como operador da BAS AI: o fluxo de dados é apenas de entrada (do provedor para o prontuário do usuário), mediante conexão OAuth autorizada pelo próprio 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.

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

3.6 O que NÃO é subprocessador

• O que ocorre no iPhone. A leitura do HealthKit e o cache no aparelho não envolvem terceiros. (Não há, hoje, de-identificação no aparelho nem OCR local antes do envio à IA — ver 1.1 e 3.2.)
• Fontes de dados conectadas pelo titular. Oura e WHOOP (Seção 3.5) são originadores de dados sob controle do titular, não operadores da BAS AI.
• Sem SDK de tracking de terceiros. O app não embarca SDK de publicidade/rastreamento que veja dados de saúde. «DECISÃO DO FUNDADOR: caso seja adotada telemetria/observabilidade de terceiros, listá-la como novo subprocessador»

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.

6. Política de Retenção e Eliminação

1. Regra geral. Os dados são mantidos enquanto a conta existir e o titular quiser manter o prontuário organizado.
2. Prazos legais. Dados de faturamento/fiscais (comprovantes de compra de assinatura e créditos) são mantidos por 5 anos para cumprir as obrigações tributárias (CTN, arts. 173 e 174 — decadência e prescrição), ainda que a conta seja excluída antes. Os logs de acesso (metadado de auditoria/segurança — quem, quando, qual tabela, ação, IP de origem) são guardados por no mínimo 6 meses, na forma do art. 15 da Lei 12.965/2014 (Marco Civil da Internet) — esse é o piso legal de guarda, e o log de acesso não é conteúdo clínico, de modo que esse prazo não justifica reter prontuário. Os logs de auditoria nunca contêm conteúdo clínico.
3. 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 — não há "retenção zero"/ZDR contratada. O resultado incorporado ao prontuário segue a regra geral; as conversas do chat assistente ficam guardadas até o titular apagá-las.
4. 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) — trata-se de política interna do Controlador, não de prazo imposto por lei.
5. Sem expurgo automático por inatividade — LACUNA a definir. Hoje não existe rotina de eliminação automática por inatividade prolongada nem por decurso de prazo máximo por categoria. Trata-se de uma lacuna a definir — e não de uma rotina vigente —, pendente para atender o princípio de limitação de conservação (GDPR Art. 5(1)(e)). «DECISÃO DO FUNDADOR: definir política de retenção por tempo / prazo máximo por categoria»
6. 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. Imutabilidade dos registros. consent_events e access_log são append-only (UPDATE/DELETE bloqueados por trigger): 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.

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 (privacy@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 abrange: os dados estruturados do prontuário (PHI/DEMO), os documentos/laudos no Storage, a PII cifrada no identity_vault, 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), os registros de uso e saldo de créditos 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. 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.
4. 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; e (c) os comprovantes de faturamento/fiscais por 5 anos (CTN, arts. 173 e 174). Nada disso recompõe o prontuário, que é eliminado.
5. Prazo e recibo. A exclusão é concluída em até 30 dias, com emissão de um recibo de exclusão (o que foi apagado, quando, e um código de confirmação).
6. 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) 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.
7. 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 (EEE) 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.
• 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 saldo 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.
• 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.

«DECISÃO DO FUNDADOR: a autodeclaração de idade não satisfaz, por si, o "mecanismo efetivo de verificação etária" do ECA Digital (em vigor desde 17/03/2026); avaliar provedor de age assurance — risco residual a registrar e endereçar.»

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 (privacy@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. Histórico de versões

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. Em emergência, procure atendimento médico imediatamente.