Gestión de riesgos de IA en centros sanitarios

El abanico va desde sistemas que en radiología marcan hallazgos sospechosos y priorizan los casos urgentes, pasando por puntuaciones de alerta temprana en cuidados intensivos, análisis en laboratorio y anatomía patológica y propuestas de dosificación, hasta modelos de lenguaje que redactan informes médicos o documentan consultas. A ello se suman herramientas sin relación directa con el paciente, por ejemplo para la planificación de turnos, la gestión de camas o la programación de citas. Cuanto más cerca de la decisión diagnóstica o terapéutica trabaja un sistema, más directamente afectan sus errores a las personas.

Basta una actualización que nadie ha advertido, una base de datos en la que apenas aparecen determinados grupos de pacientes o una calibración desplazada para que cambien los resultados, a menudo sin que se note en la rutina de la planta. Para el centro, la pregunta decisiva no es si un sistema es «inteligente», sino qué decisión influye, quién confía en sus resultados y qué ocurre cuando se equivoca o deja de funcionar.

Tres grupos de riesgos

• Riesgos técnicos: clasificaciones erróneas, rendimiento del modelo en declive, ataques a los datos, al modelo o a las interfaces, y caídas de servicios.
• Riesgos organizativos: responsabilidades difusas, falta de formación, actualizaciones sin control, uso de herramientas de IA no autorizadas y lagunas en la gestión de incidentes.
• Riesgos éticos y jurídicos: discriminación de grupos de pacientes, falta de trazabilidad, infracciones de la protección de datos y pérdida de confianza entre profesionales y pacientes.

Dos conceptos imprescindibles

La deriva del modelo designa la pérdida progresiva de rendimiento de un modelo porque los datos de entrada, la población de pacientes, los equipos o los procesos clínicos han cambiado respecto a las condiciones de la validación. La guía MDCG 2025-6 recomienda diseñar los conjuntos de datos de modo que los sesgos no intencionados y la deriva de los datos sigan siendo controlables y que puedan identificarse los subgrupos en los que un modelo rinde peor, también con el paso del tiempo.

El sesgo de automatización es la tendencia a confiar en exceso en los resultados de una máquina o a apoyarse en ellos sin cuestionarlos. El AI Act exige que las personas encargadas de la supervisión estén en condiciones de reconocer esta tendencia, interpretar correctamente los resultados, desestimarlos en el caso concreto y detener el sistema mediante un botón de parada o un procedimiento similar.

Esta página resume el artículo técnico «Risikomanagement für KI-Systeme im Medizinbetrieb» (gestión de riesgos de sistemas de IA en centros sanitarios), publicado en alemán en mt|medizintechnik, número 2.2026; lo reorganiza y lo completa con la evolución hasta octubre de 2026, en especial el Digital Omnibus del AI Act.

El AI Act no califica la IA médica como de alto riesgo de forma generalizada. Lo determinante es la vía de la legislación de producto: si la IA es en sí misma un producto sanitario o un producto para diagnóstico in vitro, o un componente de seguridad de estos, y en su evaluación de la conformidad debe intervenir un organismo notificado, se considera un sistema de IA de alto riesgo. Como el MDR clasifica por regla general al menos en la clase IIa el software que aporta información para decisiones diagnósticas o terapéuticas, esto se cumple en la mayoría de las aplicaciones de IA diagnósticas y terapéuticas. Los requisitos del AI Act se examinan entonces dentro del procedimiento MDR del organismo notificado; no surge una segunda certificación.

Además, el AI Act enumera directamente como de alto riesgo algunos usos del ámbito sanitario: la evaluación de llamadas de emergencia y el triaje de pacientes de urgencias, las decisiones de las autoridades sobre el acceso a prestaciones sanitarias públicas y la evaluación de riesgos y fijación de precios en los seguros de salud y de vida. Si un sistema de triaje de este tipo es a la vez un producto sanitario con organismo notificado, prevalece la vía de la legislación de producto.

Cómo encajan NIS2 y la protección de datos

Para los hospitales que la ley BSI alemana, con la que Alemania transpone NIS2, considera entidades especialmente importantes o importantes, los sistemas de IA forman parte de la TI que debe protegerse: un incidente de seguridad significativo en un servicio de IA debe notificarse pronto, con una alerta temprana a más tardar a las 24 horas, una notificación con una primera evaluación a las 72 horas y un informe final como máximo un mes después. La protección de datos exige una evaluación de impacto relativa a la protección de datos (EIPD) para los tratamientos de alto riesgo; el AI Act obliga a los responsables del despliegue a utilizar para ello la información facilitada por el proveedor.

Calendario desde la perspectiva del centro

