Almacenamiento cloud con cumplimiento de grado médico en Europa: qué exige el RGPD

1. El riesgo de usar almacenamiento cloud genérico para datos de salud

1.1. Por qué una nube de consumo general no es la misma capa

Un servicio de almacenamiento pensado para documentos de oficina o fotos personales no está diseñado para datos de categoría especial como los de salud. No es que esté prohibido por definición: es que rara vez ofrece, de serie, lo que un dato clínico necesita —cifrado adecuado, control de acceso por perfil, registro de quién consultó qué y un contrato de encargado del tratamiento firmado—. La clínica que usa esa capa genérica para historiales suele hacerlo sin saber que le falta alguna de esas piezas: el servicio funciona, los archivos se guardan y se recuperan sin problema, y esa normalidad aparente es precisamente lo que hace que nadie se pare a comprobar si el contrato firmado con ese proveedor cubre lo que exige un dato de salud.

1.2. Qué dice la normativa sobre dónde y cómo se guardan estos datos

El RGPD trata los datos de salud como categoría especial, con medidas de seguridad reforzadas y una base legal más estricta que un dato personal ordinario. Eso no significa que exista una lista cerrada de proveedores «autorizados»: significa que el centro sanitario, como responsable del tratamiento, tiene que poder demostrar que el almacenamiento que usa cumple esos requisitos, tenga o no una marca reconocible detrás. El marco completo de obligaciones del centro está en el cumplimiento del RGPD en clínicas privadas, y las consecuencias de no cumplirlo en sanciones de la AEPD a clínicas sanitarias. Quién de la plantilla puede llegar a ver ese dato es otra pieza del mismo problema: el detalle está en gestión de accesos y roles en la consulta.

2. Qué debe tener un almacenamiento pensado para datos médicos

2.1. Cifrado, control de acceso y trazabilidad

Tres piezas mínimas: los datos cifrados tanto en tránsito como en reposo, un control de acceso que limite quién ve qué según su perfil, y un registro que deje constancia de cada consulta o modificación, con su autor y su fecha. Sin esas tres piezas, cualquier otra funcionalidad es secundaria.

2.2. Un contrato de encargado del tratamiento firmado

El proveedor que aloja datos de salud por cuenta de la clínica actúa como encargado del tratamiento, y eso exige un contrato específico —el DPA— que fije sus obligaciones. Sin ese contrato firmado, el uso del servicio para datos de salud no está en regla, por muy segura que sea técnicamente la plataforma. Muchos proveedores de almacenamiento genérico ofrecen un DPA solo si se lo pides expresamente, y no siempre lo incluyen de serie en el contrato estándar que se firma al darse de alta: es una gestión que le corresponde hacer al centro, no algo que llega automáticamente por contratar el servicio.

3. Cifrado y seguridad técnica, en la práctica

3.1. Qué significa «cifrado en reposo» de verdad

Que los datos, mientras están guardados en el servidor sin que nadie los esté consultando en ese momento, están cifrados: si alguien accediera físicamente al disco sin la clave, no podría leer la información. En obeliOmed, los documentos clínicos y los campos marcados como sensibles se cifran con AES-256-GCM, con la clave derivada por ámbito mediante HKDF-SHA-256 y con rotación periódica de claves. Este es un dato técnico verificable, no una afirmación genérica de «máxima seguridad».

3.2. Qué parte del expediente se cifra, y qué matiz hay que conocer

El cifrado se aplica a los documentos y a los campos marcados como sensibles, no a «todo el expediente» como bloque indistinto. Es un matiz que siempre conviene tener claro desde el principio: preguntar «¿está todo cifrado?» tiene una respuesta más precisa que un simple sí o no, y cualquier proveedor que no sepa explicar qué parte exacta cifra probablemente no lo sepa él tampoco.

3.3. Qué pasa cuando alguien corrige un dato

El cifrado protege el dato guardado, pero la trazabilidad protege su historia: cuando un profesional corrige una prueba o un campo del expediente, lo correcto no es que el dato se vuelva imborrable, sino que quede registrado quién lo cambió, cuándo y qué valor había antes del cambio. En obeliOmed ningún cambio se pierde: cada corrección queda anotada con su autor, su fecha y el valor anterior, que es además lo que exige la Ley 41/2002 sobre la historia clínica. Ese mismo registro es la base de cualquier auditoría de accesos, cubierta en detalle en auditoría de accesos de empleados a la historia clínica.

4. Certificaciones: lo que es verificable y lo que no

4.1. Una certificación es un hecho comprobable, no un adjetivo

ENS Categoría Alta e ISO 27001 son certificaciones formales, emitidas por un tercero y consultables en un registro público. Cuando un proveedor las menciona, se puede pedir el certificado y comprobarlo; cuando no las tiene, decir que «cumple con los estándares de seguridad más exigentes» sin nombrar una certificación concreta es la señal de que probablemente no la tiene.

4.2. Lo que sí es cierto en obeliOmed

obeliOmed no cuenta hoy con una certificación ENS ni ISO 27001, y no se anuncia como si las tuviera. Lo que sí es verificable: los servidores están en España, y el cifrado es AES-256-GCM real, con rotación de claves. Es una distinción que vale la pena aplicar a cualquier proveedor que estés evaluando, no solo al nuestro: pide siempre el nombre exacto de la certificación y el organismo que la emite.

