MyHealth — Lista de Subprocesadores y Registro de las Actividades de Tratamiento (ROPA)

Responsable (LGPD Art. 5º, VI / GDPR "controller"): BAS AI — BAS ARTIFICIAL INTELLIGENCE LTDA CNPJ: 64.106.409/0001-70 Sitio web: www.bas-ai.com Encargado / 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 Producto: MyHealth — aplicación iOS de historial personal de salud y lectura educativa por IA (pt/en/es). Versión de este documento: 2.0 — Última actualización: 22 de junio de 2026

Naturaleza del producto. MyHealth organiza su historial de salud y ofrece una lectura educativa y prudente. No es un dispositivo médico, no realiza diagnósticos y no prescribe. Toda observación de la IA está marcada como "(a confirmar)" y debe ser validada con su médico.

Vigencia y contratos. La vigencia efectiva de este registro acompaña la firma de los DPA/SCC referidos más adelante; hasta entonces, vale como registro operacional del diseño en producción. Los instrumentos contractuales constan por proveedor en la Sección 3. La relación con Anthropic y con Resend ya se rige por DPA y Cláusulas Contractuales Estándar (SCC) EN VIGOR (incorporados a los términos comerciales de cada proveedor); el DPA de Supabase está EN VIGOR (firmado el 2026-06-18; Supabase Pte. Ltd); los términos de las fuentes de dispositivos vestibles (Oura/WHOOP) y del Apple Developer Program siguen el estado indicado en cada ítem. La versión pública de esta lista queda en https://www.bas-ai.com/myhealth/legal/subprocessadores; el historial de versiones queda publicado en https://www.bas-ai.com/myhealth/legal/versoes, y cada versión aceptada permanece archivada.

1. Cómo leer este documento

Este documento tiene dos partes complementarias:

• Parte A — Lista de Subprocesadores (Sección 3): todos los terceros que tratan datos personales en nombre de BAS AI, con su rol, los datos tratados, la finalidad, la localización/transferencia internacional y las salvaguardas.
• Parte B — Registro de las Actividades de Tratamiento (ROPA, Secciones 4 a 7): el inventario de las actividades de tratamiento (estilo GDPR Art. 30 / LGPD Art. 37), la matriz finalidad → base legal → retención, la política de retención y eliminación, y el procedimiento de eliminación de cuenta/datos.

BAS AI actúa como responsable de los datos personales tratados en MyHealth. Los terceros listados en la Parte A actúan como encargados/subencargados (LGPD Art. 5º, VII) / processors/sub-processors (GDPR Art. 28), tratando datos exclusivamente bajo las instrucciones de BAS AI.

1.1 Principios que rigen la cadena de subprocesadores

• Minimización. Cada subprocesador recibe solo el mínimo de datos necesario para su función.
• Separación entre identidad y datos clínicos. Los identificadores directos (PII) quedan cifrados en una bóveda (identity_vault), separados de las tablas clínicas, que se refieren al titular solo por un identificador seudónimo (profile_id).
• No-entrenamiento y minimización en la IA. El proveedor de IA tiene prohibido contractualmente usar los datos para entrenar o mejorar modelos. La minimización efectiva consiste en: eliminar los identificadores directos (nombre, CPF, correo electrónico, teléfono — que permanecen cifrados en el identity_vault y no se envían), sustituyéndolos por sexo y edad; no enviar los contactos de la tarjeta de emergencia; y aplicar salvaguardas contra inyección (cerca de instrucción). Esa minimización no es una desidentificación en el dispositivo: en el análisis del historial, la IA recibe contenido clínico identificable por sexo + edad; en la extracción de documento, recibe la imagen/PDF bruta, que puede contener nombre/CPF impresos en el informe. Las anotaciones libres pueden contener nombres, por eso se recomienda no insertar identificación en los campos de texto.
• Sin venta de datos. Ningún dato personal se vende a terceros.
• Cadena controlada. Ningún subprocesador puede contratar un nuevo subprocesador para tratar sus datos sin una obligación contractual equivalente y sin nuestro derecho de objeción.

2. Categorías de datos tratados (glosario)

Para uso en las tablas a continuación:

3. Parte A — Lista de Subprocesadores

3.1 Supabase — infraestructura, base de datos, almacenamiento y autenticación

3.2 Anthropic — modelos de lenguaje para lectura educativa y extracción de exámenes

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

3.4 Resend — envío de correos transaccionales

RevenueCat NO se utiliza. La monetización de MyHealth funciona por In-App Purchase nativo (StoreKit) — suscripción y paquetes adicionales —, con Apple como proveedor responsable de la transacción (merchant of record; ver 3.3). No hay intermediario de suscripciones de terceros.

