Seguridad y LGPD

Los datos sensibles exigen controles serios — así es como tratamos los tuyos

Cifrado, control de acceso basado en la titularidad y principios de la LGPD incorporados en la arquitectura, no añadidos después.

Datos sensibles de salud: la voz, la expresión facial y el contenido de la sesión terapéutica se tratan como datos sensibles en los términos de la LGPD brasileña (Ley 13.709/2018). Esta página describe los controles técnicos y organizativos aplicados.

Protección de datos

Cómo se protegen los datos de la sesión

Cifrado

Los datos en tránsito están protegidos por TLS; los datos en reposo se almacenan de forma cifrada en la base analítica.

Control de acceso

Cada informe de sesión está vinculado a la titularidad del profesional responsable — acceso restringido por cuenta, no compartido libremente por sesión.

Anonimización analítica

Las métricas agregadas para investigación interna se basan en hashes de sesión y de paciente, sin datos directamente identificables en la capa analítica.

Cómo funciona, sin simplificar en exceso

El recorrido real de una sesión

Preferimos describir la operación completa antes que resumirla de una forma que parezca más simple de lo que es.

Transmisión y procesamiento

Las sesiones remotas usan WebRTC; cuando la conexión directa entre los dispositivos no es posible, un servidor TURN actúa como relevo. Una parte relevante de las métricas se calcula en el navegador del profesional; los segmentos de audio pueden enviarse al backend de FROID y a un proveedor de transcripción especializado para el procesamiento de voz, imagen y texto.

Alojamiento y copias de seguridad

Las transcripciones, informes y registros autorizados se almacenan en la infraestructura de FROID, que puede incluir alojamiento en Estonia y proveedores de pago, IA, correo electrónico y agenda — lo que puede implicar una transferencia internacional, protegida por los mecanismos contractuales y técnicos aplicables. Las copias de seguridad están cifradas y se verifican periódicamente.

Aislamiento multiorganización

Los datos de cada organización (clínica o profesional) están segregados mediante seguridad a nivel de fila (RLS) en la base de datos — por construcción, una organización no puede acceder a los registros de otra.

Auditoría de acceso

El acceso, la modificación, la exportación y la denegación de acceso a informes y datos de pacientes quedan registrados en una pista de auditoría, vinculada a la cuenta que realizó la acción.

Cumplimiento

LGPD y buenas prácticas del sector

Tratamos los principios de la LGPD — finalidad, necesidad, transparencia y seguridad — como requisitos arquitectónicos, no como una lista de verificación aplicada después. Esto sigue el mismo razonamiento que los estándares internacionales de SaaS de salud (HIPAA, RGPD): el cumplimiento debe estar incorporado en el cifrado, en las pistas de auditoría y en el control de acceso basado en roles, no solo en un contrato.

Para las clínicas y profesionales que contratan FROID, ponemos a disposición los términos de tratamiento de datos como parte del proceso de registro profesional.

Compromisos actuales

  • Consentimiento explícito del paciente antes de cada sesión grabada
  • Derecho a la eliminación de datos a solicitud
  • Notificación en caso de incidente de seguridad

Modelo de responsabilidad compartida

Como en cualquier SaaS de salud, la seguridad se divide: FROID es responsable de la infraestructura de la plataforma (cifrado, copias de seguridad, control de acceso a la aplicación); la clínica/profesional contratante es responsable de la gestión del acceso de su equipo y del consentimiento obtenido del paciente.

Pila técnica relevante

Backend FastAPI con persistencia en DuckDB para analítica agregada; control de titularidad de informes vía _can_access_report() y _report_owner_email(); hash de sesión anónima vía _anonymous_session_hash() antes de cualquier agregación estadística.

Endurecimiento de plataforma e infraestructura

  • Cifrado: TLS en el borde; en reposo, cifrado autenticado Fernet (AES-128-CBC + HMAC-SHA256) con rotación de claves vía MultiFernet; contraseñas con PBKDF2-HMAC-SHA256 (120.000 iteraciones + salt).
  • Cabeceras de seguridad: HSTS con preload, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy y Permissions-Policy (concede solo cámara/micrófono).
  • Superficie de red reducida: los servicios internos no se publican en la interfaz pública; todo el acceso pasa por Caddy sobre TLS; firewall que permite solo 80/443 y SSH restringido.
  • Contenedores sin privilegios: proceso no-root, no-new-privileges, Linux capabilities eliminadas (cap_drop: ALL) y límite de procesos.
  • Defensa de aplicación: validación del SQL generado por IA (allowlist SELECT/WITH, conexión read_only, tablas restringidas); limitación de tasa en autenticación e ingesta; límites de cuerpo y timeouts en el borde.
  • Integridad en tiempo real: el procesamiento de señales (F0/MFCC/envolvente) se ejecuta en un thread pool para no bloquear el bucle de análisis con sesiones concurrentes.
  • Operación: dependencias fijadas para builds reproducibles; healthchecks por servicio; copias de seguridad cifradas off-site con prueba de restauración.