Pular para o conteúdo

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.7 — Última atualização: 17 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.
Vigência e contratos. A vigência efetiva deste registro acompanha a assinatura dos DPAs/SCC referidos adiante; até lá, ele vale como registro operacional do desenho em produção. Os instrumentos contratuais constam por fornecedor na Seção 3. A relação com a Anthropic e com a Resend já é regida por DPA e Cláusulas Contratuais-Padrão (SCC) EM VIGOR (incorporados aos termos comerciais de cada provedor); o DPA do Supabase está EM VIGOR (assinado em 2026-06-18; Supabase Pte. Ltd) — inclui SCC da UE + salvaguardas de transferência (UK/Suíça); os termos das fontes de wearable (Oura/WHOOP) e do Apple Developer Program seguem o status indicado em cada item. 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:

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


2. Categorias de dados tratados (glossário)

Para uso nas tabelas a seguir:

SiglaCategoriaExemplos
PIIIdentificação direta (cifrada no identity_vault)Nome/apelido, e-mail, telefone, documento/CPF
PHIDados de saúde / sensíveisExames e marcadores; condições/sistemas; medicações; alergias; vacinas; consultas; sinais vitais e bioimpedância (peso, gordura, glicemia, pressão, FC); sintomas e queixas; atividade física (incl. treinos de wearable); sono (sessões e fases — sleep_sessions); métricas contínuas de wearable (FC de repouso, HRV, VO2max, passos, energia, temperatura de pele); scores proprietários de provedores de wearable (Oura readiness/sleep/stress/resilience; WHOOP recovery/strain — daily_scores); eventos de dispositivo (ECG — apenas classificação e metadados, nunca o traçado/forma de onda bruta; ritmo irregular; FC alta/baixa; carga de fibrilação atrial; queda detectada — health_events); registro de tomada de medicação (med_intakes); check-in diário de bem-estar; ciclo menstrual e saúde reprodutiva (fluxo, sangramento intermenstrual, teste de ovulação, muco cervical, teste de gravidez — importados do HealthKit para cycle_entries; atividade sexual não é importada); hábitos de vida autodeclarados (tabagismo — incl. anos de tabagismo —, álcool, atividade, percepção de sono e status de menopausa — autodeclarado opt-in, não importado do HealthKit — lifestyle_facts); conversas com o assistente de IA (perguntas e respostas persistidas — chat_messages/conversations); documentos/laudos; história familiar; equipe de cuidados
DEMOPerfil clínico-demográfico pseudônimoSexo biológico e data/idade na data do exame (em profiles, sem PII)
LOCLocalidade opcional e idiomaPaís (country_code — enviado à IA, ver 3.2, para regionalizar a orientação educativa)/estado/cidade; idioma (locale)
CONTAConta, autenticação e consentimentoIdentificador de conta, e-mail/identificador Sign in with Apple, tokens de sessão, fator MFA (TOTP), eventos de consentimento versionados
TÉCMetadados técnicos e de usoLogs de acesso (metadado, sem conteúdo clínico), dados de uso de-identificados, telemetria de falhas/desempenho
PAGFaturamento de assinaturaEstado da assinatura, recibo/transação (processamento do pagamento é feito pela Apple; a BAS AI não recebe dados de cartão)
CONEXDados de conexão de wearablesConexões OAuth (wearable_connections: status, escopos, tokens de acesso/refresh cifrados AES-256-GCM server-side, cursores de sincronização) e estados anti-CSRF (oauth_states). Não são dados de saúde — são dados de conexão, eliminados na desconexão da fonte

3. Parte A — Lista de Subprocessadores

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

