AI Act: qué cambia el 2 de agosto de 2026 para la IA sanitaria

Dos puertas de entrada al alto riesgo

El Reglamento de IA clasifica como alto riesgo por dos vías distintas, y la diferencia importa porque los plazos no coinciden.

La primera vía es el anexo III: una lista de usos concretos —empleo, educación, servicios esenciales, migración, justicia— donde el sistema se considera de alto riesgo por lo que decide sobre las personas. En sanidad, el caso más claro es el acceso a servicios públicos esenciales y a prestaciones, incluida la asistencia sanitaria de urgencia. Un algoritmo que priorice pacientes en una lista de espera o que triaje llamadas de urgencias cae aquí.

La segunda vía es el anexo I: sistemas de IA que son, o van incorporados en, productos ya regulados por legislación sectorial que exige evaluación de conformidad por tercero. Ahí está el software sanitario bajo el MDR. Una herramienta de detección de nódulos pulmonares, un CAD de mama o un sistema de apoyo a la decisión clínica con marcado CE entran por esta puerta.

Las fechas, en orden

Fecha	Qué es exigible
2 de febrero de 2025	Prácticas prohibidas y obligación de alfabetización en IA
2 de agosto de 2025	Obligaciones para modelos de propósito general y régimen de gobernanza
2 de agosto de 2026	Obligaciones de alto riesgo del anexo III y transparencia del artículo 50
2 de agosto de 2027	Obligaciones de alto riesgo del anexo I: el software sanitario con marcado CE

Es decir: si el hospital usa un producto sanitario con IA y marcado CE, el grueso de las obligaciones del fabricante llega en 2027. Si usa un desarrollo propio o una herramienta de gestión que decide sobre acceso a prestaciones, la fecha es la de la semana que viene.

Qué obliga a quien despliega, no solo a quien fabrica

Buena parte de la atención se ha puesto en el proveedor, pero el reglamento crea obligaciones propias para el responsable del despliegue, que es el papel que ocupa un hospital cuando usa un sistema de terceros:

• Usar el sistema conforme a las instrucciones del proveedor, lo que presupone haberlas leído y haber comprobado que el uso previsto coincide con el real.
• Encomendar la supervisión humana a personas con competencia y autoridad para ejercerla. No basta con que una persona figure en un procedimiento: tiene que poder no seguir la recomendación del sistema.
• Vigilar el funcionamiento y suspender el uso e informar al proveedor y a la autoridad cuando se detecte un riesgo.
• Conservar los registros que el sistema genere automáticamente, durante al menos seis meses salvo que otra norma diga otra cosa.
• Informar a las personas afectadas cuando el sistema se use para tomar o ayudar a tomar decisiones que les conciernen.

Para organismos públicos hay además una evaluación de impacto en derechos fundamentales antes del primer uso de sistemas del anexo III.

Lo que conviene tener hecho

Ninguna de estas cuatro cosas requiere esperar a que se aclare nada:

Un inventario de sistemas con IA. Sorprende cuántas organizaciones no pueden responder a “¿qué sistemas con IA tenemos y en qué servicios?”. Sin ese inventario no se puede clasificar nada, y clasificar es el primer paso.

La clasificación de cada uno. Anexo I, anexo III, riesgo limitado con obligación de transparencia, o fuera de ámbito. La mayoría de las herramientas administrativas quedan fuera; conviene documentarlo igualmente, porque la pregunta va a llegar.

Las instrucciones de uso de cada producto, archivadas y leídas. Es el documento del que cuelgan casi todas las obligaciones del desplegador.

Quién supervisa qué. Con nombre, no con departamento, y con capacidad real de apartarse de lo que el sistema propone.

Un matiz sobre los modelos de lenguaje

Un modelo de propósito general —un LLM comercial— no es de alto riesgo por sí mismo. Lo que puede serlo es el sistema que se construye encima y el uso al que se destina. Un asistente que redacta borradores de informe de alta y que un facultativo revisa y firma no es lo mismo que un sistema que decide quién entra en un programa. La clasificación mira al uso previsto, no a la tecnología.

Esto tiene una consecuencia práctica incómoda: cuando una organización adapta un modelo para una tarea clínica concreta y lo pone en producción con su marca, puede estar asumiendo el papel de proveedor y no solo el de desplegador. Merece la pena comprobarlo antes, no después.