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

Responsable del tratamiento (LGPD Art. 5, VI / RGPD "controller"): BAS AI — BAS ARTIFICIAL INTELLIGENCE LTDA CNPJ (identificación de empresa de Brasil): 64.106.409/0001-70 Sitio web: www.bas-ai.com Delegado de Protección de Datos (DPD/DPO) (LGPD Art. 5, VIII): Guilherme Bastian — dpo@bas-ai.com Producto: MyHealth — app iOS de historial personal de salud con lectura educativa por IA (pt/en/es). Versión de este documento: 2.10 — 2026-07-19

Naturaleza del producto. MyHealth organiza tu historial de salud y ofrece una lectura educativa y prudente. No es un producto sanitario, no diagnostica y no prescribe. Toda observación de la IA se marca como "(a confirmar)" y debe validarse con tu médico. La IA no verifica interacciones medicamentosas, no verifica contraindicaciones y no cruza alergias con medicamentos.

Distribución. MyHealth se distribuye en la App Store a escala mundial, excepto en la Unión Europea/EEE y el Reino Unido en el lanzamiento. Aun así, las protecciones de nivel RGPD/RU se adoptan como base global aplicada a todos los titulares (denominador común más estricto).

Vigencia. Este registro está en vigor a partir del 2026-06-23. Los contratos de tratamiento (DPA/SCC) referidos más adelante están firmados y en vigor (ver Sección 3). La versión pública de esta lista está en https://www.bas-ai.com/myhealth/legal/subprocessadores; el historial de versiones se publica 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 Subencargados (Sección 3): todos los terceros que tratan datos personales por cuenta de BAS AI, con rol, datos tratados, finalidad, ubicación/transferencia internacional y salvaguardas.
• Parte B — Registro de las Actividades de Tratamiento (ROPA, Secciones 4 a 7): el inventario de las actividades de tratamiento (estilo RGPD Art. 30 / LGPD Art. 37), la matriz finalidad → base jurídica → conservación, la política de conservación y supresión, y el procedimiento de supresió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 / RGPD Art. 28), tratando datos exclusivamente bajo las instrucciones de BAS AI. Son solo tres: Supabase, Anthropic y Resend. Las plataformas y fuentes que actúan como responsables independientes (Apple, Oura, WHOOP) no son subencargados y se describen en la Sección 3.5.

1.1 Principios que rigen la cadena de subencargados

• Minimización. Cada subencargado recibe solo el mínimo de datos necesario para su función.
• Separación entre identidad y datos clínicos. Los identificadores directos (PII) se cifran en una bóveda (identity_vault), apartados de las tablas clínicas, que referencian al titular solo por un identificador seudónimo (profile_id). El cifrado es cifrado de campo autenticado (AEAD) determinista vía pgsodium (AES-256), aplicado a nombre, correo de contacto, teléfono y documento nacional.
• Ocultación (tarja) en el dispositivo antes de la IA (best-effort, no es anonimización). Antes de enviar un documento a la IA, la app aplica — en el propio dispositivo — una ocultación dirigida a los cuatro identificadores directos del titular (nombre, documento nacional, correo y teléfono), y es la copia ocultada la que va a la IA. Esa ocultación es best-effort y no es una anonimización: cuando la ocultación se ejecuta y ningún identificador coincide, o cuando la bóveda de identidad está vacía, el documento original puede seguir; además, un informe puede contener otros identificadores impresos que la ocultación no cubre. Por ello recomendamos no introducir información identificativa en campos de texto libre.
• Sin entrenamiento. El proveedor de IA tiene prohibido contractualmente usar los datos para entrenar o mejorar modelos.
• Sin venta de datos. Ningún dato personal se vende a terceros.
• Cadena controlada. Ningún subencargado puede contratar a un nuevo subencargado para tratar tus 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 siguientes:

3. Parte A — Lista de Subencargados

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

3.2 Anthropic — modelo de lenguaje (Claude) para lectura educativa y extracción de exámenes

Diario de salud sensible — NO va a Anthropic. Los registros diarios de hábitos sensibles (dosis de alcohol, contexto de estrés/alcohol de la noche — finalidad opt-in daily_journal) NO se comparten con Anthropic. Permanecen almacenados en la base de datos (Supabase, cifrados en reposo) y fuera del contexto de análisis (allow-list de kinds en analysis_core/wearable_context). Un eventual envío a la IA exigiría un consentimiento de IA separado y explícito del titular, inexistente en esta versión.