CampoDetalhe
SubprocessadorSupabase Pte. Ltd — entidade contratante do DPA assinado em 2026-06-18 (Document Ref IUEMY-WMWYS-MIWD9-XVTSF); regido por GDPR + leis suíças + leis dos EUA
PapelOperador/suboperador (hosting de backend)
FinalidadeHospedar a infraestrutura do MyHealth: banco de dados (PostgreSQL), armazenamento de documentos/laudos, autenticação de conta e funções de borda. Dá suporte às finalidades clinical_processing e, no roteamento da IA, ai_processing.
Dados tratadosPHI estruturado e documentos/laudos (referenciados por profile_id pseudônimo); PII cifrada campo a campo (XChaCha20-Poly1305 via pgsodium) no identity_vault; DEMO; LOC; CONTA (incl. fator MFA/TOTP e consent_events); TÉC (logs de acesso access_log). O Supabase opera a infraestrutura, mas não acessa em claro a PII do identity_vault no curso normal de operação (decifragem só via função segura, sob a identidade do próprio usuário).
Localização / transferência internacionalRegião sa-east-1 (São Paulo, Brasil) — residência de dados no Brasil. Tratamentos administrativos auxiliares (ex.: suporte) podem envolver acesso a partir de outras jurisdições pelo pessoal do subprocessador, sob as salvaguardas abaixo. Por segurança, não se expõem publicamente o ref do projeto nem a chave anon/JWT desta página ou de materiais externos.
SalvaguardasDPA EM VIGOR (assinado em 2026-06-18; Supabase Pte. Ltd) — inclui SCC da UE + salvaguardas de transferência (UK/Suíça); mecanismo equivalente sob a LGPD para eventuais transferências; infraestrutura certificada SOC 2 Type 2 e ISO 27001 (certificações do provedor Supabase); backups diários (14 dias); retenção de log 28 dias; cifra em trânsito (TLS 1.3, com certificate pinning no app) e em repouso; cifra adicional de campo (pgsodium) sob nossa gestão de chaves; isolamento por Row-Level Security (RLS) por verbo; trilha de auditoria (access_log append-only / pgaudit best-effort); cláusula de NÃO-TREINAMENTO.

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

CampoDetalhe
SubprocessadorAnthropic, PBC — a entidade contratante e o endereço serão os constantes do DPA da Anthropic, em vigor via Termos Comerciais (anthropic.com/legal/data-processing-addendum)
PapelOperador/suboperador (processamento por IA)
FinalidadeProcessar, via API Claude, o conteúdo do próprio usuário para: (a) extrair/estruturar documentos e exames; (b) gerar leitura educativa, NÃO-diagnóstica (análise longitudinal do prontuário); e (c) responder ao chat assistente educativo. Mapeia às finalidades ai_processing e, quando há saída do Brasil, intl_transfer. A busca na web existe apenas no chat assistente: o modelo é instruído a usar somente termos clínicos genéricos, sem valores, datas, idade, nomes ou identificadores do usuário — proteção por instrução ao modelo, não por filtro técnico infalível; a busca é executada pela infraestrutura da Anthropic. As funções de análise do prontuário e de extração de documentos não fazem busca na web.
Dados tratadosConteúdo clínico (PHI) do próprio usuário, enviado mediante consentimento de processamento por IA. A minimização aplicada remove os identificadores diretos (nome, CPF, e-mail, telefone — substituídos por sexo e idade) e não envia os contatos do cartão de emergência, mas 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 (marcadores e tendências de exames, medidas e bioimpedância, medicações, vacinas, alergias, sintomas, consultas e anotações, história familiar, atividade física, sono e scores de wearable, eventos de dispositivo — classificação de ECG, ritmo irregular, queda, nunca o traçado bruto, ciclo menstrual e dados reprodutivos, hábitos de vida autodeclarados — tabagismo (incl. anos de tabagismo)/álcool/atividade/sono/status de menopausa, país (country_code, para regionalizar a orientação educativa), tipo sanguíneo e observações do cartão de emergência); na extração de documento, recebe a imagem/PDF bruta, que pode conter nome/CPF impressos no laudo. As conversas do chat (perguntas e respostas) também trafegam. Quando há fonte de wearable conectada (Seção 3.5), os dados entram como agregados no contexto da análise longitudinal (tendências de sono, FC de repouso, HRV sempre com o método SDNN/rMSSD, passos, energia e scores do provedor rotulados por marca, sem recálculo); não são enviadas séries brutas contínuas (agregação server-side, limite de 90 pontos por métrica). A Anthropic não recebe a PII direta cifrada no identity_vault, dados de conta nem tokens de conexão (CONEX). Tratamento transiente; retenção limitada pelo subprocessador (ver Salvaguardas).
Localização / transferência internacionalProcessamento via API da Anthropic, com infraestrutura nos Estados Unidos. Transferência internacional de dados pessoais sensíveis a partir do Brasil, realizada somente com o consentimento específico do titular.
SalvaguardasDPA em vigor (Termos Comerciais Anthropic); cláusula de NÃO-TREINAMENTO (entradas e saídas não são usadas para treinar ou aprimorar modelos — compromisso contratual); retenção limitada pelo subprocessador (em regra, exclusão em até ~30 dias, salvo retenção exigida por lei ou para prevenção de abuso) — não há "retenção zero"/ZDR contratada; SCC UE (Módulos 2/3) + UK IDTA + adendo suíço; mecanismo equivalente sob a LGPD; TIA/avaliação de transferência (Schrems II) a documentar antes de qualquer dado real no caminho dos EUA; transmissão sob TLS 1.3 com certificate pinning de api.anthropic.com; validação estrita do payload; salvaguardas anti-injeção (cerca de instrução); sem corpo clínico nos logs das nossas Edge Functions.

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