3.5 Fuentes de datos de dispositivos vestibles — Oura y WHOOP (originadores; NO son subprocesadores)

Cuando el usuario conecta un dispositivo vestible, el proveedor actúa como fuente de datos/originador (controlador independiente de su propia plataforma), no como encargado de BAS AI: el flujo de datos es solo de entrada (del proveedor hacia el historial del usuario), mediante conexión OAuth autorizada por el propio titular y consentimiento específico por fuente (wearable_sync_oura / wearable_sync_whoop, base doble LGPD Art. 11, I + GDPR Art. 9(2)(a), revocable). El proveedor no recibe datos del historial.

El Apple Salud (HealthKit) no consta en esta tabla porque la lectura es local, en el dispositivo (ver 3.3 y 3.6) — no hay tráfico de datos entre Apple y el backend de BAS AI.

3.6 Lo que NO es subprocesador

• Lo que ocurre en el iPhone. La lectura de HealthKit y el caché en el dispositivo no involucran a terceros. (No hay, hoy, desidentificación en el dispositivo ni OCR local antes del envío a la IA — ver 1.1 y 3.2.)
• Fuentes de datos conectadas por el titular. Oura y WHOOP (Sección 3.5) son originadores de datos bajo control del titular, no encargados de BAS AI.
• Sin SDK de rastreo de terceros. La app no embarca SDK de publicidad/rastreo que vea datos de salud. Hoy no usamos ninguna herramienta de analytics o rastreo de terceros; si eso cambia, actualizaremos esta página y la Política de Privacidad antes de la activación, con un nuevo aviso (ver Sección 9).
• Vocabularios/estándares abiertos licenciados (LOINC® / UCUM). Para reconocer el mismo examen bajo nombres/siglas/idiomas diferentes como un único parámetro (catálogo canónico de marcadores) y estandarizar unidades, la app embarca un diccionario de referencia derivado de LOINC® (Regenstrief Institute, Inc.) y de UCUM. Es contenido licenciado embarcado — funciona localmente como una tabla de consulta. El Regenstrief Institute no recibe ningún dato personal/clínico del titular, no trata datos en nombre de BAS AI y no es subprocesador; se trata de una obligación de atribución/licencia de propiedad intelectual (cumplida en la Política de Privacidad §6.4 y en la pantalla de avisos de la app), no de una cadena de tratamiento de datos. La LOINC License es gratuita inclusive para uso comercial y exige atribución visible y seguimiento de las actualizaciones (~2x/año).

4. Parte B — Registro de las Actividades de Tratamiento (ROPA)

Inventario de las actividades de tratamiento (GDPR Art. 30 / LGPD Art. 37). Los consentimientos por finalidad quedan en un registro append-only (consent_events), versionados por policy_version, y las Edge Functions verifican el consentimiento en tiempo de ejecución (gate has_active_consent).

5. Matriz Finalidad → Base Legal → Retención

Base legal del núcleo clínico (decidida). La base primaria de todo el núcleo clínico (organización del historial, lectura/extracción por IA, chat asistente, transferencia internacional, compartir en familia y sincronización de dispositivos vestibles) es el consentimiento específico y destacado para dato sensible — LGPD Art. 11, I/II "a" / GDPR Art. 9(2)(a) — coherente con el posicionamiento de "historial soberano" y revocable en cualquier momento. Como base subsidiaria — restringida a la seguridad e integridad del tratamiento, al cumplimiento de obligación legal y a la ejecución de la propia eliminación de datos — se aplican LGPD Art. 7, II y Art. 10 / GDPR Art. 6(1)(c) y (f). NO se invoca la hipótesis de tutela de la salud (LGPD Art. 11, II "f" / GDPR Art. 9(2)(h)): el GDPR Art. 9(3) condiciona esa base al tratamiento por un profesional sujeto a secreto en el flujo, y no hay médico en el circuito de MyHealth — el asistente nunca comunica diagnóstico, pronóstico ni decisión terapéutica.

6. Política de Retención y Eliminación