**Anotaciones de wearable (Oura enhanced tags) — texto libre descartado; solo el código de categoría va a Anthropic bajo el Diario de salud. El texto libre que el titular registra en la app de Oura (nombre personalizado y comentario — wearable_annotations, migración 0330) es descartado en la importación y nunca llega a guardarse (no llega al historial, a nuestros registros ni a los logs). Guardamos solo el código de categoría estandarizado (el "tipo": café, alcohol, etc.), de lectura solo-titular (RLS; fuera del intercambio familiar de solo lectura) y eliminado al desconectar el proveedor. Ese código estandarizado — agregado por semana y nunca como texto libre — puede integrar el contexto enviado a Anthropic cuando, y solo cuando, el titular mantiene el Diario de salud sensible (daily_journal) activo; sin ese consentimiento, no se envía a la IA. El "consentimiento separado y explícito" que la versión anterior describía como inexistente ahora existe**: es justamente daily_journal.

3.3 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 (páginas/prompts) —, con Apple como responsable de la transacción (merchant of record; ver 3.5). No hay intermediario de suscripciones de terceros.

3.4 Lo que NO es subencargado

• Lo que ocurre en el iPhone. La lectura de HealthKit y la caché en el dispositivo no implican a terceros. La ocultación de los identificadores del titular ocurre localmente, antes del envío a la IA (best-effort — ver 1.1 y 3.2). No hay OCR local ni anonimización en el dispositivo.
• Plataforma y fuentes que son responsables independientes. Apple (plataforma/IAP/Sign in with Apple/HealthKit) y los proveedores de wearable Oura y WHOOP actúan como responsables independientes de sus propias plataformas — no como encargados de BAS AI (ver Sección 3.5).
• Sin SDK de rastreo de terceros. La app no integra ningún SDK de publicidad/rastreo que vea datos de salud. Hoy no usamos ninguna herramienta de analítica o rastreo de terceros; si esto 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 integra un diccionario de referencia derivado de LOINC® (Regenstrief Institute, Inc.) y UCUM. Es contenido licenciado integrado — funciona localmente como una tabla de consulta. Regenstrief Institute no recibe ningún dato personal/clínico del titular, no trata datos por cuenta de BAS AI y no es subencargado; 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 cadena de tratamiento de datos. La LOINC License es gratuita incluso para uso comercial y exige atribución visible y seguimiento de las actualizaciones (~2x/año).

3.5 Plataforma y fuentes de datos — Apple, Oura y WHOOP (responsables independientes; NO son subencargados)

Estas entidades no tratan datos por cuenta de BAS AI: cada una es responsable independiente de su propia plataforma. Apple es la plataforma de distribución, autenticación opcional, push y pago; Oura y WHOOP son fuentes de datos/originadores conectadas por el propio titular. El flujo de wearable es solo de entrada (del proveedor al historial del usuario), mediante conexión OAuth autorizada por el titular y consentimiento específico por fuente (wearable_sync_oura / wearable_sync_whoop, base doble LGPD Art. 11, I + RGPD Art. 9(2)(a), revocable). El proveedor no recibe datos del historial.

Apple Inc. — plataforma de distribución y servicios de SO, responsable de la transacción (merchant of record) de las compras de suscripción y paquetes adicionales vía In-App Purchase nativo (StoreKit), proveedor de Sign in with Apple (cuando se elige) y de notificaciones push. El acceso de lectura a Apple Health (HealthKit) es opcional y ocurre localmente, en el dispositivo (consentimiento wearable_sync_apple_health) — Apple no participa en el tránsito de esos datos a nuestro backend y no recibe la base clínica de MyHealth. En el pago, BAS AI no recibe ni almacena datos de tarjeta. Cumplimiento de la Apple Guideline 5.1.3 (datos de salud nunca usados para marketing, compartición con terceros o entrenamiento de IA) y de las Directrices 3.1.1/3.1.2 (compras digitales). Ubicación: EE. UU. / infraestructura global de Apple, bajo el Apple Developer Program License Agreement.

Apple Health (HealthKit) no figura en la tabla de wearables con tráfico de red porque la lectura es local, en el dispositivo — no hay tráfico de datos entre Apple y el backend de BAS AI.

Recepción de webhooks de wearable (Oura/WHOOP). Para recibir avisos de actualización/eliminación en tiempo real, guardamos un identificador seudónimo del perfil del titular en WHOOP (el user_id numérico que los registros ya traen — nunca nombre ni correo) para enrutar el webhook a la conexión correcta. El webhook solo señaliza una nueva sincronización (ningún dato clínico transita en él), la firma HMAC se valida, y el evento de eliminación del proveedor borra la fila correspondiente en el historial (paridad de eliminación). Las subscriptions de Oura nunca suscriben daily_stress (minimización). El identificador vive en la Supabase ya declarada — sin nuevo subencargado y sin nueva transferencia internacional.

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

