IA en salud: cómo navegar GDPR, MDR y el reglamento europeo de IA a la vez

Tres marcos regulatorios que se solapan

Desarrollar software con IA para el sector salud en Europa significa operar simultáneamente bajo tres marcos regulatorios que no fueron diseñados para trabajar juntos. El RGPD (Reglamento General de Protección de Datos) cubre el tratamiento de datos personales, con protección reforzada para los de salud. El MDR (Medical Device Regulation, Reglamento EU 2017/745) regula los productos sanitarios, incluido el software con finalidad médica. El EU AI Act (Reglamento 2024/1689) añade una capa adicional para sistemas de inteligencia artificial, con obligaciones específicas cuando el sistema es de alto riesgo, como lo son casi todos los de salud.

Cada uno impone obligaciones distintas. Los plazos de implementación se solapan. Las autoridades competentes son distintas —agencias de protección de datos, organismos notificados, la futura Oficina Europea de IA—. Y la intersección entre ellos en casos concretos no siempre está bien documentada: los tres reglamentos se citan entre sí de forma general, pero los casos prácticos hay que resolverlos con interpretación, asesoría y, cuando toca, consultas a autoridad.

Hemos navegado esta complejidad construyendo Race+ (coordinación de código ictus en hospitales) y Aedevita (triaje dermatológico por IA sobre WhatsApp). Lo que sigue es una guía práctica, destilada de años de trabajo, no una revisión exhaustiva de los textos legales. Cualquier proyecto real requiere además asesoría jurídica específica.

RGPD para datos de salud: categoría especial en la práctica

El RGPD clasifica los datos de salud como categoría especial en su artículo 9. La consecuencia práctica es que su tratamiento está prohibido por defecto y solo permitido bajo una de las excepciones tasadas. Para aplicaciones en entornos clínicos, la más relevante suele ser el artículo 9.2.h: tratamiento necesario para fines de medicina preventiva o laboral, diagnóstico médico, prestación de asistencia sanitaria, siempre que esté sujeto a secreto profesional.

Elegir la base legitimadora correcta importa. El consentimiento —artículo 9.2.a— parece la opción natural y a menudo es la que los equipos eligen por instinto, pero tiene una consecuencia incómoda: puede retirarse en cualquier momento y obliga a cesar el tratamiento. Para una plataforma clínica que debe mantener un histórico del paciente, eso puede ser inviable. El 9.2.h es más sólido porque se ancla en la finalidad asistencial, no en la voluntad puntual del interesado.

En la práctica, esto tiene implicaciones técnicas concretas. El principio de minimización exige no recoger más información de la estrictamente necesaria: cada campo adicional debe justificarse contra la finalidad. El derecho de supresión implica que la arquitectura de datos tiene que permitir eliminar a un paciente concreto sin corromper los datos del resto ni romper integridad referencial. El registro de actividades de tratamiento (RAT) debe documentar no solo qué datos se tratan sino los flujos técnicos completos: qué servicios los procesan, qué subprocesadores intervienen, qué regiones cloud almacenan qué.

Un error común: asumir que cifrar los datos es suficiente para cumplir RGPD. El cifrado es una medida técnica necesaria pero no suficiente. La residencia de datos, la cadena de subprocesadores, y la capacidad de responder a solicitudes de derechos de los interesados dentro de plazos legales son requisitos igualmente importantes, y son los que con más frecuencia se descubren mal resueltos durante una auditoría.

Los datos de salud son categoría especial bajo RGPD: la base legitimadora y la cadena de subprocesadores son puntos donde muchos proyectos fallan la auditoría.

MDR: cuándo el software pasa a ser producto sanitario

El MDR clasifica el software como producto sanitario cuando está destinado a utilizarse con fines médicos: diagnóstico, prevención, monitorización, predicción, pronóstico, tratamiento o alivio de una enfermedad. La clasificación no es binaria: hay cuatro clases de riesgo (I, IIa, IIb, III), y los requisitos aumentan significativamente con la clase.