CampoDetalhe
Subprocessador / plataformaApple Inc. — a entidade contratante aplicável por jurisdição é a definida nos termos do Apple Developer Program License Agreement
PapelPlataforma de distribuição e serviços de SO; operador na medida em que trate dados em nosso nome (push, HealthKit); e fornecedor responsável pela transação (merchant of record) no processamento do pagamento das assinaturas e créditos via In-App Purchase nativo (StoreKit).
Finalidade(a) Distribuição do app (App Store); (b) autenticação via Sign in with Apple, quando escolhida pelo usuário; (c) notificações push; (d) acesso de leitura aos dados do Apple Health (HealthKit)implementado, opcional, somente com autorização explícita do usuário e consentimento wearable_sync_apple_health (a leitura ocorre localmente, no dispositivo; a Apple não participa do tráfego desses dados ao nosso backend); (e) processamento de pagamentos de assinatura e créditos de IA via In-App Purchase nativo, como merchant of record.
Dados tratadosCONTA (identificador Sign in with Apple, token de push); PAG (processamento do pagamento da assinatura e dos créditos via App Store / In-App Purchase — a BAS AI não recebe nem armazena dados de cartão; sem conteúdo de saúde no fluxo de pagamento). O PHI do HealthKit é lido no próprio iPhone mediante autorização granular do iOS e gravado no prontuário do usuário; a Apple não recebe a base clínica do MyHealth. Conformidade com a Guideline 5.1.3 (nunca marketing, terceiros ou treino de IA).
Localização / transferência internacionalEUA e infraestrutura global da Apple, conforme os termos aplicáveis do Apple Developer Program. Transferência internacional.
SalvaguardasTermos do Apple Developer Program / Apple Developer Program License Agreement; termos do Apple Developer Program em vigor (aceitos); DPA aplicável conforme esses termos; SCC a celebrar/mecanismo equivalente; Apple Guideline 5.1.3: dados do HealthKit nunca usados para marketing, compartilhamento com terceiros ou treino de modelos; Diretrizes Apple 3.1.1/3.1.2 para compras digitais; permissões just-in-time; tokens de sessão protegidos no dispositivo.

3.4 Resend — envio de e-mails transacionais

CampoDetalhe
SubprocessadorResend — a entidade contratante e o endereço serão os constantes do DPA da Resend em vigor (aceite dos termos); certificação EU-US Data Privacy Framework + UK extension; SCC
PapelOperador/suboperador (provedor de e-mail transacional)
FinalidadeEntregar e-mails transacionais da conta: código de acesso/OTP de autenticação e avisos operacionais da conta. Não participa de qualquer fluxo clínico ou de IA.
Dados tratadosApenas o e-mail do destinatário e o conteúdo do e-mail (código/aviso). Sem conteúdo de saúde (PHI), sem dados de conta sensíveis além do necessário ao envio, sem PII clínica.
Localização / transferência internacionalEUA / global; a região efetiva de processamento consta do DPA da Resend. Transferência internacional.
SalvaguardasDPA da Resend em vigor (aceite dos termos); certificação EU-US Data Privacy Framework + UK extension; SCC; mecanismo equivalente; cláusula de não-treinamento/não-uso secundário; minimização (nenhum dado de saúde é compartilhado); TLS em trânsito.
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.

