Artículo técnico en mt|medizintechnik 2.2026: cómo los centros sanitarios pueden asegurar el uso de sistemas de IA con gestión de riesgos
19 de octubre de 2026
Publicado en mt|medizintechnik, Número 2.2026
Publicado en mt|medizintechnik, número 2.2026
En el número 2.2026 de la revista mt|medizintechnik, Valeri Milke explica cómo la gestión de riesgos ayuda a los hospitales a usar la IA con seguridad. Su artículo «Risikomanagement für KI-Systeme im Medizinbetrieb» (gestión de riesgos de sistemas de IA en la actividad sanitaria), con el antetítulo «Therapieentscheidungen durch Algorithmen» (decisiones terapéuticas tomadas por algoritmos), ocupa las páginas 8 a 12 del número publicado en abril de 2026 con la medicina personalizada como tema central e incluye tres figuras y una tabla. La revista la edita TÜV Media GmbH, con sede en Colonia. Autor: Valeri Milke, CEO de VamiSec GmbH, Lead Auditor de ISO/IEC 27001 e ISO/IEC 42001. El artículo (en alemán) vincula los requisitos del Reglamento de Productos Sanitarios (MDR), el Reglamento de IA (AI Act) y el Cyber Resilience Act (CRA) con un procedimiento práctico para el día a día clínico: del modelo de amenazas a la evaluación de las posibles consecuencias, las medidas y las evidencias. Esta noticia recoge sus ideas clave con palabras propias y las sitúa en el marco jurídico de octubre de 2026.
La tesis central: quien utiliza IA comparte la responsabilidad
Las aplicaciones de IA ya forman parte del día a día de muchos hospitales: señalan hallazgos en radiografías y tomografías computarizadas, proponen opciones de tratamiento o ayudan a planificar citas, camas y medicación. Cuanto más intervienen estos sistemas en las decisiones, más depende la asistencia de que sus resultados sean fiables. Un modelo entrenado con datos desequilibrados, una nueva versión del modelo instalada sin que nadie lo advierta o un deterioro progresivo durante la operación pueden poner en peligro directamente a los pacientes y, al mismo tiempo, minar la confianza en la medicina asistida por IA. Por eso el artículo sitúa en el centro una perspectiva que a menudo se queda corta en el debate: la de quienes utilizan estos sistemas. No solo los fabricantes; también hospitales, laboratorios y consultas deben gestionar activamente los riesgos de la IA, como una tarea permanente a lo largo de todo el ciclo de vida en la que técnica, organización y ética se consideran de forma conjunta.
Cuándo se considera de alto riesgo la IA médica
Por regla general, la IA médica se convierte en un sistema de alto riesgo a través del derecho de productos sanitarios: si el sistema de IA es en sí mismo un producto sanitario o un componente de seguridad de uno y un organismo notificado debe evaluar su conformidad, el AI Act también lo considera de alto riesgo. El software que aporta información para decisiones diagnósticas o terapéuticas se asigna según el MDR, por regla general, como mínimo a la clase IIa y requiere por tanto un organismo notificado, lo que afecta a la mayoría de las aplicaciones clínicas de IA. El organismo notificado comprueba los requisitos del AI Act dentro del procedimiento MDR existente; no hace falta una segunda certificación. Además, el AI Act clasifica directamente como de alto riesgo determinados usos sanitarios, como los sistemas de triaje de pacientes en urgencias. La guía MDCG 2025-6, de junio de 2025, explica esta interacción en 36 preguntas; el legislador ha aplazado desde entonces a 2028 la fecha de 2027 que allí se cita.
Responsabilidad compartida: qué aportan el proveedor y el centro sanitario
Jurídicamente, los papeles están separados; en la práctica, dependen el uno del otro. El proveedor mantiene un sistema de gestión de riesgos, garantiza una gobernanza de datos sólida y demuestra la conformidad. El responsable del despliegue —en un hospital, la institución, no el profesional médico a título individual— utiliza el sistema conforme a las instrucciones de uso, confía la supervisión humana solo a personas formadas y autorizadas, vela por que los datos de entrada que aporta sean adecuados y representativos, supervisa el funcionamiento y comunica las anomalías al proveedor. Por regla general, conserva al menos seis meses los registros generados automáticamente que estén bajo su control. El AI Act no exige a los responsables del despliegue un sistema formal de gestión de riesgos; aun así, una gestión de riesgos propia del centro, por ejemplo según IEC 80001-1, es la base práctica de estas obligaciones. Importante: quien comercializa un sistema con su propio nombre, lo modifica sustancialmente o lo destina a una finalidad de alto riesgo asume las obligaciones de un proveedor.
Detectar amenazas: STRIDE, OWASP y deriva del modelo
Para identificar los riesgos, el artículo recomienda un modelado de amenazas (threat modeling) a lo largo de los flujos de datos y las interfaces. El esquema STRIDE, surgido en Microsoft, agrupa las amenazas en seis categorías: suplantación de identidad (Spoofing), manipulación (Tampering), repudio (Repudiation), divulgación de información (Information Disclosure), denegación de servicio (Denial of Service) y elevación de privilegios (Elevation of Privilege). Ejemplos clínicos: un equipo de imagen suplantado introduce imágenes ajenas, un archivo de modelo alterado desplaza los umbrales diagnósticos y una cuenta de integración con privilegios excesivos abre el acceso a la configuración. Para las aplicaciones con modelos de lenguaje, el OWASP Top 10 for LLM Applications 2026 añade otros ataques, como la inyección de instrucciones (Prompt Injection) o el envenenamiento de datos y modelos (Data and Model Poisoning). A ello se suma la deriva del modelo: una pérdida progresiva de rendimiento porque pacientes, equipos o práctica clínica cambian respecto a la validación.
Evaluar las consecuencias, aplicar medidas, documentar evidencias
Tras la identificación llega la evaluación: ¿qué supone un fallo para los pacientes, el personal y la asistencia? El artículo contrapone para ello probabilidad y gravedad en una matriz; la gravedad recoge consecuencias médicas, de protección de datos y sociales. Agrupa las medidas en cuatro ámbitos: prevenir, detectar, corregir y documentar; por ejemplo, datos de prueba representativos, supervisión con alarmas, control humano en los puntos críticos y vuelta a la versión anterior. Como marco de referencia sirven ISO 14971 para el riesgo del producto, ISO/IEC 23894 como guía específica para la IA e ISO/IEC 42001 como sistema de gestión voluntario que ordena las obligaciones legales, pero no las sustituye. El AI Act solo exige una evaluación de impacto sobre los derechos fundamentales para determinados usos, como el triaje en urgencias, y solo a organismos públicos o prestadores de servicios públicos; en los productos sanitarios con IA, la evaluación se apoya en la evaluación de impacto relativa a la protección de datos y en la gestión de riesgos clínicos.
Por qué el tema apremia ahora y qué puede hacer usted
El AI Act está en vigor desde el 1 de agosto de 2024; las prohibiciones y el deber de fomentar la alfabetización en IA se aplican desde el 2 de febrero de 2025, y los deberes de transparencia, desde el 2 de agosto de 2026. El Digital Omnibus on AI, vigente desde el 27 de julio de 2026, fija las fechas de alto riesgo: 2 de diciembre de 2027 para usos listados directamente y 2 de agosto de 2028 para productos sanitarios con IA, para proveedores y responsables del despliegue. Los sistemas introducidos en el mercado o puestos en servicio antes solo quedan afectados tras cambios significativos en su diseño. El Cyber Resilience Act excluye los productos sanitarios, no así los productos de TI no médicos que compran los hospitales: sus fabricantes notifican desde el 11 de septiembre de 2026 vulnerabilidades explotadas activamente; las demás obligaciones, desde el 11 de diciembre de 2027. Cinco pasos sugeridos: inventariar las aplicaciones de IA con rol y clasificación; asignar claramente supervisión y formación; fijar por contrato con los proveedores monitorización, registros y vías de notificación; crear un modelo de amenazas por sistema crítico; y exigir al comprar compromisos de actualización y una lista de materiales de software (Software Bill of Materials, SBOM).
Nuevo en vamisec.com: la página de conocimiento sobre el tema
Nuevo en vamisec.com: la página de conocimiento «Gestión de riesgos de IA en centros sanitarios». Retoma las tesis del artículo, las actualiza a la situación de octubre de 2026 y las desarrolla desde la perspectiva de los centros que utilizan IA: con la clasificación de la IA médica, el reparto de obligaciones entre proveedor y hospital, un modelo de amenazas con ataques específicos de la IA, la evaluación de riesgos, medidas concretas y las evidencias necesarias, además de preguntas frecuentes y fuentes verificadas. Encontrará la página en https://vamisec.com/es/wissen/secure-software-development/ki-risikomanagement-medizin. Cómo interactúan el AI Act y el MDR desde la perspectiva de los fabricantes se explica en https://vamisec.com/es/ki-vo-medizinprodukte y la información sobre nuestra consultoría MDR, en https://vamisec.com/es/mdr.
Todos los enlaces
Número 2.2026 de mt|medizintechnik: https://mt-medizintechnik.de/fokus-auf-personalisierte-medizin/ · Página de conocimiento Gestión de riesgos de IA en centros sanitarios: https://vamisec.com/es/wissen/secure-software-development/ki-risikomanagement-medizin · Categoría Desarrollo seguro de software y de productos, sección Productos sanitarios: https://vamisec.com/es/wissen/secure-software-development#medizinprodukte · Reglamento de IA y productos sanitarios: https://vamisec.com/es/ki-vo-medizinprodukte · EU AI Act en resumen: https://vamisec.com/es/wissen/grc/eu-ai-act · Ciberseguridad MDR en resumen: https://vamisec.com/es/wissen/grc/mdr-cybersecurity · Threat Modeling: https://vamisec.com/es/wissen/secure-software-development/threat-modeling · Consultoría MDR: https://vamisec.com/es/mdr
¿Tiene preguntas sobre la seguridad TI de su empresa?
Consulta inicial gratuita →