Los wearables saben más de ti que tu teléfono: datos de salud, IA, privacidad y confianza

Un teléfono sabe dónde estás porque lo llevas contigo. Un wearable puede saber cuándo cambia tu pulso mientras duermes, cuántas veces te despiertas, cuánto entrenas y si tu rutina empieza a ser irregular. Esa diferencia se subestima porque el dispositivo parece un reloj o un anillo, no una historia clínica.

Los datos son continuos, íntimos e inferenciales

Un teléfono suele producir señales puntuales: se abre una app, se solicita una ubicación, se toma una foto o se envía un mensaje. Un wearable está diseñado para muestrear de forma continua. Según sus sensores y ajustes, puede registrar pulso, variabilidad de la frecuencia cardiaca, estimaciones de oxígeno en sangre, temperatura de la piel, movimiento, ventanas de sueño, rutas de entrenamiento, elevación e identificadores del dispositivo. Algunos también recogen señales del micrófono, pagos sin contacto o indicadores relacionados con el estrés.

Ningún campo tiene que decir “depresión”, “embarazo” o “riesgo cardiaco” para ser sensible. El momento y la correlación pueden hacer ese trabajo. Un modelo puede inferir un cambio en el sueño, un nuevo trayecto, un periodo de enfermedad o una rutina de medicación a partir de mediciones ordinarias. La lectura directa puede tener ruido; el patrón de varias semanas puede revelar mucho.

Los datos de salud revelan más cuando se unen: una muestra de pulso con fecha y hora, una ruta, una rutina del calendario y la confianza de un modelo pueden describir a una persona con más precisión que cualquier campo aislado.

Por eso decir “el reloj solo registra pasos” es un argumento incompleto de privacidad. La pregunta importante es qué puede deducir el servicio al combinar pasos con sueño, ubicación, edad, modelo del dispositivo e historial de la cuenta.

Los permisos son un contrato de acceso, no una garantía de privacidad

En iOS, una app puede solicitar acceso de lectura o escritura mediante Apple HealthKit. Una app de entrenamiento puede pedir leer pulso y entrenamientos y, a la vez, permiso para escribir sesiones de ejercicio. En Android, una app puede usar permisos de Health Connect como HeartRateRecord, sesiones de sueño, pasos o distancia. Las etiquetas ayudan, pero no son todo el contrato: el servidor de la app puede recibir una copia después de la sincronización, y un servicio de análisis conectado puede recibir un resultado derivado.

Revisa los permisos en tres niveles:

• Dispositivo: ¿qué sensores están activos? ¿Hace falta la medición continua o bastaría con registrar solo el entrenamiento?
• Almacén de salud del teléfono: ¿la app puede leer historiales, escribir registros o ambas cosas? ¿Puede leer categorías ajenas a su función declarada?
• Servicio en la nube: después de sincronizar, ¿qué sale del teléfono? ¿Qué alcances OAuth, exportaciones, webhooks o integraciones de socios están activos?

Las ventanas de permiso responden “¿puede esta app acceder a esta categoría?”. No siempre responden “¿usará el proveedor estos datos para entrenar un modelo, conservarlos cinco años, vender un segmento de audiencia o combinarlos con un perfil de intermediario de datos?”. Lee el aviso de privacidad y los controles de borrado con la misma atención que la ventana de permiso.

Qué puede exponer una API de wearable

Una API no es solo un botón que devuelve una puntuación diaria. Una API de wearable o de una plataforma de salud con autorización puede exponer muestras con fecha y hora, agregados y contexto. Los campos exactos cambian, pero una integración técnica puede recibir:

• Mediciones: pulso a intervalos, pulso en reposo, variabilidad cardiaca, calorías, estimaciones de oxígeno, pasos, temperatura o valores relacionados con la respiración.
• Eventos: inicio y fin del sueño, despertares, entrenamientos, caídas, avisos de ritmo irregular, registros del ciclo menstrual o puntuaciones de recuperación.
• Contexto: puntos GPS, elevación, zona horaria, modelo y firmware del dispositivo, batería y si una lectura fue introducida manualmente.
• Identidad y autorización: identificador de cuenta, correo electrónico, rango de edad, configuración regional, token de actualización OAuth y registro de los alcances aprobados.

Las API también exponen hechos operativos. Una petición de los últimos 30 días dice algo sobre cómo funciona la app. Los webhooks revelan cuándo ocurre un nuevo entrenamiento o evento de sueño. Un alcance de “leer todo el historial” es materialmente distinto de “leer el entrenamiento de hoy”. Los equipos deben minimizar tanto los campos como la ventana temporal, guardar solo lo que exige la función y revocar tokens cuando se elimina una conexión.

Ejemplo de revisión del alcance mínimo 
leer:pulso          → ¿hace falta para una zona de entrenamiento en directo? 
leer:sueño          → ¿hace falta para la función de recuperación declarada? 
leer:ubicación      → ¿hace falta después de terminar la ruta? 
historial:completo  → ¿por qué no basta un intervalo acotado? 
escribir:entreno    → ¿la app debe modificar el registro de salud?

La IA cambia la pregunta: de recopilar a inferir

La IA puede resumir una semana, predecir recuperación, detectar anomalías, guiar un entrenamiento o clasificar a una persona para una oferta. Esas funciones pueden ser útiles sin ser misteriosas, pero el riesgo de privacidad se desplaza de la recopilación a las conclusiones invisibles. Un sistema que nunca guarda un diagnóstico puede guardar un nivel de riesgo, una etiqueta de “fatiga probable”, una línea base personalizada o un valor de confianza. Esos resultados pueden afectar notificaciones, precios, elegibilidad y lo que ve un operador humano.