CampoOuraWHOOP
EntidadeOura Health Oy (Finlândia / EEE) — o endereço será o constante do API Agreement; os termos de API serão aceitos na criação da conta de desenvolvedor, antes de a integração operarWHOOP, Inc. (EUA) — o endereço será o constante dos Developer Terms; os termos de API serão aceitos na criação da conta de desenvolvedor, antes de a integração operar
PapelFonte de dados conectada pelo titular (controlador independente)Fonte de dados conectada pelo titular (controlador independente)
Dados coletados (conforme escopos autorizados)Sono (sessões/fases), scores diários (readiness, sleep, activity, stress, resilience), métricas (FC de repouso, HRV rMSSD, temperatura, SpO2, VO2max), atividade diária, treinosSono (sessões/fases), scores diários (recovery, strain), métricas (FC de repouso, HRV rMSSD, SpO2, temperatura de pele), treinos
Dados de conexão (CONEX)Tokens OAuth cifrados (AES-256-GCM) só no servidor; o app nunca vê tokens; eliminados na desconexãoIdem
Localização / transferência internacionalColeta a partir da API da Oura (Finlândia/EEE) → armazenamento no Brasil (sa-east-1)Coleta a partir da API do WHOOP (EUA) → armazenamento no Brasil (sa-east-1)
Desconexão / purgeRevogação do token no provedor + consent_events granted=false; o titular escolhe manter ou apagar os dados já importadosRevogação (DELETE /v2/user/access) + consent_events granted=false + purge obrigatório de todos os dados originados do WHOOP (exigência contratual do provedor — sem opção de manter)
Salvaguardas / contratosOura API Terms/Agreement a aceitar na criação da conta de desenvolvedor, antes de a integração operar (com avaliação, na aprovação, da cláusula de cache de 60 dias e da base de transferência internacional); atribuição de marca obrigatória; scores nunca recalculados/combinadosWHOOP Developer Terms a aceitar na criação da conta de desenvolvedor, antes de a integração operar (a aprovação exige Privacy Policy URL e conformidade com brand guidelines); atribuição de marca; proibição de derivação de scores
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


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