Inventario de las actividades de tratamiento (RGPD Art. 30 / LGPD Art. 37). Los consentimientos por finalidad se guardan 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 Jurídica → Conservación

Base jurídica 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, compartición familiar y sincronización de wearables) es el consentimiento específico y destacado para dato sensible — LGPD Art. 11, I/II "a" / RGPD Art. 9(2)(a) — coherente con el posicionamiento de "historial soberano" y revocable en cualquier momento. Como base subsidiaria — limitada a la seguridad e integridad del tratamiento, al cumplimiento de una obligación legal y a la ejecución de la propia supresión de datos — se aplican LGPD Art. 7, II y Art. 10 / RGPD Art. 6(1)(c) y (f). NO se invoca la base de tutela de la salud (LGPD Art. 11, II "f" / RGPD Art. 9(2)(h)): el RGPD Art. 9(3) condiciona esa base a un tratamiento por un profesional sujeto a secreto en el flujo, y no hay médico en el bucle de MyHealth — el asistente nunca comunica diagnóstico, pronóstico ni decisión terapéutica.

HIPAA no aplica. MyHealth es un producto B2C bajo el control del propio titular; BAS AI no es covered entity ni business associate de HIPAA. Por ello no publicamos "BAA" ni "HIPAA compliant".

6. Política de Conservación y Supresión (doble vía)

1. Regla general (vía clínica). Los datos del historial (PHI/DEMO, documentos, conversaciones de IA, wearables, rutina) se conservan mientras exista la cuenta y el titular quiera mantener el historial organizado; se suprimen al borrar la cuenta (Sección 7).

1-A. Condensación de series de wearable (minimización). Las series diarias brutas de métricas continuas de wearable (p. ej., SpO2, pasos, FC media al caminar — nunca mediciones manuales ni mediciones clínicas como peso, glucosa o presión) pueden ser condensadas después de 13 meses en rollups semanales (mínimo/media/máximo/conteo) y, después de 36 meses, en mensuales (migración 0231; parámetros en wearable_condense_config). El DELETE del dato bruto solo ocurre en la misma transacción del rollup persistido; la condensación nunca dispara un análisis de pago; la supresión de la cuenta borra también los rollups (cascada). Base: minimización/limitación de almacenamiento — LGPD art. 6, III; RGPD art. 5(1)(c)/(e).

1. Doble vía de identidad. La identidad directa (nombre/correo, cifrada en el identity_vault) se conserva solo para quien TRANSACCIONÓ (se suscribió o compró paquetes adicionales), por el plazo fiscal de la jurisdicción: 5 años (Brasil, EE. UU. y demás), 6 años (Reino Unido, Canadá), 10 años (UE). Para menores y para no pagadores, la identidad se SUPRIME en el acto de la supresión — no hay vía fiscal de identidad.
2. Comprobantes fiscales. Los comprobantes de facturación/fiscales (compra de suscripción y paquetes adicionales) siguen el mismo plazo fiscal de la jurisdicción anterior (Brasil: CTN, arts. 173 y 174), aunque la cuenta se borre antes.
3. Registros de acceso. El access_log (metadato de auditoría/seguridad — quién, cuándo, qué tabla, acción, IP de origen y el user-agent de la petición en los accesos síncronos orientados al usuario — edges analyze-exam/ai-assistant/access-ping, migración 0309; en los inserts asíncronos/cron el user-agent queda nulo por diseño) se guarda por 6 meses (Marco Civil de Internet, art. 15). Es metadato sin contenido clínico; ese plazo no justifica conservar contenido del historial.

