Tras inspiradoras conversaciones acerca de IA y la regulación del producto sanitario, me planteo cómo afecta, en realidad, la incorporación de inteligencia artificial generativa a los productos sanitarios y el debate abierto que trasciende más allá de la propia tecnología. Una de las cuestiones que considero más interesantes es si los modelos actuales de verificación y validación son suficientes para demostrar el cumplimiento regulatorio cuando el comportamiento del software deja de responder completamente al esquema tradicional de entradas, procesamiento y resultados predeterminados. En mi opinión, se abre el debate por ¿Cómo validar la inteligencia artificial como producto sanitario?.
El MDR establece el punto de partida para este análisis. El RGSF 17.1 del Anexo I de MDR exige que los productos que incorporen software, o que sean ellos mismos software, se diseñen garantizando su repetibilidad, fiabilidad y funcionamiento conforme a su finalidad prevista.
El RGSF 17.2 añade que el software debe desarrollarse y fabricarse conforme al estado de la técnica (SOTA por siglas en inglés), teniendo en cuenta los principios del ciclo de vida, la gestión de riesgos —incluida la seguridad de la información—, la verificación y la validación.
Permíteme que destaque este concepto: VALIDACIÓN.
La aparición de la IA generativa no elimina ninguno de estos requisitos. Sino que ahora la dificultad reside en cómo demostrar su cumplimiento.
RGSF 17 exige validar el software utilizado en el producto terminado
El MDR no se limita a establecer una obligación genérica de validación. El Anexo II exige que la documentación técnica incluya evidencia de la validación del software tal como se utiliza en el producto terminado, junto con los resultados de las actividades de verificación, validación y ensayo realizadas antes de su liberación final. El concepto de evaluación clínica, espera, por definición, la existencia de clinical data suficiente como para evidenciar su seguridad y funcionamiento.
Adicionalmente, este planteamiento encaja con la estructura de diseño y desarrollo que conocemos en los sistemas de gestión de calidad de producto sanitario.
ISO 13485 (cláusula 7.3.7) establece un marco sistemático para diseño y desarrollo en el que planificación, entradas y salidas de diseño, revisión, verificación, validación, transferencia y control de cambios permiten demostrar que el producto finalmente desarrollado (representativo) responde a los requisitos previamente establecidos.
No existe ninguna razón directa e inmediata para abandonar este modelo porque el producto incorpore IA generativa. Pero sí puede ser necesario ampliarlo o reformar el planteamiento.
El problema aparece cuando el estado validado no depende únicamente del código
En un software tradicional podemos identificar una determinada versión, verificar sus requisitos y validar el producto terminado antes de su liberación. Hasta ahora, los resultados deterministas han avalado profundamente este enfoque.
En un sistema GenAI, el comportamiento final puede depender de más elementos. Obviamente debe ser predecible, pero, cuanto menos, no será totalmente conocido durante todo el ciclo de vida del producto sanitario.
Puede depender de la versión del modelo fundacional, del system prompt, de parámetros de configuración, de los guardrails, de las fuentes disponibles mediante RAG, de la lógica de orquestación o de servicios proporcionados por terceros.
Esto cambia parcialmente el enfoque de la validación en relación con su concepto, hasta ahora, determinista, planificado y rígido.
Un fabricante podría no modificar una sola línea del código de su aplicación y, sin embargo, experimentar una modificación del comportamiento del producto como consecuencia de un cambio en alguno de esos componentes.
Por tanto, definir el estado validado de un producto GenAI puede exigir algo más que identificar la versión del software, incluso un férreo proceso de supervisión..
El artículo 15 del AI Act introduce una exigencia especialmente relevante para el RGSF 17
Aquí es donde la interacción entre MDR y AI Act adquiere especial interés.
El artículo 15.1 del AI Act establece que los sistemas de IA de alto riesgo deben diseñarse y desarrollarse para alcanzar niveles adecuados de precisión, solidez y ciberseguridad y, además, exige que funcionen consistentemente en estos aspectos durante todo su ciclo de vida.
La relación con el RGSF 17.1 es evidente. Se trata de dos preceptos que han nacido para unirse de forma inseparable.
MDR exige repetibilidad, fiabilidad y funcionamiento conforme a la finalidad prevista. AI Act introduce requisitos adicionales de precisión y solidez (robustez) y ciberseguridad, enfatizando expresamente su mantenimiento durante el ciclo de vida.
No considero que exista una contradicción entre ambos Reglamentos. Al contrario, el AI Act obliga a mirar con mayor profundidad una cuestión que ya estaba presente en MDR: no basta con que el software haya funcionado correctamente cuando fue validado; debe mantenerse conforme durante su utilización.
Con GenAI, demostrar esa continuidad es posiblemente el mayor de los retos.
Del Design & Development al mantenimiento del estado validado
Aquí introduciría una distinción que considero importante. No debemos confundir validación del producto con validación de los procesos que permiten mantener controlado el producto.
La primera continúa siendo imprescindible, es requisito inviolable y que no desaparecerá como soporte de la seguridad y funcionamiento (eficacia). El fabricante deberá seguir demostrando que el producto terminado cumple su finalidad prevista y sus requisitos.
Pero determinados sistemas GenAI pueden hacer que esa demostración inicial resulte insuficiente para garantizar por sí sola el mantenimiento posterior del estado validado.
El proceso de diseño y desarrollo tendrá que definir no solamente qué producto se valida, sino también qué condiciones deben permanecer controladas para que esa validación continúe siendo representativa.
Esto puede afectar al control de modelos y versiones, datasets, prompts, RAG, configuración, proveedores tecnológicos, criterios de aceptación, cambios y monitorización del funcionamiento.
La consecuencia es importante para un sistema ISO 13485: el proceso de D&D ya no termina realmente en la liberación del diseño. Sus resultados deberán conectarse de manera mucho más directa con gestión de cambios, gestión de proveedores, gestión de riesgos y PMS.
MDCG 2025-6 va precisamente en esta dirección al considerar MDR/IVDR y AI Act como marcos complementarios y señalar que los requisitos adicionales relacionados con datos, gobernanza, registros, transparencia y supervisión humana pueden (deben) integrarse dentro del sistema de calidad existente del fabricante.
Human oversight no significa que una persona valide cada respuesta de la IA
El artículo 14 del AI Act exige que los sistemas de IA de alto riesgo se diseñen y desarrollen de forma que puedan ser supervisados eficazmente por personas durante el periodo en el que estén siendo utilizados. Las medidas deben ser proporcionales al riesgo, al nivel de autonomía y al contexto de utilización.
Esto no significa convertir al profesional sanitario en el mecanismo que compensa cualquier incertidumbre del algoritmo. Es más, ni es viable ni es el camino pretendido. Justamente se trataría de un concepto que choca frontalmente con el espíritu de los Reglamentos MDR e IVDR.
Si un fabricante necesita que un profesional detecte sistemáticamente los errores del sistema para garantizar su seguridad, significará en sí mismo que el programa no es capaz de asegurarlo por si solo, y esto supone no cumplir los requisitos; esto es simplemente imposible, inviable.
La supervisión humana debe diseñarse, debemos establecer qué información recibe el usuario, qué limitaciones debe conocer, qué capacidad tiene para interpretar el resultado y en qué situaciones puede intervenir, ignorar o detener la actuación del sistema.
En un producto GenAI, además, será necesario analizar si ese mecanismo continúa siendo eficaz cuando evoluciona el comportamiento del sistema.
La validación debe convertirse en un proceso más dinámico
Esto nos lleva al punto que considero central. No creo que el AI Act invalide el modelo de validación de ISO 13485 ni los requisitos del RGSF 17. Tampoco considero correcto afirmar que la validación de producto deba sustituirse por una validación de procesos.
El cambio necesita ser más profundo y, al mismo tiempo, más coherente con el sistema regulatorio existente.
En determinados productos GenAI tendremos que validar el producto y, además, disponer de procesos capaces de demostrar que se mantienen las condiciones que sustentaron esa validación.
El reciente Discussion Paper de FDA sobre productos sanitarios con IA generativa apunta hacia el mismo problema desde otra perspectiva. FDA está analizando herramientas como re-benchmarking periódico, revisión clínica basada en muestras y monitorización postmarket de degradación del funcionamiento. No son todavía requisitos regulatorios FDA, sino propuestas sometidas a discusión, pero muestran que el mantenimiento del funcionamiento después de la autorización se está convirtiendo en una cuestión regulatoria central para GenAI.
Por tanto, quizá no debamos hablar simplemente de una nueva forma de validar IA.
El verdadero cambio puede estar en cómo definimos y mantenemos el estado validado de un producto sanitario cuyo comportamiento depende de elementos que pueden evolucionar durante su ciclo de vida.
RGSF 17 continúa proporcionando el requisito. La ISO 13485 proporciona la estructura de diseño y desarrollo. AI Act incorpora nuevas exigencias sobre robustez, consistencia y supervisión humana.
La dificultad para los fabricantes será convertir esos tres elementos en un único sistema de control capaz de demostrar, con evidencia objetiva, que aquello que fue validado sigue siendo representativo del producto que realmente está siendo utilizado.