#AtividadeCategorias de dadosCategorias de titularesDestinatários / subprocessadoresTransferência internacional
1Cadastro, autenticação e segurança da conta (MFA TOTP)CONTA, PII (cifrada)Usuários adultos; responsáveis legaisSupabase; Apple (Sign in with Apple); Resend (e-mail/OTP)Não (BR), salvo Sign in with Apple e Resend (EUA/global)
2Organização do prontuário (extração, linha do tempo, tendências; rotina diária — tomada de medicação med_intakes e check-in de bem-estar; hábitos de vida lifestyle_facts)PHI, DEMO, documentos/laudosTitulares e dependentes (menores)SupabaseNão (BR)
3Leitura educativa e extração de documentos por IA (incl. agregados de wearable, ciclo, hábitos e eventos de dispositivo no contexto da análise longitudinal — ver 3.2)PHI (conteúdo do próprio usuário, identificável por sexo+idade); documento/imagem bruta na extraçãoTitulares e dependentesAnthropic (Claude)Sim — EUA
4Chat assistente educativo por IA (perguntas/respostas persistidas em chat_messages/conversations; busca na web só com termos genéricos — ver 3.2)PHI (conteúdo do próprio usuário); conversasTitulares e dependentesAnthropic (Claude); Supabase (persistência)Sim — EUA (Anthropic); persistência BR
5Compartilhamento familiar (opt-in, somente leitura)PHI, DEMOTitular e familiar vinculadoSupabaseNão (BR)
6Sincronização Apple Health (HealthKit) — opcional, leitura local no dispositivo, contínua (background delivery)PHI (medidas, métricas contínuas, sono, treinos, eventos de dispositivo, ciclo/reprodutivo)TitularesLeitura local (iPhone); armazenamento SupabaseNão (leitura local; armazenamento BR)
7Portabilidade / exportação (FHIR R4, PDF) — inclui dados de wearables, hábitos, conversas de IA e registros de rotinaPHI, DEMO, PIITitulares e dependentesGerado no app/backend; entregue ao titularNão
8Conta, assinatura e créditos (In-App Purchase nativo / StoreKit); telemetria de uso e cobrança de IA (ai_usage, credit_ledger)CONTA, PAG, TÉC (sem PHI no fluxo de pagamento)Assinantes; responsáveis (cobrança de menor)Apple (merchant of record); SupabaseSim — Apple (EUA/global); persistência BR
9Segurança, auditoria e prevenção a abusoTÉC (metadado de acesso, sem PHI)Todos os usuáriosSupabaseNão (BR)
10Telemetria de estabilidade / diagnósticoTÉC (sem PHI)Todos os usuáriosBAS AI — hoje sem terceiro de observabilidade; se adotado, será listado nesta página antes da ativaçãoNão (BR) — hoje sem terceiro
11Gestão de consentimentos versionadosCONTA (consent_events)Todos os usuáriosSupabaseNão (BR)
12Atestação de idade (age_attestation) — declaração de 18+; bloqueio de cadastro de menor; registro imutável com data/hora do servidorCONTATodos os usuáriosSupabaseNão (BR)
13Sincronização Oura — conexão OAuth, coleta via API e webhook (sono sleep_sessions, scores daily_scores, métricas, treinos)PHI (wearable), CONEXTitularesOura Health Oy (fonte/originador — ver 3.5); SupabaseSim — coleta da Finlândia/EEE → BR
14Sincronização WHOOP — conexão OAuth, coleta via API e webhook (sono, recovery/strain, métricas, treinos)PHI (wearable), CONEXTitularesWHOOP, Inc. (fonte/originador — ver 3.5); SupabaseSim — coleta dos EUA → BR
15Gestão de conexões de wearables (tokens cifrados, estado OAuth, revogação e purge na desconexão)CONEXTitularesSupabase (acesso restrito a service_role; o app nunca lê tokens)Não (BR)

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