El árbol de decisión, simplificado, es el siguiente. Primera pregunta: ¿el software influye en una decisión clínica sobre un paciente concreto? Si la respuesta es no —es una herramienta administrativa, de coordinación, de gestión— el MDR probablemente no aplique. Si la respuesta es sí, la segunda pregunta es qué tipo de decisión apoya. Si monitoriza o informa, suele ser clase IIa. Si diagnostica o sugiere tratamiento, clase IIb o superior. Si toma decisiones autónomas sobre terapia, clase III.

Race+ y Aedevita son un ejemplo útil del contraste. Race+ coordina equipos y registra tiempos durante una emergencia neurológica, pero no toma decisiones clínicas ni las apoya directamente. Tras consulta con especialistas en regulación sanitaria, la conclusión fue que no califica como software médico bajo MDR: es una herramienta de coordinación, no de apoyo a la decisión. Esa calificación se fundamentó en el análisis de la finalidad prevista, la documentación de producto y el rol del software en el flujo clínico. No es una declaración unilateral: está soportada por un análisis regulatorio formal.

Aedevita, en cambio, clasifica lesiones cutáneas y genera recomendaciones de derivación. Eso influye directamente en la decisión clínica, lo que lo coloca bajo MDR. La clasificación de riesgo —IIa en este caso, basada en el anexo VIII— determina el nivel de evidencia clínica requerido, el tipo de organismo notificado involucrado, y el proceso de vigilancia post-mercado. El marcado CE como producto sanitario es un proceso costoso —decenas de miles de euros en consultoría y tasas— y largo —entre 12 y 24 meses típicamente—. Pero sin él, el producto no puede comercializarse.

La lección: el alcance clínico exacto tiene implicaciones regulatorias enormes. Cambiar "sugerimos derivación" por "clasificamos urgencia y recomendamos ruta asistencial" puede parecer un matiz de marketing pero mueve la clasificación. Las decisiones de redacción del manual de usuario y del material comercial tienen peso regulatorio.

EU AI Act: sistemas de alto riesgo en salud

El Reglamento Europeo de IA, con aplicación plena progresiva hasta 2026, clasifica los sistemas de IA como de alto riesgo cuando se usan, entre otros, para tomar decisiones que afecten a la salud o seguridad de las personas. El Anexo III lista explícitamente los sistemas de IA para diagnóstico o triaje médico dentro de esa categoría.

Para los sistemas de alto riesgo, el AI Act impone un conjunto de obligaciones que conviven y, a veces, se solapan con las del MDR. Gestión de riesgos documentada a lo largo del ciclo de vida del sistema (artículo 9). Gobernanza de los datos de entrenamiento, validación y prueba con análisis de sesgos y representatividad (artículo 10). Documentación técnica exhaustiva (artículo 11). Transparencia hacia los usuarios sobre capacidades y limitaciones (artículo 13). Supervisión humana como requisito, no como opción (artículo 14). Robustez, precisión y ciberseguridad verificables (artículo 15). Y registro del sistema en la base de datos europea de sistemas de IA de alto riesgo antes de la comercialización.

El concepto de supervisión humana tiene implicaciones de diseño de producto directas. No basta con poner un botón de "revisar" al final del flujo. El sistema tiene que estar diseñado para que el profesional sanitario comprenda en qué se basa la recomendación de la IA, pueda identificar casos donde el sistema puede estar fuera de su dominio de confianza, y pueda anular la recomendación sin fricciones. Esto requiere outputs explicables —no solo precisos— y umbrales de confianza que modulen la presentación: una recomendación con baja confianza debe visualmente diferenciarse de una con alta confianza, y el flujo debe forzar la intervención humana en los casos ambiguos.

El artículo 9, gestión de riesgos, merece atención especial. Exige un proceso iterativo que identifique riesgos conocidos y razonablemente previsibles, estime y evalúe esos riesgos, y adopte medidas para mitigarlos. Este proceso se documenta y se mantiene durante toda la vida del sistema. No es un PDF que se escribe una vez al inicio: es un artefacto vivo que se actualiza con cada cambio significativo y con el aprendizaje de la vigilancia post-comercialización.

El EU AI Act exige supervisión humana como requisito de diseño, no como disclaimer legal.

Residencia de datos: "cloud EU" no siempre es suficiente