4-A. Índice forense post-eliminación (account_forensic_hold, migración 0308, aplicada 2026-07-17). En el acto de la eliminación, y para toda cuenta (incl. menores — gate DPD), se guarda un índice minimizado que sobrevive al borrado, con como máximo: identificadores de búsqueda (correo, Apple sub, teléfono, documento nacional) en HMAC-SHA256 con pepper dedicado guardado en una bóveda (Vault), cifrado por una clave-raíz gestionada fuera de la base de datos, nunca expuesto (nunca texto legible) + IPs recientes en texto; y el identificador seudónimo de la cuenta (account_ref) con metadatos mínimos de guarda (account_id, fechas de creación/eliminación, jurisdicción, plazo). Sin PHI, sin nombre/correo legible. Los identificadores en HMAC son dato SEUDONIMIZADO — siguen siendo dato personal (LGPD Art. 12/13), retenidos bajo el Art. 16, I; no se invoca la anonimización (Art. 16, IV). Finalidad: prevención de fraude, ejercicio/defensa de derechos y respuesta a autoridad competente dentro del plazo de guarda. Plazo: plazo prescriptivo aplicable, fijado por defecto en la misma duración que el plazo de guarda fiscal (ítem 2) por proporcionalidad — no "plazo fiscal" —, con purga automática (purge_legal_retention); para menores, plazo REDUCIDO y proporcional a la prevención de fraude (nunca el fiscal, que no se aplica a un menor que no transacciona), sujeto a evaluación de proporcionalidad + sign-off del DPD. Tabla blindada (RLS sin políticas, sin grant a admin_ops); acceso solo vía RPCs SECURITY DEFINER owner-gated que auditan antes de resolver. Base (por finalidad): LGPD Art. 16, I (autoridad) + Art. 7, VI (defensa de derechos) + Art. 7, IX (fraude, bajo LIA); GDPR Art. 6(1)(f) + Art. 17(3)(e). (La guarda fiscal — GDPR Art. 6(1)(c)/Art. 17(3)(b) — es del account_legal_hold; el Marco Civil Art. 15 rige el access_log de 6 meses, no este índice.) Las cuentas eliminadas antes de la vigencia no tienen hold.

1. Procesamiento por IA. El contenido enviado a Anthropic es transitorio; el subencargado lo conserva por un período limitado y luego lo suprime (por regla, en hasta ~30 días), salvo conservación exigida por ley o para prevención de abuso. El resultado incorporado al historial sigue la regla general; las conversaciones del chat asistente se guardan hasta que el titular las borre.
2. Telemetría técnica. La telemetría de estabilidad/diagnóstico (sin PHI) se conserva por hasta ~12 meses, por autolimitación de minimización (LGPD art. 6, III) — política interna del Responsable, no plazo impuesto por ley.
3. Inmutabilidad y desvinculación de los registros. El access_log es append-only (UPDATE/DELETE bloqueados por trigger). Los consent_events están desvinculados/seudonimizados (clave HMAC mantenida fuera de la base de datos) — no "anónimos": preservan la prueba de cuándo se concedió/revocó el consentimiento sin reidentificar directamente al titular. 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.
4. Supresión a petición. La supresión se ejecuta a petición del titular (o del tutor legal, en el caso de menores), según el procedimiento de la Sección 7, en hasta 30 días.

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

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