• Desde el 2 de febrero de 2025: prohibición de determinadas prácticas de IA; obligación de fomentar la alfabetización en IA de la plantilla, que desde el Omnibus no exige expresamente garantizar un nivel de competencia.
• Desde el 2 de agosto de 2026: aplicación general del AI Act y obligaciones de transparencia; supervisión a cargo de la Oficina Europea de IA y de las autoridades nacionales.
• Desde el 11 de septiembre de 2026: obligaciones de notificación de los fabricantes según el Cyber Resilience Act para vulnerabilidades explotadas activamente e incidentes de seguridad graves.
• A partir del 2 de diciembre de 2027: obligaciones de alto riesgo para usos listados directamente, por ejemplo un triaje de urgencias que no se evalúe como producto sanitario con organismo notificado.
• A partir del 2 de agosto de 2028: obligaciones de alto riesgo para los productos sanitarios con IA, tanto para proveedores como para responsables del despliegue. Los sistemas introducidos antes en el mercado solo quedan afectados tras cambios significativos en su diseño; los sistemas destinados a autoridades públicas deben cumplir a más tardar el 2 de agosto de 2030.

El Omnibus incluye además una vía abierta cuyo resultado aún está por ver: para los productos con normativa sectorial propia, entre ellos los productos sanitarios, la Comisión puede limitar mediante un acto delegado determinados requisitos del AI Act, siempre que la normativa sectorial ofrezca una protección equivalente. Tiene de plazo hasta el 2 de agosto de 2027. Para la planificación en los hospitales cambia poco, porque las obligaciones del responsable del despliegue no se ven afectadas. Más lejos llega una propuesta de la Comisión de diciembre de 2025 para revisar el MDR y el IVDR: trasladaría los productos sanitarios con IA a un grupo de regulación más ligero del AI Act, de modo que los requisitos de IA se aplicarían prioritariamente a través del MDR. No está aprobada; hasta entonces rigen las fechas aquí indicadas.

Proveedor es quien desarrolla un sistema de IA o encarga su desarrollo y lo introduce en el mercado o lo pone en servicio con su propio nombre; en los productos sanitarios suele ser el fabricante según el MDR. Responsable del despliegue es quien utiliza el sistema profesionalmente bajo su propia responsabilidad. La guía MDCG 2025-6 aclara que el responsable del despliegue no equivale al «usuario» del MDR: en el hospital, el responsable del despliegue es el centro; la médica en su puesto de diagnóstico es la usuaria.

Cuándo el propio centro se convierte en proveedor

• Comercializa con su propio nombre o marca un sistema de alto riesgo ya introducido en el mercado.
• Modifica sustancialmente un sistema de alto riesgo, es decir, de un modo no previsto en la evaluación de la conformidad original y que afecta a la conformidad o a la finalidad.
• Utiliza un sistema que hasta entonces no era de alto riesgo, también un modelo de lenguaje de uso general, para un fin que lo convierte en sistema de alto riesgo.

Según MDCG 2025-6, tras una modificación sustancial hace falta una nueva evaluación de la conformidad aunque el centro solo siga utilizando el sistema modificado para sí mismo. En cambio, los cambios fijados y evaluados de antemano por el fabricante, por ejemplo en un plan de cambios predeterminados, no se consideran sustanciales. Los desarrollos propios que un centro sanitario utiliza exclusivamente de forma interna conforme a las reglas de los productos de fabricación propia (in-house) no son, según la guía, IA de alto riesgo; las demás obligaciones del AI Act se mantienen.

Qué debe figurar en el contrato

• Información sobre el origen de los datos, las poblaciones de validación y los límites de rendimiento conocidos.
• Política de actualizaciones con plazos de preaviso, información de versiones y opción de vuelta atrás.
• Acceso a los registros y apoyo en el análisis de incidentes y en la evaluación de impacto relativa a la protección de datos.
• Vías de notificación, tiempos de respuesta y personas de contacto para cuestiones de seguridad.
• Compromisos de seguridad para componentes en la nube y bibliotecas de terceros, incluida la lista de materiales de software (SBOM).
• Fin del soporte y devolución o eliminación ordenada de los datos al terminar el contrato.

La ley solo impone al proveedor un sistema de gestión de riesgos propio en el sentido del AI Act. Los responsables del despliegue tienen obligaciones de vigilancia, supervisión, datos, registro y notificación. Aun así, una gestión de riesgos estructurada en el centro es la base práctica para cumplirlas. La norma para operadores IEC 80001-1 describe precisamente este enfoque para los productos sanitarios conectados y el software sanitario: gestión de riesgos antes, durante y después de su integración en la TI del hospital.

1. 1
   Antes de la compra: finalidad y clasificación

   Aclarar el beneficio clínico, la finalidad prevista, el rol del centro y la clasificación regulatoria. Fijar criterios de aceptación: qué tasas de error y qué riesgos residuales son asumibles para este uso, y quién lo decide.