1. Regla general. Los datos se mantienen mientras la cuenta exista y el titular quiera mantener el historial organizado.
2. Plazos legales. Los datos de facturación/fiscales (comprobantes de compra de suscripción y paquetes adicionales) se mantienen por 5 años para cumplir las obligaciones tributarias (CTN, arts. 173 y 174 — caducidad y prescripción), aunque la cuenta se elimine antes. Los logs de acceso (metadato de auditoría/seguridad — quién, cuándo, qué tabla, acción, IP de origen) se guardan por un mínimo de 6 meses, en la forma del art. 15 de la Ley 12.965/2014 (Marco Civil de Internet) — ese es el piso legal de guarda, y el log de acceso no es contenido clínico, de modo que ese plazo no justifica retener el historial. Los logs de auditoría nunca contienen contenido clínico.
3. Procesamiento por IA. El contenido enviado a Anthropic es transitorio; el subprocesador lo retiene por un período limitado y luego lo elimina (por regla, en hasta ~30 días), salvo retención exigida por ley o para prevención de abuso — no hay "retención cero"/ZDR contratada. El resultado incorporado al historial sigue la regla general; las conversaciones del chat asistente quedan guardadas hasta que el titular las borre.
4. Telemetría técnica. La telemetría de estabilidad/diagnóstico (sin PHI) se mantiene por hasta ~12 meses, por autolimitación de minimización (LGPD art. 6º, III) — se trata de una política interna del Responsable, no de un plazo impuesto por ley.
5. Sin purga automática por inactividad. Hoy no existe rutina de eliminación automática por inactividad prolongada ni por transcurso de plazo máximo por categoría — y este documento no afirma una rutina vigente. Cuando la política de retención por tiempo / plazo máximo por categoría se defina — en atención al principio de limitación de conservación (GDPR Art. 5(1)(e)) —, constará aquí y en la Política de Privacidad.
6. Eliminación a pedido. La eliminación se ejecuta a pedido del titular (o del responsable legal, en el caso de menores), conforme el procedimiento de la Sección 7, en hasta 30 días.
7. Inmutabilidad de los registros. consent_events y access_log son append-only (UPDATE/DELETE bloqueados por trigger): revocar el consentimiento es insertar un nuevo evento granted=false; la revocación no borra retroactivamente el tratamiento ya realizado lícitamente, pero interrumpe el tratamiento futuro de esa finalidad.

7. Procedimiento de Eliminación de Cuenta y de Datos

La eliminación de cuenta está disponible en la propia app (exigencia de Apple) y también puede solicitarse al Encargado (privacy@bas-ai.com).

1. Solicitud. El titular (o responsable legal, en el caso de dependiente menor) inicia la eliminación en la app o por contacto con el Encargado.
2. Alcance. La eliminación abarca: los datos estructurados del historial (PHI/DEMO), los documentos/informes en el Storage, la PII cifrada en el identity_vault, los vínculos de compartir en familia, los datos de dispositivos vestibles y rutina (sleep_sessions, daily_scores, health_events, med_intakes, mediciones con provider/external_id), los hábitos de vida (lifestyle_facts), las conversaciones con el asistente de IA (chat_messages/conversations), los registros de uso y saldo de cuota de IA (páginas/prompts) (ai_usage, credit_ledger y correlatos, salvo la retención fiscal de comprobantes de compra), los datos de conexión de dispositivos vestibles (wearable_connections, oauth_states — tokens cifrados) y los datos de cuenta. Las tablas clínicas tienen eliminación en cascada a partir del profile_id (claves foráneas on delete cascade).
3. Eliminación efectiva. Remoción permanente, en cascada, de los registros y de los documentos; limpieza de los datos en caché en el dispositivo al cerrar sesión/eliminar. La eliminación es permanente, pero no se alega destrucción de claves de cifrado (crypto-shredding) ni irreversibilidad absoluta en copias de seguridad — eventuales copias de seguridad expiran conforme los ciclos de retención de la infraestructura.
4. Retención mínima legal. Aun después de la eliminación, se mantienen: (a) el mínimo de metadato que la ley exige (registro de que la eliminación ocurrió); (b) los logs de acceso por el piso de 6 meses (Marco Civil, art. 15) — metadato, sin contenido clínico; y (c) los comprobantes de facturación/fiscales por 5 años (CTN, arts. 173 y 174). Nada de esto recompone el historial, que es eliminado.
5. Plazo y confirmación. La eliminación es una operación inmediata en la base de datos. No hay emisión de recibo automático; el titular puede solicitar la confirmación de la conclusión al Encargado (DPO) — privacy@bas-ai.com — que responde con base en el registro mínimo de eliminación (LGPD art. 6º, X).
6. Subprocesadores. La eliminación se propaga a la infraestructura (Supabase). El contenido enviado a Anthropic es transitorio y retenido por un período limitado (~30 días) y luego eliminado por el subprocesador, conforme sus términos. Para Apple (incl. datos de compra/suscripción vía In-App Purchase) y Resend (correo), se aplican los mecanismos de eliminación de la respectiva plataforma en cuanto a los datos que cada una trata. RevenueCat no se utiliza.
7. Desconexión de dispositivo vestible (purga selectiva por proveedor, sin eliminar la cuenta). Disponible en la pantalla de Integraciones. La desconexión: (a) revoca los tokens ante el proveedor (Oura: oauth/revoke; WHOOP: DELETE /v2/user/access); (b) elimina los datos de conexión (CONEX); (c) graba consent_events granted=false para la finalidad de la fuente; (d) aplica la política de datos importados — WHOOP: purga obligatoria de todos los datos con source='whoop' (exigencia contractual, verificable por conteo cero); Oura/HealthKit: el titular elige mantener o borrar. Los eventos de connect/disconnect/purge se registran en auditoría.