FinalidadeBase legal LGPDBase legal GDPRRetenção
Processamento clínico (clinical_processing) — organizar o prontuárioArt. 7, I e Art. 11, I (consentimento específico e destacado para dado sensível)Art. 6(1)(a) + Art. 9(2)(a) (consentimento explícito)Enquanto a conta existir; eliminado a pedido (Seção 7)
Processamento por IA (ai_processing) — extração de documentos, leitura educativa e chat assistenteArt. 7, I e Art. 11, I (consentimento específico)Art. 6(1)(a) + Art. 9(2)(a)Processamento transiente na Anthropic, com retenção limitada pelo subprocessador (em regra, exclusão em até ~30 dias) — sem "retenção zero"/ZDR contratada; resultado guardado no prontuário enquanto a conta existir; conversas do chat persistidas até exclusão pelo titular
Transferência internacional (intl_transfer) — saída para a Anthropic/EUA no processamento por IAArt. 7, I; Art. 11, I; Art. 33Art. 6(1)(a) + Art. 9(2)(a); Arts. 44–49Transiente; retenção limitada no destino (~30 dias), conforme termos da Anthropic; SCC em vigor (DPA Anthropic) + TIA a documentar
Compartilhamento familiar (family_sharing) — opt-in, somente leituraArt. 7, I e Art. 11, I (consentimento)Art. 6(1)(a) + Art. 9(2)(a)Vínculo ativo até revogação; convite expira em 7 dias
Sincronização de wearables (wearable_sync_apple_health / wearable_sync_oura / wearable_sync_whoop) — consentimento específico por fonte, gravado antes de qualquer leitura/pullArt. 7, I e Art. 11, I (consentimento específico e destacado; revogável)Art. 6(1)(a) + Art. 9(2)(a) (consentimento explícito; revogável)Dados importados: regra geral (enquanto a conta existir). Na desconexão: tokens/conexão (CONEX) sempre eliminados; WHOOP — purge obrigatório dos dados importados (exigência contratual do provedor); Oura/HealthKit — o titular escolhe manter (sob consentimento ativo) ou apagar
Dados de menores sob guardaArt. 14 (melhor interesse; consentimento do responsável)Art. 6(1)(a)/Art. 8 + Art. 9(2)(a), exercido pelo responsávelEnquanto a conta do responsável existir; eliminado a pedido
Atestação de idade (age_attestation) — declaração de 18+ no cadastroArt. 14 + Lei 15.211/2025 (ECA Digital)Art. 8Registro imutável enquanto a conta existir (prova de conformidade)
Conta, assinatura e créditos (In-App Purchase) — manter a conta e processar assinatura/créditos de IA (em regra, 1 crédito = 1 página); o consumo de IA de um menor é cobrado do responsávelArt. 7, V (execução de contrato); Art. 7, II e Art. 16, I (guarda fiscal obrigatória dos comprovantes)Art. 6(1)(b); Art. 6(1)(c) (guarda fiscal)Conta: enquanto existir. Comprovantes fiscais/de faturamento: 5 anos (CTN, arts. 173 e 174 — prazos de decadência e prescrição tributárias), independentemente da exclusão da conta
Segurança, auditoria e prevenção a abusoArt. 7, II (obrigação legal) e Art. 10 (legítimo interesse) — não Art. 11, II "f" (tutela da saúde)Art. 6(1)(c) (obrigação legal) e Art. 6(1)(f) (legítimo interesse) — não Art. 9(2)(h)Logs de acesso (data/hora + IP, metadado sem conteúdo clínico): mínimo de 6 meses (Marco Civil da Internet, Lei 12.965/2014, art. 15 — piso legal de guarda). Esse piso refere-se a log de acesso, que não é dado de saúde e não justifica reter conteúdo de prontuário
Telemetria técnica / estabilidadeArt. 7, IX (legítimo interesse)Art. 6(1)(f)Até ~12 meses, por autolimitação de minimização (LGPD art. 6º, III) — política interna do Controlador, não prazo imposto por lei; sem PHI
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. Hoje não existe rotina de eliminação automática por inatividade prolongada nem por decurso de prazo máximo por categoria — e este documento não afirma rotina vigente. Quando a política de retenção por tempo / prazo máximo por categoria for definida — em atenção ao princípio de limitação de conservação (GDPR Art. 5(1)(e)) —, ela constará aqui e na Política de Privacidade.
  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 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)privacy@bas-ai.com — que responde com base no registro mínimo de exclusão (LGPD art. 6º, X).
  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).

Verificação etária (Lei 15.211/2025 — ECA Digital, em vigor desde 17/03/2026). Hoje, a verificação de idade é feita por autodeclaração, com a atestação registrada no aceite (age_attestation, imutável, com data/hora do servidor); mecanismos reforçados de verificação etária estão em avaliação para atender plenamente ao "mecanismo efetivo de verificação etária" exigido pelo ECA Digital.

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

| Versão | Data | Mudança |

