Cuando un software de salud promete “sus datos están cifrados”, lo que en realidad dice es: los conservamos, y si alguien accede a nuestros servidores, necesitará una clave para leerlos. La promesa es útil. También es más débil de lo que parece.

Para los datos clínicos en salud mental, el verdadero estándar — el que impone la lógica del secreto médico y el espíritu de las regulaciones europeas — no es “cifrar bien”. Es no almacenar.

Qué significa concretamente “zero-retention”

Zero-retention (o retención cero) significa que un software no conserva nada del contenido clínico que procesa:

El audio del dictado no se escribe en disco
La transcripción no se persiste
La nota generada no se almacena en los servidores
Nada aparece en los logs de la aplicación
Nada queda en una caché

Concretamente: los datos transitan por la memoria RAM durante el procesamiento (unos segundos), la nota se devuelve al navegador del clínico, y todos los rastros se borran inmediatamente. Si se incauta el servidor al día siguiente, no hay nada que incautar.

En el lado de la plataforma solo permanece lo necesario para operar el servicio: el correo del clínico, su suscripción, estadísticas de uso agregadas. Ningún contenido de paciente.

Por qué es más fuerte que el cifrado

El cifrado protege contra un atacante que no tiene la clave. Pero los datos cifrados siguen:

Copiándose a las copias de seguridad
Presentes en los logs hasta su rotación
Accesibles a los administradores con la clave (o vía una clave maestra alojada en el mismo servidor)
Vulnerables si el proceso de descifrado se ve comprometido
Sujetos a requerimiento judicial

No almacenar elimina todos estos riesgos con una sola decisión de arquitectura. No hay nada que requerir, filtrar, descifrar o respaldar. El riesgo no se reduce: es inexistente.

Lo que dicen el RGPD y la LOPDGDD

El RGPD (Reglamento General de Protección de Datos, UE) y la LOPDGDD (Ley Orgánica de Protección de Datos Personales y garantía de los derechos digitales, España) comparten tres principios que convergen hacia la retención cero.

Minimización de datos (RGPD Art. 5.1.c). Solo se trata lo estrictamente necesario. Para una herramienta que estructura un dictado clínico en nota, el tratamiento se cumple en el momento en que la nota es devuelta. Cualquier conservación posterior no responde a finalidad legítima alguna y no es conforme.

Limitación del plazo de conservación (RGPD Art. 5.1.e). Los datos no deben conservarse más de lo necesario. “No más de lo necesario” puede significar, para una herramienta de transcripción, cero segundos una vez producida la nota.

Protección por defecto (RGPD Art. 25). El responsable del tratamiento debe aplicar “por defecto” medidas que garanticen que solo se traten los datos necesarios. La arquitectura es una de esas medidas. Un software diseñado para no persistir los datos es conforme por construcción — no por compromiso contractual.

El secreto médico apunta en la misma dirección

El secreto médico (en España, art. 199 del Código Penal y art. 10 de la Ley 41/2002) no se detiene en las paredes del consultorio. Se extiende a todos los auxiliares del clínico — y un software de notas entra en esa categoría desde que trata datos identificativos o contenidos clínicos.

Cuanto más almacena un subcontratista, más expuesto está a un incidente que vulnere el secreto. La mejor estrategia para un subcontratista responsable es organizar su arquitectura para no estar en condiciones de vulnerar el secreto, ni siquiera por accidente.

Lo que el zero-retention no resuelve

Honestidad intelectual: la retención cero no lo resuelve todo.

El proveedor de IA (Whisper, Mistral, GPT, etc.) trata los datos durante unos segundos. Puede conservar logs de inferencia según sus propias políticas. Hay que leer su acuerdo de tratamiento (DPA) y verificar que excluye el entrenamiento con los datos y la conservación prolongada.
El navegador del clínico puede conservar la nota en su caché o historial. Es responsabilidad del clínico.
Los metadatos técnicos (IP, marca temporal, duración del dictado, especialidad) siguen existiendo en el lado de la plataforma por razones operativas. No son contenido clínico pero existen.

Zero-retention no significa ningún dato existe jamás. Significa ningún contenido clínico identificable se conserva.

Lo que esto cambia en la práctica para el clínico

Tres consecuencias tangibles:

Sin DPA extenso con el subcontratista. El DPA (acuerdo de tratamiento) sigue siendo obligatorio, pero su contenido es más simple: no hay procedimiento de notificación de brecha, no hay procedimiento de restitución de datos, no hay procedimiento de supresión — porque no hay nada que filtrar, restituir o suprimir.

El derecho de acceso del paciente se vuelve trivial. Si el paciente pide, en virtud del RGPD Art. 15, qué datos el subcontratista retiene sobre él: ninguno. El clínico puede responder de forma documentada.

Los incidentes de seguridad se desacoplan del contenido clínico. Un compromiso del servidor de Psydict (por ejemplo) expondría la lista de clínicos suscritos y metadatos de uso. No expondría ni una sola palabra de ninguna nota de ningún paciente.

Criterios prácticos para evaluar una herramienta

Cuando un software de salud anuncia “seguro” o “conforme al RGPD”, hacer tres preguntas precisas:

¿Se persiste el contenido clínico (audio, transcripción, nota) en sus servidores? Si sí, ¿durante cuánto tiempo y dónde?
¿Aparece en los logs de la aplicación? Si sí, ¿cuál es la política de rotación?
¿Quién, en su empresa, tiene acceso técnico al contenido en claro, y en qué circunstancias?

Las respuestas “cifrado en reposo” y “cifrado en tránsito” son insuficientes por sí solas. Dicen cómo se protegen los datos, no cuánto tiempo existen.

Conclusión

Cifrar lo que se almacena es una buena práctica. No almacenar es mejor. Para una herramienta que no tiene razón funcional para conservar las notas clínicas que produce, la arquitectura “zero-retention” no es un lujo de seguridad — es la consecuencia lógica del principio de minimización y del secreto médico.

El estándar para los datos clínicos en salud mental debería ser este: si no lo necesita en cinco segundos, no debería haberlo tenido nunca.