5. Dónde están los servidores, y por qué importa

5.1. Localización física dentro de la Unión Europea

Que los servidores estén físicamente en territorio de la Unión Europea, y no solo que la empresa que los opera tenga sede en Europa, es una garantía distinta y más fuerte. Los servidores de obeliOmed están en España. Es un dato que se puede pedir por escrito a cualquier proveedor, y que no siempre coincide con lo que su marketing sugiere.

5.2. Qué preguntar sobre transferencias fuera de la UE

Si algún componente del servicio —soporte técnico, copias de análisis, subcontratas— implica el tratamiento de datos fuera de la Unión Europea, tiene que estar cubierto por las garantías que exige el RGPD para transferencias internacionales. No es un detalle menor: conviene preguntarlo explícitamente, porque no siempre aparece en la primera conversación comercial. Un proveedor que no puede explicar con precisión por dónde pasan los datos en cada etapa del servicio —desde que se suben hasta que se procesan o se hace soporte técnico sobre ellos— probablemente tampoco lo tiene documentado internamente, lo que en sí mismo ya es una señal de alerta.

6. Responsabilidad de la clínica al elegir proveedor

6.1. El responsable del tratamiento sigue siendo el centro

Contratar un proveedor cloud no traslada la responsabilidad legal: el centro sanitario sigue siendo el responsable del tratamiento de los datos de sus pacientes, y el proveedor es el encargado. Si el proveedor incumple, la clínica sigue teniendo que responder ante sus pacientes y ante la autoridad de control. Elegir bien el proveedor, y tenerlo por escrito, es parte de esa responsabilidad, no un trámite aparte. Y si a pesar de todo se produce un incidente, tener ya decidido cómo se actúa marca la diferencia: el detalle está en plan de contingencia ante una brecha de seguridad.

6.2. Qué revisar antes de firmar, no después

El contrato de encargado del tratamiento, la localización de los servidores y el nivel de cifrado son piezas que hay que pedir y leer antes de dar de alta el servicio, no algo que se revisa cuando ya hay datos de pacientes cargados. Cambiar de proveedor de almacenamiento con historiales ya en producción es una migración completa, con su propio riesgo, su propio coste y su propio calendario.

7. Copias de los datos: qué hay de verdad

Una copia solo sirve si existe de verdad cuando hace falta — y eso depende de quién decide sacarla, y cuándo.

7.1. Por qué «backup automático geo-redundante» es una frase para desconfiar

Es habitual que un proveedor prometa copias de seguridad automáticas y geo-redundantes sin más detalle. Antes de dar esa frase por buena, conviene preguntar con qué frecuencia se hacen, dónde se guardan y quién puede restaurarlas: una promesa genérica de redundancia no sustituye a una respuesta concreta. Pedir que te muestren, aunque sea en la demo, cómo se restauraría un dato concreto es la forma más rápida de comprobar si el proceso existe de verdad o si es una frase de la web comercial.

7.2. Lo que ofrece obeliOmed hoy

obeliOmed no hace copias de seguridad automáticas ni geo-redundantes de forma prometida como tal. Lo que sí permite es que cada centro descargue en cualquier momento una copia completa de sus propios datos, cuando quiera. Es, además, un argumento de portabilidad: los datos no quedan atrapados en el sistema del proveedor. El detalle específico de copias y continuidad está en copia de seguridad del historial médico en la nube.

8. Qué hay que exigir por escrito antes de firmar

8.1. Las seis cosas mínimas que pedir por escrito

¿Dónde están físicamente los servidores? ¿Hay un DPA firmado como parte del contrato, o hay que pedirlo aparte? ¿Qué se cifra exactamente, y con qué algoritmo? ¿Qué certificaciones tiene, con qué organismo y desde cuándo? ¿Con qué frecuencia se pueden exportar los propios datos, y en qué formato exacto? ¿Qué pasa exactamente con los datos si se deja de ser cliente?

8.2. Por qué conviene pedirlo por escrito

Una respuesta verbal en una llamada comercial no es lo mismo que una cláusula en el contrato. Pedir estas seis respuestas por escrito, antes de firmar, separa bastante rápido a un proveedor que conoce bien su propia infraestructura de uno que está improvisando la respuesta en el momento. Guarda esas respuestas junto al contrato: si algún día hay una inspección o una reclamación, es la clínica la que tiene que poder mostrar que hizo esas preguntas, no solo el proveedor el que tiene que poder responderlas.

9. Qué aporta obeliOmed y cómo empezar

9.1. Lo verificable, sin adornarlo

Servidores en España, cifrado AES-256-GCM de documentos y campos sensibles con rotación de claves, contrato de encargado del tratamiento firmado, y exportación de tus propios datos disponible en cualquier momento. Sin certificación ENS ni ISO 27001 todavía, y sin backup automático geo-redundante prometido: lo que no tenemos, se dice que no se tiene. Más detalle en seguridad de datos en software sanitario.

9.2. Cómo dar el primer paso

Puedes pedir las respuestas a las seis preguntas de la sección 8 directamente en la demo de obeliOmed, y contrastarlas con las que te dé cualquier otro proveedor que estés evaluando.