1.52026-06-11Publicação: removidos todos os marcadores de revisão (texto 100% publicável); URLs públicas preenchidas (subprocessadores e histórico de versões em www.bas-ai.com/myhealth/legal); exclusão corrigida (imediata, sem recibo automático — confirmação via DPO); redação de PII on-device registrada.
1.0— (versão arquivada; ver histórico publicado)Publicação inicial. Subprocessadores ativos: Supabase (BR, sa-east-1) e Anthropic (IA). Apple como plataforma/operador (App Store, Sign in with Apple, push, HealthKit futuro). RevenueCat então previsto (não ativo) — posteriormente descartado na 1.3.
1.12026-06-10Integrações de wearables: novas categorias de PHI (sono, métricas contínuas, scores proprietários, eventos de dispositivo, med_intakes, check-in, ciclo menstrual em breve) e categoria CONEX; Apple HealthKit implementado (leitura local); Oura Health Oy e WHOOP, Inc. como fontes/originadores (Seção 3.5); atividades ROPA 11–13; finalidades wearable_sync_* (LGPD Art. 11 + GDPR Art. 9); agregados de wearable no contexto da IA; purge na desconexão (WHOOP obrigatório).
1.32026-06-11Correção de fato e sincronização com o código em produção: Anthropic = infraestrutura nos EUA (transferência internacional), com retenção limitada (~30 dias) — removida qualquer alegação de "retenção zero/ZDR" e de "BAA"; honestidade sobre o que a IA recebe (conteúdo identificável por sexo+idade na análise; imagem/PDF bruta na extração; conversas do chat; sem de-identificação no aparelho); ciclo menstrual e hábitos de vida já em produção e enviados à IA; eventos de dispositivo apenas como classificação (ECG sem traçado bruto); RevenueCat removido (não utilizado) e substituído por In-App Purchase nativo com a Apple como merchant of record; novo subprocessador Resend (e-mail transacional); chat assistente como atividade própria (conversas persistidas); menores multi-guardião com cobrança do responsável executor e verificação de autorização no servidor; age_attestation e idade fixa 18 (titularidade ≠ consentimento digital GDPR Art. 8); escopo de exclusão/portabilidade ampliado (lifestyle_facts, conversas, ai_usage/créditos, IAP); removida alegação de crypto-shredding; nota de segurança (não expor ref/anon JWT); controlador/DPO atualizados. DPA/SCC/TIA assinalados como a firmar/documentar.
1.42026-06-11Prazos de retenção concretos na ROPA (sincronizados com a Política): logs de acesso — piso de 6 meses (Marco Civil, Lei 12.965/2014, art. 15), metadado sem conteúdo clínico; comprovantes fiscais/faturamento — 5 anos (CTN, arts. 173 e 174); telemetria — ~12 meses por autolimitação de minimização (LGPD art. 6º, III), política interna, não prazo legal; registrada com honestidade (não como rotina vigente) a ausência de expurgo automático por inatividade (GDPR Art. 5(1)(e)). Base legal decidida: núcleo clínico = consentimento primário (LGPD Art. 11, II "a" / GDPR Art. 9(2)(a)); base subsidiária para segurança, obrigação legal e exclusão = LGPD Art. 7, II e Art. 10 / GDPR Art. 6(1)(c) e (f); rejeitada a tutela da saúde (LGPD Art. 11, II "f" / GDPR Art. 9(2)(h)) por não haver médico no loop (GDPR Art. 9(3)).
1.52026-06-12Catálogo canônico de marcadores (LOINC®/UCUM): registrado o dicionário de referência embarcado que reconhece o mesmo exame sob nomenclaturas diferentes como um único parâmetro — conteúdo licenciado, NÃO subprocessador (Regenstrief não recebe dado pessoal); atribuição cumprida na Política de Privacidade §6.4 e na tela de avisos do app (Seção 3.6). Sem novo dado pessoal coletado nem nova transferência internacional → não dispara re-consentimento.
1.62026-06-14Alinhamento de fato (saúde reprodutiva e contexto da IA) — sem nova cadeia de subprocessadores e sem nova transferência internacional: (a) tornado explícito que o teste de gravidez do HealthKit é gravado em cycle_entries (atividade ROPA 6, já existente — leitura local no iPhone, Apple não é subprocessadora desse fluxo); (b) registrados como dados autodeclarados opt-in em lifestyle_facts (NÃO importados do HealthKit) o status de menopausa e os anos de tabagismo (smoking_years), que compõem o contexto da IA sob ai_processing já consentido; (c) confirmado que país (country_code) e observações autorrelatadas do cartão de emergência (emergency_info.notes) passam a compor o contexto enviado à Anthropic (atividade ROPA 3, fluxo já existente — o country_code é usado para regionalizar a orientação educativa de emergência/crise e contextualizar a leitura; ver glossário LOC e Seção 3.2): nenhum subprocessador novo, nenhum destino novo — o mesmo regime ai_processing/intl_transfer já declarado. Reconfirmada a retenção do dado reprodutivo (regra geral PHI; exclusão em cascata; ~30 dias transiente na Anthropic). Não dispara re-consentimento (categorias e fluxos já consentidos; é descrição mais precisa, não novo tratamento — policy_version permanece 1.6). Risco reprodutivo pós-Dobbs incorporado ao DPIA (R-19).
1.72026-06-17DPA/SCC da Anthropic e Resend descritos como em vigor (antes 'a firmar'); remoção de ressalvas de rascunho; correções de tradução; + criadas as versões EN/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. Em emergência, procure atendimento médico imediatamente.