Un requisito que aparece en casi todos los contratos con administraciones públicas y grandes empresas es la residencia de datos en Europa. GCP tiene región en Europa (europe-west1 en Bélgica, europe-southwest1 en Madrid desde 2022), lo que simplifica la conversación inicial. Pero "datos en Europa" puede no ser suficiente.

Primero, algunos clientes —especialmente en sector público— exigen datos en España específicamente, no en Europa genérica. Verificar esto antes de firmar evita migraciones costosas posteriores.

Segundo, el concepto de residencia se complica con los subprocesadores. Si tu servicio envía datos a una API externa —un proveedor de LLMs, un servicio de OCR, una plataforma de analytics—, esos datos pueden procesarse fuera de la UE aunque tu infraestructura principal esté en Madrid. La cadena de subprocesadores debe estar mapeada y documentada, con DPAs firmados y cláusulas contractuales tipo donde aplique. Después de la sentencia Schrödinger de transferencias internacionales, los subprocesadores en EE.UU. requieren análisis específico bajo el marco de adecuación actual o cláusulas contractuales reforzadas.

Tercero, el acceso administrativo. Que los datos residan en un datacenter europeo pero estén gestionados por personal fuera de la UE introduce un matiz que algunas auditorías consideran transferencia internacional de facto. Los proveedores cloud ofrecen "soberanía de datos" con controles de acceso restringidos geográficamente, pero hay que pedirlo y configurarlo; no es el default.

Pseudonimización vs. anonimización

Esta distinción tiene consecuencias regulatorias significativas. Los datos pseudonimizados —en los que se sustituyen identificadores directos pero sigue siendo posible re-identificar con información adicional— siguen siendo datos personales bajo RGPD. Los datos genuinamente anonimizados quedan fuera del ámbito del reglamento.

En la práctica, anonimizar datos clínicos de forma real es muy difícil. Una historia clínica contiene decenas de variables que combinadas pueden ser únicas: edad, diagnósticos, procedimientos, fechas, códigos postales. Las técnicas de k-anonimato, l-diversidad y privacidad diferencial existen, pero reducen la utilidad estadística de los datos. Para la mayoría de los usos en IA médica, trabajar con datos pseudonimizados bajo un acuerdo de procesamiento y asumir que siguen siendo datos personales es el enfoque pragmático.

Cuando un proyecto afirma trabajar con "datos anonimizados", vale la pena revisar en detalle la técnica de anonimización y la robustez frente a ataques de re-identificación. Si no hay análisis formal, probablemente son pseudonimizados mal etiquetados.

La anonimización real de datos clínicos es técnicamente difícil: la mayoría de los proyectos trabajan con datos pseudonimizados, aunque se autodescriban de otra forma.

Checklist práctico para empezar bien

Antes de escribir una línea de código en un proyecto de IA para salud, estas son las preguntas que deben tener respuesta documentada.

1. ¿El sistema influye en decisiones diagnósticas o terapéuticas? Si sí, MDR es probablemente aplicable. El proceso de certificación condiciona el calendario entero del proyecto.
2. ¿El sistema cae bajo el Anexo III del EU AI Act? Si sí, el proceso de gestión de riesgos debe arrancar desde el diseño, no desde la certificación.
3. ¿Cuál es la base legitimadora del RGPD para cada finalidad de tratamiento? ¿Está documentada en el RAT?
4. ¿Dónde residen los datos? ¿Cuál es la cadena completa de subprocesadores? ¿Hay DPAs firmados?
5. ¿Cómo se garantiza la supervisión humana en el flujo de producto? ¿Está integrada en el diseño de la experiencia o es un disclaimer al final?
6. ¿Cuál es el proceso de gestión de cambios? Un cambio en el modelo, en el prompt o en los datos de entrenamiento puede ser un cambio sustancial que requiere nueva evaluación regulatoria.
7. ¿Quién es responsable de la vigilancia post-comercialización? ¿Cómo se monitoriza el comportamiento del sistema en producción y se notifican incidentes?

La regulación no es un obstáculo que aparece al final. Es un parámetro de diseño que debe estar presente desde la primera conversación de arquitectura. Los proyectos que la tratan como trámite terminal descubren, tarde, que la mitad de lo construido no es certificable sin reescribirse.