1. Solicitud. El titular (o tutor legal, en el caso de un dependiente menor) inicia la supresión en la app o por contacto con el DPD.
2. Alcance. La supresión borra toda la PHI, los documentos/informes en el Storage, los vínculos de compartición familiar, los datos de wearables y rutina (sleep_sessions, daily_scores, health_events, med_intakes, medidas con provider/external_id), los hábitos de vida (lifestyle_facts), las conversaciones con el asistente de IA (chat_messages/conversations), las comunicaciones de soporte (support_tickets/support_ticket_messages), los registros de uso del Servicio de IA (ai_usage, credit_ledger y correlatos, salvo la conservación fiscal de comprobantes de compra), los datos de conexión de wearables (wearable_connections, oauth_states — tokens cifrados) y los datos de cuenta. Las tablas clínicas se borran en cascada desde profile_id (claves foráneas on delete cascade).
3. Dependientes gestionados. La supresión de la cuenta también borra los datos de los dependientes gestionados (perfiles de menores) bajo esa cuenta. Antes de borrar a un menor, la app ofrece MIGRAR la tutela del menor a un co-tutor existente — en cuyo caso el perfil del menor sobrevive bajo el nuevo tutor, en lugar de ser borrado.
4. Identidad (doble vía). Si el titular transaccionó, su identidad mínima (nombre/correo) se conserva cifrada solo por el plazo fiscal de la jurisdicción (Sección 6). Si no transaccionó — y siempre para menores — la identidad se SUPRIME en el acto de la supresión.
5. Supresión efectiva. Eliminación permanente, en cascada, de los registros y de los documentos; limpieza de los datos en caché del dispositivo al cerrar sesión/borrar. La supresión es permanente, pero no se alega destrucción de claves de cifrado (crypto-shredding) ni irreversibilidad absoluta en copias de seguridad — eventuales copias expiran según los ciclos de conservación de la infraestructura.
6. Conservación mínima legal. Incluso tras la supresión, se mantienen: (a) el mínimo de metadato que la ley exige (registro de que la supresión ocurrió); (b) los registros de acceso por el piso de 6 meses (art. 15) — metadato, sin contenido clínico; (c) la vía fiscal (comprobantes + identidad mínima de quien transaccionó) por el plazo fiscal de la jurisdicción (Sección 6); y (d) el índice forense mínimo (account_forensic_hold — ítem 4-A: identificadores de búsqueda en HMAC + IPs + account_ref/metadatos de guarda, sin PHI), por el plazo prescriptivo aplicable (misma duración que el plazo de guarda fiscal, por proporcionalidad; para menores, plazo REDUCIDO), para prevención de fraude, ejercicio/defensa de derechos y respuesta a autoridad competente, bajo acceso break-glass owner auditado. Nada de esto recompone el historial, que es suprimido.
7. Plazo y confirmación. La supresió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 DPD — dpo@bas-ai.com — que responde con base en el registro mínimo de supresión (LGPD art. 6, X).
8. Subencargados. La supresión se propaga a la infraestructura (Supabase). El contenido enviado a Anthropic es transitorio y conservado por un período limitado (~30 días) y luego suprimido por el subencargado, según sus términos. Para Apple (incl. datos de compra/suscripción vía In-App Purchase, como responsable independiente) y Resend (correo), se aplican los mecanismos de supresión de la respectiva plataforma respecto a los datos que cada una trata. RevenueCat no se utiliza.
9. Desconexión de wearable (purga selectiva por proveedor, sin borrar 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 conservar 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 de Brasil (Ley 8.069/1990), la Ley 15.211/2025 (ECA Digital), el Art. 14 de la LGPD, el Art. 8 del RGPD (estándar de referencia) 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). Este requisito se refiere a la titularidad de la cuenta y no se confunde con la edad de consentimiento digital autónomo del RGPD (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 un menor de 18 con cuenta propia está bloqueado.
• El menor no posee cuenta ni correo propios: existe solo como perfil gestionado (profiles.kind='minor', profiles.managed_by) dentro de la cuenta de un tutor adulto, que ejerce los derechos en nombre del menor (LGPD Art. 14).
• Multi-tutor. El perfil puede tener más de un tutor: el principal invita a otro adulto mediante un código de invitación con plazo de validez. Cada invitado recibe un rol — tutor (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ó. Al borrar la cuenta del tutor principal, la app ofrece migrar la tutela del menor a un co-tutor existente (ver Sección 7).
• Facturación. Las funciones de pago de IA requieren rol de tutor y se facturan al adulto responsable que ejecuta la acción; el dependiente no tiene cuota, paquete ni medio de pago propios. El registro de uso permanece vinculado al perfil del menor para auditoría.
• Los datos de wearables y de Apple Salud nunca siguen el 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. La identidad del menor se SUPRIME en el acto de la supresión (Sección 6).
• EE. UU. (COPPA): MyHealth no ofrece cuentas a menores ni recopila datos directamente de niños; cualquier dato de menor es introducido 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 2026-03-17). La verificación de edad se hace por autodeclaración en el registro, con la atestación registrada en la aceptación (age_attestation, inmutable, con fecha/hora del servidor).

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

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

10. Derechos del titular (multijurisdicción)

Independientemente de la jurisdicción, el titular puede, vía la app o el DPD (dpo@bas-ai.com): acceder y exportar sus datos (portabilidad FHIR R4/PDF), rectificar, suprimir (Sección 7), revocar el consentimiento en cualquier momento y oponerse a tratamientos basados en interés legítimo.

• LGPD (Brasil): derechos del Art. 18 (confirmación, acceso, rectificación, anonimización/supresión, portabilidad, información sobre compartición, revocación).
• RGPD (estándar de referencia global): derechos de acceso, rectificación, supresión, limitación, portabilidad y oposición (Arts. 15–21).
• EE. UU. — CCPA/CPRA (California): derecho a saber, suprimir, rectificar y a excluirse de la "venta"/"compartición" — BAS AI no vende ni comparte datos personales para publicidad comportamental; no hay señales de rastreo de terceros.
• EE. UU. — Washington My Health My Data (MHMDA): los "datos de salud del consumidor" se tratan previo consentimiento; el titular puede retirar el consentimiento y solicitar la supresión; BAS AI no vende datos de salud.
• Canadá (PIPEDA + leyes provinciales): acceso, rectificación y retirada del consentimiento, con conservación fiscal de 6 años cuando aplique.

11. Historial de versiones

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

Nota de no diagnóstico. MyHealth organiza tu historial de salud y ofrece una lectura educativa y prudente. No es un producto sanitario, no diagnostica y no sustituye la evaluación de un profesional de salud. La IA no verifica interacciones medicamentosas, contraindicaciones ni cruza alergias con medicamentos. En una emergencia, busca atención médica de inmediato.