Política de Seguridad.

1. Alcance

Aplica a todo el tratamiento de datos personales —incluidos datos personales sensibles de salud— realizado por Health Companion en app.healthcompanion.app y api.healthcompanion.app, y a la infraestructura de los encargados listados en Subprocesadores.

2. Cifrado

• En tránsito: todas las conexiones usan TLS/HTTPS de extremo a extremo: navegador → Vercel/Cloudflare → API → Supabase / Anthropic. No existe ningún tramo en claro.
• En reposo: la base de datos y el almacenamiento de documentos cifran los datos en reposo.
• Notificaciones push: el contenido de cada notificación viaja cifrado de extremo a extremo (RFC 8291); los relays de push no pueden leerlo.

3. Aislamiento por usuario (control de acceso a datos)

• Todas las tablas con datos de salud tienen Row-Level Security (RLS) en modo FORCE, con políticas owner-only. La protección es a nivel de base de datos, no solo de aplicación.
• Cada request abre su sesión de base de datos con el JWT del propio usuario; un usuario no puede leer filas de otro aunque exista un defecto en la capa de aplicación.
• La llave service_role (que omite RLS, necesaria para bitácora de auditoría y jobs) es exclusivamente server-side, custodiada como secreto (ver §5).

4. Autenticación

• Inicio de sesión con Google (OAuth) vía Supabase Auth.
• La API valida cada request con JWT verificado contra el JWKS de Supabase: selección de llave por kid, verificación de firma, exp, nbf, iss y aud, con rotación de llaves soportada.
• No existe bypass de autenticación en producción.
• Operaciones destructivas (confirmar la eliminación de cuenta) exigen re-autenticación reciente (JWT emitido en los últimos 5 minutos).

5. Gestión de secretos

• Los secretos de producción (llaves de base de datos, API de Anthropic, llaves VAPID) viven exclusivamente en el vault del proveedor de cómputo, nunca en el repositorio git.
• El código no contiene defaults inseguros: toda credencial ausente equivale a funcionalidad deshabilitada, no a un valor de fábrica.
• La llave privada VAPID de push nunca se expone al cliente (solo la pública).

6. Bitácoras sin contenido del paciente

Política: los logs técnicos nunca contienen el texto del paciente (mensajes de chat, contenido de estudios, datos del perfil).

• Los errores hacia el usuario se enmascaran con un identificador; el detalle técnico queda en el servidor sin contenido de salud.
• La bitácora de auditoría registra únicamente metadata: identificadores de turno/usuario/sesión, endpoint, modelo, tokens, costo y timestamps — nunca el contenido de la conversación ni de los documentos.
• El detector de situaciones de crisis registra solo la categoría y el nivel del evento — nunca la frase detectada ni el mensaje del usuario.

7. Límites de uso (contención de abuso)

• Límites de tasa por usuario en los endpoints costosos: 30 turnos de chat por hora y 10 ingestas de documentos por día.
• Invitaciones de cuidador: de un solo uso, expiran a los 7 días, máximo 3 activas por paciente, revocables por el paciente en cualquier momento.

8. Respaldos

• Respaldos diarios automáticos de la base de datos, con retención de 7 días.
• El acceso a los respaldos está restringido al dashboard del proveedor, bajo la cuenta del responsable.

9. Continuidad

La API, los jobs programados y la aplicación web corren en infraestructura de nube gestionada (Render, Vercel, Cloudflare, Supabase) — sin dependencia de hardware doméstico para el tratamiento de datos personales.

10. Reporte de vulnerabilidades

Si detectas una vulnerabilidad de seguridad en Health Companion:

• Escribe a privacidad@healthcompanion.app con la descripción, pasos para reproducirla y, si aplica, evidencia mínima. No accedas a datos de otros usuarios más allá de lo indispensable para demostrar el hallazgo.
• Acusaremos recibo en un máximo de 5 días hábiles y te informaremos la resolución. No emprenderemos acciones contra reportes de buena fe.
• Por ahora no existe un programa de recompensas (bug bounty).

11. Revisión de esta política

Esta política se revisa semestralmente (alineada al ciclo de auditoría interna) o antes, si cambia la arquitectura o los encargados. Responsable de la revisión: Juan Manuel Fraga Sastrías.