Haz cuatro preguntas técnicas. ¿El modelo funciona en el dispositivo o en la nube del proveedor? ¿Se envían muestras sin procesar o solo agregados? ¿Se conservan las indicaciones, embeddings y resultados para depuración o entrenamiento? ¿Puede una persona corregir una inferencia y hacer que la corrección llegue a los sistemas posteriores? “Con IA” debe describir un flujo de datos, no sustituirlo.

Un diseño responsable separa telemetría e identidad cuando es posible, limita el acceso al conjunto mínimo útil, registra las versiones del modelo y ofrece una explicación en lenguaje común. También fija un límite de finalidad: un modelo creado para orientar el sueño no debe convertirse en silencio en un clasificador de riesgo laboral o asegurador.

El cifrado protege el canal; la gobernanza protege el significado

Usa TLS para el transporte entre dispositivo y teléfono y entre teléfono y nube, cifrado autenticado para los registros almacenados y rotación gestionada de claves para las copias de seguridad. Son controles básicos. No hacen que el proveedor sea incapaz de leer los datos. Un servicio puede descifrarlos para calcular una puntuación, buscar una cuenta, moderar contenido o ejecutar una inferencia.

Para una persona, las preguntas prácticas son: ¿hay cifrado en tránsito y en reposo? ¿Las copias de seguridad se cifran por separado? ¿Quién accede a las bases de producción? ¿Las exportaciones de soporte tienen tiempo limitado y auditoría? ¿Los tokens se guardan en un almacén respaldado por hardware en el teléfono? ¿El proveedor ofrece borrar datos sin procesar, datos derivados y copias, o solo la vista de la cuenta?

El cifrado de extremo a extremo es una propiedad más fuerte que “está cifrado”. Si el proveedor puede ejecutar el motor de recomendaciones sobre tu historial de salud sin que tú lo hagas, probablemente existe un punto donde el texto claro o una representación reversible está disponible. Puede ser aceptable cuando la finalidad es clara y los controles son sólidos, pero debe explicarse sin eufemismos.

La retención decide cuánto puede viajar un error

La retención es una decisión de producto, no una nota al pie. Un servicio puede conservar muestras sin procesar 30 días, agregados diarios dos años, características del modelo indefinidamente y registros de auditoría aún más. Borrar la app no necesariamente borra la cuenta en la nube. Desconectar HealthKit o Health Connect corta una vía futura de permisos; no siempre borra los registros ya exportados a un proveedor o socio.

Busca un calendario de retención que distinga datos sin procesar, puntuaciones derivadas, copias de seguridad, tickets de soporte y reservas legales. Prefiere sistemas que permitan borrar una conexión, una fuente de datos concreta y la cuenta por separado. Si compartes una exportación, asume que también importa la política de retención del destinatario. Guarda una nota de lo que autorizaste y cuándo; las capturas de permisos y confirmaciones de cancelación son evidencia útil.

Aseguradoras, empleadores y el límite de compartir voluntariamente

Los programas de wearables suelen ofrecer un descuento, un beneficio de bienestar, coaching o recompensas a cambio de actividad. El beneficio puede ser real, pero “voluntario” se siente distinto cuando un precio, una promoción o la cultura laboral generan presión. Antes de inscribirte, identifica la entidad legal que recibe los datos, los campos exactos, el periodo de evaluación y si el programa comparte registros sin procesar o solo una puntuación.

Con una aseguradora, pregunta si los datos afectan a la suscripción, a una recompensa de bienestar, a la revisión de una reclamación o solo a un panel individual. Con un empleador, pregunta si recibe registros identificables, estadísticas agregadas, estado de participación o nada más que una factura del proveedor. Un proveedor puede operar el programa mientras el contrato le concede derechos separados para analizar o conservar datos. No deduzcas el límite a partir de una pantalla amable; lee las condiciones del programa.

Checklist práctico de confianza

1. Enumera cada sensor, categoría de salud, campo de ubicación y dato de identidad que la función podría usar.
2. Concede el alcance más estrecho de iOS HealthKit o Android Health Connect; rechaza historiales ajenos.
3. Confirma si el procesamiento ocurre en el dispositivo, en la nube del proveedor o con un tercero.
4. Comprueba TLS, cifrado en reposo, custodia de claves, acceso de producción, copias y aviso de brechas.
5. Busca los plazos de retención de muestras, puntuaciones, entradas del modelo, registros y copias.
6. Lee las condiciones de aseguradora o empleador sobre datos identificables, agregados, precios, elegibilidad y apelaciones.
7. Prueba desconexión, revocación de tokens, exportación, corrección y borrado antes de depender del servicio.
8. Revisa permisos cada trimestre y después de cambios en la app, firmware, propiedad o política.

Para una revisión técnica, dibuja el flujo desde sensor hasta dispositivo, almacén de salud, API, modelo, destinatario y tarea de borrado. Pon un responsable y un control medido en cada flecha. Si un equipo no puede mostrar adónde va una muestra sin procesar después de pulsar “borrar”, la confianza sigue siendo una suposición.

Preguntas frecuentes

Qué viene

Los wearables serán mejores para captar contexto mientras desaparecen dentro de objetos cotidianos: anillos, auriculares, ropa y dispositivos cercanos a lo médico. La IA convertirá más flujos en recomendaciones y clasificaciones. El modelo de privacidad ganador no será “no recopilar nada”, porque el cuidado y el acompañamiento útiles necesitan datos. Serán límites visibles: permisos estrechos, procesamiento local cuando sea posible, retención breve, destinatarios responsables y una forma real de revocar la confianza.