8. Edad mínima y datos de menores

La protección de niños y adolescentes observa el Estatuto del Niño y del Adolescente (Ley 8.069/1990), la Ley 15.211/2025 (ECA Digital), el Art. 14 de la LGPD, el Art. 8 del GDPR (EEE) y la COPPA (EE. UU.).

• Edad única de 18 años para cuenta propia, en cualquier país (o la mayoría de edad civil del país, si es superior). Ese requisito se refiere a la titularidad de la cuenta y no se confunde con la edad de consentimiento digital autónomo del GDPR (Art. 8, entre 13 y 16 años según el país). La atestación de edad (age_attestation) se registra de forma inmutable, con fecha/hora del servidor; el registro de menor de 18 con cuenta propia está bloqueado.
• El menor no posee cuenta ni correo electrónico propios: existe solo como perfil gestionado (profiles.kind='minor', profiles.managed_by) dentro de la cuenta de un responsable adulto, que ejerce los derechos en nombre del menor (LGPD Art. 14).
• Multi-guardián. El perfil puede tener más de un responsable: el principal invita a otro adulto mediante código de invitación con plazo de validez. Cada invitado recibe un rol — responsable (ve y edita) o acompañante (solo lectura). Toda autorización se verifica en el servidor en cada operación (protección contra acceso indebido a objeto / IDOR). El consentimiento relativo al menor se registra identificando qué adulto lo concedió.
• Cobro. Los recursos pagos de IA exigen rol de responsable y se cobran al adulto responsable que ejecuta la acción; el dependiente no tiene saldo ni medio de pago propios. El registro de uso permanece vinculado al perfil del menor para auditoría.
• Los datos de dispositivos vestibles y de Apple Salud nunca siguen al perfil de un menor — siempre se graban en el perfil del titular adulto de la cuenta.
• A los datos de menores se aplican las mismas protecciones (cifrado de PII, separación de identidad, no-entrenamiento de la IA) y el mejor interés del niño/adolescente.
• EE. UU. (COPPA): MyHealth no ofrece cuentas a menores ni recopila datos directamente de niños; cualquier dato de menor es insertado y controlado por un adulto responsable, que ejerce el consentimiento parental verificable.

Verificación de edad (Ley 15.211/2025 — ECA Digital, en vigor desde el 17/03/2026). Hoy, la verificación de edad se hace por autodeclaración, con la atestación registrada en la aceptación (age_attestation, inmutable, con fecha/hora del servidor); mecanismos reforzados de verificación de edad están en evaluación para atender plenamente el "mecanismo efectivo de verificación de edad" exigido por el ECA Digital.

9. Notificación de nuevos subprocesadores y derecho de objeción

1. Due diligence previa y DPA con obligaciones equivalentes (mínimo: no-entrenamiento; salvaguardas de transferencia internacional — cláusulas contractuales estándar / SCC y mecanismo equivalente bajo la LGPD; límites contractuales de retención cuando sea aplicable).
2. Aviso previo con ventana de objeción de 30 días antes de que el nuevo subprocesador trate datos, salvo urgencia de seguridad/continuidad.
3. Derecho de objeción ante el Encargado (privacy@bas-ai.com); donde la finalidad depende de consentimiento (ai_processing, intl_transfer, family_sharing, wearable_sync_*), el nuevo tratamiento no ocurre sin el consentimiento registrado.

10. Historial de versiones

| Versión | Fecha | Cambio |

El historial de versiones queda publicado en https://www.bas-ai.com/myhealth/legal/versoes; cada versión aceptada permanece archivada.

Nota de no-diagnóstico. MyHealth organiza su historial de salud y ofrece una lectura educativa y prudente. No es un dispositivo médico, no realiza diagnósticos y no sustituye la evaluación de un profesional de salud. En caso de emergencia, busque atención médica inmediatamente.