La etiqueta 'IA sanitaria' oculta diferencias regulatorias decisivas. Una herramienta que resume documentación administrativa, un sistema que ayuda a priorizar urgencias y un software con finalidad médica no deben compartir la misma clasificación por el mero hecho de utilizar IA. Una gobernanza útil empieza describiendo finalidad, producto, versión, datos, personas afectadas y grado de influencia; después conecta AI Act, MDR/IVDR, RGPD y controles clínicos o de seguridad que correspondan.
Ideas clave
- Distingue primero finalidad médica, apoyo clínico, triaje, comunicación y uso administrativo.
- El AI Act complementa MDR/IVDR cuando el sistema entra en ambos marcos.
- La supervisión humana necesita competencia, autoridad, información y capacidad de intervención reales.
- Un cambio de versión, finalidad o integración puede exigir reabrir la evaluación aunque la marca no cambie.
1. Crea unidades de inventario que coincidan con el uso real
Un mismo producto puede necesitar fichas separadas si se usa para finalidades distintas. Documenta qué recibe, qué produce, qué decisión apoya, quién utiliza la salida, qué personas pueden verse afectadas y si la finalidad real coincide con la prevista por el proveedor o fabricante.
2. Identifica si existe un producto sanitario regulado
La Comisión Europea señala que software basado en IA destinado a finalidades médicas puede quedar sometido al régimen de alto riesgo y a requisitos como gestión de riesgos, calidad de datos, información y supervisión humana. El documento MDCG 2025-6 desarrolla la interacción práctica entre MDR/IVDR y AI Act. La organización que despliega el sistema debe enlazar la documentación del producto con su propio uso, sin confundir su expediente interno con la evaluación de conformidad del fabricante.
3. Separa triaje y priorización de tareas administrativas
El AI Act contempla como alto riesgo determinados sistemas utilizados para evaluar y clasificar llamadas de emergencia o priorizar el envío de primeros intervinientes y asistencia médica. En cambio, tareas administrativas deben analizarse por sus propios datos, finalidad y consecuencias. La prudencia no exige sobrerregular lo trivial; exige no esconder una función materialmente sensible detrás de una etiqueta administrativa.
4. Diseña la supervisión humana sobre el punto de decisión
| Pregunta | Evidencia útil |
|---|---|
| ¿Quién interpreta la salida? | Designación, función, competencia y turno. |
| ¿Qué puede corregir o rechazar? | Procedimiento, permisos y umbrales. |
| ¿Qué información ve? | Entradas, explicación, alertas, registros e instrucciones. |
| ¿Cuándo debe escalar? | Criterios clínicos/operativos e incidentes definidos. |
| ¿Queda rastro de la intervención? | Registro de revisión, excepción y decisión final. |
5. Mantén un historial que conecte producto y despliegue
- Versión del software/modelo y configuración activa.
- Finalidad, área, usuarios y entorno en que se usa.
- Datos, integraciones y controles de acceso.
- Documentación regulatoria disponible del producto cuando corresponda.
- Aprobaciones, incidentes, reclamaciones, cambios y fecha de próxima revisión.
Fuentes y referencias
Se priorizan fuentes oficiales para el marco normativo. La aplicación a un caso concreto puede exigir revisar normativa sectorial, guías, jurisprudencia y documentación técnica adicional.