¿Qué es la regulación de la IA en el sector sanitario?
Regulación de la IA: sectores y ámbitos
La regulación de la IA en el sector sanitario es el conjunto de normas en capas que rige cómo se diseña, prueba, comercializa, despliega y supervisa la IA cuando afecta a pacientes, decisiones clínicas o servicios de salud. En la práctica, suele combinar legislación sobre productos sanitarios, normas de seguridad clínica y calidad, obligaciones en materia de datos y ciberseguridad y, en algunos lugares, legislación general sobre IA. Las preguntas centrales son: finalidad prevista, nivel de riesgo, evidencia, supervisión humana, documentación, control de cambios y seguimiento posterior al despliegue.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
La IA sanitaria no está regulada por un único reglamento independiente. La mayor parte del tiempo, la legislación sanitaria existente ya hace gran parte del trabajo. Si un software ayuda a diagnosticar enfermedades, orienta tratamientos, monitoriza la fisiología o controla un dispositivo, generalmente se tratará en primer lugar como software médico. En algunas jurisdicciones, las normas más recientes específicas sobre IA se superponen a lo anterior y añaden obligaciones adicionales en materia de gobernanza, transparencia, registro y supervisión.
Un mismo modelo puede, por tanto, enfrentarse a obligaciones muy distintas según lo que esté destinado a hacer. Una herramienta de análisis de imágenes de ictus, un motor de clasificación de quimioterapia, un intérprete de ECG, una herramienta de documentación ambiental y un optimizador de turnos de personal no se encuentran en el mismo ámbito legal. Los reguladores suelen partir de la finalidad prevista, el grupo de usuarios, el impacto clínico y si un profesional puede revisar adecuadamente la base de la recomendación del sistema.
Para operadores, compradores y fundadores, la lección práctica es sencilla. No hay que esperar al lanzamiento para preguntarse qué tipo de sistema se tiene. En el sector sanitario, la clasificación, la evidencia y el seguimiento deben definirse desde el principio, porque condicionan el diseño del producto, los contratos, el trabajo de validación, los controles de puesta en marcha y lo que debe ocurrir cuando el modelo se actualiza o algo sale mal.
Por qué es importante
La IA sanitaria puede influir en el diagnóstico, el triaje, la elección del tratamiento, el seguimiento, la documentación y la forma en que se emplea el escaso tiempo del personal. Si una organización se equivoca en su posición regulatoria, el resultado no es solo fricción legal. Puede significar retrasos en el acceso al mercado, fracasos en la contratación pública, evidencia insuficiente, despliegue inseguro, responsabilidad de usuario confusa y costosas correcciones posteriores cuando un regulador, un organismo notificado o un cliente importante solicita documentación que nunca se elaboró.
Para los responsables, lo importante es que la regulación sanitaria es una regulación de ciclo de vida. Lo difícil no es solo llegar al mercado o firmar un contrato. Es demostrar la finalidad prevista, la evidencia, la supervisión humana, la gestión del cambio, la trazabilidad y el tratamiento de incidentes antes y después del despliegue. En el sector sanitario, "lanzar ahora y ordenar después" suele ser el modelo operativo equivocado.
Cómo funciona
La clasificación comienza con la finalidad prevista
En el sector sanitario, la primera pregunta regulatoria no suele ser "¿es IA?", sino "¿para qué está destinada esta herramienta?". Si el software está destinado a diagnosticar, monitorizar, predecir, clasificar opciones de tratamiento, analizar imágenes médicas o producir de otro modo información utilizada para decisiones clínicas, a menudo entra en el ámbito del software médico. Si solo busca registros, gestiona tareas administrativas o apoya la planificación de personal, la respuesta puede ser diferente.
Por eso el trabajo de clasificación debe realizarse desde el principio y por escrito. La guía de software de la UE señala que no todo el software utilizado en el ámbito sanitario es un producto sanitario. Pone como ejemplos fuera del software de productos sanitarios la "búsqueda simple" y funciones no médicas como la facturación o la planificación de personal. Al mismo tiempo, la misma guía deja claro que el software puede convertirse en software médico regulado si procesa, analiza o modifica información médica con una finalidad médica, incluido el apoyo a los profesionales sanitarios.
Estados Unidos adopta un enfoque similar basado en la función, pero con su propia estructura. La guía actual de la FDA sobre apoyo a la decisión clínica establece que algunas funciones de apoyo dirigidas a profesionales sanitarios pueden quedar fuera de la definición de dispositivo si cumplen los cuatro criterios legales, incluido que el profesional pueda revisar de forma independiente la base de la recomendación. Esto significa que la clasificación depende de lo que hace el software, lo que afirma y el tipo de dependencia del usuario que genera.
La legislación sobre productos sanitarios sigue siendo la capa base
Para la IA con relevancia clínica, la legislación existente sobre productos sanitarios sigue haciendo la mayor parte del trabajo. En Europa, el software con finalidad médica se evalúa conforme al Reglamento de Productos Sanitarios o al Reglamento de Productos Sanitarios para Diagnóstico In Vitro. La guía de software del MDCG vigente muestra cómo funciona la clasificación de riesgos y por qué las herramientas de apoyo a la decisión suelen tratarse con seriedad. Con arreglo a la Regla 11, el software utilizado para apoyar el diagnóstico o la terapia suele situarse por encima de la Clase I, y algunos casos de uso, como el análisis de imágenes de ictus para decisiones de tratamiento, pueden alcanzar la Clase III.
Esto importa porque las clases superiores conllevan revisión por terceros, documentación técnica más exhaustiva y una gestión de la calidad más formal. En la práctica, muchas herramientas de IA clínica importantes no pueden tratarse como una adquisición de software ordinario. Necesitan evidencia, gestión de riesgos, trabajo de usabilidad, planificación poscomercialización y una vía de conformidad acorde con su función clínica.
En Estados Unidos no existe un único estatuto de IA sanitaria que realice esta función. La FDA regula el software de dispositivos a través de las autoridades y vías existentes para productos sanitarios. Sus orientaciones relacionadas con la IA siguen reforzando una visión del ciclo de vida total del producto, lo que significa que el regulador no solo se preocupa por el modelo en el momento de la presentación, sino también por los controles de diseño, la validación, las modificaciones futuras y la seguridad poscomercialización.
La legislación específica sobre IA puede añadir una segunda capa
En la UE, la IA sanitaria debe entenderse ahora como una superposición sectorial. El AI Act no sustituye al MDR ni al IVDR. Para los sistemas que cumplen los requisitos, añade una segunda capa. Las preguntas frecuentes conjuntas de 2025 del Consejo de Inteligencia Artificial y del Grupo de Coordinación de Productos Sanitarios explican el criterio principal: la IA médica se trata generalmente como de alto riesgo cuando la IA es en sí misma un producto sanitario, o un componente de seguridad de uno, y el producto está sujeto a evaluación de la conformidad por un organismo notificado.
Las mismas preguntas frecuentes son útiles porque muestran cómo se supone que funciona el cumplimiento dual en la práctica. Los requisitos del AI Act sobre gestión de la calidad, gobernanza de datos, mantenimiento de registros, transparencia, supervisión humana y registro están destinados a integrarse en la vía de conformidad existente para productos sanitarios, no a ejecutarse como un compartimento estanco completamente separado. En otras palabras, la IA médica en la UE no es una elección entre la legislación sobre dispositivos y la legislación sobre IA. Son ambas, si se cumplen las condiciones desencadenantes.
Sin embargo, los plazos requieren atención. La conocida fecha del 2 de agosto de 2026 para el AI Act no es toda la historia para los productos sanitarios. Las páginas de implementación actuales de la Comisión indican que las normas para los sistemas de IA integrados en productos regulados seguirán un calendario posterior, el 2 de agosto de 2028, tras el acuerdo político sobre el propuesto "AI Omnibus". Dado que esto depende del proceso del Omnibus y del trabajo de implementación relacionado, las organizaciones deben consultar el texto legal final más reciente y el material actual de la Comisión antes de fijar fechas de programa.
La evidencia, la documentación y la supervisión constituyen la columna vertebral del control
La regulación de la IA sanitaria es intensiva en documentación por una razón. Los reguladores quieren evidencia de que el sistema es seguro y funciona según lo declarado en el contexto en que se utilizará. Para la IA médica, eso suele significar una finalidad prevista definida, afirmaciones claras, estrategia de validación, pruebas clínicamente relevantes, gestión de riesgos, ingeniería de usabilidad, controles de ciberseguridad, instrucciones de uso y documentación técnica que pueda ser revisada por una autoridad o un organismo de conformidad.
Aquí es donde muchos equipos de IA subestiman el cambio que supone pasar de la práctica ordinaria de software a la práctica sanitaria regulada. En el sector sanitario, no basta con decir que un modelo funciona "bien en promedio" o que los clínicos utilizarán su criterio. La evidencia debe demostrar que el sistema ha sido probado en condiciones adecuadas, que sus limitaciones son conocidas y que el diseño favorece un uso seguro por parte de los usuarios previstos en el flujo de trabajo previsto.
La supervisión humana también es más específica de lo que el eslogan sugiere. No es simplemente "un médico participa en algún punto". Dependiendo de la herramienta, puede significar razonamiento revisable, controles de parada, restricciones al comportamiento autónomo, vías de escalada, formación, diseño de la interfaz, gestión de la confianza e instrucciones que reduzcan la probabilidad de dependencia excesiva. En las preguntas frecuentes sobre IA médica de la UE, la supervisión humana está vinculada directamente al diseño, el uso documentado y la supervisión por parte de profesionales e instituciones. En el contexto de apoyo a la decisión clínica en Estados Unidos, la línea entre apoyo de dispositivo y no dispositivo también depende en parte de si el clínico puede revisar de forma independiente la base de la recomendación.
El control de cambios y el seguimiento poscomercialización forman parte del régimen
Los reguladores sanitarios asumen que el software cambia, y que la IA puede cambiar de formas significativas para el riesgo. Por eso el control de cambios es fundamental. La guía definitiva de la FDA sobre planes de control de cambios predeterminados permite a un fabricante especificar previamente ciertas modificaciones futuras, explicar cómo se desarrollarán y validarán esos cambios y evaluar su probable impacto. El objetivo es favorecer la mejora iterativa sin obligar a presentar una nueva solicitud de comercialización para cada actualización que lo requiera.
La orientación europea sobre IA médica avanza en la misma dirección, aunque a través de su propia arquitectura. Las preguntas frecuentes sobre IA médica de la UE de 2025 explican que los cambios predeterminados pueden incorporarse a la documentación técnica y evaluarse durante la evaluación de la conformidad, y que deben integrarse en el procedimiento de gestión de cambios del dispositivo. El punto es el mismo: la evolución del modelo es trabajo regulado, no un hábito informal de ingeniería.
Una vez desplegado el sistema, las obligaciones de seguimiento continúan. Las normas de notificación de incidentes de productos sanitarios de la FDA son un ejemplo claro. Ciertos fallecimientos, lesiones graves y averías peligrosas recurrentes deben ser notificados por los declarantes obligatorios, y los datos de incidentes se incorporan a la vigilancia poscomercialización. La agencia también advierte que las bases de datos de notificaciones pasivas son valiosas pero limitadas, lo que recuerda que el registro y la revisión interna no pueden sustituirse únicamente por bases de datos públicas de eventos adversos. En la UE, las preguntas frecuentes sobre IA médica vinculan el seguimiento del ciclo de vida a la trazabilidad, el registro, la revisión poscomercialización y el cumplimiento continuo para la IA médica de alto riesgo.
Las normas y los marcos voluntarios ayudan con las herramientas que no son dispositivos
No todas las herramientas de IA sanitaria están reguladas como productos sanitarios, pero eso no significa que la gobernanza pueda ser informal. Las herramientas de servicios de salud, como los asistentes de documentación, los copilotos administrativos, las herramientas de resumen de registros o las herramientas de apoyo operativo, pueden quedar fuera de la legislación sobre dispositivos, dependiendo de su función y uso. Aun así, los compradores y los responsables del despliegue siguen necesitando una forma de gobernar la finalidad, las pruebas, la revisión por usuarios, el seguimiento, el control de versiones y la escalada.
Aquí es donde importan las normas y los marcos voluntarios. El documento de 2025 del IMDRF sobre Buenas Prácticas de Aprendizaje Automático establece principios de ciclo de vida alineados internacionalmente para dispositivos médicos habilitados con IA, incluidos la experiencia multidisciplinar, la ingeniería de software, la calidad de los datos, la trazabilidad, el seguimiento y las pruebas de rendimiento. El Marco de Gestión de Riesgos de IA del NIST y su perfil de IA generativa son voluntarios y no vinculantes, pero resultan útiles para estructurar la fiabilidad y los controles de riesgo, especialmente para las herramientas de servicios de salud que no son dispositivos, donde la regulación del producto puede ser más ligera o más fragmentada.
El límite clave es que estos marcos apoyan la implementación. No sustituyen a la ley. Un hospital no puede utilizar un marco voluntario como sustituto de la autorización de un dispositivo, la evaluación de la conformidad, los controles contractuales o la gobernanza clínica local. Pero sí puede utilizar esos marcos para organizar el trabajo práctico de garantía, captura de evidencia y supervisión continua.
Ejemplos
Una empresa que desarrolla software para analizar imágenes de ictus y apoyar decisiones de tratamiento se encuentra claramente en el ámbito del software médico regulado. La guía de software de la UE vigente lo cita como ejemplo de Clase III conforme a la Regla 11(a). Eso empuja al equipo hacia evidencia clínica sólida, documentación técnica, gestión de la calidad y evaluación por terceros desde el principio, en lugar de tratar la regulación como un trámite de última hora.
Una herramienta hospitalaria que solo recupera registros por metadatos, o un software utilizado para la planificación de personal, generalmente no es software de producto sanitario según la guía de la UE. En Estados Unidos, algunas herramientas de apoyo dirigidas a profesionales sanitarios también pueden quedar fuera de la regulación de dispositivos si cumplen los cuatro criterios legales de apoyo a la decisión clínica, incluido que el clínico pueda revisar de forma independiente la base de la recomendación. La lección práctica es que "utilizado en el sector sanitario" no determina la clasificación por sí solo.
Un fabricante que prevé actualizar un dispositivo habilitado con IA tras el lanzamiento debe planificar esa vía antes de la primera presentación. La guía de la FDA sobre planes de control de cambios predeterminados permite a los promotores describir las modificaciones previstas, el método para desarrollarlas y validarlas, y el impacto de esos cambios. Tras el despliegue, los fallecimientos, las lesiones graves y determinadas averías siguen perteneciendo al ámbito de la notificación y la vigilancia poscomercialización, y no deben tratarse como simples defectos internos de software.
Malentendidos frecuentes
Malentendido: Toda la IA sanitaria está regulada por una única ley especial sobre IA.
Corrección: En la práctica, la IA sanitaria suele estar regulada por normas en capas, especialmente la legislación sobre productos sanitarios, a la que se añade en algunas jurisdicciones una legislación más reciente específica sobre IA.
Malentendido: Si un clínico utiliza la herramienta, automáticamente es un producto sanitario.
Corrección: La clasificación depende de la finalidad médica prevista y la función, no simplemente del entorno en que se utiliza el software.
Malentendido: Si un humano puede anular el sistema, la regulación deja de ser un asunto serio.
Corrección: La supervisión humana ayuda a gestionar el riesgo, pero no elimina las obligaciones en materia de evidencia, documentación, diseño seguro, control de cambios o seguimiento.
Malentendido: Una vez autorizado o con marcado CE, un modelo de IA puede seguir cambiando libremente.
Corrección: Las modificaciones significativas, el reentrenamiento y la evolución del comportamiento están regulados y generalmente requieren una gobernanza predefinida.
Malentendido: Si una herramienta queda fuera de la legislación sobre productos sanitarios, básicamente no está regulada.
Corrección: Puede quedar fuera de la legislación sobre dispositivos, pero sigue necesitando gobernanza organizativa, controles de proveedores, pruebas y seguimiento adecuados al contexto sanitario.
Riesgos y límites
Este artículo explica la arquitectura regulatoria, no la posición legal completa para ningún producto específico. La clasificación puede cambiar con pequeñas diferencias en la finalidad prevista, el grupo de usuarios, el diseño del flujo de trabajo, el beneficio declarado, la fuente de datos, el patrón de actualización del modelo o si el software se utiliza para impulsar una decisión clínica.
También existe incertidumbre de plazos en la UE. Algunos materiales sectoriales publicados en 2025 hacían referencia a fechas de aplicación anteriores para determinadas obligaciones de IA de alto riesgo relacionadas con productos. Las páginas de implementación actuales de la Comisión para 2026 apuntan ahora a una fecha posterior, el 2 de agosto de 2028, para los sistemas de IA integrados en productos regulados, tras el acuerdo político sobre el propuesto AI Omnibus. Por eso los equipos no deben basarse en resúmenes de plazos desactualizados, ni en un único documento de forma aislada, al establecer planes de lanzamiento o de corrección.
Otro límite es la calidad de la evidencia tras el despliegue. Las bases de datos de incidentes y los informes de reclamaciones son señales de seguridad útiles, pero no prueban automáticamente la causalidad, la frecuencia ni la causa raíz. La revisión poscomercialización necesita, por tanto, algo más que la notificación pasiva. Necesita registro, trazabilidad, revisión clínica, conciencia de versiones y derechos de decisión sobre cuándo pausar, corregir o reevaluar un sistema.
Por último, los marcos voluntarios como el NIST AI RMF o el IMDRF GMLP son herramientas de gobernanza útiles, pero no sustituyen a los pasos legales vinculantes, como la autorización de dispositivos, la evaluación de la conformidad, las obligaciones de vigilancia del mercado o la aprobación de la gobernanza clínica local.
Qué hacer a continuación
Comience por mapear cada caso de uso por separado. Anote la finalidad prevista, el usuario, el grado de autonomía, el impacto en la decisión, los datos de entrada y el modelo de actualización. A continuación, divida el portafolio en al menos dos categorías: probable software médico y herramientas de servicios de salud que no son dispositivos. No permita que los equipos de adquisición o de producto colapsen esas categorías en un único compartimento genérico de "política de IA".
Construya una base de evidencia para cada caso de uso relevante. Eso significa una declaración clara de finalidad prevista, método de validación, limitaciones conocidas, diseño de supervisión humana, controles de ciberseguridad, plan de registro, política de actualización y vía de gestión de incidentes. Si el caso de uso es probable software médico, vincule esa evidencia a la gestión formal de la calidad y la documentación regulatoria, en lugar de mantenerla como notas informales del producto.
Establezca la gobernanza del despliegue antes de la puesta en marcha. Designe al responsable, defina en qué puede y no puede confiar el usuario, decida qué se registra, cree vías de reversión y escalada, y asegúrese de que los contratos con proveedores cubran las actualizaciones, el apoyo al seguimiento y la cooperación en incidentes. Para hospitales y compradores, los controles del flujo de trabajo local son importantes incluso cuando el proveedor asume la carga regulatoria del producto.
Si opera en la UE, verifique el calendario actual del AI Act para productos regulados y la orientación más reciente sobre la interacción con los productos sanitarios antes de fijar hojas de ruta. Si opera en Estados Unidos, confirme desde el principio si la función es apoyo a la decisión clínica no dispositivo o software de dispositivo regulado, porque eso cambia la vía previa a la comercialización y las obligaciones poscomercialización que se derivan.
Relacionado: Regulación de la IA por sector.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Toda la IA en el sector sanitario está regulada como producto sanitario?
No. La IA con finalidad médica a menudo sí lo está, especialmente si diagnostica, monitoriza, trata o impulsa decisiones clínicas. Otras herramientas, como algunas funciones de búsqueda, documentación o gestión de personal, pueden quedar fuera de la legislación sobre dispositivos dependiendo de lo que hagan.
¿Qué hace que la IA sanitaria sea de "alto riesgo" en la UE?
Para la IA médica, el criterio principal suele ser que la IA sea en sí misma un producto sanitario, o un componente de seguridad de uno, y que el dispositivo esté sujeto a evaluación de la conformidad por terceros conforme al MDR o al IVDR.
¿El AI Act sustituye al MDR o al IVDR para la IA médica?
No. Se superpone a ellos para los sistemas que cumplen los requisitos. La seguridad del dispositivo, la evidencia de rendimiento y la evaluación de la conformidad siguen siendo centrales.
¿La presencia de un humano en el proceso elimina las obligaciones regulatorias?
No. La supervisión humana es un control, no una exención. El sistema puede seguir estando regulado, y la propia supervisión debe diseñarse y documentarse adecuadamente.
¿Puede un modelo de IA seguir aprendiendo tras el despliegue?
Solo bajo una gestión del cambio controlada. Los reguladores esperan una gobernanza planificada de las actualizaciones, validación, documentación y seguimiento, especialmente cuando puede verse afectada la seguridad del paciente.
¿Por qué los hospitales necesitan controles locales si el proveedor está regulado?
Porque el riesgo del despliegue depende del flujo de trabajo local, la formación de los usuarios, la calidad de los datos, las vías de escalada y la gestión de incidentes. La regulación del producto no gestiona por sí sola el contexto de uso del hospital.
¿Qué deben solicitar los compradores antes de la adquisición?
Solicite la declaración de finalidad prevista, la clasificación regulatoria, la evidencia de validación, las limitaciones conocidas, el diseño de supervisión humana, los controles de ciberseguridad y registro, la política de actualización y la vía de notificación de incidentes.
¿Son suficientes por sí solos los marcos del NIST o del IMDRF?
No. Son útiles para organizar la gobernanza y la evidencia, pero no sustituyen a las obligaciones legales vinculantes, la autorización de dispositivos, la evaluación de la conformidad ni la gobernanza clínica local.