2. 2
   Antes de la puesta en servicio: prueba en el propio entorno

   Comprobar con datos propios y representativos si en la población del centro se alcanza el rendimiento declarado por el fabricante. Asegurar interfaces, permisos y segmento de red, designar y formar a las personas de supervisión y definir el proceso alternativo.

3. 3
   En operación: vigilancia y retroalimentación

   Observar de forma continua los indicadores de rendimiento, las tasas de desestimación, la calidad de los datos y la disponibilidad. Documentar las anomalías, comunicarlas al proveedor y, si hay riesgo, suspender el uso.

4. 4
   Ante cambios: aprobación controlada

   Cada actualización del modelo, cada nueva interfaz y cada nuevo ámbito de uso pasa por evaluación, prueba, aprobación y documentación. Comprobar si el fabricante había predeterminado el cambio o si este situaría al centro en el rol de proveedor.

5. 5
   En la retirada: una despedida ordenada

   Garantizar un proceso sustitutivo, conservar los registros y evidencias según los plazos de conservación, cerrar accesos e interfaces, pedir al proveedor que elimine los datos y aprovechar la experiencia en la siguiente compra.

STRIDE se remonta a Loren Kohnfelder y Praerit Garg, que describieron el esquema en Microsoft en 1999. Asigna las amenazas a seis categorías y se aplica bien sobre un diagrama de flujo de datos: para cada componente y cada conexión se pregunta qué categoría es concebible allí. En un sistema de diagnóstico por imagen con IA suelen incluirse el equipo de imagen (en radiología, la «modalidad»), el archivo de imágenes, el servicio de inferencia —local o en la nube—, la visualización de resultados, el sistema de información hospitalaria y el canal de actualizaciones del fabricante.

Amenazas específicas de la IA

El propio AI Act menciona ataques típicos contra la IA: el envenenamiento de datos y de modelos, las entradas modificadas deliberadamente para engañar a un modelo, los ataques a la confidencialidad y la explotación de debilidades del modelo. Para las aplicaciones con modelos de lenguaje, el OWASP Top 10 for LLM Applications, en su versión de 2026, ofrece una clasificación actualizada. Para los centros son relevantes sobre todo estos patrones:

Ha dado buen resultado una matriz con dos ejes. En uno figura la probabilidad, alimentada por factores técnicos como la superficie de ataque y la robustez del modelo, por factores organizativos como el nivel de formación y la madurez de los procesos, y por factores humanos como la presión asistencial y el sesgo de automatización. En el otro figura la gravedad de las consecuencias: médicas, de protección de datos, operativas y en términos de confianza en el centro.

Revisar el sesgo de forma específica

Los sesgos surgen cuando los datos de entrenamiento no reflejan la población de pacientes del propio centro o cuando cambian procesos y equipos. Por eso, los centros deberían analizar los indicadores de rendimiento no solo en conjunto, sino también por subgrupos relevantes, siempre que los datos y la base jurídica lo permitan. Desde el Omnibus, el AI Act permite a los responsables del despliegue de sistemas de alto riesgo tratar excepcionalmente categorías especiales de datos personales, como los datos de salud, para detectar sesgos, con estrictas garantías y sin que de ello se derive una obligación.

Evaluación de impacto sobre los derechos fundamentales: cuándo es obligatoria

El AI Act solo exige una evaluación de impacto sobre los derechos fundamentales para los usos de alto riesgo que él mismo enumera, y únicamente a los organismos públicos y a las entidades privadas que prestan servicios públicos, así como a quienes evalúan la solvencia o fijan los precios de seguros de vida y de salud. Los hospitales públicos y los privados con encargo asistencial pueden verse afectados, por ejemplo, al usar un sistema de triaje en urgencias; si ese sistema es a la vez un producto sanitario con organismo notificado, conviene comprobar en cada caso si la obligación se aplica, dada la prevalencia de la legislación de producto. Para los productos sanitarios con IA que son de alto riesgo únicamente por la vía del MDR, esta obligación no rige. El Omnibus permite remitirse a una evaluación de impacto relativa a la protección de datos ya realizada.

1. 1
   Prevención

   La seguridad empieza en la selección: exigir al proveedor seguridad desde el diseño (secure by design), validar con datos de prueba propios y representativos, e implantar segmentación de red, autenticación multifactor y permisos basados en roles. Quien, antes de la puesta en producción, recaba una segunda mirada independiente —de una auditoría de seguridad externa o de un hospital asociado con experiencia en el mismo ámbito de uso— detecta los puntos ciegos antes de que afecten a los pacientes.

2. 2
   Detección

   Advertir pronto las desviaciones: vigilar la deriva en los indicadores de rendimiento y en los datos de entrada, analizar los registros, definir alertas ante comportamientos inusuales y usar como indicador temprano las desestimaciones por parte del personal. En cuidados intensivos y en urgencias cuenta la rapidez con que una anomalía llega al equipo responsable.

3. 3
   Corrección

   Cuando algo sale mal, las personas conservan la última palabra en los puntos críticos y pueden detener el sistema. Los procesos alternativos sin IA, la posibilidad de volver a una versión anterior del modelo, unas vías de escalado claras y un procedimiento de gestión de incidentes ensayado limitan el daño.

4. 4
   Evidencia

   La documentación lo une todo: clasificación, evaluación de riesgos, resultados de las pruebas, aprobaciones, formaciones, desestimaciones, incidentes y correcciones. Acredita el cumplimiento de las obligaciones ante la supervisión y los auditores y es la base de la mejora continua.

Notificar cuando la situación es seria

Si el centro tiene motivos para pensar que el uso entraña un riesgo, informa sin demora al proveedor o al distribuidor y a la autoridad de vigilancia del mercado, y suspende el uso. Ante un incidente grave, el AI Act exige informar sin demora, en primer lugar, al proveedor. En los productos sanitarios con IA, los incidentes relacionados con la salud siguen el sistema de vigilancia del MDR: el fabricante notifica, según la gravedad, en un plazo máximo de 15, 10 o 2 días. En Alemania, además, operadores y usuarios deben notificar sin demora los presuntos incidentes graves a la autoridad federal competente, por lo general el BfArM. En esos casos, por la vía del AI Act solo deben notificarse las infracciones de obligaciones que protegen los derechos fundamentales. En paralelo pueden surgir notificaciones según la ley BSI y la normativa de protección de datos.

Medidas concretas de un vistazo

• Inventario de todos los sistemas de IA con finalidad, clasificación, responsables y flujos de datos.
• Personas de supervisión designadas para cada sistema, con formación documentada y autoridad para desestimar resultados.
• Registro con versión del modelo y acción del usuario, conservado durante al menos seis meses.
• Procedimiento de aprobación de actualizaciones con pruebas en un entorno de referencia.
• Pruebas de seguridad periódicas y red teaming de IA, sobre todo en modelos de lenguaje y agentes.
• Matriz de notificación acordada para el proveedor, la vigilancia de productos sanitarios, el BSI y la autoridad de protección de datos.

Muchos centros ya cuentan con un sistema de gestión de la seguridad de la información (SGSI), una gestión de la calidad y una gestión de la protección de datos. Los riesgos de la IA pueden incorporarse a ellos: como categoría de riesgo propia, con controles propios y con un papel claro en la aprobación de nuevos sistemas. El siguiente resumen muestra qué aporta cada norma.

Para los hospitales sujetos a la ley BSI, la integración es también jurídicamente lógica: las medidas de gestión de riesgos exigidas incluyen, entre otras, la gestión de incidentes, la seguridad de la cadena de suministro y la seguridad en la adquisición, el desarrollo y el mantenimiento, incluida la gestión de vulnerabilidades. Los servicios de IA y sus proveedores forman parte, por tanto, de la gestión de proveedores y de vulnerabilidades del SGSI.

1. 1
   Días 1–15: asignar la responsabilidad

   Designar una unidad responsable de la IA, reunir en un comité a ingeniería clínica, seguridad informática, protección de datos, gestión de la calidad y dirección médica, y vincular a este comité la aprobación de nuevos sistemas de IA.

2. 2
   Días 16–30: elaborar el inventario

   Registrar todos los sistemas de IA, también las funciones integradas en equipos y servicios en la nube. Anotar para cada sistema la finalidad, el proveedor, los flujos de datos, los grupos de usuarios y la clasificación regulatoria.

3. 3
   Días 31–45: priorizar los riesgos

   Elaborar un modelo de amenazas STRIDE para los sistemas con mayor relación con el paciente y evaluar su impacto. El resultado es una lista de las medidas más urgentes.

4. 4
   Días 46–60: contratos y proveedores

   Revisar los contratos vigentes en cuanto a política de actualizaciones, acceso a registros, origen de los datos, vías de notificación y fin del soporte; renegociar los compromisos que falten y fijar requisitos para las futuras compras.

5. 5
   Días 61–75: supervisión y competencias

   Designar personas de supervisión para cada sistema, impartir formación adaptada a cada colectivo sobre los límites de rendimiento y el sesgo de automatización, e informar a la plantilla y a sus representantes.

6. 6
   Días 76–90: consolidar la operación

   Poner en marcha la vigilancia y la conservación de registros, implantar el procedimiento de cambios y la matriz de notificación, realizar un ejercicio de gestión de incidentes y aprobar el plan para los doce meses siguientes.

El plan es una orientación y no sustituye el análisis de cada caso. El alcance y el orden dependen del tamaño, del encargo asistencial y del parque de IA del centro.