Guía ejecutiva 01
Comprender y evaluar una herramienta de IA radiológica
Lectura estimada: 15–20 minutos
Objetivo: poder mantener una primera conversación rigurosa sobre una herramienta de IA sin necesidad de entrar en programación ni en estadística avanzada.
Uso: material personal de estudio y discusión. No constituye una posición aprobada de la SERAM.
La idea central
Una herramienta de inteligencia artificial no debe juzgarse por lo sofisticado que parezca su modelo ni por una cifra aislada de rendimiento. Hay que evaluar el sistema completo, la decisión que modifica, la evidencia que respalda esa modificación y la forma en que interactúa con las personas y la organización.
En la práctica, casi todas las preguntas importantes pueden ordenarse alrededor de seis cuestiones:
- ¿Qué hace exactamente el sistema?
- ¿Dónde reside realmente el riesgo?
- ¿Qué puede cambiar después de validarlo?
- ¿Qué demuestra —y qué no demuestra— la evidencia disponible?
- ¿Cómo afecta la prevalencia y el contexto a sus resultados?
- ¿Qué ocurre cuando entra en contacto con el radiólogo y el flujo real?
1. ¿Qué hace exactamente el sistema?
No compres una etiqueta: reconstruye el sistema
“IA multimodal”, “modelo fundacional” o “triaje inteligente” describen muy poco. Una solución puede contener varias piezas:
- selección de las series DICOM;
- preprocesado de las imágenes;
- modelo que genera una predicción;
- umbral que convierte esa predicción en una alerta;
- integración con PACS/RIS;
- regla que reordena la lista de trabajo;
- interfaz que muestra el resultado;
- canal por el que se avisa a alguien;
- persona que interpreta y actúa.
Si el caso acaba mal, el problema puede estar en cualquiera de ellas. El algoritmo puede detectar correctamente una hemorragia y, sin embargo, la alerta no llegar al radiólogo. También puede enlazarse una segmentación correcta al paciente equivocado. En ambos casos, “el modelo acertó”, pero el sistema asistencial falló.
Cuatro palabras que no significan lo mismo
| Modelo |
La función que transforma entradas en salidas: probabilidad, etiqueta, máscara o texto. |
Permite estudiar el rendimiento técnico, pero no describe el uso real. |
| Sistema |
Modelo más preprocesado, reglas, interfaz, integraciones y permisos. |
Es la unidad que realmente opera y puede producir efectos. |
| Producto |
El sistema ofrecido para una finalidad, población y versión determinadas. |
Las afirmaciones del fabricante y las condiciones de uso delimitan lo que se supone que hace. |
| Flujo clínico |
Producto más profesionales, protocolos, organización, contingencias y decisiones posteriores. |
Es donde aparece el beneficio o el daño para el paciente. |
Ejemplo práctico: triaje de ictus
Un proveedor afirma que su sistema “detecta oclusiones de gran vaso y acelera la atención”. En realidad, esas son dos afirmaciones diferentes:
- Afirmación técnica: identifica una oclusión en la angio-TC.
- Afirmación asistencial: reduce el tiempo hasta la trombectomía o mejora el resultado del paciente.
La primera puede evaluarse con imágenes etiquetadas. La segunda depende además de la latencia, la integración, las guardias, los protocolos, la disponibilidad del equipo de ictus y la conducta de los profesionales. Una sensibilidad alta no demuestra por sí sola que el paciente sea tratado antes.
Para recordar: antes de preguntar si una IA es buena, define qué pieza produce qué salida y qué decisión pretende modificar.
2. ¿Dónde reside realmente el riesgo?
La complejidad del modelo no es un buen sustituto del riesgo. Tres ejes son más útiles.
A. Qué salida produce
No es lo mismo producir:
- una puntuación;
- una segmentación revisable;
- un borrador de informe;
- una recomendación;
- una orden ejecutable.
Una salida abierta —por ejemplo, texto libre generado— es más difícil de verificar sistemáticamente que una etiqueta binaria. Pero una salida simple también puede ser peligrosa si desencadena una acción importante.
B. Qué autonomía tiene
Hay una diferencia esencial entre:
- informar: mostrar un dato al radiólogo;
- priorizar: modificar el orden de trabajo;
- decidir: condicionar una conducta clínica;
- ejecutar: enviar, cancelar, solicitar o comunicar algo sin confirmación previa.
Dos herramientas con el mismo modelo pueden tener riesgos muy distintos. Una segmentación que el radiólogo puede revisar no equivale a utilizar esa misma segmentación para decidir automáticamente que no hace falta una prueba adicional.
C. Qué ocurre si falla
El riesgo depende de la consecuencia, de la facilidad para detectar el error y del tiempo disponible para corregirlo. Un falso negativo silencioso en una herramienta de triaje urgente puede ser más peligroso que un texto incorrecto que siempre revisa un especialista antes de firmarlo.
La supervisión humana debe ser real
Decir que “siempre hay un médico” no basta. La supervisión solo es efectiva si el profesional:
- recibe la información a tiempo;
- entiende qué ha hecho el sistema y sus límites;
- puede reconocer razonablemente un fallo;
- dispone de autoridad y tiempo para corregirlo;
- no está condicionado por una dependencia excesiva de la herramienta.
Si una herramienta procesa cientos de casos, genera una salida difícil de comprobar y el radiólogo debe aprobarla en segundos, la supervisión puede ser más nominal que efectiva.
Para recordar: describe siempre la herramienta mediante esta frase: “produce esta salida, influye en esta decisión, actúa con este grado de autonomía y su fallo puede causar esta consecuencia”.
3. ¿Qué puede cambiar después de validarlo?
“Modelo bloqueado” no significa “sistema estable”
Aunque los pesos del modelo no cambien, sí pueden cambiar:
- el protocolo de adquisición;
- el fabricante o la reconstrucción del equipo;
- la población y la prevalencia;
- el preprocesado;
- el umbral de alerta;
- la integración con el sistema de información;
- la interfaz;
- el prompt de una herramienta generativa;
- la base documental de un sistema RAG;
- el proveedor o la versión de una API externa.
Por tanto, una validación pertenece a una versión, una población y unas condiciones de uso. No es una propiedad permanente del nombre comercial.
Ejemplo práctico: detector de embolia pulmonar
El hospital valida un detector sobre su protocolo habitual. Meses después modifica la administración de contraste y la reconstrucción. El modelo conserva la misma versión, pero la distribución de las imágenes cambia. El rendimiento anterior ya no garantiza el rendimiento actual.
No siempre será necesario repetir toda la validación, pero sí debe existir un proceso para valorar el cambio y decidir qué comprobación corresponde.
El ciclo de vida no termina con la compra
Una gobernanza mínima debe cubrir:
- Definición: problema, población, finalidad y beneficio esperado.
- Evaluación: evidencia disponible y prueba local.
- Despliegue: integración, formación, supervisión y contingencia.
- Vigilancia: rendimiento, fallos, subgrupos, incidentes y cambios.
- Revalidación: cuándo repetir comprobaciones.
- Retirada: quién puede detener el sistema y cómo se vuelve al flujo previo.
Un atajo útil consiste en exigir tres respuestas durante todo el ciclo:
- Responsable: ¿quién responde de esta fase y quién puede decidir?
- Evidencia: ¿qué información demuestra que funciona como se espera?
- Parada: ¿qué hallazgo obliga a corregirlo, suspenderlo o retirarlo?
Monitorizar sin una regla de actuación no es gobernar. Un panel de indicadores no protege a nadie si nadie tiene autoridad para detener el sistema.
Para recordar: el despliegue no cierra la evaluación; abre la fase más importante de vigilancia en el mundo real.
4. ¿Qué demuestra realmente la evidencia?
Empieza por la afirmación, no por el artículo
Antes de leer las métricas, completa esta frase:
“En esta población, esta versión del sistema, utilizada de esta manera y comparada con esta alternativa, pretende mejorar este resultado”.
Si no puede completarse, la afirmación es demasiado vaga para evaluarla.
La escalera de evidencia
| Rendimiento técnico retrospectivo |
¿Detecta o predice correctamente en un conjunto de datos? |
Que funcione en nuestra infraestructura o que ayude al radiólogo. |
| Validación externa |
¿Mantiene el rendimiento en otros datos, centros, tiempos o equipos? |
Que sea transferible a cualquier hospital o a otra versión. |
| Estudio prospectivo silencioso |
¿Procesa correctamente casos reales, consecutivos y actuales sin mostrar el resultado? |
Que mejore decisiones o resultados clínicos. |
| Evaluación con usuarios |
¿Qué ocurre cuando el radiólogo ve y utiliza la salida? |
Que el beneficio se mantenga a gran escala o a largo plazo. |
| Impacto asistencial |
¿Mejora tiempos, decisiones, calidad, resultados o eficiencia en el flujo real? |
Que sea coste-efectiva o sostenible en todos los contextos. |
Cada escalón responde una pregunta distinta. Un estudio retrospectivo excelente no equivale a una implantación exitosa.
Reportar bien, no tener sesgo y ser aplicable son tres cosas distintas
Conviene separar:
- Transparencia: ¿puedo entender lo que hicieron? Guías como CLAIM o TRIPOD+AI ayudan a comprobarlo.
- Riesgo de sesgo: ¿puedo creer el resultado? PROBAST+AI ayuda a identificar problemas en modelos predictivos.
- Aplicabilidad: aunque el resultado sea válido, ¿se parece suficientemente a nuestra población y flujo?
Un estudio puede describir perfectamente una muestra seleccionada de forma favorable. Estará bien reportado, pero seguirá sesgado. También puede ser metodológicamente sólido y no trasladarse a un hospital con otros equipos, prevalencia o usuarios.
Dónde entra el sesgo con más frecuencia
- selección de casos claros o exclusión de artefactos;
- pacientes repetidos entre entrenamiento y evaluación;
- partición por imagen en vez de por paciente;
- referencia estándar imperfecta o influida por el propio algoritmo;
- ajuste repetido utilizando el conjunto de prueba;
- elección retrospectiva del mejor umbral;
- validación “externa” en un entorno casi idéntico;
- evaluación de una versión distinta de la que se pretende comprar.
Para recordar: ante un estudio, pregunta por separado: “¿lo entiendo?”, “¿me lo creo?” y “¿puedo aplicarlo aquí?”.
5. ¿Qué significan las métricas en la práctica?
AUC no es utilidad clínica
El área bajo la curva ROC resume la capacidad del sistema para ordenar casos positivos por encima de negativos a lo largo de muchos umbrales. Es útil para comparar discriminación, pero no indica por sí sola:
- qué sensibilidad y especificidad tendrá el umbral utilizado;
- cuántas falsas alertas aparecerán en el hospital;
- si las probabilidades están bien calibradas;
- si cambia una decisión clínica;
- si el balance final entre beneficio y daño es favorable.
La prevalencia cambia lo que ve el usuario
Imaginemos una herramienta con sensibilidad del 90 % y especificidad del 90 % aplicada a 1.000 estudios, con una prevalencia del 2 %.
- Hay 20 casos positivos: detectará aproximadamente 18.
- Hay 980 negativos: marcará erróneamente aproximadamente 98.
- El radiólogo recibirá unas 116 alertas, pero solo 18 serán verdaderas.
- El valor predictivo positivo será cercano al 16 %.
La herramienta no ha cambiado de rendimiento técnico. Lo que ha cambiado es el contexto. En una población de baja prevalencia, incluso cifras aparentemente buenas pueden generar muchas más alertas falsas que verdaderas.
Esto no significa que la herramienta sea inútil. Puede ser razonable si el coste de omitir un caso es muy alto y las falsas alertas son fáciles de resolver. Pero ese balance debe hacerse explícito.
Discriminación, calibración y utilidad responden preguntas diferentes
- Discriminación: ¿separa bien positivos de negativos?
- Calibración: cuando dice 80 %, ¿el evento ocurre aproximadamente en el 80 % de casos comparables?
- Utilidad: en un umbral concreto, ¿las decisiones que provoca producen más beneficio que daño?
Una herramienta puede discriminar bien y estar mal calibrada. Esto importa especialmente si la puntuación se interpreta como riesgo absoluto o activa decisiones diferentes según el umbral.
“No inferior” no significa “igual”
Un estudio de no inferioridad intenta excluir que una nueva estrategia sea peor que el comparador por más de un margen clínicamente aceptable. No demuestra identidad ni equivalencia.
Ese margen es una decisión clínica: ¿qué pérdida máxima de sensibilidad aceptaríamos a cambio de reducir carga, acelerar la atención o liberar una segunda lectura? Debe definirse antes de analizar los datos y justificarse por sus consecuencias, no elegirse para facilitar un resultado positivo.
Para recordar: ninguna métrica interpreta por sí sola el valor clínico. Hay que conectarla con prevalencia, umbral, consecuencias y alternativa disponible.
6. ¿Qué ocurre cuando la IA interactúa con el radiólogo?
La unidad real suele ser persona + IA + interfaz
Si el producto pretende asistir a un radiólogo, no basta con conocer el rendimiento del algoritmo aislado. Debemos comparar:
- radiólogo sin IA;
- algoritmo solo;
- radiólogo con IA.
El resultado de la combinación no se deduce sumando los dos rendimientos. La IA puede ayudar a algunos lectores y perjudicar a otros; aumentar sensibilidad y falsos positivos a la vez; ahorrar tiempo en casos normales y aumentarlo en casos complejos; o desplazar la atención hacia zonas señaladas.
Ejemplo: el silencio del algoritmo también influye
Un estudio de Radiology de 2026 hizo que diez lectores interpretaran 60 mamografías primero sin IA y después con las indicaciones visibles de un sistema comercial. Mediante seguimiento ocular, los investigadores observaron que las sugerencias incorrectas modificaban tanto la exactitud como la búsqueda visual. El mayor efecto negativo apareció cuando la IA omitía un cáncer: la ausencia de señal podía reducir la atención dedicada a la lesión.
La implicación es profunda: una herramienta no solo influye cuando muestra una alerta. Su silencio también comunica información si el usuario espera que marque lo relevante.
Esto obliga a evaluar:
- cómo se muestra la salida;
- qué entiende el usuario que significa una ausencia de señal;
- cómo se explican las limitaciones y los falsos negativos;
- si existe fatiga de alertas;
- qué ocurre con lectores de distinta experiencia;
- cómo se auditan las discrepancias humano–IA;
- si el flujo favorece una revisión independiente o una aceptación automática.
Qué puede hacer el hospital antes de activar la herramienta
Un estudio prospectivo silencioso es un buen ensayo general: el algoritmo procesa casos reales y actuales dentro de la infraestructura prevista, pero sus salidas todavía no influyen en la asistencia. Permite medir cobertura, latencia, errores DICOM, prevalencia local, fallos por equipo y rendimiento contemporáneo.
Después, si la herramienta va a asistir al radiólogo, hace falta una evaluación con usuarios que reproduzca razonablemente la interfaz, la presión temporal y la conducta real. Para herramientas de mayor impacto puede ser necesaria una evaluación prospectiva interventional más robusta.
Para recordar: si la finalidad es asistir, el objeto de evaluación no es el algoritmo: es el equipo humano–IA dentro de un flujo concreto.
El caso integrador: ¿comprarías este detector?
Un proveedor ofrece un detector de hemorragia intracraneal con marcado CE. Presenta una AUC de 0,96, sensibilidad del 94 % y especificidad del 91 % en un estudio retrospectivo multicéntrico. Afirma que permitirá priorizar la lista de trabajo y reducir retrasos. El hospital utiliza equipos y protocolos no incluidos en el estudio. La salida se mostrará como una alerta y modificará automáticamente la prioridad.
Lo que sí sabemos
- Existe un producto definido y una evaluación técnica aparentemente favorable.
- El resultado se ha estudiado en más de un centro.
- El uso previsto no es meramente informativo: cambia el orden de trabajo.
Lo que todavía no sabemos
- Si los centros del estudio representan nuestros equipos, población y prevalencia.
- Qué umbral se utilizará y cuántas alertas falsas producirá localmente.
- Cuántos estudios no procesará y con qué latencia.
- Si la versión evaluada coincide con la que se desplegará.
- Cómo se comporta ante posoperatorios, artefactos y hemorragias pequeñas.
- Qué efecto tendrá sobre los casos no marcados y sobre la atención del radiólogo.
- Si priorizar positivos retrasará otros casos urgentes.
- Quién vigilará el sistema y cuándo se detendrá.
Decisión razonable
La evidencia no justifica todavía ni rechazar ni activar directamente la herramienta. Justifica avanzar de forma proporcionada:
- revisar el dossier y las condiciones exactas de uso;
- realizar una prueba técnica e integración local;
- ejecutar un periodo prospectivo silencioso con criterios predefinidos;
- estimar el efecto real sobre la lista de trabajo, incluidos los casos no señalados;
- definir supervisión, contingencia, indicadores y regla de parada;
- activar de forma controlada solo si los resultados sostienen el beneficio esperado.
Esta es la diferencia entre “una IA con buenas métricas” y “una implantación gobernada”.
Plantilla de ocho preguntas para cualquier herramienta
- Finalidad: ¿qué problema concreto pretende resolver y para quién?
- Sistema: ¿qué piezas intervienen desde la entrada hasta la acción final?
- Salida y autonomía: ¿qué produce y qué decisión modifica o ejecuta?
- Evidencia: ¿qué afirmación respalda realmente cada estudio?
- Transferibilidad: ¿se parecen población, equipos, protocolos, usuarios y versión a nuestro contexto?
- Interacción humana: ¿cómo cambia la conducta del radiólogo cuando acierta, se equivoca o permanece en silencio?
- Vigilancia: ¿qué indicadores se medirán, por subgrupos y a lo largo del tiempo?
- Control: ¿quién puede corregir, suspender y retirar el sistema, y con qué criterio?
Si una conversación no puede responder estas ocho preguntas, todavía no está madura para una decisión de despliegue.
Referencias esenciales
No es necesario leerlas de forma lineal. Sirven para profundizar cuando aparezca una duda concreta.
Sistema, ciclo de vida y riesgo
- NIST AI Risk Management Framework 1.0. Marco general para analizar riesgo durante todo el ciclo de vida y en la interacción sociotécnica.
- IMDRF Good Machine Learning Practice for Medical Device Development: Guiding Principles. Principios sobre datos representativos, evaluación independiente, equipo humano–IA y vigilancia posterior al despliegue.
- Zech JR et al. Variable generalization performance of a deep learning model to detect pneumonia in chest radiographs. Ejemplo clásico de aprendizaje de señales específicas del hospital y pérdida de generalización.
Evaluación científica
- CLAIM 2024 Update. Lista de comprobación para informar estudios de IA en imagen médica.
- TRIPOD+AI. Guía de reporte para modelos clínicos predictivos basados en regresión o aprendizaje automático.
- PROBAST+AI. Herramienta para evaluar calidad, riesgo de sesgo y aplicabilidad de modelos predictivos.
- Vasey B et al. DECIDE-AI. Guía para la evaluación clínica temprana y en vivo de sistemas de apoyo a la decisión basados en IA.
- Taib AG et al. Automation Bias in Action: Eye Tracking of Humans Reading Screening Mammograms with and without AI Prompts. Evidencia experimental sobre cómo los errores de IA modifican la precisión y la búsqueda visual.
Resumen en cinco frases
- La IA sanitaria es un sistema sociotécnico, no solo un modelo.
- El riesgo depende de la salida, la autonomía, el contexto y las consecuencias del fallo.
- Una métrica técnica no demuestra automáticamente beneficio clínico ni organizativo.
- La validación debe pertenecer a una versión, población, flujo y finalidad concretos.
- Cuando la IA asiste a un radiólogo, hay que evaluar y gobernar la pareja humano–IA.
Guía ejecutiva 02
Leer y aplicar el AI Act en radiología sin perderse en el Derecho
Lectura estimada: 15–20 minutos
Fecha de actualización: 5 de agosto de 2026
Objetivo: poder clasificar provisionalmente un caso, identificar las obligaciones y actores relevantes y comunicar con precisión qué está confirmado, qué es interpretación y cuándo hace falta revisión jurídica.
Uso: material personal de estudio y discusión. No constituye asesoramiento jurídico ni una posición aprobada de la SERAM.
La idea central
El AI Act no debe aprenderse como una lista de artículos. Debe utilizarse como un método de razonamiento:
caso concreto → finalidad prevista → norma aplicable → categoría de riesgo → actor → obligación → fecha de aplicación
Saltarse uno de esos pasos produce la mayoría de los errores. “Usa IA”, “tiene marcado CE” o “hay un médico supervisando” no permiten, por sí solos, concluir qué exige la ley ni quién responde.
Para un coordinador de la Comisión, el objetivo no es emitir dictámenes jurídicos. Es poder formular bien el problema, detectar afirmaciones demasiado categóricas y saber qué pregunta debe resolver un jurista, la AEMPS, protección de datos, contratación o el responsable clínico.
1. Antes de interpretar una norma, define la pregunta
“¿Cumple esta IA el reglamento?” es una pregunta demasiado amplia. Conviene reconstruirla en seis elementos:
- Qué sistema es: versión, componentes y salida.
- Para qué se utiliza: finalidad prevista y decisión que modifica.
- Quién hace qué: desarrolla, comercializa, compra, configura, utiliza y supervisa.
- Dónde se usa: investigación, asistencia, gestión, comunicación o uso personal.
- Cuándo: la fecha puede cambiar completamente la obligación aplicable.
- Qué se quiere decidir: comprar, desplegar, investigar, publicar, modificar o atribuir responsabilidad.
Ejemplo breve
Un modelo de lenguaje puede utilizarse para:
- corregir el estilo de un texto administrativo;
- redactar un borrador de informe radiológico;
- recomendar un diagnóstico;
- responder directamente a un paciente;
- publicar una nota institucional.
El modelo subyacente puede ser el mismo, pero la finalidad, los riesgos y las normas aplicables no lo son. La clasificación jurídica pertenece al sistema aplicado y a su finalidad, no a la etiqueta “LLM”.
Para recordar: no preguntes “qué regula la IA”; pregunta “qué regla se aplica a este actor, para este uso y en esta fecha”.
2. No todas las fuentes tienen el mismo valor
Una jerarquía práctica
| Reglamento de la UE |
Norma vinculante y directamente aplicable. |
Empezar por el artículo, sus definiciones, anexos y fecha de aplicación. |
| Directiva de la UE |
Obliga al resultado, pero requiere transposición nacional. |
Comprobar además la ley española vigente; una directiva nueva no sustituye automáticamente el Derecho nacional. |
| Ley o real decreto español |
Completa competencias, procedimientos, sanciones u otros ámbitos nacionales. |
Confirmar que es texto vigente, no anteproyecto o proyecto parlamentario. |
| Acto delegado o de ejecución |
Modifica o concreta aspectos autorizados por la norma. |
Revisarlo porque puede cambiar anexos, procedimientos o especificaciones. |
| Norma armonizada |
Traduce requisitos legales a especificaciones técnicas. |
Es voluntaria, pero su publicación en el Diario Oficial puede otorgar presunción de conformidad. |
| Directriz, FAQ o código de prácticas |
Explica cómo interpreta o pretende aplicar la norma una autoridad. |
Tiene gran valor práctico, pero no debe presentarse como si fuera el artículo de una ley. |
| Considerando |
Explica contexto, finalidad y lógica del articulado. |
Ayuda a interpretar; no crea por sí solo una obligación independiente. |
| Propuesta legislativa |
Indica hacia dónde puede cambiar el Derecho. |
Sirve para anticipar, no para afirmar qué es obligatorio hoy. |
Dos trampas frecuentes
Primera: una versión consolidada de EUR-Lex es la mejor herramienta de trabajo porque integra las modificaciones, pero EUR-Lex advierte que el texto consolidado es documental. Para una cuestión controvertida debe comprobarse el acto publicado en el Diario Oficial y sus modificaciones.
Segunda: una guía oficial puede ser muy influyente sin ser jurídicamente vinculante. La formulación correcta es “las directrices de la Comisión interpretan…” y no “la ley dice…”, salvo que también lo diga el articulado.
Situación española a 5 de agosto de 2026
El Proyecto de Ley Orgánica para el buen uso y la gobernanza de la inteligencia artificial fue presentado al Congreso el 28 de mayo de 2026. Sigue siendo un proyecto, no una ley vigente. Por tanto, su propuesta de autoridades y régimen sancionador no debe citarse todavía como decisión definitiva. La AESIA ya existe y publica guías útiles, pero estas indican expresamente que no son vinculantes ni sustituyen la normativa aplicable.
Para recordar: antes de usar una fuente, etiqueta mentalmente: “ley vigente”, “interpretación oficial”, “estándar voluntario” o “propuesta”.
3. ¿Entra el sistema en el AI Act y qué categoría tiene?
El esquema no es simplemente “bajo, medio o alto”
El AI Act combina varias capas:
- Prácticas prohibidas: usos concretos considerados incompatibles con los valores y derechos de la Unión.
- Sistemas de alto riesgo: por estar ligados a productos regulados o por su finalidad en ámbitos enumerados.
- Obligaciones específicas de transparencia: por ejemplo, interacción directa con personas o ciertos contenidos generados.
- Riesgo mínimo o no regulado específicamente: sigue sometido al resto del Derecho, aunque no tenga requisitos propios de alto riesgo.
- Modelos de propósito general, o GPAI: tienen un régimen propio para quien proporciona el modelo; la aplicación construida sobre él puede, además, ser un sistema de alto riesgo o estar sujeta a transparencia.
Una herramienta puede acumular capas. Utilizar un modelo de propósito general no evita tener que clasificar la aplicación clínica construida sobre él.
La ruta habitual para la IA radiológica clínica
El artículo 6.1 considera de alto riesgo un sistema cuando se cumplen dos condiciones:
- la IA es un producto —o un componente de seguridad de un producto— cubierto por la legislación del anexo I; y
- ese producto requiere una evaluación de conformidad por un tercero antes de comercializarse o ponerse en servicio.
El anexo I incluye los reglamentos de productos sanitarios MDR e IVDR. Por ello, una parte importante del software radiológico con finalidad médica y evaluación por organismo notificado entra en esta vía. Pero no es correcto decir que toda IA radiológica es automáticamente de alto riesgo: hay que comprobar finalidad prevista, condición de producto sanitario, clase y procedimiento de conformidad.
Tres distinciones esenciales
- Marcado CE no equivale a alto riesgo AI Act. Primero hay que saber bajo qué legislación se obtuvo y si se cumplen las condiciones del artículo 6.1.
- Alto riesgo no significa prohibido. Significa que el sistema puede comercializarse y utilizarse si cumple requisitos reforzados.
- No ser de alto riesgo no significa estar sin regular. Pueden seguir aplicándose MDR, RGPD, ciberseguridad, contratación pública, responsabilidad profesional y normas sanitarias.
Para recordar: en radiología, la clasificación se construye desde la finalidad médica y la vía regulatoria del producto, no desde lo impresionante que parezca el algoritmo.
4. ¿Quién es proveedor y quién es responsable del despliegue?
Los nombres jurídicos no coinciden necesariamente con los nombres cotidianos
| Proveedor |
Desarrolla un sistema y lo comercializa o pone en servicio con su nombre o marca. |
Empresa que ofrece un detector de hemorragia; hospital que pone en servicio un desarrollo propio. |
| Responsable del despliegue |
Utiliza el sistema bajo su autoridad, salvo uso personal no profesional. |
Habitualmente el hospital o servicio de salud que implanta la herramienta. |
| Persona que ejerce supervisión |
Vigila e interpreta el sistema por encargo del responsable del despliegue. |
Radiólogo u otro profesional designado, con competencia y autoridad suficientes. |
| Fabricante MDR |
Asume la responsabilidad de un producto sanitario bajo su nombre. |
Puede coincidir con el proveedor AI Act, pero son conceptos de normas distintas. |
El radiólogo individual no suele ser, por el mero hecho de utilizar la herramienta, el “responsable del despliegue”: normalmente actúa dentro de la organización que ha decidido implantarla. Esto no elimina sus deberes profesionales, pero evita atribuirle obligaciones organizativas que corresponden al hospital.
El hospital puede cambiar de rol
Un distribuidor, responsable del despliegue u otra parte puede pasar a ser considerado proveedor de un sistema de alto riesgo si, por ejemplo:
- lo comercializa o pone en servicio bajo su propio nombre;
- realiza una modificación sustancial;
- cambia la finalidad prevista de modo que el sistema pase a ser de alto riesgo.
No toda configuración local es una modificación sustancial. Pero cambiar el umbral, combinar componentes, introducir una nueva población o utilizar el sistema fuera de la finalidad prevista exige preguntar si se ha alterado la conformidad o el propósito evaluado. Esto debe resolverse antes del cambio, no después de un incidente.
Para recordar: “comprar” suele situar al hospital como responsable del despliegue; “desarrollar, renombrar o transformar” puede acercarlo al rol de proveedor.
5. ¿Qué está vigente hoy y qué llegará después?
Calendario actualizado tras el AI Omnibus
| 2 febrero 2025 |
Aplicación de las prácticas prohibidas iniciales y de la obligación de alfabetización en IA. |
| 2 agosto 2025 |
Aplicación de gobernanza europea y obligaciones para proveedores de modelos GPAI. |
| 2 agosto 2026 |
Aplicación general del AI Act y de las obligaciones de transparencia del artículo 50, con las excepciones y transiciones previstas. Comienza la aplicación y supervisión efectiva de las reglas ya exigibles. |
| 2 diciembre 2027 |
Aplicación de las obligaciones para los casos de alto riesgo del anexo III, tras la reforma de 2026. |
| 2 agosto 2028 |
Aplicación de las obligaciones de alto riesgo del artículo 6.1 para IA que sea producto o componente de productos regulados del anexo I, incluidos los productos sanitarios cuando corresponda. |
La conclusión correcta para radiología
Desde el 2 de agosto de 2026 el AI Act ya es aplicable, pero el bloque específico de requisitos de alto riesgo para productos sanitarios no empieza, con carácter general, hasta el 2 de agosto de 2028 tras el Reglamento (UE) 2026/1744, conocido como AI Omnibus.
Esto no crea dos años de vacío:
- el MDR y el IVDR mantienen sus obligaciones;
- el RGPD y la normativa sanitaria siguen vigentes;
- la alfabetización en IA ya es exigible;
- las obligaciones aplicables a GPAI y las de transparencia tienen su propio calendario;
- contratos, instrucciones de uso, vigilancia y deberes profesionales no desaparecen.
También existen reglas transitorias para sistemas ya comercializados. Por eso, ante un producto concreto, no basta con memorizar la tabla: hay que comprobar fecha de puesta en el mercado, modificaciones posteriores y categoría exacta.
La alfabetización no es “hacer un curso genérico”
El artículo 4 obliga a proveedores y responsables del despliegue a adoptar medidas de alfabetización teniendo en cuenta experiencia, formación, contexto y sistema utilizado. Tras la reforma de 2026 no se exige garantizar un nivel individual específico, pero la obligación organizativa permanece.
La consecuencia para SERAM es relevante: puede ofrecer una base común de calidad, pero no puede certificar por sí sola que un hospital cumple. La organización debe adaptar la formación a sus herramientas, riesgos, profesionales y procedimientos.
Para recordar: el AI Act no tiene una sola fecha; cada obligación posee su propio reloj.
6. ¿Qué exige el régimen de alto riesgo?
Al proveedor
El núcleo de requisitos de los artículos 9 a 15 puede resumirse en:
- gestión continua de riesgos;
- gobernanza y calidad de datos;
- documentación técnica;
- registros y trazabilidad;
- información suficiente para el responsable del despliegue;
- supervisión humana diseñada de forma efectiva;
- precisión, robustez y ciberseguridad.
A ello se añaden obligaciones organizativas: sistema de gestión de calidad, evaluación de conformidad, registro cuando proceda, vigilancia poscomercialización, gestión de incidentes, acciones correctivas y cooperación con autoridades.
Al hospital como responsable del despliegue
Cuando resulte aplicable el régimen de alto riesgo, la organización no puede limitarse a comprobar el CE y delegar todo en el proveedor. Entre otras obligaciones, debe:
- usar el sistema conforme a las instrucciones y adoptar medidas técnicas y organizativas adecuadas;
- asignar la supervisión a personas competentes, formadas y con autoridad;
- asegurar, cuando controle los datos de entrada, que sean pertinentes y suficientemente representativos para la finalidad;
- monitorizar el funcionamiento a partir de las instrucciones del proveedor;
- comunicar riesgos e incidentes y suspender el uso cuando corresponda;
- conservar los registros que estén bajo su control;
- cumplir las obligaciones de información, protección de datos o evaluación de derechos fundamentales cuando sean aplicables al caso.
La evaluación de impacto sobre derechos fundamentales del artículo 27 no es una obligación universal para toda IA médica. Depende del tipo de sistema y del responsable del despliegue. Debe comprobarse su ámbito antes de afirmarla.
Supervisión humana no significa “que el médico asuma todo”
La norma distribuye responsabilidades. El proveedor debe diseñar un sistema susceptible de supervisión efectiva; la organización debe asignar medios, competencia y autoridad; y el profesional debe ejercer sus deberes clínicos dentro de ese marco.
Una casilla que diga “revisado por un médico” no compensa una interfaz opaca, una carga imposible de revisar o la falta de capacidad para detener el sistema.
Para recordar: el cumplimiento del proveedor y la gobernanza del hospital son complementarios; ninguno sustituye al otro.
7. Qué regula el AI Act y qué no resuelve
El AI Act puede imponer requisitos sobre diseño, datos, documentación, supervisión, transparencia, vigilancia y organización. Pero no responde por sí solo a todas las preguntas relevantes.
| “Tiene CE, por tanto está demostrado que mejora la asistencia.” |
El CE acredita conformidad con una vía regulatoria, no utilidad local ni coste-efectividad. |
| “Es de alto riesgo, por tanto no se puede usar.” |
Alto riesgo implica requisitos reforzados, no prohibición. |
| “No es de alto riesgo, así que no hay obligaciones.” |
Pueden aplicar otras partes del AI Act y todo el marco sanitario, de datos y profesional. |
| “Hay un médico en el circuito, por tanto la empresa no responde.” |
La supervisión humana no borra obligaciones del proveedor ni de la organización. |
| “El AI Act determina quién paga por el error diagnóstico.” |
El reparto de responsabilidad por daños exige analizar producto, contrato, actuación profesional, organización, causalidad y Derecho nacional. |
| “Todo texto creado con IA debe etiquetarse.” |
El artículo 50 contiene usos, destinatarios y excepciones concretos; no es una regla universal para todo borrador o informe clínico. |
Aplicación a una comunicación de SERAM
Si una herramienta ayuda a redactar una noticia sobre un asunto de interés público, hay que valorar el artículo 50 y sus directrices: grado de generación o manipulación, revisión humana y responsabilidad editorial. Esto es distinto de publicar automáticamente un texto generado.
Además, aunque jurídicamente no fuese obligatorio etiquetarlo, SERAM podría adoptar una política interna más exigente por razones de transparencia. Esa sería una decisión institucional, no una obligación legal atribuible automáticamente al AI Act.
Para recordar: distinguir “la ley exige”, “la guía interpreta” y “la organización decide” evita convertir preferencias prudenciales en falsas obligaciones jurídicas.
Caso integrador: detector de hemorragia con priorización automática
Un hospital público compra un detector de hemorragia intracraneal con marcado CE. El sistema analiza TC, genera una alerta y reordena automáticamente la lista de trabajo. El proveedor afirma que es “AI Act compliant”. El hospital quiere reducir el tiempo hasta la lectura.
Análisis en siete pasos
- Finalidad: no solo detecta; modifica la prioridad asistencial. Hay que evaluar detección, latencia y efectos sobre los casos marcados y no marcados.
- MDR: debe comprobarse finalidad prevista, clase, certificado, organismo notificado, versión e instrucciones de uso.
- AI Act: si el software es producto sanitario sujeto a evaluación por tercero, probablemente seguirá la vía de alto riesgo del artículo 6.1.
- Calendario: los requisitos AI Act específicos de esta vía se aplican, con carácter general, desde el 2 de agosto de 2028; el resto del marco aplicable no queda suspendido.
- Roles: la empresa es previsiblemente proveedor y fabricante; el hospital, responsable del despliegue; los radiólogos ejercen supervisión dentro de la organización.
- Cambios: si el hospital modifica umbrales o utiliza la herramienta fuera de su finalidad, debe analizar antes si cambia su rol o invalida la conformidad prevista.
- Decisión: “cumple el AI Act” no basta para comprar. Deben revisarse evidencia, integración, validación local, registros, formación, monitorización, incidentes, contingencia y regla de parada.
Conclusión razonable
La regulación de producto y el AI Act ofrecen un suelo de seguridad y obligaciones. No sustituyen la decisión clínica y organizativa de si el sistema aporta valor en ese hospital. La gobernanza local de la Guía 01 sigue siendo necesaria aunque toda la documentación regulatoria sea correcta.
Plantilla de nueve preguntas para una consulta regulatoria
- Sistema: ¿qué versión y qué componentes se están evaluando?
- Finalidad: ¿qué afirma que hace y qué decisión modifica?
- Ámbito: ¿es investigación, asistencia, gestión, comunicación o uso personal?
- Clasificación: ¿es producto sanitario, alto riesgo, sujeto a transparencia o GPAI?
- Actor: ¿quién es proveedor, fabricante, responsable del despliegue y supervisor?
- Fuente: ¿la afirmación procede de una ley, guía, estándar o propuesta?
- Fecha: ¿la obligación ya se aplica a esta categoría y a este sistema?
- Evidencia: ¿qué documento demostraría el cumplimiento?
- Límite: ¿qué parte requiere revisión jurídica, regulatoria o de protección de datos?
Implicaciones directas para tu papel en la Comisión
- Corregir simplificaciones públicas: especialmente “toda IA médica es de alto riesgo”, “todo entra en vigor a la vez” o “el médico responde siempre”.
- Separar formación general y cumplimiento local: SERAM puede alfabetizar y ofrecer plantillas; el hospital debe aplicarlas a sus sistemas y organización.
- Trabajar con versiones y fechas: toda nota regulatoria debería llevar fecha de actualización y enlace al texto consolidado vigente.
- Mantener revisión experta: los posicionamientos públicos sobre responsabilidad, clasificación o autoridades españolas deberían incorporar revisión jurídica o regulatoria.
- No confundir propuesta con posición: un borrador de la Comisión no es una recomendación oficial de SERAM hasta su aprobación.
Una formulación segura en una reunión sería:
“Mi interpretación preliminar es esta, basada en la finalidad y el rol del hospital; debemos confirmarla con el equipo jurídico o regulatorio antes de presentarla como conclusión institucional.”
Referencias oficiales esenciales
- Reglamento de IA: texto consolidado a 27 de julio de 2026. Herramienta principal de trabajo; debe contrastarse con los actos del Diario Oficial cuando la precisión jurídica sea crítica.
- Reglamento (UE) 2026/1744 — AI Omnibus. Modifica, entre otros aspectos, el calendario de los sistemas de alto riesgo.
- Comisión Europea: AI Act y calendario de aplicación. Resumen oficial actualizado del régimen y de la reforma de 2026.
- AI Act Service Desk: navegación y preguntas frecuentes. Explicación oficial de clasificación, proveedores, responsables del despliegue, estándares y aplicación.
- Comisión Europea: alfabetización en IA. Alcance práctico del artículo 4 tras la reforma de 2026.
- Comisión Europea: normalización del AI Act. Función de CEN-CENELEC y de la presunción de conformidad.
- Unión Europea: tipos de legislación. Diferencias entre reglamentos, directivas, decisiones, recomendaciones y dictámenes.
- EUR-Lex: textos consolidados. Explica su finalidad documental y cómo integran modificaciones.
- Congreso de los Diputados: Proyecto de Ley Orgánica para el buen uso y la gobernanza de la IA. Estado de la adaptación española, todavía en tramitación a la fecha de esta guía.
- AESIA: guías de aplicación. Recursos prácticos no vinculantes desarrollados en España.
Resumen en seis frases
- La regulación se aplica a un sistema, una finalidad, un actor y una fecha concretos.
- Una guía oficial ayuda a interpretar, pero no debe confundirse con la ley.
- Gran parte de la IA médica será de alto riesgo por la vía MDR–artículo 6.1, pero no toda IA radiológica lo es automáticamente.
- Tras el AI Omnibus, los requisitos de alto riesgo para productos sanitarios se aplican, con carácter general, desde el 2 de agosto de 2028; no existe por ello un vacío regulatorio.
- El hospital suele ser responsable del despliegue, pero puede convertirse en proveedor si desarrolla o modifica sustancialmente el sistema.
- El AI Act establece obligaciones de seguridad y gobernanza, pero no demuestra utilidad clínica ni decide por sí solo quién responde por un daño.
Guía ejecutiva 03
Producto sanitario, MDR–AI Act y desarrollo in-house en radiología
Lectura estimada: 15–20 minutos
Fecha de actualización: 5 de agosto de 2026
Objetivo: reconocer cuándo un software radiológico se convierte en producto sanitario, interpretar correctamente su marcado CE y detectar cuándo un hospital deja de ser un simple usuario para asumir obligaciones de fabricante o proveedor.
Uso: material personal de estudio y discusión. No constituye asesoramiento jurídico ni una posición aprobada de la SERAM.
La idea central
El MDR y el AI Act no regulan “la tecnología” en abstracto. Regulan una finalidad concreta, unas afirmaciones del fabricante, un producto delimitado y las actuaciones de determinados actores.
Por eso, el mismo algoritmo puede encontrarse en situaciones muy diferentes:
| Se entrena retrospectivamente y sus resultados no se usan para atender pacientes. |
Proyecto de investigación; no es todavía un despliegue clínico, aunque siguen aplicándose las normas de investigación y datos. |
| Segmenta tumores y muestra resultados a un radiólogo para influir en el seguimiento de pacientes. |
Probable software producto sanitario; hay que definir finalidad y clase. |
| Se compra como producto con marcado CE y se usa exactamente según sus instrucciones. |
El hospital es principalmente usuario y responsable del despliegue, pero mantiene obligaciones de selección, formación, uso y vigilancia. |
| El hospital reentrena el producto, cambia su finalidad o añade una recomendación clínica nueva. |
Puede dejar de ser una mera configuración y convertir al hospital en fabricante o proveedor respecto del sistema modificado. |
| El hospital desarrolla el software para utilizarlo exclusivamente dentro de su propia entidad. |
Puede existir una vía in-house, pero exige condiciones estrictas; no es una exención informal ni una vía rápida para “evitar el CE”. |
La secuencia correcta es:
finalidad prevista → producto sanitario o no → clase MDR → fabricante → evaluación de conformidad → AI Act → forma de despliegue y cambios
1. ¿Cuándo es el software un producto sanitario?
La finalidad médica importa más que la técnica
El punto de partida no es si utiliza aprendizaje profundo, reglas, estadística convencional o un modelo de lenguaje. Según el MDR, el software entra en el ámbito de los productos sanitarios cuando el fabricante lo destina, entre otros fines, al diagnóstico, prevención, predicción, pronóstico, seguimiento o tratamiento de una enfermedad.
La guía europea MDCG 2019-11 rev.1 añade una distinción práctica: el software debe tener una finalidad médica propia. No todo programa utilizado en un hospital es producto sanitario.
Ejemplos radiológicos
| Archivar y transferir imágenes en un PACS. |
En principio, no por esa función aislada. |
Almacenamiento y comunicación no constituyen por sí solos una finalidad médica del software. |
| Buscar estudios por metadatos. |
En principio, no. |
Es una búsqueda simple. |
| Detectar nódulos en una TC y señalarlos al radiólogo. |
Sí, previsiblemente. |
Procesa imágenes de un paciente para apoyar el diagnóstico. |
| Segmentar una lesión y calcular su variación volumétrica para seguimiento. |
Sí, si el resultado se destina a una decisión clínica. |
Produce información individual con finalidad de seguimiento o evaluación terapéutica. |
| Priorizar una lista de trabajo según sospecha de hemorragia. |
Sí, previsiblemente. |
El análisis modifica el proceso asistencial de pacientes concretos. |
| Corregir ortografía de un informe sin interpretar su contenido clínico. |
No necesariamente. |
La función editorial aislada no equivale a diagnóstico. |
| Generar una impresión diagnóstica o recomendar conducta. |
Probablemente sí. |
La salida está destinada a influir en una decisión médica. |
La ubicación tampoco decide la clasificación. Un algoritmo puede ejecutarse en el escáner, el PACS, un servidor hospitalario o la nube y seguir siendo el mismo tipo de producto. Tampoco deja de serlo porque el radiólogo revise la salida.
La finalidad prevista debe ser específica
No basta con escribir “ayuda al médico”. Deben concretarse al menos:
- patología y población;
- modalidad, secuencia y requisitos de adquisición;
- usuario previsto;
- salida del sistema;
- decisión que pretende apoyar;
- condiciones y exclusiones de uso;
- grado de automatización;
- beneficio clínico alegado.
Una finalidad ambigua permite vender una imagen de versatilidad, pero impide saber qué se ha validado. Además, las afirmaciones comerciales deben estar sostenidas por evidencia clínica adecuada: no puede ampliarse el producto mediante eslóganes que excedan la finalidad evaluada.
Para recordar: el código no “es” producto sanitario por naturaleza; lo convierte en producto sanitario la finalidad médica que se le atribuye y el uso para el que se pone en servicio.
2. ¿Cómo se clasifica el software bajo el MDR?
La regla 11 traduce el daño indirecto
En muchos productos físicos el riesgo procede del contacto con el paciente o de administrar energía. En el software radiológico, el daño suele ser indirecto: información errónea conduce a una decisión errónea.
La regla 11 del anexo VIII del MDR establece, de forma simplificada:
| Información utilizada para decisiones diagnósticas o terapéuticas. |
IIa como punto de partida. |
| Una decisión errónea puede causar deterioro grave o requerir cirugía. |
IIb. |
| Una decisión errónea puede causar muerte o deterioro irreversible. |
III. |
| Monitorización de procesos fisiológicos. |
IIa; IIb si son parámetros vitales cuyas variaciones pueden producir peligro inmediato. |
| Resto del software. |
I, salvo que otra regla más estricta resulte aplicable. |
Esto explica por qué gran parte del software de decisión clínica ya no queda en clase I. Pero la clase no se determina únicamente por la gravedad de la enfermedad: hay que valorar qué peso tiene la información del software, qué decisión modifica y cuál es la consecuencia razonablemente previsible de un resultado erróneo.
Ejemplo
Un segmentador de metástasis cerebrales puede parecer técnicamente idéntico en tres usos:
- generar medidas para un artículo retrospectivo;
- ayudar a documentar cambios de volumen en el informe;
- recomendar progresión y desencadenar un cambio de tratamiento.
La significación clínica de la salida aumenta de un escenario al siguiente. No puede inferirse la clase solo por la palabra “segmentación”.
Quién clasifica y quién comprueba
El fabricante propone y justifica la clase. Para clases IIa, IIb y III interviene normalmente un organismo notificado en la evaluación de conformidad. La autoridad competente —en España, la AEMPS— mantiene funciones de vigilancia, clasificación en casos frontera y control del mercado.
La clasificación del dossier no sustituye el análisis del hospital. Antes de comprar conviene confirmar:
- finalidad exacta y clase declarada;
- versión y módulos cubiertos;
- certificado y organismo notificado;
- población, modalidad y flujo incluidos;
- limitaciones e instrucciones de uso.
Para recordar: “clase IIa” no describe cuán buena es la herramienta; describe la vía regulatoria asociada al riesgo de su finalidad prevista.
3. ¿Qué demuestra realmente el marcado CE?
El marcado CE indica que el fabricante declara la conformidad del producto con los requisitos aplicables y que ha seguido la evaluación de conformidad correspondiente. En clases que lo requieren, participa un organismo notificado.
Para un software clínico, esto implica un marco de:
- gestión de calidad y riesgos;
- documentación técnica;
- verificación y validación;
- evaluación clínica;
- usabilidad e información al usuario;
- ciberseguridad;
- vigilancia poscomercialización y gestión de incidentes.
La evaluación clínica del software debe conectar tres piezas:
- asociación clínica válida: la salida se relaciona científicamente con la condición que pretende evaluar;
- rendimiento técnico: el sistema genera con precisión y fiabilidad la salida prevista;
- rendimiento clínico: la salida es clínicamente relevante en la población y uso previstos.
Lo que el CE no demuestra por sí solo
El marcado CE no significa automáticamente que:
- el producto sea mejor que el radiólogo o que otra alternativa;
- mejore desenlaces o tiempos en tu hospital;
- su población de validación sea representativa de la local;
- el precio sea razonable;
- la integración en PACS/RIS sea segura y eficaz;
- el modelo conserve el rendimiento tras una actualización;
- cualquier uso imaginable quede cubierto.
La frase correcta es: el CE habilita el producto para su finalidad prevista dentro del marco regulatorio aplicable; la adopción local exige además evidencia, validación, integración y gobernanza.
Cinco documentos o datos que pedir
- declaración UE de conformidad;
- certificado y alcance del organismo notificado, cuando corresponda;
- instrucciones de uso y finalidad prevista completas;
- versión exacta, módulos y política de actualizaciones;
- resumen de evidencia clínica y plan de vigilancia relevante para el uso propuesto.
El hospital no tendrá necesariamente acceso a todo el expediente técnico confidencial, pero sí necesita información suficiente para decidir si el producto encaja con su población, flujo y riesgo.
Para recordar: el CE es un requisito de acceso y uso conforme al mercado europeo, no una recomendación de compra ni una validación local.
4. ¿Cómo se superponen MDR y AI Act?
Aplicación simultánea y complementaria
Si el software es a la vez producto sanitario y sistema de IA, puede estar sometido a ambas normas. El AI Act no sustituye al MDR ni cambia su clase.
Una IA de producto sanitario es de alto riesgo por la vía del artículo 6.1 del AI Act cuando se cumplen las dos condiciones explicadas en la Guía 02:
- la IA es el producto o un componente de seguridad; y
- el producto requiere evaluación de conformidad por un tercero bajo MDR o IVDR.
Por tanto, la dirección causal habitual es:
clase MDR y evaluación por tercero → posible alto riesgo AI Act
No al revés. La etiqueta “alto riesgo” del AI Act no convierte un producto IIa en III.
Un proceso integrado, no dos mundos independientes
La guía conjunta AIB 2025-1 / MDCG 2025-6 considera al fabricante MDR y al proveedor AI Act como figuras coincidentes para el producto y recomienda integrar los requisitos nuevos en los procesos ya existentes:
- gestión de riesgos;
- sistema de calidad;
- gobernanza de datos;
- documentación técnica;
- transparencia y supervisión humana;
- precisión, robustez y ciberseguridad;
- evaluación y vigilancia a lo largo del ciclo de vida.
Para los productos de alto riesgo por el artículo 6.1, la evaluación de los requisitos AI Act se incorpora a la vía de conformidad sectorial del MDR/IVDR. No se trata de añadir un sello comercial separado sin relación con el producto.
Una cautela temporal
La guía conjunta se publicó en junio de 2025 y contiene el calendario original. Tras la reforma de 2026, las obligaciones específicas de alto riesgo para productos del anexo I —incluidos los productos sanitarios cuando corresponda— se aplican con carácter general desde el 2 de agosto de 2028. La interpretación estructural de la guía sigue siendo útil, pero sus fechas deben leerse con el texto consolidado vigente.
Para recordar: MDR aporta el armazón de producto sanitario; el AI Act añade exigencias específicas sobre riesgos y funcionamiento de la IA. El fabricante debe cumplir ambos de forma coherente.
5. ¿Cuándo una modificación local cambia el papel del hospital?
Instalar un producto, conectarlo al PACS o seleccionar una opción prevista en las instrucciones no convierte automáticamente al hospital en fabricante. Pero tampoco todo cambio puede llamarse “configuración”.
Hay que detenerse si el hospital pretende:
- reentrenar o ajustar el modelo con datos propios;
- modificar umbrales fuera del rango previsto;
- aplicarlo a otra modalidad, población o enfermedad;
- combinarlo con otro algoritmo para producir una decisión nueva;
- permitir que el resultado rellene automáticamente el informe;
- añadir una recomendación diagnóstica o terapéutica;
- eliminar una supervisión prevista;
- distribuir la versión modificada a otra entidad.
El fabricante debe evaluar durante todo el ciclo de vida cómo afectan los cambios a la finalidad, seguridad, funcionamiento, cualificación y clase. El AI Act utiliza además su propio concepto de modificación sustancial. Ambos análisis están relacionados, pero no son jurídicamente idénticos.
Regla práctica
Antes de cualquier cambio local, documentar:
- qué versión certificada se recibió;
- qué cambio se propone y por qué;
- si estaba previsto por el fabricante;
- si altera entradas, salidas, población, finalidad o supervisión;
- quién validará el cambio;
- quién asumirá mantenimiento, vigilancia e incidentes;
- si el proveedor confirma por escrito que permanece dentro de la conformidad evaluada.
El “fine-tuning local” no es solo una mejora técnica. Puede crear un producto diferente, desplazar responsabilidades y exigir una nueva evaluación.
Para recordar: cuando el hospital modifica lo que el sistema hace, para quién lo hace o cómo influye en la decisión, debe volver a preguntar quién es el fabricante y el proveedor.
6. La vía in-house: útil, pero exigente
Qué permite el artículo 5.5 del MDR
Una institución sanitaria de la UE puede fabricar y utilizar internamente un producto para cubrir necesidades específicas de pacientes que no puedan satisfacerse —o no con el nivel adecuado— mediante un producto CE equivalente disponible.
Si se cumplen todas las condiciones, el producto queda exento de gran parte del MDR, pero siguen existiendo obligaciones importantes:
- fabricación y uso dentro de la misma institución sanitaria y sin transferencia a otra entidad jurídica;
- escala no industrial;
- cumplimiento de los requisitos generales de seguridad y funcionamiento aplicables;
- sistema de gestión de calidad;
- justificación documentada de la necesidad no cubierta por un equivalente CE;
- documentación de diseño, fabricación, finalidad y funcionamiento;
- declaración pública e identificación del producto;
- revisión de la experiencia clínica, trazabilidad y acciones correctivas;
- información disponible para la autoridad competente.
Un producto research use only puede permanecer en investigación. Pero si el hospital le atribuye una finalidad médica y empieza a utilizarlo para atender pacientes, no conserva mágicamente la etiqueta de investigación: debe encajar en una vía regulatoria válida.
Condiciones adicionales en España
El artículo 9 del Real Decreto 192/2023 concreta la fabricación in-house de productos sanitarios:
- solo pueden realizarla hospitales;
- deben comunicar previamente el inicio de actividad a la AEMPS;
- deben designar una persona responsable;
- no pueden fabricar por esta vía productos de clase IIb, III o implantables;
- no pueden subcontratar actividades de fabricación;
- no pueden vender, entregar ni permitir el uso por terceros.
La AEMPS dispone de un procedimiento específico de comunicación. Esta comunicación permite iniciar la actividad, pero no equivale a una autorización previa ni elimina la posible comprobación e inspección posterior.
Dos implicaciones especialmente relevantes para innovación en IA
Primera: colaborar con una empresa no es imposible, pero debe delimitarse con precisión. Si la empresa realiza actividades que jurídicamente constituyen fabricación del producto, puede entrar en conflicto con la prohibición española de subcontratación. No debe firmarse una colaboración técnica y decidir después quién era el fabricante.
Segunda: una red multicéntrica no equivale automáticamente a una única institución. Si el software se entrega o utiliza fuera de la entidad jurídica que lo fabrica, puede perderse la vía in-house. En estructuras complejas —empresa pública, hospital, fundación, instituto de investigación y servicio regional— debe identificarse quién desarrolla, quién pone en servicio y bajo qué personalidad jurídica.
La FAQ europea de 2025 considera que un producto de IA in-house correctamente acogido al artículo 5.5 no es alto riesgo por la vía del artículo 6.1 del AI Act, porque no se somete a evaluación por organismo notificado. Eso no significa ausencia de control: siguen aplicándose el régimen in-house, otras partes del AI Act y el resto del Derecho sanitario y de datos.
Para recordar: in-house sustituye una vía de conformidad por una responsabilidad institucional intensa; no convierte un prototipo en herramienta clínica por decisión del investigador.
Caso integrador: segmentación tumoral desarrollada por un hospital
Un equipo hospitalario entrena con 1.500 resonancias un modelo que segmenta glioblastomas, calcula volúmenes longitudinales y propone una categoría de respuesta. El objetivo inicial es investigación. Tras buenos resultados retrospectivos, se plantea integrarlo en el visor y mostrar sus conclusiones al radiólogo durante la lectura.
Análisis en ocho pasos
- Delimitar el cambio de fase. Mientras se analiza retrospectivamente sin influir en pacientes, es investigación. Mostrar la salida en la lectura asistencial y utilizarla en el informe constituye puesta en servicio clínico, aunque se denomine “piloto”.
- Definir la finalidad. No es solo segmentar: cuantifica evolución y propone respuesta. Deben precisarse tumor, secuencias, tratamientos, usuarios, exclusiones y peso de la salida.
- Cualificar el software. Al producir información individual para seguimiento y decisiones clínicas, previsiblemente es MDSW.
- Clasificarlo. La regla 11 orienta al menos hacia IIa; podría ser IIb si un error puede razonablemente conducir a deterioro grave o intervención. No debe cerrarse la clase sin análisis regulatorio específico.
- Elegir vía. Las opciones no son “piloto o CE”, sino investigación, producto comercial conforme o fabricación in-house cumpliendo todos sus requisitos.
- Comprobar viabilidad española del in-house. Si resultara IIb, el Real Decreto 192/2023 impediría esa vía. Si fuera IIa, todavía habría que demostrar necesidad no cubierta, sistema de calidad, documentación, responsable, comunicación a AEMPS y ausencia de subcontratación de fabricación.
- Controlar alcance jurídico. Compartir el modelo con otro hospital independiente o entregarlo a una empresa para comercializarlo rompería el supuesto de uso exclusivo interno y exigiría replantear fabricante, conformidad y contratos.
- Separar regulación y adopción. Incluso con vía regulatoria válida, habría que validar rendimiento local, interacción humano–IA, integración, versiones, incidentes, contingencia y regla de retirada.
Decisión razonable
El proyecto puede continuar como investigación, pero antes de cualquier uso asistencial necesita un hito formal de transición regulatoria. Ese hito debe decidir finalidad, clase provisional, fabricante, vía de conformidad, sistema de calidad y gobernanza clínica. No debería recaer solo en el investigador principal ni resolverse con una aprobación ética diseñada para el estudio retrospectivo.
Plantilla de diez preguntas para un proyecto hospitalario
- ¿Qué salida produce exactamente y qué decisión clínica modifica?
- ¿Cuál es la finalidad prevista escrita y quién la asume?
- ¿Es MDSW y qué regla justifica su clase?
- ¿Quién es fabricante MDR y proveedor AI Act?
- ¿Qué versión, módulos y componentes forman el producto?
- ¿Se utilizará en investigación, como producto CE o por vía in-house?
- ¿Qué evidencia demuestra asociación clínica, rendimiento técnico y rendimiento clínico?
- ¿Qué cambios locales están permitidos y quién los valida?
- ¿Cómo se monitorizarán rendimiento, versiones, incidentes y retirada?
- ¿Qué cuestión debe confirmar AEMPS, un especialista regulatorio o el servicio jurídico antes del despliegue?
Implicaciones directas para tu papel en la Comisión
- Enseñar la frontera investigación–asistencia. “Piloto” no es una categoría jurídica y el CE no es el único camino, pero tampoco puede sustituirse por una aprobación ética genérica.
- Evitar presentar el in-house como atajo. En España tiene límites especialmente relevantes: clase, entidad jurídica, comunicación y prohibición de subcontratar fabricación.
- Exigir finalidad, clase y versión en cualquier discusión de compra. “Tiene CE” es información incompleta.
- Separar evaluación regulatoria y valor asistencial. El producto puede cumplir y, aun así, no resolver el problema local.
- Preparar materiales con revisión especializada. La Comisión dispone de capacidades potenciales en regulación, metodología e ingeniería, pero un documento institucional sobre clasificación o fabricación hospitalaria debería contar además con revisión regulatoria o jurídica formal y la aprobación correspondiente.
- No comprometer a SERAM. Una futura plantilla o recomendación debe presentarse como propuesta de la Comisión hasta que Científico, Publicaciones y, cuando corresponda, la Junta determinen su validación institucional.
Una formulación segura ante un proyecto sería:
“Antes de discutir el rendimiento del modelo, necesitamos definir su finalidad clínica, quién lo pone en servicio y bajo qué vía regulatoria. Sin esas tres respuestas no sabemos qué evidencia ni qué responsabilidades estamos evaluando.”
Referencias oficiales esenciales
- Reglamento (UE) 2017/745 sobre productos sanitarios — texto consolidado a 1 de enero de 2026. Definiciones, artículo 5.5, clasificación, evaluación clínica y obligaciones de fabricantes.
- MDCG 2019-11 rev.1 — cualificación y clasificación del software, junio de 2025. Guía práctica principal sobre MDSW, regla 11, módulos y cambios.
- AIB 2025-1 / MDCG 2025-6 — interacción MDR/IVDR y AI Act. Aplicación complementaria, integración de requisitos y productos MDAI; su calendario debe actualizarse con la reforma de 2026.
- MDCG 2020-1 — evaluación clínica del software producto sanitario. Asociación clínica válida, rendimiento técnico y rendimiento clínico.
- MDCG 2023-1 — exención para productos fabricados en instituciones sanitarias. Interpretación europea del artículo 5.5 y de la entidad jurídica, el sistema de calidad y la necesidad no cubierta.
- Real Decreto 192/2023 — productos sanitarios en España. El artículo 9 desarrolla la fabricación hospitalaria para uso propio.
- AEMPS — procedimiento de comunicación de fabricación in-house. Trámite nacional vigente.
- AEMPS — requisitos de los productos sanitarios. Resumen oficial de conformidad, documentación y evaluación clínica.
- Reglamento de IA — texto consolidado a 27 de julio de 2026. Texto vigente para clasificación, roles, modificaciones y calendario.
Resumen en siete frases
- Un software entra en el MDR por su finalidad médica, no por utilizar IA ni por ejecutarse dentro de un hospital.
- La regla 11 clasifica gran parte del software clínico según la consecuencia de una decisión basada en información errónea.
- El marcado CE acredita una vía de conformidad para una finalidad y versión concretas; no demuestra superioridad, utilidad local ni coste-efectividad.
- Cuando un producto sanitario incorpora IA, MDR y AI Act se aplican de forma complementaria y deben integrarse en el mismo ciclo de calidad, riesgo y vigilancia.
- Reentrenar, ampliar la población o cambiar la finalidad puede convertir al hospital en fabricante o proveedor del sistema modificado.
- La vía in-house exige necesidad no cubierta, calidad, documentación, vigilancia y uso dentro de la misma entidad; en España añade límites de clase y prohíbe subcontratar la fabricación.
- El paso de investigación a uso asistencial debe ser una decisión formal de la institución, no una extensión informal del proyecto.
Guía ejecutiva 04
Responsabilidad, supervisión humana e incidentes con IA en radiología
Lectura estimada: 12–15 minutos
Fecha de actualización: 5 de agosto de 2026
Objetivo: comprender cómo se distribuyen los deberes entre fabricante, hospital y profesional; reconocer cuándo la supervisión humana es real; y saber qué hacer ante un fallo o un daño sin atribuir responsabilidades de forma prematura.
Uso: material personal de estudio y discusión. No constituye asesoramiento jurídico ni una posición aprobada de la SERAM.
La idea central
La frase «la decisión final es del médico» es cierta solo en un sentido limitado: el radiólogo conserva sus deberes profesionales. Pero es falsa si se utiliza para descargar sobre él toda la responsabilidad de un sistema que la organización seleccionó, compró, integró y configuró, y cuyo diseño controla el fabricante.
La responsabilidad no sigue automáticamente al último clic. Sigue, entre otros elementos:
- el control real sobre cada parte del sistema;
- el deber jurídico o profesional de actuar;
- la capacidad de prever y evitar el daño;
- la información disponible en ese momento;
- la relación causal entre cada fallo y el resultado.
Un mismo incidente puede contener simultáneamente:
- un defecto o una limitación no comunicada del producto;
- una mala selección, integración o vigilancia hospitalaria;
- una actuación profesional inadecuada;
- un fallo de comunicación o de continuidad asistencial.
La pregunta útil no es «¿quién tiene la culpa de la IA?», sino:
¿Qué ocurrió, quién controlaba cada barrera de seguridad, qué debía hacer, qué podía realmente hacer y qué contribuyó al daño?
1. Cuatro planos que no deben confundirse
| Seguridad y conformidad del producto |
¿El sistema era razonablemente seguro para su finalidad y versión? |
Fabricante MDR / proveedor AI Act. |
Rendimiento deficiente no declarado en TC con cortes gruesos; actualización que altera el comportamiento. |
| Gobernanza del despliegue |
¿Se escogió, integró, configuró y vigiló correctamente? |
Hospital o servicio de salud como responsable del despliegue. |
Usarlo en una población no validada; carecer de contingencia; no formar a los usuarios. |
| Actuación profesional |
¿El profesional actuó conforme al conocimiento, contexto y medios disponibles? |
Radiólogo y demás profesionales intervinientes. |
Aceptar una salida incompatible con las imágenes sin revisarla; omitir un hallazgo visible por exceso de confianza. |
| Compensación y litigio |
¿Quién debe indemnizar y por qué vía? |
Fabricante, organización, aseguradoras y, según el caso, profesional. |
Reclamación por producto defectuoso, responsabilidad patrimonial sanitaria o responsabilidad civil. |
Estos planos se relacionan, pero no son equivalentes. Incumplir una obligación regulatoria no demuestra por sí solo que ese incumplimiento causara el daño. Y que un producto tenga marcado CE no elimina una posible actuación profesional u organizativa inadecuada.
No hay una ley única de «responsabilidad de la IA»
En España, un caso puede involucrar normas de productos sanitarios, responsabilidad civil por producto defectuoso, responsabilidad patrimonial de la Administración, obligaciones profesionales, documentación clínica, protección de datos, contrato y, solo en supuestos extremos, responsabilidad penal.
Dos precisiones temporales son importantes:
- La propuesta europea de Directiva de responsabilidad por IA de 2022 fue retirada. No debe presentarse como norma aprobada.
- La Directiva (UE) 2024/2853 sobre productos defectuosos incorpora expresamente el software y contempla actualizaciones, falta de actualizaciones necesarias y modificaciones sustanciales. A 5 de agosto de 2026 está todavía en plazo de transposición; sus nuevas reglas se aplicarán a productos puestos en el mercado o en servicio desde el 9 de diciembre de 2026. Los casos anteriores continúan bajo el régimen previo y el Derecho nacional aplicable.
En un hospital público, además, el paciente reclama normalmente frente a la Administración correspondiente. La Ley 40/2015 prevé la acción de regreso contra el empleado cuando haya dolo o culpa o negligencia graves; no convierte cada error clínico individual en una reclamación directa contra el profesional.
Para recordar: regulación, atribución de culpa y compensación son preguntas diferentes. Un coordinador debe saber separarlas y pedir revisión jurídica para el caso concreto.
2. La supervisión humana solo existe si puede cambiar el resultado
«Human in the loop» no es una garantía por sí misma
El artículo 14 del AI Act exige que la supervisión de sistemas de alto riesgo sea efectiva y proporcional al riesgo, autonomía y contexto. La persona designada debe poder comprender capacidades y limitaciones, detectar anomalías, interpretar la salida, evitar el sesgo de automatización, ignorar o revertir el resultado e interrumpir el sistema de forma segura.
Para las IA de producto sanitario de alto riesgo, estas obligaciones específicas tendrán el calendario explicado en las guías anteriores. Pero la idea de seguridad es aplicable desde ahora: una firma humana no corrige un diseño que hace imposible supervisar.
Las cuatro condiciones de una supervisión real
| Competencia |
¿La persona conoce la tarea clínica, la finalidad, las limitaciones y los fallos previsibles del sistema? |
| Información |
¿Ve las imágenes y datos relevantes, la salida de IA, su estado y las advertencias necesarias para juzgarla? |
| Tiempo e independencia cognitiva |
¿Puede revisar de verdad o se le asigna un volumen que convierte la supervisión en una ratificación automática? |
| Autoridad y salida segura |
¿Puede ignorar la recomendación, pedir una segunda revisión, detener el sistema y continuar por un procedimiento alternativo? |
Si falta una de ellas, la supervisión puede ser nominal.
Tres ejemplos
- Segundo lector visible después de la lectura inicial. Favorece una opinión clínica independiente antes de mostrar la IA, aunque puede aumentar el tiempo.
- Resultado visible desde el primer segundo. Puede mejorar eficiencia, pero condiciona la búsqueda y aumenta el riesgo de anclaje y errores de omisión.
- Priorización invisible de la lista. El radiólogo quizá no ve ningún resultado, pero la IA ya ha modificado qué paciente será informado antes. La supervisión no puede limitarse a revisar el informe final: debe incluir el funcionamiento de la cola y los estudios que el algoritmo deja abajo.
La supervisión debe diseñarse para la función real. No es lo mismo verificar una segmentación, reconsiderar una sospecha diagnóstica, aprobar un informe generado o vigilar una lista de trabajo con cientos de estudios.
Para recordar: supervisar no significa «estar presente»; significa disponer de competencia, información, tiempo y autoridad para detectar y corregir el error.
3. ¿Qué debe hacer el radiólogo cuando la IA discrepa?
Ni obediencia ni rechazo automáticos
La Ley 44/2003 exige una atención técnica y profesional adecuada al estado del conocimiento y a los niveles de calidad y seguridad aplicables. Esto no crea una regla de «seguir siempre la IA» ni de «el médico sabe más».
Ante una discrepancia material, el razonamiento práctico es:
- Comprobar que el caso entra en la finalidad prevista: población, modalidad, protocolo, calidad y exclusiones.
- Revisar el dato primario: imágenes, antecedentes y comparación, no solo el marcador o la puntuación.
- Buscar causas conocidas de fallo: artefactos, posoperatorio, contraste, anatomía alterada, lesión fuera del campo o entrada incompleta.
- Valorar las consecuencias de equivocarse: no exige la misma cautela una medición ligeramente distinta que descartar una hemorragia.
- Escalar cuando sea necesario: segunda lectura, consulta clínica, secuencia adicional o procedimiento de contingencia.
- Decidir y comunicar con claridad: la salida de IA es información auxiliar; el informe debe expresar la conclusión clínica y la incertidumbre relevante.
Qué conviene documentar
No es necesario convertir cada informe en una auditoría del algoritmo ni escribir «la IA dijo X» en todos los casos. La documentación debe ser proporcional y útil.
Conviene dejar trazabilidad cuando:
- una discrepancia relevante cambia diagnóstico, priorización o conducta;
- el caso parece estar fuera de la finalidad prevista;
- se detecta un funcionamiento anómalo repetido;
- se activa una segunda revisión o una contingencia;
- puede existir un incidente de producto o de seguridad del paciente.
La historia clínica debe contener la información asistencial trascendente. Los detalles técnicos para investigar el sistema —versión, identificador del estudio, hora, entrada, salida, registros y configuración— pueden pertenecer además al registro de incidentes, al sistema de calidad o a los logs técnicos. Deben poder relacionarse sin volcar información innecesaria en el informe clínico.
Una discrepancia aislada puede ser un error clínico esperado dentro de las limitaciones conocidas. Un patrón de fallos, una salida imposible, una degradación tras actualización o un fallo con daño potencial requieren una vía distinta.
Para recordar: documentar no es practicar medicina defensiva; es conservar la información necesaria para atender al paciente y reconstruir un evento material.
4. Los fallos más peligrosos aparecen en la interacción
El sistema no es solo el algoritmo
El rendimiento publicado suele medir la salida del modelo. La seguridad asistencial depende del conjunto:
paciente → adquisición → transferencia → modelo → interfaz → profesional → informe → comunicación → acción clínica
Un fallo en cualquiera de esos pasos puede producir daño aunque la sensibilidad del algoritmo permanezca idéntica.
Patrones frecuentes
1. Sesgo de automatización
El profesional da un peso excesivo a la salida automática. Puede producir:
- error de omisión: la IA no señala una lesión y el lector reduce su búsqueda;
- error de comisión: la IA marca una falsa lesión y el lector la acepta.
En un experimento prospectivo con 27 radiólogos y mamografías, las sugerencias BI-RADS incorrectas de una supuesta IA redujeron el porcentaje de clasificaciones correctas en lectores de todos los niveles de experiencia. La experiencia protegió parcialmente, pero no eliminó el efecto.
2. Anclaje y cambio de estrategia visual
Incluso cuando el radiólogo rechaza el marcador, este puede haber dirigido su atención a una zona y restado búsqueda al resto del estudio. Comparar «radiólogo solo» con «radiólogo más IA» exige estudiar la interacción, no sumar sensibilidades.
3. Fatiga de alertas
Si la herramienta produce demasiados falsos positivos, los avisos pierden significado. Aumentar el número de alarmas puede disminuir la seguridad si las alertas importantes dejan de distinguirse.
4. Sobreconfianza y deskilling
La repetición de una tarea parcialmente automatizada puede reducir la práctica de la habilidad que después se necesita para detectar el fallo o trabajar durante una caída del sistema.
5. Error silencioso de integración
El algoritmo funciona, pero no recibe todos los estudios; procesa una serie equivocada; muestra un resultado antiguo; falla la asociación paciente–estudio; o la prioridad no llega a la lista correcta. Estos errores pueden no aparecer en las métricas del modelo.
6. Cambio de distribución o de versión
Un nuevo escáner, protocolo, contraste, población o actualización puede modificar el rendimiento. La degradación puede ser global o concentrarse en un subgrupo pequeño y clínicamente importante.
Para recordar: la supervisión más valiosa busca los fallos que el profesional puede detectar; la monitorización organizativa debe cubrir los que no puede ver desde su estación.
5. Qué hacer ante un incidente
Primero proteger; después explicar
Una respuesta segura separa la asistencia inmediata de la investigación causal.
Secuencia operativa
- Proteger al paciente. Confirmar el hallazgo, corregir el informe si procede, contactar con el equipo asistencial y revisar si hay otros pacientes en riesgo inmediato.
- Contener el sistema. Limitar o suspender la función afectada si continuar puede causar daño. Activar el flujo alternativo previsto.
- Preservar evidencia. Conservar versión, configuración, entradas y salidas, logs, tiempos, capturas necesarias y comunicaciones. No reentrenar, actualizar o sobrescribir antes de preservar el estado relevante.
- Notificar internamente. Seguridad del paciente, responsable clínico, tecnología, calidad, protección de datos o ciberseguridad según el evento; y el responsable de vigilancia de productos sanitarios cuando corresponda.
- Activar la vigilancia regulatoria. En España, el artículo 35 del Real Decreto 192/2023 obliga a los profesionales sanitarios que conozcan un incidente grave con un producto sanitario a notificarlo a la AEMPS. Los hospitales deben tener un responsable de vigilancia y el portal previsto es NotificaPS.
- Informar al fabricante y coordinar. La notificación al centro o al proveedor no sustituye necesariamente la comunicación a la autoridad. El fabricante debe investigar y cumplir sus propias obligaciones MDR.
- Analizar el sistema completo. Reconstruir cronología, condiciones, barreras fallidas y factores contribuyentes. Evitar cerrar la investigación con «error humano» o «falló la IA».
- Corregir y verificar. Puede requerir cambiar protocolo, interfaz, umbral, formación, contrato, monitorización o producto. La reactivación debe tener criterios definidos y evidencia de que la barrera funciona.
- Aprender y comunicar. Compartir la lección con quienes puedan prevenir recurrencias, preservando confidencialidad y sin afirmar causalidad o responsabilidad legal antes de que se establezcan.
¿Qué es un incidente grave de producto sanitario?
El MDR considera grave el incidente que directa o indirectamente produjo, pudo haber producido o podría producir la muerte, un deterioro grave temporal o permanente de la salud, o una amenaza grave para la salud pública. No hace falta esperar a que haya daño consumado.
Además pueden coexistir otros circuitos:
- evento de seguridad del paciente o near miss;
- brecha de datos personales;
- incidente de ciberseguridad;
- incumplimiento contractual;
- incidente grave bajo el AI Act cuando su régimen resulte aplicable al sistema.
Las categorías no deben fusionarse. Una misma situación puede requerir varias comunicaciones con criterios y plazos diferentes.
Para recordar: notificar un incidente no equivale a admitir culpa; permite proteger a otros pacientes e iniciar la investigación correcta.
Caso integrador: una hemorragia que no sube en la lista
Un hospital implanta una IA con marcado CE para priorizar TC craneales con sospecha de hemorragia. Un estudio urgente con una pequeña hemorragia subaracnoidea recibe resultado negativo y permanece abajo en la lista durante 70 minutos. El radiólogo acaba detectándola, pero el tratamiento se retrasa. Se comprueba después que el protocolo utilizado tenía reconstrucciones más gruesas que las recomendadas. El sistema llevaba tres semanas mostrando más falsos negativos, pero el hospital solo monitorizaba el tiempo medio global de informe.
Análisis sin atribución prematura
1. Delimitar la función real
La IA no «diagnosticaba» formalmente, pero sí alteraba el orden de atención. Su salida negativa tuvo efecto clínico antes de que el radiólogo abriese el estudio.
2. Proteger al paciente y buscar alcance
Corregir la atención del caso no basta. Hay que identificar qué otros estudios se procesaron con el mismo protocolo y podrían haber quedado indebidamente relegados.
3. Preservar el estado
Versión del modelo, instrucciones, series enviadas, parámetros de reconstrucción, reglas de integración, salida, tiempos de cola y cambios recientes.
4. Examinar cada barrera
| Producto |
¿Las limitaciones por grosor estaban claras? ¿El sistema debía rechazar o advertir una entrada no compatible? |
| Integración |
¿Quién mapeó las series y comprobó la compatibilidad del protocolo antes del despliegue? |
| Operación |
¿Existía una prioridad clínica independiente para evitar que un negativo de IA retrasara casos urgentes? |
| Monitorización |
¿Por qué no se vigilaban falsos negativos, fallos por protocolo y estudios no procesados? |
| Profesional |
¿El radiólogo conocía que el orden dependía de IA y disponía de otro criterio para detectar urgencias? |
5. No aceptar respuestas simplistas
- «El radiólogo debía revisarlo» ignora que la IA decidió cuándo llegaría a revisarlo.
- «Falló el algoritmo» ignora la posible entrada fuera de especificación y la ausencia de monitorización.
- «Tenía marcado CE» no demuestra que el despliegue local fuera correcto.
- «No hubo muerte» no excluye un incidente grave o potencialmente grave.
Decisión prudente
Suspender temporalmente la priorización automática afectada, mantener lectura clínica por un flujo alternativo, revisar casos potencialmente expuestos, notificar por los circuitos correspondientes y reactivar solo después de corregir compatibilidad, alarmas y monitorización.
Plantilla de diez preguntas ante un fallo
- ¿Qué daño ocurrió o pudo haber ocurrido?
- ¿Qué función cumplía realmente la IA en el flujo, aunque comercialmente se llamara «asistencia»?
- ¿Qué versión, configuración, entrada y salida estuvieron implicadas?
- ¿El uso estaba dentro de la finalidad e instrucciones previstas?
- ¿Qué personas y organizaciones controlaban cada barrera?
- ¿La supervisión humana tenía competencia, información, tiempo y autoridad?
- ¿Hay otros pacientes o estudios expuestos al mismo patrón?
- ¿Debe suspenderse el sistema o una función concreta?
- ¿Qué circuitos internos, AEMPS, fabricante, datos o ciberseguridad deben activarse?
- ¿Qué evidencia falta antes de hablar de causa o responsabilidad?
Implicaciones directas para tu papel en la Comisión
- Corregir el mensaje «el médico siempre responde». El profesional conserva deberes, pero la organización y el fabricante no pueden convertir una supervisión imposible en una firma humana defensiva.
- Promover supervisión por diseño. Formación, interfaz, tiempo, autoridad, contingencia y monitorización deben definirse antes del despliegue.
- Enseñar a reconocer incidentes. Muchos radiólogos no relacionarán un falso negativo, una prioridad incorrecta o un estudio no procesado con la vigilancia de productos sanitarios.
- Evitar protocolos puramente punitivos. Si se teme sanción personal, se notificará menos y se perderán señales tempranas. La cultura debe proteger al paciente y aprender, sin impedir la rendición de cuentas cuando corresponda.
- Separar orientación general y asesoramiento jurídico. SERAM puede proponer principios, listas de comprobación y formación. La atribución de responsabilidad en un caso concreto corresponde a los procedimientos legales e institucionales competentes.
- Pedir revisión multidisciplinar. Un futuro documento institucional debería integrar radiología, seguridad del paciente, ingeniería, AEMPS/producto sanitario, derecho sanitario, protección de datos y representación de pacientes.
Una formulación útil ante la Junta o un proveedor sería:
«La supervisión humana no puede utilizarse como transferencia automática de responsabilidad. Debemos demostrar que el profesional conoce las limitaciones, puede detectar el fallo y tiene tiempo y autoridad para actuar; el resto requiere barreras técnicas y organizativas.»
Referencias esenciales
- Reglamento de IA — texto consolidado a 27 de julio de 2026. Artículos 14, 26 y 73: supervisión humana, obligaciones del responsable del despliegue e incidentes graves.
- Reglamento (UE) 2017/745 sobre productos sanitarios — texto consolidado. Definición de incidente grave y artículos 83–92 sobre vigilancia poscomercialización.
- Real Decreto 192/2023, de productos sanitarios. El artículo 35 regula la notificación española y el responsable de vigilancia del centro.
- AEMPS — sistema de vigilancia y funciones del responsable de los centros. Procedimiento operativo y NotificaPS.
- Directiva (UE) 2024/2853 sobre responsabilidad por productos defectuosos. Software, actualizaciones, modificaciones sustanciales, carga de la prueba y calendario de aplicación.
- Procedimiento 2022/0303/COD en EUR-Lex. Confirma que la propuesta de Directiva de responsabilidad por IA fue retirada.
- Ley 44/2003, de ordenación de las profesiones sanitarias. Artículo 5: atención adecuada al conocimiento científico y a los niveles de calidad y seguridad.
- Ley 41/2002, de autonomía del paciente y documentación clínica. Deberes de información y documentación e historia clínica.
- Ley 40/2015, de Régimen Jurídico del Sector Público. Artículos 32–36: responsabilidad patrimonial y acción frente al personal.
- Dratsch et al. Automation Bias in Mammography, Radiology, 2023. Experimento prospectivo sobre el efecto de recomendaciones incorrectas de IA en lectores con distinta experiencia.
- FUTURE-AI: international consensus guideline for trustworthy and deployable AI in healthcare, BMJ, 2025. Marco de despliegue, monitorización, explicabilidad, factores humanos y seguridad.
Resumen en siete frases
- La decisión final del radiólogo mantiene sus deberes profesionales, pero no absorbe los deberes del fabricante ni del hospital.
- La responsabilidad depende del control, el deber, la previsibilidad y la contribución causal de cada actor; puede ser compartida.
- La supervisión humana solo es efectiva si existe competencia, información, tiempo, independencia y autoridad para corregir o detener.
- Seguir o rechazar la IA no es automáticamente correcto: la actuación debe justificarse por las imágenes, el contexto, la finalidad prevista y el riesgo.
- Los fallos más peligrosos suelen surgir en la interacción, la integración o el flujo, no únicamente en la métrica del modelo.
- Ante un incidente, primero se protege al paciente y se contiene el riesgo; después se preserva evidencia, se notifica y se investiga sin atribución prematura.
- SERAM puede promover principios y procedimientos seguros, pero no debe convertirlos en dictámenes sobre responsabilidad individual ni posiciones oficiales sin revisión y aprobación.
Guía ejecutiva 05
IA generativa en radiología: usos razonables, límites y despliegue seguro
Lectura estimada: 12–15 minutos
Fecha de actualización: 5 de agosto de 2026
Objetivo: distinguir qué usos de IA generativa aportan valor hoy, qué riesgos son específicos de estos sistemas y qué condiciones mínimas deben exigirse antes de utilizarlos con información clínica o integrarlos en un flujo radiológico.
Uso: material personal de estudio y discusión. No constituye asesoramiento jurídico ni una posición aprobada de la SERAM.
La idea central
La IA generativa puede ahorrar trabajo real en radiología, especialmente cuando transforma información que ya existe: resumir, estructurar, traducir, adaptar un texto al paciente o preparar un borrador que después revisa un profesional.
El riesgo aumenta cuando pasa de transformar a añadir contenido clínico, de redactar a interpretar imágenes, y de proponer a ejecutar acciones. En esos niveles, una respuesta fluida puede ocultar una omisión, una invención o una decisión no justificada.
La regla práctica no debe ser «permitir o prohibir ChatGPT». Debe ser:
Autorizar un caso de uso definido, con unos datos concretos, en un entorno determinado, para una función limitada, con validación, supervisión y trazabilidad proporcionales a sus consecuencias.
1. No toda IA generativa es el mismo sistema
Modelo, producto y caso de uso
Un gran modelo de lenguaje genera una continuación probable a partir del contexto recibido. Puede producir una explicación excelente sin disponer de una representación estable de la verdad y sin saber cuándo carece de información. Su facilidad para conversar no demuestra razonamiento clínico ni fiabilidad.
Además, el modelo general es solo una pieza. El resultado depende de:
- la versión del modelo;
- el prompt y las instrucciones del sistema;
- los documentos o imágenes introducidos;
- la información recuperada por un sistema RAG;
- las herramientas externas a las que pueda acceder;
- la memoria y el historial de la conversación;
- los filtros, umbrales y reglas posteriores;
- la interfaz y la persona que revisa o ejecuta la salida.
Por eso, dos aplicaciones basadas en el mismo modelo pueden tener riesgos radicalmente distintos.
Cinco niveles prácticos
| 1. Transformación no clínica |
Redactar un correo, resumir un artículo público o preparar material docente. |
Confidencialidad, errores y falsas referencias. |
| 2. Transformación de texto clínico |
Estructurar un informe ya redactado o generar una versión comprensible para el paciente. |
Omitir, alterar o añadir significado clínico. |
| 3. Borrador clínico |
Generar una impresión a partir de hallazgos dictados, mediciones y antecedentes. |
Introducir diagnósticos o recomendaciones no sustentados. |
| 4. Interpretación multimodal |
Producir un informe directamente desde imágenes y contexto clínico. |
Error diagnóstico difícil de detectar detrás de un texto plausible. |
| 5. Agente con capacidad de actuar |
Consultar la historia, redactar el informe, solicitar una prueba y comunicar un resultado. |
Acciones erróneas, acceso excesivo, ataques y pérdida de control humano. |
El paso decisivo no es que el modelo sea «más potente». Es que la salida tenga más influencia clínica, menos verificabilidad o mayor autonomía.
Para recordar: evalúa el sistema que opera y la decisión que modifica; no el nombre del modelo que contiene.
2. Qué usos son razonables hoy
Con información pública o en un entorno institucional autorizado, los usos más maduros suelen ser:
- preparar esquemas, materiales docentes y primeros borradores;
- resumir literatura aportada por el usuario, comprobando después el original;
- transformar un texto sin cambiar su contenido: estilo, estructura o traducción;
- extraer campos de informes para tareas administrativas o de investigación;
- redactar código o consultas, siempre con revisión y prueba;
- construir un asistente interno que responda desde procedimientos aprobados y muestre la fuente utilizada.
Son tareas de menor riesgo porque el usuario puede comparar con facilidad la salida con una fuente identificable y porque el error no tiene por qué alcanzar directamente al paciente.
Convertir un informe en lenguaje comprensible, generar una impresión o estructurar hallazgos parece una tarea editorial. Sin embargo, cambiar «no se identifica progresión» por «el tumor está estable», omitir una limitación técnica o añadir una recomendación de seguimiento modifica el mensaje clínico.
Por tanto, una herramienta de transformación clínica debe evaluarse al menos en:
- preservación de todos los hallazgos relevantes;
- ausencia de información nueva no sustentada;
- tratamiento correcto de negaciones, incertidumbre y comparaciones;
- coherencia entre hallazgos e impresión;
- comportamiento en casos urgentes, raros y ambiguos;
- adecuación del lenguaje al destinatario y al idioma.
En un estudio prospectivo de un sistema sanitario académico, el uso de borradores generados para radiografías se asoció con una reducción del tiempo de documentación del 15,5% en 11.980 interpretaciones asistidas. La revisión de 800 casos no encontró diferencias en precisión clínica ni calidad textual de los informes finales. Es una demostración importante de valor real en un flujo clínico, no solo en un banco de pruebas.
Pero no demuestra que la generación autónoma de informes esté resuelta:
- fue un modelo, una organización y un flujo concretos;
- los radiólogos verificaban y editaban los borradores;
- la comparación de eficiencia no fue un ensayo aleatorizado;
- la evidencia más madura sigue concentrada en radiografía simple;
- un buen promedio puede ocultar fallos graves en subgrupos pequeños.
La interpretación prudente es que la colaboración radiólogo–modelo puede aportar eficiencia, no que el informe radiológico pueda automatizarse de forma general.
Para recordar: una demostración prospectiva específica justifica explorar un caso de uso; no autoriza extrapolar a otras modalidades, centros, versiones o grados de autonomía.
3. Por qué una respuesta convincente puede ser incorrecta
El error generativo no siempre parece un error
En un algoritmo tradicional, una salida incorrecta puede ser una etiqueta o una segmentación evidentemente extraña. En un modelo generativo, el mismo fallo puede aparecer dentro de un texto coherente, detallado y seguro de sí mismo.
Los patrones principales son:
1. Invención
El modelo añade un hallazgo, antecedente, cita, explicación o recomendación no apoyados por la entrada. Llamarlo «alucinación» no debe hacer que parezca un fenómeno misterioso: es contenido no fundamentado.
2. Omisión
Puede resumir correctamente la mayor parte del caso y eliminar justo una limitación, un hallazgo incidental o una frase de incertidumbre que cambia la conducta. La fluidez del resto reduce la probabilidad de que el revisor lo detecte.
3. Inestabilidad
Entradas equivalentes, cambios menores de redacción o ejecuciones repetidas pueden producir respuestas diferentes. La reproducibilidad debe medirse; no puede suponerse.
4. Dependencia del contexto
El modelo puede priorizar información reciente, ignorar partes de documentos extensos, mezclar pacientes o conservar elementos de la conversación previa si el sistema no aísla adecuadamente cada caso.
5. Automatización del sesgo
Puede reproducir asociaciones presentes en los datos, ofrecer recomendaciones distintas según características demográficas o funcionar peor en idiomas y estilos documentales poco representados.
6. Sobreconfianza humana
Un borrador bien escrito acelera la revisión, pero también induce una lectura más superficial. El ahorro de tiempo puede provenir parcialmente de verificar menos, justo lo contrario de lo que exige un sistema todavía falible.
RAG ayuda, pero no garantiza la verdad
La generación aumentada por recuperación, o RAG, busca fragmentos en una base documental y se los aporta al modelo antes de responder. Es útil para actualizar conocimiento, limitar el dominio y mostrar fuentes.
En un estudio con 100 consultas simuladas sobre contraste yodado, añadir RAG a un modelo local redujo las alucinaciones observadas del 8% al 0% en esas condiciones. Es una señal prometedora, pero no una garantía universal: el estudio usó casos sintéticos, la recuperación puede seleccionar un fragmento equivocado y el modelo todavía puede interpretar mal una fuente correcta.
Para evaluar un RAG hay que separar:
- recuperación: ¿encontró el documento y fragmento adecuados?;
- generación: ¿respondió fielmente a lo recuperado?;
- vigencia: ¿la fuente era la versión aprobada y actual?;
- cobertura: ¿qué hace cuando la respuesta no está en el repositorio?;
- citación: ¿la fuente mostrada respalda realmente la frase concreta?
Para recordar: un RAG puede reducir la invención y mejorar la trazabilidad; no convierte un modelo generativo en una base de datos determinista.
4. Los datos clínicos cambian por completo el problema
La pregunta no es «¿se entrena con mis datos?»
Que un proveedor prometa no utilizar los prompts para entrenar futuros modelos es relevante, pero insuficiente. Antes de introducir datos sanitarios hay que reconstruir todo el flujo:
- qué datos se envían y con qué base jurídica;
- quién actúa como responsable y encargado del tratamiento;
- dónde se procesan y almacenan;
- qué subencargados intervienen y si hay transferencias internacionales;
- cuánto tiempo se conservan conversaciones, archivos, logs y copias;
- quién puede revisarlos manualmente;
- si el contenido alimenta entrenamiento, evaluación o mejora del servicio;
- qué memoria mantiene el sistema entre casos y usuarios;
- qué controles de acceso, borrado, auditoría e incidentes existen;
- qué ocurre al finalizar el contrato.
La política interna de IA generativa de la AEPD ofrece un modelo organizativo útil: inventario de sistemas y casos de uso, análisis previo, minimización, entornos autorizados, validación documentada, control de versiones y procedimientos de incidentes. También recomienda impedir la inclusión accidental de datos personales o confidenciales en prompts y archivos.
«Local» y «anonimizado» tampoco son sellos automáticos
- Un modelo local reduce la exposición a terceros, pero puede tener permisos excesivos, registros inseguros, vulnerabilidades o un mantenimiento deficiente.
- Eliminar nombre y número de historia no garantiza anonimización. Informes, metadatos DICOM, texto incrustado e información clínica rara pueden permitir reidentificación.
- Un contrato empresarial mejora el control, pero no sustituye el análisis del tratamiento ni la autorización institucional.
- Un dato de investigación desidentificado puede seguir sujeto a las condiciones del consentimiento, del protocolo o del repositorio de origen.
| Servicio público o cuenta personal no autorizada |
Solo información pública, ficticia o verdaderamente no confidencial. No introducir casos clínicos, imágenes, informes identificables ni documentación interna sensible. |
| Entorno institucional autorizado |
Utilizar únicamente los casos de uso aprobados, con los datos mínimos y dentro de las condiciones técnicas y contractuales definidas. |
| Producto clínico integrado |
Tratarlo como parte del flujo asistencial: finalidad, conformidad, validación local, formación, monitorización, trazabilidad y contingencia. |
Para recordar: la seguridad no depende de la marca ni de que el modelo sea abierto, local o empresarial; depende de la arquitectura completa y de su gobernanza.
5. Cómo validar un caso de uso generativo
La unidad de validación debe quedar congelada
No basta con escribir «se evaluó el modelo X». Deben registrarse:
- proveedor, modelo y versión;
- fecha y vía de acceso;
- prompt de sistema y plantilla de usuario;
- parámetros relevantes;
- fuentes y versión del repositorio RAG;
- herramientas externas y permisos;
- reglas de posprocesado;
- interfaz y modo de presentación;
- población, modalidad, idioma y usuario previstos.
Si uno de estos componentes cambia, hay que decidir si requiere comprobación limitada o revalidación completa.
Las métricas deben seguir al riesgo
Una comparación de parecido textual —BLEU, ROUGE u otra— no mide adecuadamente seguridad clínica. Dos informes pueden usar palabras diferentes y ser clínicamente equivalentes; también pueden parecerse mucho y discrepar en una negación crítica.
Según el caso de uso, interesa medir:
| Fidelidad |
¿Cada afirmación está respaldada por la entrada o una fuente identificada? |
| Completitud |
¿Conserva hallazgos, negaciones, incertidumbre y limitaciones relevantes? |
| Seguridad clínica |
¿Qué errores podrían cambiar diagnóstico, prioridad, seguimiento o tratamiento? |
| Consistencia |
¿Repite la respuesta ante entradas equivalentes y funciona en casos límite? |
| Interacción humana |
¿El borrador mejora al radiólogo o induce omisiones y aceptación automática? |
| Equidad e idioma |
¿Mantiene el rendimiento por población, idioma y nivel de alfabetización? |
| Eficiencia real |
¿Reduce tiempo total incluyendo revisión y corrección? |
| Operación |
¿Cuál es la latencia, disponibilidad, coste y comportamiento ante caída? |
La prueba debe incluir casos consecutivos y casos de estrés: urgentes, raros, posoperatorios, con múltiples comparaciones, mala calidad, contradicciones y entradas incompletas. Hay que revisar tanto el promedio como los peores errores.
La supervisión debe diseñarse, no invocarse
Para un borrador de informe, una opción prudente es que el radiólogo conserve acceso directo a imágenes y antecedentes, vea claramente qué parte es generada, pueda editarla o descartarla y responda del informe final. Pero eso solo funciona si dispone de tiempo y si la interfaz no favorece una aceptación automática.
Un despliegue inicial razonable puede incluir:
- evaluación retrospectiva;
- funcionamiento silencioso sin mostrar la salida;
- piloto limitado con usuarios formados;
- registro de edición, omisiones graves y tiempo total;
- criterios explícitos de suspensión;
- ampliación progresiva solo si se mantiene el beneficio.
Para recordar: validar la salida aislada no basta; hay que demostrar que el conjunto profesional–IA es al menos tan seguro y útil como el flujo que sustituye.
6. Los agentes son un cambio de categoría
De responder a actuar
Un asistente genera una propuesta. Un agente puede planificar pasos, consultar sistemas, llamar herramientas, guardar memoria y ejecutar acciones. Podría, por ejemplo, recuperar antecedentes, comparar informes, rellenar un borrador, solicitar una prueba y enviar una comunicación.
Cada conexión añade capacidad y también una nueva vía de fallo. La AEPD identifica riesgos específicos como acceso excesivo, memoria no controlada e inyección indirecta de instrucciones: un texto malicioso oculto en un documento consultado puede inducir al agente a ignorar reglas o divulgar información.
Controles mínimos
- permisos mínimos por función y por caso;
- separación entre pacientes, usuarios y tratamientos;
- lista cerrada de herramientas y destinos;
- confirmación humana antes de acciones clínicas o comunicaciones;
- límites de gasto, volumen, tiempo y número de pasos;
- registro de entradas, fuentes, llamadas y acciones;
- filtrado de contenido recuperado y pruebas de ataques;
- procedimiento de parada y operación manual;
- prohibición de aprender o conservar memoria no autorizada;
- responsable humano y organizativo claramente identificados.
Decir que «el agente tiene un humano en el circuito» no es suficiente si ese humano solo recibe una acción ya ejecutada o una secuencia imposible de reconstruir.
Para recordar: al dar herramientas a un modelo, el riesgo deja de limitarse a que diga algo incorrecto; puede hacer algo incorrecto.
Caso integrador: el borrador que añade una recomendación
Un hospital prueba un asistente que recibe la indicación, el informe previo y los hallazgos dictados por el radiólogo. Genera automáticamente la impresión y una versión para el paciente. En una TC oncológica, los hallazgos describen estabilidad y una imagen hepática probablemente quística ya conocida. El borrador añade: «Se recomienda RM hepática en seis semanas para descartar progresión». El radiólogo, en una guardia con alta carga, firma el informe tras una revisión rápida. La recomendación genera ansiedad, una prueba adicional y retraso en la decisión oncológica.
Qué ha fallado
No basta con concluir «el modelo alucinó» o «el médico debía leerlo».
- Finalidad mal delimitada. ¿Debía el sistema resumir o también formular recomendaciones?
- Fidelidad insuficiente. La recomendación no estaba sustentada por los hallazgos ni por una guía recuperada.
- Interfaz peligrosa. El texto generado podía confundirse con el dictado original y favorecía aceptación automática.
- Validación incompleta. Quizá se midió estilo y tiempo, pero no adiciones clínicas no fundamentadas.
- Supervisión nominal. La carga de trabajo hacía improbable una revisión palabra por palabra.
- Daño del sistema completo. La salida afectó al paciente y al flujo aunque el diagnóstico principal fuese correcto.
Rediseño prudente
- limitar inicialmente el sistema a reordenar el contenido aportado;
- impedir recomendaciones nuevas o exigir una fuente institucional visible;
- diferenciar de forma clara texto original y generado;
- resaltar cualquier frase sin correspondencia con la entrada;
- medir tasa de adiciones, omisiones y correcciones clínicamente relevantes;
- exigir confirmación específica para recomendaciones de seguimiento;
- monitorizar pruebas inducidas, discrepancias y tiempo real de revisión.
El objetivo no es hacer un prompt más elegante. Es reducir la libertad del sistema allí donde una frase puede activar una conducta clínica.
Semáforo ejecutivo para decidir
| Redactar o resumir material público sin datos personales |
Verde: uso razonable con verificación de hechos y fuentes. |
| Transformar documentación interna en un entorno autorizado |
Ámbar: caso de uso aprobado, minimización, revisión y trazabilidad. |
| Introducir información clínica en una herramienta pública o personal |
Rojo: no hacerlo. |
| Generar borradores clínicos dentro del sistema asistencial |
Ámbar intenso: producto y flujo evaluados, piloto, supervisión y monitorización. |
| Generar informes directamente desde imágenes |
Ámbar intenso: evidencia específica por modalidad, población y versión; no extrapolar. |
| Enviar informes, pedir pruebas o modificar prioridades automáticamente |
Rojo salvo gobernanza reforzada: autonomía, permisos, confirmación, auditoría y contingencia deben resolverse antes. |
Diez preguntas ante cualquier propuesta
- ¿Qué tarea exacta realiza: transforma, añade, interpreta o actúa?
- ¿Qué datos recibe y a dónde viajan?
- ¿Qué versión, prompt, fuentes, memoria y herramientas componen el sistema?
- ¿Qué afirmaciones puede producir que no estén sustentadas por la entrada?
- ¿Qué error sería difícil de detectar y qué consecuencia tendría?
- ¿Qué evidencia existe en el mismo flujo, modalidad, población e idioma?
- ¿Cómo se medirá fidelidad, omisiones, adiciones, consistencia e interacción humana?
- ¿Quién puede modificar, actualizar, suspender o retirar el sistema?
- ¿Qué ve y puede hacer realmente el supervisor humano?
- ¿Cuál es el beneficio demostrable frente al flujo actual, incluyendo el coste de revisión y corrección?
Qué deberías poder explicar como coordinador
En una conversación institucional, tu posición de partida puede resumirse así:
La IA generativa ya puede aportar eficiencia en tareas de documentación, acceso al conocimiento y comunicación. Su riesgo no deriva solo de que pueda «alucinar», sino de que produce lenguaje convincente, cambia con múltiples componentes y puede integrarse con datos y acciones sensibles. SERAM debería promover experimentación útil, pero basada en casos de uso concretos, entornos autorizados, evaluación clínica, supervisión efectiva y vigilancia; no en permisos genéricos para una marca o un modelo.
Tres matices regulatorios evitan afirmaciones simplistas:
- Un modelo de propósito general no es automáticamente un producto sanitario; una aplicación con finalidad médica puede serlo según su función e intención de uso.
- Las obligaciones del proveedor del modelo de propósito general no sustituyen las del fabricante de la aplicación, el hospital que la despliega ni el profesional que la utiliza.
- El artículo 50 del AI Act establece obligaciones de transparencia para determinadas interacciones y contenidos generados, aplicables desde el 2 de agosto de 2026, pero no debe interpretarse como una etiqueta universal obligatoria en todo borrador interno. La trazabilidad institucional puede y debe ser más amplia que la etiqueta visible al destinatario.
Fuentes esenciales
Institucionales y regulatorias
- Organización Mundial de la Salud. Ethics and governance of artificial intelligence for health: Guidance on large multi-modal models.
- NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1.
- Agencia Española de Protección de Datos. Política general para el uso de IA generativa en procesos administrativos de la AEPD.
- Agencia Española de Protección de Datos. Orientaciones sobre inteligencia artificial agéntica.
- Comisión Europea. The General-Purpose AI Code of Practice.
- Comisión Europea. Guidelines on transparency obligations for AI-generated content.
- Unión Europea. Reglamento (UE) 2024/1689 de Inteligencia Artificial, texto consolidado.
Evidencia y práctica radiológica
- Bluethgen C, et al. Best Practices for the Safe Use of Large Language Models and Other Generative AI in Radiology. Radiology. 2025.
- Huang J, et al. Efficiency and Quality of Generative AI–Assisted Radiograph Reporting. JAMA Network Open. 2025.
- Tanno R, et al. Collaboration between clinicians and vision–language models in radiology report generation. Nature Medicine. 2025.
- Wada A, et al. Retrieval-augmented generation elevates local LLM quality in radiology contrast media consultation. npj Digital Medicine. 2025.
Conclusión en una frase
La IA generativa es más útil cuando reduce trabajo sin adquirir autoridad clínica invisible; cuanto más añade, interpreta o actúa, más debe limitarse, validarse y vigilarse el sistema completo.
Guía ejecutiva 06
Datos sanitarios, RGPD, EHDS y uso secundario para IA radiológica
Lectura estimada: 12–15 minutos
Fecha de actualización: 5 de agosto de 2026
Objetivo: decidir qué vía de gobernanza necesita un proyecto que reutiliza imágenes o informes, distinguir anonimización de seudonimización y comprender qué cambiará —y qué no— con el Espacio Europeo de Datos Sanitarios.
Uso: material personal de estudio y discusión. No constituye asesoramiento jurídico ni una posición aprobada de la SERAM.
La idea central
En IA radiológica, el error habitual es empezar por una solución técnica —«quitaremos el nombre», «lo subiremos a una nube europea» o «usaremos aprendizaje federado»— antes de definir para qué se tratarán los datos, quién decide ese uso y qué recorrido completo seguirán.
Los datos sanitarios son una categoría especialmente protegida, pero eso no significa que todo tratamiento exija consentimiento individual. Bajo el RGPD deben concurrir, de forma simplificada:
- una base general del artículo 6;
- una excepción que permita tratar datos de salud conforme al artículo 9;
- una finalidad definida y garantías proporcionales;
- cumplimiento de la legislación sanitaria, de investigación y nacional aplicable.
La regla ejecutiva es:
finalidad concreta → actores y roles → base jurídica → datos mínimos → arquitectura → garantías → autorización → vigilancia
Ni el informe favorable de un comité de ética, ni un contrato con el proveedor, ni la seudonimización sustituyen por sí solos esta cadena.
1. La finalidad determina la vía
«Mejorar la IA» no es una finalidad suficientemente precisa
El mismo conjunto de resonancias puede utilizarse en situaciones jurídicamente distintas:
| Asistencia individual |
¿El tratamiento es necesario para atender a ese paciente? |
| Control de calidad o gestión |
¿Se evalúa el funcionamiento del servicio o se inicia una investigación generalizable? |
| Validación local de un producto |
¿Se comprueba de forma limitada que funciona en el centro o se pretende producir nueva evidencia científica? |
| Investigación |
¿Existe un protocolo, una pregunta científica y aprobación institucional? |
| Entrenamiento de un modelo |
¿Quién define la finalidad, conserva el modelo y puede reutilizarlo? |
| Desarrollo comercial |
¿El proveedor trabaja por cuenta del hospital o persigue también su propio producto? |
| Docencia o publicación |
¿Puede identificarse a una persona por imágenes, texto, fechas o combinación de datos? |
Una validación silenciosa de una herramienta adquirida puede formar parte de la gestión de calidad asistencial si está delimitada y no pretende investigación. Si se amplían datos, centros, objetivos o explotación científica, la clasificación puede cambiar. No debe decidirla unilateralmente el investigador: corresponde al responsable institucional, con el delegado de protección de datos —DPD— y, cuando proceda, el comité de ética.
Dos capas de legitimación
Para datos personales ordinarios se necesita una base del artículo 6 del RGPD. En sanidad pública pueden ser relevantes, según el caso, el cumplimiento de una obligación legal, una misión de interés público o los intereses vitales. Para datos de salud hay que justificar además una excepción del artículo 9.2, por ejemplo asistencia y gestión sanitaria, interés público en salud pública o investigación científica con las garantías del artículo 89 y del Derecho nacional.
El consentimiento explícito puede ser una vía, especialmente en investigación, pero no es la respuesta automática:
- puede no ser la base adecuada cuando existe una relación de dependencia o una misión pública;
- debe ser informado, específico, libre y revocable;
- retirarlo debe tener consecuencias reales y gestionables;
- un consentimiento asistencial o para participar en un estudio no autoriza cualquier desarrollo posterior;
- un proyecto sin consentimiento no es necesariamente ilícito si existe otra habilitación suficiente y las garantías exigidas.
Para recordar: consentimiento, base jurídica, aprobación ética y autorización institucional son piezas relacionadas, pero no intercambiables.
2. Anónimo no es lo mismo que seudonimizado
Tres estados con consecuencias diferentes
| Identificable |
DICOM con nombre, historia, fechas y UID vinculables. |
Es dato personal de salud. |
| Seudonimizado |
Identificadores sustituidos por un código; otro equipo conserva la tabla de correspondencia. |
Sigue siendo dato personal y se aplica el RGPD. |
| Anonimizado de forma efectiva |
El riesgo de identificación con medios razonablemente disponibles se ha reducido hasta que la persona deja de ser identificable en el contexto previsto. |
Queda fuera del RGPD, pero la conclusión debe estar justificada y revisarse si cambia el contexto. |
La seudonimización es una garantía muy útil porque separa la identidad de los datos analíticos. No convierte los datos en anónimos: alguien conserva la clave o puede recombinar información.
La anonimización tampoco consiste en borrar dos campos. La AEPD la plantea como un proceso basado en riesgo, no como una propiedad binaria garantizada por una herramienta. En radiología deben considerarse:
- cabeceras DICOM, identificadores únicos y fechas;
- texto incrustado en píxeles y capturas secundarias;
- reconstrucciones faciales en TC o RM;
- informes con enfermedades raras, localizaciones, ocupaciones o cronologías singulares;
- posibilidad de enlazar el conjunto con registros externos;
- acceso del destinatario a información auxiliar;
- conservación de imágenes originales, máscaras, embeddings y logs.
Eliminar todas las fechas puede destruir la utilidad longitudinal; conservarlas aumenta el riesgo. La solución no es declarar el conjunto «anónimo», sino justificar qué precisión se necesita y aplicar desplazamiento de fechas, generalización, separación de claves, control de acceso u otras medidas proporcionales.
Datos sintéticos y aprendizaje federado
Los datos sintéticos pueden reducir la exposición, pero un generador puede memorizar casos o reproducir rasgos raros. Hay que evaluar semejanza, ataques de pertenencia y riesgo de reidentificación antes de tratarlos como no personales.
El aprendizaje federado evita centralizar imágenes, pero intercambia parámetros, gradientes y métricas que también pueden filtrar información. Además, no resuelve finalidad, base jurídica, roles, acceso local ni propiedad del modelo resultante.
Para recordar: una arquitectura que reduce movimiento de datos es una salvaguarda; no es una base jurídica ni una exención del RGPD.
3. Investigación con imágenes en España
Lo que permite la LOPDGDD
La disposición adicional decimoséptima de la LOPDGDD configura vías específicas para investigación en salud. Entre otros elementos:
- permite un consentimiento referido a áreas generales relacionadas con una especialidad investigadora;
- admite, bajo condiciones, reutilizar datos para áreas relacionadas con el estudio inicial, con información a los afectados e informe favorable del comité de ética;
- considera lícito utilizar datos personales seudonimizados para investigación sanitaria y biomédica;
- exige separación técnica y funcional entre el equipo investigador y quien seudonimiza y conserva la clave;
- exige compromiso de confidencialidad, prohibición de reidentificación y medidas de seguridad;
- somete el uso de datos seudonimizados al informe previo del comité de ética;
- requiere una evaluación de impacto cuando proceda, incluyendo específicamente el riesgo de reidentificación.
Esto no significa que cualquier investigador pueda extraer imágenes del PACS después de codificarlas. La institución responsable debe documentar la base, aprobar el protocolo, delimitar accesos y conservar evidencia de cumplimiento.
El mínimo operativo de un proyecto
Antes de acceder a datos debería existir:
- protocolo con finalidad, población, variables y análisis;
- responsable del tratamiento y promotor claramente identificados;
- base del artículo 6 y excepción del artículo 9 documentadas;
- informe del comité de ética cuando corresponda;
- participación temprana del DPD;
- evaluación de impacto si existe alto riesgo —muy frecuente con IA, gran escala y datos de salud—;
- plan de seudonimización y separación de la clave;
- control de accesos, registro, conservación, destrucción y respuesta a incidentes;
- reglas para resultados, modelos, publicación y reutilización posterior.
La EIPD no es un formulario retrospectivo. Debe identificar antes del tratamiento escenarios como reidentificación, acceso indebido, sesgos, inferencias inesperadas, transferencia a terceros o uso del modelo fuera del propósito original.
Para recordar: «retrospectivo» describe cuándo se recogieron los datos; no rebaja automáticamente el riesgo ni elimina la gobernanza.
4. Compartir entre centros o con una empresa
Primero hay que asignar los roles reales
| Un proveedor aloja o procesa datos siguiendo exclusivamente instrucciones documentadas del hospital. |
Puede actuar como encargado; requiere contrato del artículo 28, seguridad, subencargados y destino final de los datos. |
| Dos hospitales deciden conjuntamente finalidad y elementos esenciales del proyecto. |
Pueden ser corresponsables; deben repartir de forma transparente sus obligaciones. |
| Cada centro investiga con fines propios y después comparte resultados o datos. |
Pueden existir responsables independientes y una comunicación de datos que necesita su propia justificación. |
| Una empresa recibe datos y decide usarlos también para mejorar su producto general. |
No es un mero encargado respecto de esa finalidad propia; debe analizarse como responsable o corresponsable. |
El nombre que figure en el contrato no domina la realidad. Si el proveedor decide para qué reutiliza los datos, durante cuánto tiempo o cómo incorpora el aprendizaje a su producto, llamarlo «encargado» no elimina su finalidad propia.
Qué debe cerrar el acuerdo
- finalidad y conjuntos exactos;
- roles y punto de contacto para derechos;
- acceso de personas y centros autorizados;
- seudonimización y custodia de claves;
- infraestructura, localización y subencargados;
- transferencias internacionales y mecanismo aplicable;
- prohibición o condiciones de reidentificación y reutilización;
- propiedad y acceso a modelos, parámetros, anotaciones y resultados;
- publicación, propiedad intelectual y conflictos de interés;
- conservación, devolución, borrado y verificabilidad del borrado;
- incidentes, auditoría y salida del proyecto.
Nube y transferencias
Que una plataforma sea «sanitaria», tenga certificaciones o prometa cifrado no autoriza el tratamiento. Hay que saber dónde están datos, copias, logs, soporte y subencargados. Un tratamiento dentro del Espacio Económico Europeo no constituye por ese solo hecho una transferencia internacional, pero sigue necesitando base, contrato, seguridad y control. El acceso o tratamiento desde un tercer país puede activar el capítulo V del RGPD aunque el servidor principal esté en Europa.
Para imágenes de investigación, una arquitectura prudente suele priorizar:
- análisis dentro de la infraestructura institucional o de un entorno autorizado;
- acceso remoto controlado en lugar de copias dispersas;
- seudonimización en origen y clave fuera del equipo investigador;
- exportación solo de resultados necesarios;
- aprendizaje federado o envío del algoritmo al dato cuando reduzca un riesgo real;
- descarga de datos personales solo cuando esté justificada y gobernada.
Para recordar: cifrar el traslado protege el canal; no legitima el destino ni controla lo que el receptor hará después.
5. Qué cambia con el EHDS
No es un «RGPD más permisivo»
El Reglamento del Espacio Europeo de Datos Sanitarios —EHDS— entró en vigor el 26 de marzo de 2025, pero su aplicación es gradual. Su régimen principal de uso secundario comenzará el 26 de marzo de 2029 para la mayoría de las categorías, incluidos datos de historias clínicas. Algunas categorías, como datos genómicos y datos de determinadas cohortes de investigación, se incorporarán en 2031.
Para uso primario transfronterizo, el intercambio obligatorio de resúmenes del paciente y recetas se prevé en 2029; las imágenes médicas, resultados de laboratorio e informes de alta, en 2031. Este calendario de uso primario no debe confundirse con el del uso secundario.
El EHDS no sustituye al RGPD. Añade una infraestructura y una gobernanza específica:
- organismos nacionales de acceso a datos sanitarios;
- catálogo de conjuntos disponibles;
- solicitud y permiso de datos para finalidades autorizadas;
- acceso a datos personales seudonimizados en entornos de procesamiento seguros;
- salida del entorno únicamente de resultados no personales, revisados;
- trazabilidad, controles de acceso y auditoría;
- derecho de las personas a excluir sus datos del uso secundario, con excepciones nacionales limitadas;
- deberes de publicación de resultados y reconocimiento de la fuente.
La IA está incluida expresamente
El artículo 53 permite el acceso para investigación sanitaria que beneficie a pacientes, profesionales o gestores, incluyendo desarrollo e innovación y entrenamiento, prueba y evaluación de algoritmos, productos sanitarios y sistemas de IA.
Pero el acceso no es libre. El permiso debe delimitar finalidad, datos, personas autorizadas, duración y condiciones. El reglamento prohíbe, entre otros usos:
- decisiones perjudiciales o discriminatorias contra personas o grupos;
- decisiones sobre empleo, seguros, crédito o condiciones de servicios basadas en esos datos;
- publicidad o marketing;
- desarrollo de productos dañinos o adictivos;
- actividades contrarias a las normas éticas nacionales.
Implicación estratégica para radiología
El EHDS puede reducir la fragmentación y facilitar validaciones multicéntricas sin multiplicar copias locales. También cambia la ventaja competitiva: será más importante formular una pregunta legítima, preparar algoritmos reproducibles y trabajar en entornos seguros que «poseer» una copia masiva de imágenes.
Pero en agosto de 2026 aún faltan organismos, actos de ejecución e infraestructura. Un proyecto actual debe utilizar las vías vigentes de RGPD, LOPDGDD, investigación y acuerdos institucionales; no puede invocar el EHDS como permiso anticipado.
Para recordar: el EHDS crea acceso gobernado, no datos abiertos; facilita usos legítimos y dificulta la extracción indiscriminada.
Caso integrador: tres hospitales y una empresa
Tres hospitales quieren entrenar con resonancias de esclerosis múltiple un modelo que detecte lesiones nuevas. Una empresa aporta la plataforma y propone recibir DICOM seudonimizados en una nube europea. El protocolo dice «investigación», pero la empresa conservará el modelo para incorporarlo a un producto futuro. También solicita edad exacta, fechas completas, todos los informes y acceso del equipo técnico desde Estados Unidos.
Por qué no basta con «seudonimizar y firmar un convenio»
- Hay al menos dos finalidades. Investigación clínica y desarrollo de un activo comercial.
- Los roles no están resueltos. La empresa no parece un simple encargado si conserva y reutiliza el modelo para fines propios.
- El conjunto puede ser excesivo. Debe justificarse cada campo, la precisión temporal y el texto íntegro.
- La nube europea no cierra el flujo. El acceso desde Estados Unidos y los subencargados requieren análisis específico.
- La seudonimización sigue bajo RGPD. Cada centro debe separar la clave y controlar quién accede.
- El modelo resultante necesita reglas. Deben definirse propiedad, reutilización, retirada de datos, riesgos de memorización y beneficio para los centros.
- Ética y protección de datos deben coordinarse. El comité evalúa el estudio, pero el responsable y el DPD deben resolver legitimación, EIPD y arquitectura.
Rediseño prudente
- dividir con claridad investigación y desarrollo posterior;
- establecer responsables, corresponsables y encargados según las decisiones reales;
- minimizar campos y generalizar o desplazar fechas cuando sea posible;
- seudonimizar en cada centro y mantener la clave fuera del consorcio analítico;
- valorar un entorno seguro europeo sin descarga o aprendizaje federado;
- limitar accesos internacionales hasta justificar mecanismo y necesidad;
- impedir reutilización del modelo y de los datos fuera del protocolo sin nueva evaluación;
- definir derechos sobre el modelo, publicaciones y futura comercialización;
- aprobar protocolo, acuerdo, EIPD y plan de seguridad antes de transferir datos.
En el futuro, el EHDS podría ofrecer una vía de permiso y entorno seguro. Hoy no sustituye este trabajo.
Semáforo ejecutivo
| Uso asistencial necesario dentro del entorno clínico autorizado |
Verde condicionado: finalidad asistencial, mínimo acceso y controles ordinarios reforzados. |
| Validación local silenciosa y limitada |
Ámbar: clasificar como calidad, evaluación o investigación; documentar y autorizar antes. |
| Investigación con datos seudonimizados y protocolo aprobado |
Ámbar: vía posible con CEI, DPD, separación de claves, seguridad y EIPD cuando proceda. |
| Compartir DICOM seudonimizados por correo, disco o carpeta personal |
Rojo: canal, acceso, copias y trazabilidad inadecuados. |
| Empresa que reutiliza datos o modelo bajo un contrato de «encargado» |
Rojo: el rol contractual puede no reflejar la finalidad real. |
| Aprendizaje federado dentro de un consorcio gobernado |
Ámbar favorable: reduce centralización, pero conserva obligaciones y riesgos técnicos. |
| Invocar el EHDS para acceder hoy a imágenes sin la vía institucional vigente |
Rojo: su régimen operativo de uso secundario aún no resulta aplicable. |
Diez preguntas ante cualquier proyecto de datos
- ¿Cuál es la finalidad exacta y qué producto, publicación o decisión resultará?
- ¿Es asistencia, calidad, investigación, desarrollo comercial o una combinación?
- ¿Quién decide finalidad y medios, y quién actúa solo por instrucciones?
- ¿Cuál es la base del artículo 6 y la excepción del artículo 9?
- ¿Los datos son identificables, seudonimizados o justificadamente anónimos?
- ¿Cada campo, imagen, fecha e informe es necesario para el objetivo?
- ¿Dónde se procesan datos, copias, logs y modelos, y quién puede acceder desde dónde?
- ¿Se necesita comité de ética, DPD, EIPD, contrato de encargado o acuerdo de corresponsabilidad?
- ¿Qué se conservará, reutilizará, publicará o comercializará al terminar?
- ¿Puede alcanzarse el objetivo con menos datos, sin descargarlos o exportando solo resultados?
Qué deberías poder explicar como coordinador
En una conversación institucional, tu posición de partida puede resumirse así:
La protección de datos no debe reducirse a pedir consentimiento ni a eliminar identificadores. Para aprovechar imágenes en IA necesitamos definir finalidades legítimas, roles, conjuntos mínimos y arquitecturas seguras. España ya permite investigación con datos seudonimizados bajo garantías estrictas. El EHDS facilitará el acceso secundario mediante permisos y entornos seguros desde 2029, pero no convierte los datos sanitarios en abiertos ni sustituye la gobernanza actual.
Cuatro frases prudentes evitan errores frecuentes:
- «Anonimizado» debe ser una conclusión documentada sobre el riesgo de identificación, no el nombre de una carpeta.
- «El proveedor no entrena con los datos» no responde dónde se procesan, quién accede, qué se conserva ni qué ocurre con el modelo resultante.
- El comité de ética no sustituye al responsable del tratamiento ni al DPD.
- El EHDS ampliará el acceso legítimo, pero también hará más exigentes la trazabilidad, el entorno seguro y la rendición de cuentas.
Fuentes esenciales
Normativa y fuentes institucionales
- Unión Europea. Reglamento (UE) 2016/679 — Reglamento General de Protección de Datos.
- España. Ley Orgánica 3/2018 — LOPDGDD, especialmente disposición adicional decimoséptima.
- Unión Europea. Reglamento (UE) 2025/327 sobre el Espacio Europeo de Datos Sanitarios.
- Comisión Europea. European Health Data Space Regulation: calendario y aplicación.
- Agencia Española de Protección de Datos. Guía básica de anonimización.
- Agencia Española de Protección de Datos. Gestión del riesgo y evaluación de impacto en tratamientos de datos personales.
- Agencia Española de Protección de Datos. Aproximación a los espacios de datos desde la perspectiva del RGPD.
- Comité Europeo de Protección de Datos. Directrices 07/2020 sobre responsable y encargado del tratamiento.
Conclusión en una frase
El uso responsable de imágenes para IA no depende de mover o esconder identificadores, sino de gobernar la finalidad, los actores y todo el ciclo de vida del dato; el EHDS reforzará precisamente ese modelo de acceso controlado.
Guía ejecutiva 07
Implantar, comprar y vigilar una IA radiológica
Lectura estimada: 12–15 minutos
Fecha de actualización: 5 de agosto de 2026
Objetivo: decidir si una IA merece ser adquirida, convertirla en un proceso asistencial seguro y comprobar que sigue aportando valor después del despliegue.
Uso: material personal de estudio y discusión. No constituye asesoramiento jurídico ni una posición aprobada de la SERAM.
La idea central
Un hospital no compra solamente un algoritmo. Compra un sistema sociotécnico compuesto por un producto, una integración, personas, instrucciones, alertas, contratos, datos, mantenimiento y consecuencias sobre pacientes que quizá nunca aparecieron en el estudio publicado.
Por eso, estas cuatro afirmaciones pueden ser simultáneamente ciertas:
- el producto tiene marcado CE;
- su A-U-C publicada es excelente;
- funciona correctamente en una validación local retrospectiva;
- y, aun así, empeora el servicio cuando se introduce en la práctica.
Puede generar demasiadas alertas, alterar la búsqueda visual, retrasar estudios no priorizados, fallar con un protocolo local, desaparecer de la lista de trabajo durante una caída o ahorrar minutos que no se convierten en capacidad real.
La regla ejecutiva es:
problema y línea basal → resultado deseado → requisitos → evidencia → contrato → validación local → despliegue gradual → vigilancia → salida
El marcado CE es una condición de entrada cuando resulta exigible. No demuestra por sí solo que el producto sea la mejor compra, que generalice al centro, que mejore resultados ni que sea coste-efectivo.
1. Empezar por el problema, no por el catálogo
«Queremos IA para ictus» no define un proyecto. Una formulación útil sería:
En los TC craneales urgentes, la demora hasta la primera revisión clínica de las hemorragias es excesiva durante determinadas franjas. Queremos reducirla sin aumentar de forma inaceptable los falsos avisos, retrasar otros estudios urgentes ni generar una vigilancia paralela insostenible.
Antes de mirar proveedores hay que fijar:
- Población y escenario: qué pacientes, modalidades, sedes, protocolos y horarios.
- Decisión o tarea: detección, priorización, cuantificación, borrador de informe o control de calidad.
- Usuario y momento: quién ve la salida, cuándo y en qué interfaz.
- Mecanismo esperado: cómo esa salida debería cambiar una acción.
- Resultado principal: qué mejora se pretende observar.
- Medidas de equilibrio: qué daño colateral no se acepta.
Si no puede dibujarse el camino entre la salida del modelo y el beneficio clínico, tampoco puede evaluarse la compra.
Medir primero la línea basal
Sin una línea basal previa, cualquier mejora posterior será difícil de interpretar. Conviene medir durante un periodo representativo:
- volumen y mezcla de casos;
- tiempo de adquisición, disponibilidad, lectura, comunicación y actuación;
- variabilidad por turno, sede y profesional;
- errores, repeticiones y eventos relevantes;
- carga de trabajo y puntos reales de cuello de botella;
- coste actual del proceso.
Una IA de priorización no resolverá un retraso causado por la disponibilidad del TC, el transporte del paciente o la comunicación posterior del resultado. Puede incluso desplazar el problema a otra parte del circuito.
Para recordar: si no sabemos qué parte del proceso está fallando, la IA solo automatiza una conjetura.
2. Qué debe demostrar el proveedor antes de un piloto
El expediente mínimo de decisión
No basta una demostración comercial ni una publicación elegida por el proveedor. Para cada producto debe existir un dossier estructurado:
| Identidad regulatoria |
Fabricante legal, representante, finalidad prevista, clase, certificado y organismo notificado cuando proceda, versión exacta e instrucciones de uso. |
| Alcance clínico |
Hallazgos incluidos y excluidos, población, modalidad, protocolos, fabricantes de equipos y situaciones no validadas. |
| Evidencia |
Desarrollo, validaciones externas, estudios prospectivos o de impacto, referencia estándar, prevalencia, intervalos de confianza, subgrupos y conflictos de interés. |
| Rendimiento operativo |
Latencia, disponibilidad, tasa de análisis fallidos, falsos avisos por volumen de trabajo y comportamiento ante estudios incompletos. |
| Integración |
Arquitectura, flujo DICOM, RIS–PACS, listas de trabajo, visualización, identidad de pacientes, contingencia y responsabilidades de soporte. |
| Datos y seguridad |
Datos enviados, localización, conservación, logs, subencargados, acceso remoto, uso para reentrenamiento, cifrado y respuesta a incidentes. |
| Ciclo de vida |
Política de actualizaciones, cambio de modelo, comunicación de nuevas limitaciones, vigilancia poscomercialización y fin de soporte. |
| Economía |
Licencia, integración, infraestructura, mantenimiento, personal, consumo por estudio, ampliación de sedes y costes de salida. |
Las instrucciones de uso importan especialmente. Definen el uso autorizado, las condiciones necesarias, las limitaciones y el rendimiento declarado. Una propuesta que depende de utilizar el sistema fuera de ese marco exige detenerse: puede ser clínicamente insegura y alterar la posición regulatoria del hospital.
Tres filtros rápidos
- ¿La finalidad del producto coincide con nuestro caso? «Detecta hemorragia» no equivale necesariamente a «permite descartar hemorragia» ni a «puede informar de forma autónoma».
- ¿La evidencia se parece a nuestro entorno? Deben compararse prevalencia, espectro de enfermedad, equipos, protocolos, edad, urgencias, artefactos y práctica real.
- ¿La salida puede utilizarse con seguridad? Una probabilidad sin umbral documentado, una caja en otra pantalla o una alerta sin responsable pueden no ser operables.
Una empresa que no facilite información suficiente para evaluar estos puntos no debe compensarlo con promesas contractuales vagas.
Para recordar: la opacidad comercial no es una característica inevitable de la IA; es un riesgo de compra.
3. El contrato debe proteger el ciclo de vida
Comprar resultados verificables
En contratación pública, las prescripciones pueden expresarse en términos de rendimiento o exigencias funcionales. Para IA, suele ser más útil especificar qué debe conseguir el sistema y cómo se aceptará que exigir una marca o una arquitectura cerrada.
El pliego o contrato debería concretar, según el riesgo:
| Objeto y aceptación |
Caso de uso, versión, sedes, población, métricas, umbrales, periodo de prueba y facultad de no aceptar si no se cumplen. |
| Integración y servicio |
Interfaces, compatibilidad, latencia, disponibilidad, soporte, contingencia, recuperación y responsabilidades ante una caída. |
| Actualizaciones |
Preaviso, descripción del cambio, evidencia, posibilidad de probarlo, regresión local, rechazo o aplazamiento y retorno a una versión segura. |
| Datos y modelos |
Qué recibe el proveedor, para qué puede usarlo, qué conserva, derechos sobre anotaciones y modelos, y prohibición de reutilización no autorizada. |
| Trazabilidad |
Acceso del hospital a versión, estado, inputs procesados, outputs, fallos y logs necesarios para auditoría e investigación. |
| Riesgo e incidentes |
Canal urgente, tiempos de comunicación, cooperación, preservación de evidencia, acciones correctivas y apoyo a las notificaciones regulatorias. |
| Ciberseguridad |
Requisitos institucionales, subcontratistas, vulnerabilidades, parches, pruebas, acceso privilegiado, copias y notificación de brechas. |
| Salida |
Exportación de datos y configuraciones, borrado verificable, continuidad durante la transición, costes, documentación y ausencia de formatos cautivos. |
Las cláusulas modelo europeas para compra pública de IA ofrecen una base útil sobre gestión de riesgos, documentación, logs, supervisión, precisión y cooperación. No son un contrato completo: deben integrarse con protección de datos, producto sanitario, propiedad intelectual, responsabilidad, seguridad, aceptación y contratación pública.
Calcular el coste total, no la licencia
El coste real incluye:
- integración y pruebas;
- infraestructura local o nube;
- interfaces y mantenimiento;
- tiempo clínico, de física, ingeniería, informática y protección de datos;
- doble circuito durante el piloto;
- formación inicial y de nuevos profesionales;
- monitorización y análisis de incidentes;
- ampliación a nuevos equipos o sedes;
- actualizaciones, renegociación y salida.
«Ahorra dos minutos por informe» no equivale automáticamente a ahorro económico. Debe explicarse si esos minutos reducen demoras, evitan actividad, aumentan capacidad sin deterioro o liberan una tarea realmente reasignable.
Para recordar: una compra barata puede ser cara si el hospital no puede medirla, actualizarla ni abandonarla.
4. Validar localmente sin confundir etapas
Cuatro fases con preguntas diferentes
Fase 1. Aceptación técnica
Comprobar en un entorno controlado:
- recepción y enrutamiento correctos;
- asociación inequívoca con paciente y estudio;
- compatibilidad con protocolos y equipos;
- latencia, fallos, duplicados y comportamiento ante datos incompletos;
- presentación de resultados y logs;
- contingencia si el sistema o la red no están disponibles.
Fase 2. Despliegue silencioso
El sistema analiza casos consecutivos, pero su salida no modifica todavía la asistencia. Permite estimar rendimiento local, fallos técnicos, carga potencial de alertas y subgrupos problemáticos.
No demuestra interacción humano–IA, cambio de conducta ni beneficio clínico. Tampoco debe convertirse en recogida indefinida de datos sin finalidad, protocolo y autorización claros.
Fase 3. Piloto asistencial limitado
Se introduce la salida en un número controlado de sedes, turnos o usuarios, con formación, supervisión, canal de incidencias y criterios de parada. Aquí se estudian:
- comprensión y uso real;
- omisiones y sobreconfianza;
- tiempo añadido o ahorrado;
- cambios de priorización y comunicación;
- consecuencias para casos positivos y negativos;
- efectos inesperados sobre otros pacientes.
Fase 4. Escalado condicionado
Solo después de revisar los resultados se amplía el despliegue. La autorización debe indicar versión, alcance, responsable, indicadores, frecuencia de revisión y condiciones de continuidad.
Cómo evitar una validación decorativa
Antes de abrir los resultados hay que definir:
- hipótesis y resultado principal;
- población consecutiva y exclusiones;
- tamaño y precisión necesarios;
- referencia estándar y resolución de discrepancias;
- métricas y umbrales de aceptación;
- subgrupos relevantes;
- análisis de fallos y estudios no procesados;
- medidas de equilibrio;
- responsables de decidir continuidad, modificación o parada.
Probar solo casos positivos seleccionados o comparar la IA con un informe clínico que ya pudo estar influido por ella produce una falsa seguridad. La evaluación temprana en vivo debe estudiar también factores humanos y cambios del flujo, no únicamente exactitud.
Para recordar: el despliegue silencioso responde «¿cómo funciona aquí sin influir en nadie?»; el piloto asistencial responde «¿qué ocurre cuando las personas actúan con su salida?».
5. Vigilar lo que realmente puede degradarse
Un cuadro de mando en cinco capas
| Técnica |
Disponibilidad, latencia, estudios fallidos, duplicados, integridad de mensajes, versión activa. |
| Rendimiento del modelo |
Sensibilidad, especificidad, VPP, falsos avisos por 100 estudios, calibración y subgrupos. |
| Flujo y factores humanos |
Adopción, tiempo de revisión, alertas ignoradas, anulaciones, discrepancias, carga cognitiva y trabajo añadido. |
| Clínica y seguridad |
Tiempo hasta decisión o comunicación, errores relevantes, retrasos inducidos, rescates por profesionales y eventos potencialmente graves. |
| Valor y equidad |
Volumen, capacidad, coste por estudio, recursos desplazados, beneficio por sede y diferencias entre poblaciones. |
Cada indicador necesita propietario, fuente, periodicidad, umbral y respuesta. Un panel sin decisiones asociadas solo produce vigilancia aparente.
La deriva no es una sola cosa
El rendimiento puede cambiar por:
- datos: nuevo escáner, protocolo, reconstrucción, compresión o DICOM;
- población: edad, prevalencia, derivación o gravedad distintas;
- práctica clínica: nueva definición diagnóstica o tratamiento;
- flujo: cambia quién ve la alerta o en qué momento;
- software: actualización del modelo, PACS, interfaz o sistema operativo;
- conducta: los usuarios aprenden a ignorar avisos o dependen excesivamente de ellos.
Por eso, toda evaluación debe registrar la versión completa del producto y de la integración. Tras cambios relevantes se necesita una comprobación de regresión proporcional al riesgo, incluso cuando el proveedor afirme que la actualización está cubierta por su conformidad.
Vigilancia local y vigilancia del fabricante son complementarias
El MDR obliga al fabricante a recopilar y analizar de forma activa y sistemática datos sobre calidad, rendimiento y seguridad durante la vida del producto. Eso no sustituye la vigilancia del hospital: el fabricante no observa por sí solo todos los fallos locales, atajos de trabajo o retrasos inducidos.
En España, los hospitales deben disponer de responsable de vigilancia de productos sanitarios. Los profesionales deben notificar los incidentes graves a través de NotificaPS; también son relevantes los fallos que podrían haber causado un daño grave aunque la intervención humana o la fortuna lo evitaran.
Cuando sean aplicables las obligaciones del AI Act a los sistemas de alto riesgo correspondientes, el centro desplegador deberá, entre otros elementos, seguir las instrucciones, asignar supervisión competente, monitorizar el funcionamiento, conservar los logs bajo su control y suspender el uso si identifica un riesgo. Es sensato diseñar hoy estos mecanismos aunque el calendario específico de determinados productos sanitarios se haya desplazado.
Para recordar: «no hubo daño porque el radiólogo lo detectó» puede describir un rescate exitoso, no la ausencia de incidente.
6. Gobernanza ligera, pero con autoridad real
Un propietario y una red de control
Cada implantación necesita una persona responsable del resultado del proceso, no solo un contacto técnico. Alrededor de ella deben participar, de forma proporcionada:
- responsable clínico del circuito;
- usuarios finales y técnicos;
- RIS–PACS e informática;
- seguridad y protección de datos;
- calidad y seguridad del paciente;
- ingeniería clínica o responsable de productos sanitarios;
- contratación y asesoría jurídica;
- dirección con capacidad presupuestaria;
- proveedor.
No todos deben reunirse cada semana. Sí debe quedar claro quién aprueba el piloto, quién accede a métricas, quién recibe una alerta, quién puede suspender el sistema y quién autoriza su reactivación.
Criterios de parada predefinidos
Ejemplos:
- error de identificación o asociación paciente–resultado;
- caída que altera la lista de trabajo sin indicación visible;
- aumento inesperado de falsos negativos clínicamente relevantes;
- tasa de fallos superior al umbral acordado;
- brecha de seguridad o uso de datos no autorizado;
- actualización sin control o versión no identificable;
- daño grave o patrón de cuasiincidentes;
- imposibilidad del proveedor para investigar con trazabilidad suficiente.
Parar no significa necesariamente rescindir. Puede implicar desactivar una función, volver a la versión anterior, limitar población o pasar temporalmente a modo silencioso.
Caso integrador: priorización de hemorragia intracraneal
Un hospital quiere incorporar una IA que reordena la lista de TC craneales según sospecha de hemorragia. El producto tiene marcado CE y estudios externos sólidos. El proveedor promete reducir un 30 % el tiempo de informe.
La compra débil
- se adquiere por su sensibilidad publicada;
- no se mide la demora basal ni por turnos;
- el contrato no fija versión ni falsos avisos aceptables;
- la alerta aparece en una aplicación separada;
- no se evalúa el retraso de estudios no marcados;
- una actualización puede desplegarse automáticamente;
- solo el proveedor dispone de los logs.
Aunque la IA detecte bien la hemorragia, el proyecto no puede demostrar beneficio ni investigar de forma independiente un fallo.
El rediseño prudente
Problema: demora relevante en primera revisión de hemorragias urgentes durante noches y fines de semana.
Resultado principal: tiempo desde final de adquisición hasta revisión o comunicación clínica de los verdaderos positivos.
Medidas de equilibrio: tiempo de casos urgentes no marcados, falsos avisos por turno, estudios no procesados, latencia, carga de interrupciones y cuasiincidentes.
Aceptación técnica: identidad, DICOM, protocolos, visibilidad de caída, contingencia y acceso a logs.
Despliegue silencioso: cohorte consecutiva representativa, análisis de fallos y subgrupos, umbrales fijados antes de conocer el resultado.
Piloto: usuarios y horarios limitados, formación sobre limitaciones, sistema ordinario preservado, revisión diaria inicial y autoridad de parada.
Contrato: versión exacta, umbrales, acceso a logs, preaviso y prueba de actualizaciones, soporte urgente, cooperación ante incidentes y salida sin pérdida de datos.
Decisión: escalar solo si mejora el resultado principal sin deterioro clínicamente importante de las medidas de equilibrio. Si la demora basal ya es mínima, incluso una IA precisa puede no justificar su coste y complejidad.
Semáforo ejecutivo
| Problema definido, línea basal y resultado clínico medible |
Verde: existe una base razonable para explorar soluciones. |
| Marcado CE, pero finalidad o población local no coinciden |
Rojo: no usar el marcado para cubrir una discordancia esencial. |
| Despliegue silencioso con protocolo, autorización y umbrales |
Verde condicionado: útil para rendimiento y funcionamiento local. |
| Compra basada solo en A-U-C y descuento comercial |
Rojo: evidencia y valor insuficientes. |
| Piloto asistencial limitado con formación y criterios de parada |
Ámbar favorable: permite estudiar interacción e impacto. |
| Actualización automática sin versión, preaviso ni regresión |
Rojo: se pierde control sobre el sistema evaluado. |
| Panel continuo con indicadores, propietario y acciones |
Verde: vigilancia operativa real. |
| Ahorro de tiempo sin mecanismo para convertirlo en capacidad o beneficio |
Ámbar: eficiencia aparente; falta demostrar valor. |
Doce preguntas antes de aprobar una IA
- ¿Qué problema medido queremos resolver y dónde está el cuello de botella?
- ¿Qué cambio concreto provocará la salida de la IA en qué usuario y momento?
- ¿Cuál es el resultado principal y cuáles son las medidas de equilibrio?
- ¿Coinciden finalidad prevista, versión, población y entorno con nuestro uso?
- ¿Qué evidencia externa existe y qué incertidumbre sigue abierta?
- ¿Qué datos salen, dónde se procesan y para qué puede reutilizarlos el proveedor?
- ¿Cómo se integra, cómo se detecta una caída y cuál es el circuito alternativo?
- ¿Qué umbrales debe superar la aceptación técnica y la validación local?
- ¿Qué cambiará entre modo silencioso, piloto y despliegue completo?
- ¿Qué métricas, subgrupos y fallos se vigilarán, por quién y con qué frecuencia?
- ¿Cómo se controlan versiones, actualizaciones, incidentes y criterios de parada?
- ¿Cuál es el coste total y cómo recuperamos datos, continuidad y capacidad de elección al salir?
Qué deberías poder explicar como coordinador
En una conversación institucional, tu posición de partida puede resumirse así:
La evaluación no termina con la evidencia publicada ni con el marcado CE. Una implantación responsable empieza por un problema medido, exige requisitos y cláusulas verificables, valida el sistema en el entorno local, estudia la interacción con los profesionales y mantiene vigilancia durante todo su ciclo de vida. El objetivo no es comprar más algoritmos, sino obtener mejoras asistenciales demostrables sin crear riesgos, costes o dependencias invisibles.
Tres oportunidades realistas para SERAM serían:
- una ficha común de evaluación previa y validación local;
- un conjunto mínimo de cláusulas funcionales y de ciclo de vida para orientar a los servicios;
- un marco compartido de indicadores e incidentes que permita aprendizaje entre centros sin crear un ranking comercial de productos.
La Comisión podría proponer estas herramientas. Su adopción institucional, jurídica o contractual correspondería a los órganos competentes de cada organización y, cuando proceda, a la Junta de la SERAM.
Fuentes esenciales
Normativa y fuentes institucionales
- Unión Europea. Reglamento (UE) 2017/745 sobre los productos sanitarios — especialmente artículos 83–92.
- Medical Device Coordination Group. MDCG 2025-10: Guidance on post-market surveillance of medical devices and IVDs.
- Agencia Española de Medicamentos y Productos Sanitarios. Sistema de vigilancia y responsable de vigilancia de los centros sanitarios, actualización 2026.
- Unión Europea. Reglamento de Inteligencia Artificial, texto consolidado a 27 de julio de 2026 — artículo 26.
- Public Buyers Community. Cláusulas contractuales modelo para la contratación pública de IA, versión 2025.
- España. Ley 9/2017 de Contratos del Sector Público.
- España. Real Decreto 311/2022, Esquema Nacional de Seguridad.
- DICOM Standards Committee. DICOM: estándar internacional para imágenes médicas e información asociada.
Evaluación clínica
- Vasey B, et al. DECIDE-AI: guía para la evaluación clínica temprana en vivo de sistemas de apoyo a la decisión basados en IA. BMJ. 2022.
Conclusión en una frase
Una IA radiológica solo merece escalar cuando el hospital puede demostrar qué problema resuelve, controlar qué versión utiliza, medir su impacto y detenerla o abandonarla sin perder seguridad ni autonomía.
Guía ejecutiva 08
Liderazgo institucional, consenso y construcción de posición sobre IA
Lectura estimada: 12–15 minutos
Fecha de actualización: 5 de agosto de 2026
Objetivo: convertir conocimiento técnico y diversidad de opiniones en propuestas legítimas, aprobables y útiles, preservando la independencia de la Comisión y distinguiendo siempre la voz personal de la posición institucional.
Uso: material personal de estudio y discusión. No constituye una posición aprobada de la SERAM.
La idea central
Coordinar una Comisión no consiste en ser quien más sabe de todos los temas ni en producir opiniones rápidas. Consiste en construir un proceso que permita a personas con experiencias diferentes llegar a una propuesta que:
- responda a un problema real;
- se apoye en evidencia suficiente y transparente;
- incorpore las perspectivas necesarias;
- haga visibles la incertidumbre y los desacuerdos relevantes;
- llegue al órgano que tiene autoridad para aprobarla;
- pueda aplicarse y evaluarse.
La influencia institucional sostenible nace de una combinación:
mandato claro + evidencia proporcionada + participación legítima + decisión trazable + comunicación disciplinada
Una Comisión puede tener mucha actividad y poca influencia si organiza reuniones sin decisiones, publica antes de acordar, confunde consenso con silencio o produce documentos que nadie puede aprobar ni implementar.
En SERAM, la Comisión de IA puede analizar, coordinar, elaborar borradores y formular propuestas. La Junta Directiva dirige la Sociedad y regula sus comisiones. Por tanto, la autonomía operativa no equivale a capacidad para comprometer presupuesto, convenios, marca o posiciones oficiales. Esta separación no debilita a la Comisión: le permite trabajar con iniciativa sin atribuirse una autoridad que no tiene.
Para recordar: tu función no es hablar por todos; es conseguir que la Sociedad pueda decidir mejor.
1. Cinco niveles de voz que nunca deben confundirse
| Criterio personal |
Tu análisis como Pablo Naval, neurorradiólogo o coordinador. |
«Mi interpretación es…» |
Que hablas a título personal; intereses relevantes. |
| Borrador de trabajo |
Texto preparado por ti o por un grupo pequeño. |
«Borrador para discusión; no aprobado». |
Autores, versión, objetivo y preguntas abiertas. |
| Propuesta de la Comisión |
Resultado revisado y aceptado mediante el procedimiento acordado. |
«La Comisión propone…» |
Participantes, método, acuerdos, disenso y fecha. |
| Posición institucional |
Propuesta validada por el órgano competente de SERAM. |
«SERAM considera/recomienda…» |
Acuerdo o aprobación, alcance, versión y responsables. |
| Comunicación pública |
Traducción autorizada para socios, medios u otras instituciones. |
Mensajes coherentes con la posición aprobada. |
Portavoz, audiencia, canal y coordinación con Comunicación. |
El salto peligroso suele producirse entre el segundo y el cuarto nivel: un documento técnicamente bueno se presenta como posición oficial porque «no había tiempo» o porque nadie formuló una objeción. La ausencia de objeciones no demuestra aprobación si no se pidió una decisión explícita.
Una regla práctica de etiquetado
Todo documento debería mostrar en la primera página:
- estado: borrador, propuesta de la Comisión o aprobado;
- versión y fecha;
- autoría o grupo redactor;
- audiencia;
- decisión que se solicita;
- órgano que debe aprobarla.
Si un texto circula fuera del grupo para recibir comentarios, sigue siendo un borrador. Consultar no es aprobar.
Para recordar: la autoridad de un documento no depende de su calidad ni de su apariencia, sino de quién lo ha validado y para qué uso.
2. Antes de redactar, definir la decisión
El encargo mínimo
Cuando llegue una petición —de Formación, la Junta, una institución, un medio o una empresa— conviene aclarar primero:
- quién pregunta y con qué autoridad;
- qué producto necesita: conversación, informe técnico, respuesta pública o posición oficial;
- qué decisión debe facilitar;
- quién es la audiencia;
- qué plazo existe y por qué;
- qué nivel de aprobación será necesario.
Sin esto, el grupo puede invertir semanas en un tratado cuando se necesitaba una recomendación de una página, o contestar informalmente a una cuestión con consecuencias institucionales.
El brief de decisión de una página
Una propuesta ejecutiva debería contener:
- Decisión solicitada. Una frase que pueda terminar en aprobar, modificar, pilotar, consultar, posponer o rechazar.
- Problema. Qué ocurre, a quién afecta y por qué importa ahora.
- Hechos confirmados. Evidencia, normativa y datos disponibles.
- Incertidumbres. Qué no sabemos y cuánto puede cambiar la decisión.
- Opciones reales. Incluida la opción de no actuar todavía.
- Propuesta razonada. Beneficios, riesgos, recursos y condiciones.
- Aplicación. Responsable, calendario, dependencias e indicadores.
- Aprobación necesaria. Comisión, Junta, otra vocalía o tercero competente.
La Comisión Europea estructura su enfoque de mejor regulación alrededor de definición del problema, evidencia, alternativas, impactos, consulta y evaluación. No es necesario copiar su burocracia; sí adoptar su disciplina: primero entender el problema y comparar opciones, después defender una solución.
Para recordar: un buen documento institucional no demuestra cuánto has estudiado; permite saber qué debe decidirse, por qué y con qué consecuencias.
3. Construir consenso sin convertirlo en unanimidad
El consenso es un proceso, no una votación invisible
Un grupo diverso no debe eliminar el desacuerdo. Debe distinguir entre:
- desacuerdo sobre hechos: se resuelve buscando datos o explicitando incertidumbre;
- desacuerdo sobre interpretación: exige comparar razonamientos;
- desacuerdo sobre valores o prioridades: debe hacerse visible;
- desacuerdo sobre viabilidad: necesita la perspectiva de quien implementará;
- conflicto de intereses: requiere declaración y gestión, no debate encubierto.
La OMS recomienda que los procesos de elaboración de guías combinen evidencia, composición adecuada del grupo, gestión de intereses, proceso explícito de consenso, valores de usuarios y transparencia de las decisiones. Para una Comisión pequeña puede aplicarse de forma ligera.
Secuencia de consenso en siete pasos
- Enmarcar la pregunta. Qué decisión se intenta tomar y qué queda fuera.
- Nombrar un responsable de síntesis. Coordina, pero no se apropia del contenido.
- Circular un borrador breve. Con hechos, opciones y preguntas abiertas.
- Recoger aportaciones antes de la reunión. Evita que domine quien improvisa mejor o habla más.
- Discutir primero los desacuerdos materiales. No gastar la reunión leyendo lo ya aceptado.
- Probar el grado de apoyo. Aceptación, aceptación con reservas, objeción que debe resolverse o desacuerdo mantenido.
- Registrar el resultado. Qué se acordó, qué cambió, qué reservas quedan y qué autoridad falta.
Elegir de antemano cómo se decidirá
No todos los asuntos requieren el mismo método:
| Consulta y decisión delegada |
Cuestiones operativas dentro de un mandato claro. |
Que la consulta sea solo decorativa. |
| Consentimiento |
Propuesta reversible que nadie considera inaceptable. |
Confundir «puedo convivir con ello» con apoyo entusiasta. |
| Consenso |
Recomendaciones técnicas o institucionales con necesidad de legitimidad amplia. |
Bloqueo si se interpreta como unanimidad. |
| Votación |
Alternativas definidas cuando no es posible cerrar el desacuerdo. |
Ocultar las razones de la minoría. |
| Elevación a la Junta |
Compromiso institucional, económico, externo o normativo. |
Presentar una decisión pendiente como ratificación automática. |
Si existe una discrepancia importante que no cambia la recomendación final, puede documentarse. Si afecta a seguridad, legalidad, independencia o validez científica, no debe ocultarse para producir una falsa unanimidad.
Para recordar: consenso no significa que todos prefieran la propuesta; significa que el método fue legítimo, las objeciones se trataron y el grado de apoyo quedó claro.
4. Pasar de la evidencia a una recomendación
La evidencia no decide por sí sola
Una publicación puede estimar rendimiento o impacto. No decide automáticamente qué debe recomendar SERAM. Entre evidencia y posición hay juicios sobre:
- magnitud del problema;
- beneficios y daños;
- certeza y transferibilidad;
- equidad entre centros y pacientes;
- aceptabilidad para profesionales y usuarios;
- recursos y coste de oportunidad;
- viabilidad organizativa;
- efectos sobre la profesión y el sistema sanitario.
Una recomendación debe separar explícitamente:
| Hecho |
«El estudio encontró…», «la norma establece…». |
| Interpretación |
«Esto probablemente implica…, dentro de estas limitaciones». |
| Valor |
«Priorizamos seguridad, acceso equitativo e independencia clínica». |
| Propuesta |
«Por ello proponemos…, condicionado a…». |
| Decisión |
«La Comisión/Junta aprueba…, con fecha y alcance…». |
Cuándo es suficiente una respuesta provisional
La urgencia no justifica inventar certeza. Puede emitirse una nota provisional cuando:
- se identifica claramente como tal;
- delimita qué pregunta contesta;
- utiliza la mejor evidencia disponible;
- expone incertidumbres y conflictos;
- evita compromisos irreversibles;
- fija revisión o caducidad.
Una postura temporal honesta suele ser más útil que el silencio y más segura que una posición definitiva improvisada.
Para recordar: transparencia no consiste en incluir muchas referencias; consiste en mostrar cómo se pasó de los datos a la recomendación.
5. Industria, expertos e independencia
Escuchar a la industria no equivale a delegar la posición
Las empresas conocen el producto, el mercado, las barreras técnicas y los modelos de despliegue. Excluirlas siempre empobrece el análisis. Permitir que definan el problema, seleccionen la evidencia o redacten la conclusión compromete la independencia.
La relación prudente distingue:
- información: demostraciones, documentación, datos de funcionamiento y respuestas técnicas;
- consulta: experiencia del sector sobre viabilidad o barreras;
- colaboración: proyecto formal con objetivos, gobernanza, financiación y derechos definidos;
- decisión: permanece en los órganos de SERAM sin control del patrocinador.
El marco ético publicado por SERAM exige diferenciar visión personal e institucional, declarar intereses relevantes, abstenerse cuando proceda y preservar independencia, transparencia y objetividad en la relación con industria.
La declaración por sí sola no resuelve el conflicto. Para cada iniciativa hay que decidir si procede:
- declarar y participar plenamente;
- participar aportando información, pero no redactar la recomendación;
- participar en la discusión, pero no en la decisión;
- abstenerse de todo el proceso concreto.
La respuesta depende de relevancia, magnitud, proximidad al tema y capacidad de introducir contrapesos. Los intereses no son solo económicos: también incluyen autoría de una tecnología, rivalidad profesional, posición pública previa o beneficio institucional.
En tu caso, una participación accionarial minoritaria ya declarada no invalida tu contribución general a la IA. Sí exige identificar las iniciativas en las que pueda ser directamente relevante, declararla de forma específica y acordar si necesitas limitar tu papel en la redacción o decisión. La medida debe quedar registrada; no decidirla tú solo.
Barreras sencillas frente a la captura
- agenda y preguntas definidas por la Comisión;
- más de una fuente o actor cuando el asunto lo permita;
- documentación comercial separada de la evidencia independiente;
- financiación, materiales y autoría visibles;
- control editorial final de SERAM;
- acta de reuniones relevantes;
- prohibición de presentar acceso a la Comisión como aval de un producto;
- revisión del conflicto antes de la decisión, no después de publicar.
Para recordar: un conflicto de interés no demuestra mala conducta; ocultarlo o gestionarlo mal sí destruye confianza.
Tres frases que toda comunicación debería contestar
- Qué sabemos. Hecho principal y nivel de evidencia.
- Qué no sabemos. Incertidumbre que importa para interpretar el mensaje.
- Qué proponemos hacer. Acción, condición o siguiente paso.
Una nota pública no debe reproducir todo el análisis, pero tampoco eliminar las condiciones que sostienen la recomendación. «La IA mejora la eficiencia» puede ser engañoso si la posición aprobada era «determinados sistemas han reducido tiempos en flujos concretos, condicionados a validación e integración».
Antes de hablar externamente
Comprobar:
- ¿hablo personalmente, por la Comisión o por SERAM?;
- ¿existe una posición aprobada y sigue vigente?;
- ¿soy el portavoz adecuado?;
- ¿la audiencia entenderá los límites técnicos?;
- ¿hay implicaciones legales, comerciales o reputacionales?;
- ¿debe intervenir Comunicación o Presidencia?;
En la práctica, María Navallas puede funcionar como enlace habitual para elevar la propuesta a la Junta. Comunicación debe participar cuando el mensaje sea público; Presidencia o la Junta, cuando comprometa a la Sociedad. No conviene abrir simultáneamente varias vías institucionales salvo que el asunto lo requiera.
Es legítimo decir:
«Puedo ofrecer una valoración técnica personal y explicar el estado de la evidencia. SERAM no ha adoptado todavía una posición formal sobre esa pregunta».
Esto permite aportar valor sin fabricar una postura institucional. Si la cuestión es sensible, puede ofrecerse una respuesta posterior coordinada.
Para recordar: rapidez y autoridad son dimensiones distintas. Puedes responder rápido sin atribuirte una autoridad que no tienes.
Una institución solicita a SERAM, con 72 horas de plazo, una posición sobre permitir que una IA emita informes autónomos de estudios aparentemente normales para aliviar el déficit de radiólogos. Una empresa ofrece datos y propone patrocinar el documento.
Respuesta débil
- el coordinador redacta una opinión definitiva;
- se consulta solo a los miembros disponibles;
- se mezclan distintas modalidades y sistemas;
- la empresa aporta casi toda la evidencia;
- la falta de respuesta se interpreta como consenso;
- el texto se envía con logotipo antes de aprobación.
Aunque la conclusión fuese razonable, el proceso sería frágil y difícil de defender.
Respuesta institucional prudente
1. Clarificar el encargo
¿Se pide una explicación técnica, una recomendación de política sanitaria o un aval regulatorio? ¿Quién decidirá y para qué modalidad, población y producto?
2. Acotar la afirmación
«Informar autónomamente estudios normales» puede referirse a cribado, triaje, borrador de informe o exclusión sin lectura humana. Son funciones distintas y no deben recibir una respuesta única.
3. Preparar una nota provisional
Separar:
- evidencia de rendimiento e impacto;
- finalidad autorizada y marco regulatorio;
- falsos negativos y grupos vulnerables;
- supervisión, contingencia y responsabilidad;
- efecto sobre acceso, carga profesional y pérdida de capacidades;
- alternativas menos irreversibles, como priorización o piloto supervisado.
4. Consultar perspectivas necesarias
Clínica, metodología, implementación, regulación, ejercicio profesional y, si procede, pacientes o gestores. La industria puede aportar datos técnicos bajo preguntas definidas; no controlar la síntesis.
Por ejemplo: no apoyar una autorización genérica por tecnología. Evaluar casos de uso y productos concretos, dentro de su finalidad, con evidencia prospectiva, validación local, responsabilidades definidas, vigilancia y criterios de parada. La posibilidad de mayor autonomía debería depender del riesgo y de resultados demostrados, no de la etiqueta «IA» ni de la escasez de profesionales por sí sola.
6. Registrar el grado de acuerdo
Qué miembros participaron, qué reservas existen y si el texto es una propuesta de la Comisión o una nota técnica provisional.
7. Elevar y comunicar
Enviar a María Navallas para la ruta de validación correspondiente. Solo tras aprobación debe convertirse en posición SERAM y coordinarse su comunicación externa.
8. Gestionar el ofrecimiento empresarial por separado
El patrocinio no debe condicionar el calendario, la autoría ni la conclusión. Cualquier colaboración necesita cauce formal, aprobación y control editorial independiente.
Semáforo ejecutivo
| Borrador etiquetado, decisión solicitada y aprobador identificado |
Verde: trazabilidad suficiente para iniciar consulta. |
| «Nadie contestó, por tanto está aprobado» |
Rojo: silencio no equivale a acuerdo. |
| Desacuerdo documentado que no invalida la recomendación |
Verde condicionado: puede avanzarse con reserva visible. |
| Documento financiado por industria con control editorial de la Comisión |
Ámbar: posible, pero exige acuerdo formal, transparencia y barreras. |
| Empresa selecciona autores, evidencia y mensaje final |
Rojo: riesgo alto de captura y pérdida de credibilidad. |
| Respuesta personal claramente identificada ante una consulta urgente |
Verde condicionado: útil si no se presenta como postura institucional. |
| Posición oficial sin aprobación de la Junta competente |
Rojo: exceso de autoridad. |
| Propuesta con responsable, recursos, calendario e indicador |
Verde: tiene posibilidad real de implantación. |
Doce preguntas antes de construir una posición
- ¿Qué decisión concreta se intenta facilitar?
- ¿Quién solicita el trabajo, quién será afectado y quién debe aprobarlo?
- ¿Qué mandato tiene la Comisión sobre este asunto?
- ¿Qué hechos están confirmados y qué incertidumbres pueden cambiar la conclusión?
- ¿Qué opciones reales existen, incluida la de no actuar todavía?
- ¿Qué perspectivas clínicas, técnicas, profesionales, jurídicas o ciudadanas faltan?
- ¿Cómo se recogerán las aportaciones y cómo se decidirá?
- ¿Qué intereses financieros, intelectuales o institucionales deben declararse y gestionarse?
- ¿Qué desacuerdo sería aceptable y cuál impediría cerrar la recomendación?
- ¿El texto identifica estado, versión, autores, audiencia y aprobación pendiente?
- ¿La propuesta puede implementarse: responsable, recursos, calendario e indicadores?
- ¿Quién comunicará el resultado y cómo evitará simplificarlo de forma engañosa?
Cómo evaluar tu desempeño como coordinador
No midas principalmente número de reuniones, correos o apariciones. Cada seis meses, revisa cinco dimensiones:
| Legitimidad |
¿Las decisiones siguieron un método conocido y una aprobación adecuada? |
Propuestas con estado, acta y aprobador identificados. |
| Participación |
¿Contribuyeron perfiles diferentes o siempre los mismos? |
Miembros con aportación sustantiva y distribución de liderazgos. |
| Entrega |
¿Se produjeron resultados útiles y proporcionados? |
Entregables terminados frente a compromisos; tiempo hasta decisión. |
| Adopción e influencia |
¿Alguien utilizó lo producido? |
Formación realizada, herramientas adoptadas, consultas respondidas o decisiones informadas. |
| Independencia y aprendizaje |
¿Se gestionaron intereses y se corrigieron errores? |
Declaraciones por iniciativa, disensos registrados y revisiones realizadas. |
Una Comisión sana no depende de que tú redactes todo. Una señal de buen liderazgo será que varios miembros lideren iniciativas coherentes, con autonomía dentro de un marco compartido, y que tú puedas asegurar dirección, conexión institucional y calidad sin convertirte en cuello de botella.
Qué deberías poder explicar como coordinador
Tu posición de partida puede resumirse así:
La Comisión debe tener iniciativa para analizar y proponer, pero la autoridad institucional exige un proceso explícito. Separaremos evidencia, interpretación y recomendación; consultaremos a quienes puedan aportar o verse afectados; declararemos y gestionaremos intereses; registraremos acuerdos y desacuerdos; y elevaremos cada propuesta al órgano competente. El objetivo no es producir unanimidad ni comunicados rápidos, sino decisiones legítimas, aplicables y revisables.
Tres prácticas iniciales de gran rendimiento serían:
- etiquetar todos los documentos por estado y aprobación;
- utilizar un brief de decisión común para nuevas iniciativas;
- declarar y gestionar intereses específicamente en cada proyecto sensible.
Estas medidas son suficientemente ligeras para no burocratizar la Comisión y suficientemente claras para proteger su credibilidad.
Fuentes esenciales
- SERAM. Estatutos de la Sociedad Española de Radiología Médica — órganos de gobierno y comisiones.
- SERAM. Marco ético — visión personal e institucional, conflictos de interés y relación con industria.
- World Health Organization. WHO handbook for guideline development, 2nd edition.
- World Health Organization. Ethics and governance of artificial intelligence for health. 2021.
- European Commission. Better regulation: evidence, impact assessment and stakeholder engagement.
- European Commission. Better Regulation Toolbox 2025 — stakeholder consultation and evaluation.
- International Committee of Medical Journal Editors. Disclosure of financial and non-financial relationships and conflicts of interest. Recomendaciones actualizadas en 2026.
- OECD. Recommendation on Transparency and Integrity in Lobbying and Influence. 2024.
Conclusión en una frase
Liderar institucionalmente es convertir diversidad y evidencia incompleta en una decisión trazable, independiente y aplicable, sin atribuir a la Comisión ni a ti una autoridad que todavía no ha sido concedida.
Guía ejecutiva 09
Geopolítica de la IA sanitaria y radiológica
Lectura estimada: 12–15 minutos
Fecha de actualización: 5 de agosto de 2026
Objetivo: comprender qué intereses estatales, industriales y profesionales condicionan la IA sanitaria internacional y traducirlos en decisiones prudentes para la radiología española.
Uso: material personal de estudio y discusión. Contiene interpretación estratégica y propuestas; no constituye una posición aprobada de la SERAM.
La idea central
La competición internacional por la IA no es solo una carrera por construir el modelo más potente. Es una disputa por controlar una cadena completa:
chips y energía → cómputo y nube → modelos → datos → aplicaciones clínicas → estándares → acceso al mercado
En radiología, una herramienta concreta puede reunir chips fabricados en Asia, diseño estadounidense, nube sometida a otra jurisdicción, datos multinacionales, un fabricante europeo y una compra autonómica. Por eso, «¿de qué país es la empresa?» es insuficiente. Importa saber:
- quién controla la infraestructura y las actualizaciones;
- dónde se procesan los datos y qué jurisdicciones pueden alcanzarlos;
- qué componentes pueden ser interrumpidos por sanciones, licencias o decisiones comerciales;
- quién conserva los registros, el conocimiento y la capacidad de sustituir el sistema;
- qué mercado o regulador impone las condiciones de diseño;
- quién captura el valor económico y científico producido con los datos clínicos.
La lectura más realista en 2026 es una interdependencia politizada: las cadenas siguen conectadas, pero gobiernos y empresas intentan reducir vulnerabilidades y convertir tecnologías, normas, infraestructuras y mercados en influencia.
Para recordar: la soberanía útil no es fabricar todo dentro de una frontera; es conservar capacidad real de decisión cuando una dependencia falla o cambia de condiciones.
1. Dónde está realmente el poder
| Semiconductores |
Diseño, fabricación avanzada, memoria, empaquetado y equipos de producción. |
Determinan disponibilidad y coste de entrenamiento, inferencia, reconstrucción y procesamiento local. |
| Energía y centros de datos |
Electricidad, suelo, refrigeración, permisos y financiación. |
Condicionan el coste y la localización de nubes, modelos y repositorios de imagen. |
| Nube y plataformas |
Infraestructura, servicios de datos, identidad, seguridad e integración. |
Una aplicación puede ser sustituible, mientras toda la arquitectura hospitalaria queda ligada a la plataforma. |
| Modelos y propiedad intelectual |
Modelos fundacionales, pesos, código, patentes, talento y capital. |
Influyen en informes, búsqueda, asistencia clínica y automatización; pueden cambiar sin que el hospital controle su evolución. |
| Datos y conocimiento clínico |
Imágenes, informes, resultados, anotaciones, flujos y experiencia profesional. |
El volumen solo no basta: el valor surge de curación, representatividad, contexto y seguimiento. |
| Mercado y contratación |
Capacidad de comprar a escala y exigir condiciones. |
Un sistema sanitario puede imponer interoperabilidad, evaluación y vigilancia o aceptar dependencia contractual. |
| Regulación y estándares |
Reglas de acceso, evidencia, seguridad, formatos y auditoría. |
Definen qué productos pueden venderse y trasladan costes de cumplimiento a toda la industria. |
Ningún actor controla toda la cadena. Estados Unidos concentra gran parte de la capacidad empresarial en modelos avanzados, diseño de chips y nube; Asia oriental es indispensable en fabricación; China posee escala industrial y un ecosistema propio creciente; la UE aporta mercado, sistemas sanitarios, investigación y capacidad regulatoria, pero mantiene dependencias críticas.
La Comisión Europea reconoció en junio de 2026 que la UE depende de terceros países para más del 80 % de productos, servicios, infraestructura y propiedad intelectual digitales considerados clave. Su nueva política de soberanía tecnológica busca actuar desde chips hasta nube, software y código abierto, sin plantear una autarquía completa.
Para recordar: una cadena global puede ser eficiente en condiciones normales y frágil cuando aparece conflicto político, escasez, cambio regulatorio o concentración empresarial.
2. Cuatro estrategias distintas
Estados Unidos: liderazgo tecnológico y exportación del ecosistema
La política federal estadounidense formula la IA expresamente como una competición por el liderazgo económico, tecnológico y de seguridad. El America’s AI Action Plan de 2025 se articula en innovación, infraestructura y proyección internacional; su marco legislativo de 2026 insiste en reducir barreras, acelerar despliegues y evitar un mosaico de leyes estatales.
Sus palancas son:
- empresas líderes en modelos, nube, semiconductores y software;
- capital privado y capacidad de escalar productos globalmente;
- contratación federal, universidades, talento y control de exportaciones;
- un mercado sanitario grande y la influencia internacional de la FDA.
No significa ausencia de regulación sanitaria. La FDA mantiene autorización previa según el producto y un enfoque de ciclo de vida, control de cambios y rendimiento real. La diferencia es de arquitectura: Estados Unidos regula por sectores y riesgos concretos mientras promueve su industria.
Interpretación estratégica: su interés no es únicamente vender aplicaciones. Es que empresas y aliados construyan sobre cómputo, nube, modelos y estándares estadounidenses. Los controles de exportación intentan preservar ventaja y seguridad, pero también incentivan a China a desarrollar sustitutos.
Implicación radiológica: un producto estadounidense puede aportar madurez y soporte, pero el hospital debe conocer jurisdicción, subencargados, actualizaciones, continuidad, portabilidad y capacidad de operar si cambia la relación comercial o política.
China: autonomía, despliegue industrial y oferta al Sur Global
China combina planificación estatal, mercado interno, investigación, fabricación y datos. Las restricciones extranjeras sobre chips avanzados refuerzan su búsqueda de autosuficiencia en cómputo, modelos y software.
Sus planes de 2025–2026 promueven la integración «AI Plus» en la economía, el acceso a datos y capacidad de cómputo, ecosistemas de código abierto, estándares, talento y aplicaciones industriales. En paralelo, China propone cooperación, capacitación e infraestructura para países en desarrollo y una mayor voz en la gobernanza global de la IA.
Interpretación estratégica: la oferta china combina un objetivo defensivo —reducir vulnerabilidad tecnológica— y otro expansivo: proyectar productos, estándares, infraestructura y relaciones hacia mercados que no desean depender exclusivamente de Estados Unidos o Europa. El énfasis en soberanía estatal y desarrollo inclusivo también compite con el discurso occidental centrado en derechos individuales.
Implicación radiológica: los fabricantes chinos pueden ofrecer integración, escala y precios competitivos. Deben evaluarse con los mismos criterios clínicos que cualquier proveedor, atendiendo a evidencia, actualizaciones, seguridad, transferencias, acceso remoto y auditoría.
No debe asumirse que toda tecnología china implica el mismo riesgo ni que toda tecnología occidental garantiza control. La diligencia debe recaer sobre el sistema y su cadena, no sobre estereotipos nacionales.
Unión Europea: poder regulatorio y búsqueda de capacidad propia
La UE intenta combinar cuatro objetivos que pueden entrar en tensión:
- proteger seguridad, derechos fundamentales y datos;
- mantener un mercado abierto y competitivo;
- acelerar una adopción de IA que sigue por detrás de su ambición;
- reducir dependencias en chips, nube, modelos e infraestructura.
El AI Act, el MDR, el RGPD y el EHDS convierten el mercado europeo en palanca normativa. El AI Continent Action Plan, las AI Factories, InvestAI y el paquete de soberanía tecnológica de 2026 intentan ampliar cómputo, datos, código abierto y capacidad industrial. La propuesta de Cloud and AI Development Act añade un marco graduado de soberanía para la contratación pública.
Fortalezas: mercado único potencial, sistemas sanitarios públicos, investigación, industria de dispositivos médicos, datos longitudinales y legitimidad para fijar reglas.
Debilidades: fragmentación, compra pública lenta, menor escala de capital y nube, y riesgo de que el coste del cumplimiento beneficie a actores ya grandes.
Interpretación estratégica: Europa intenta pasar de ser principalmente regulador y comprador a conservar capacidad en la cadena. Su ventaja más plausible en salud no es replicar cada plataforma generalista, sino combinar datos gobernados, excelencia clínica, infraestructuras compartidas, evaluación rigurosa y aplicaciones sectoriales confiables.
Implicación radiológica: los hospitales y servicios europeos no son receptores pasivos. Su contratación, datos y validación pueden convertirse en política industrial y de seguridad. Pero exigir «proveedor europeo» sin comprobar propiedad, nube, chips, soporte y subcontratación puede producir soberanía solo nominal.
Actores bisagra: Reino Unido, India, Asia industrial y el Golfo
La competición no es únicamente Estados Unidos–China–UE.
- Reino Unido busca un entorno de innovación flexible y utilizar el NHS como comprador y espacio de evaluación; su riesgo es depender de capital e infraestructura externa.
- India democratiza cómputo, datos y modelos mediante la IndiaAI Mission. Puede actuar como mercado, fuente de talento, productor de tecnología asequible y voz de países que no quieren elegir un bloque.
- Japón, Corea del Sur y Taiwán son esenciales en semiconductores, electrónica, equipamiento y cadenas industriales. Su alineamiento político no elimina su exposición a una interrupción regional.
- Emiratos y Arabia Saudí utilizan capital, energía, centros de datos, modernización sanitaria y alianzas múltiples para convertirse en nodos de cómputo y adopción, no solo compradores finales.
- Países de renta baja y media reclaman acceso, capacidad local y reparto de beneficios; corren el riesgo de recibir sistemas poco adaptados o aportar datos sin conservar capacidad de decisión.
Estos actores practican grados distintos de multi-alineamiento: cooperan con varias potencias, diversifican proveedores y buscan capturar partes concretas de la cadena.
Para recordar: el mundo de la IA será probablemente multipolar en adopción y regulación, aunque algunas capas tecnológicas sigan muy concentradas.
3. La regulación y los estándares también son instrumentos de poder
Existe cierta convergencia internacional en principios: enfoque basado en riesgo, calidad de datos, transparencia, supervisión, ciberseguridad y vigilancia durante el ciclo de vida. La OMS, la OCDE y el IMDRF contribuyen a este lenguaje común; el Convenio Marco del Consejo de Europa traslada derechos humanos y garantías a un tratado abierto también a países no europeos.
Pero la convergencia tiene límites. Persisten diferencias materiales sobre:
- privacidad y capacidad estatal de acceso;
- libertad empresarial y autorización previa;
- responsabilidad y reparación;
- transparencia de modelos y propiedad intelectual;
- localización y transferencias de datos;
- control de contenidos y usos de seguridad nacional;
- apertura de pesos, código y conjuntos de datos;
- intensidad de la vigilancia poscomercialización.
Los estándares técnicos parecen neutrales, pero distribuyen poder. Quien define cómo demostrar rendimiento, documentar subgrupos o comunicar una actualización determina costes de entrada y capacidades legítimas.
El IMDRF armoniza principios entre reguladores. En imagen, DICOM, IHE y otros estándares reducen dependencia si existe interoperabilidad real; no basta cumplir un formato si anotaciones, configuraciones o registros siguen siendo propietarios.
Implicación para sociedades científicas: participar en normas, marcos de evidencia y criterios de contratación puede influir más que publicar declaraciones generales sobre la IA. El terreno decisivo suele estar en una especificación aparentemente técnica.
4. Los datos sanitarios: activo estratégico, no materia prima gratuita
Las imágenes sin contexto, calidad, etiquetas, resultados y conocimiento del flujo tienen valor limitado. El activo real es:
datos + curación + experiencia clínica + infraestructura + derecho de uso + capacidad de validación
La relación se desequilibra cuando una institución entrega datos y trabajo experto, mientras otra conserva modelo, propiedad intelectual, acceso comercial y conocimiento generado.
Antes de una colaboración internacional conviene preguntar:
- ¿qué recibe el sistema sanitario además del pago o la publicación?;
- ¿puede reutilizar resultados, modelos o herramientas?;
- ¿se evaluará rendimiento en su población y se devolverán hallazgos?;
- ¿quién decide nuevos usos y transferencias posteriores?;
- ¿cómo se reconocen el trabajo de curación y la autoría clínica?;
- ¿se crea capacidad local o dependencia?
El EHDS facilitará un uso secundario gobernado mediante permisos y entornos seguros, no una extracción libre. Puede aumentar escala y poder negociador, pero obliga a definir acceso, propiedad intelectual, reciprocidad y beneficio público.
España dispone de datos diversos, un SNS con escala, capacidad radiológica e investigación. La fragmentación autonómica y la madurez desigual pueden convertir esa ventaja en acuerdos pequeños con poco poder negociador.
Para recordar: proteger datos no es inmovilizarlos; es utilizarlos de forma que pacientes e instituciones conserven derechos, conocimiento y una parte justa del valor creado.
5. Cuatro escenarios para 2026–2030
Escenario base: interdependencia controlada
Se mantienen productos globales, pero aumentan requisitos de soberanía, seguridad, localización, evaluación y proveedores alternativos.
Consecuencia: aumentan coste y complejidad, pero sigue siendo posible comprar globalmente. Es el escenario central más plausible.
Escenario de tensión: desacoplamiento parcial
Controles de exportación, sanciones, ciberincidentes o una crisis en Asia limitan chips, soporte o componentes y producen ecosistemas menos interoperables.
Consecuencia: hospitales sin inventario de dependencias ni plan de contingencia descubren que un servicio clínico dependía de decisiones externas invisibles.
Escenario de oportunidad: capacidad sanitaria europea
Europa conecta EHDS, cómputo, compra pública y evaluación clínica; desarrolla plataformas sustituibles y empresas capaces de escalar, sin excluir proveedores extranjeros.
Consecuencia: España puede ser nodo de validación e implementación si coordina comunidades autónomas, hospitales, sociedades y grupos tecnológicos.
Pocos proveedores integran nube, PACS, dictado, modelos y agentes. La comodidad aumenta el coste de cambio y permite que la plataforma decida qué algoritmos llegan al usuario.
Consecuencia: el riesgo principal deja de ser el fallo de un algoritmo aislado y pasa a ser la dependencia estructural de toda la actividad radiológica.
Estos escenarios pueden coexistir. Una organización debe aprovechar el escenario base y prepararse para los de tensión y concentración.
6. Qué significa para SERAM y para ti como coordinador
Una posición prudente: soberanía clínica abierta
La Comisión no necesita convertirse en un foro de política exterior ni elegir ganadores nacionales. Puede defender un principio profesional:
Soberanía clínica es la capacidad de comprender, evaluar, gobernar, auditar y sustituir los sistemas que influyen en la asistencia, manteniendo continuidad, datos y competencia profesional.
Es compatible con tecnología estadounidense, china, europea o multinacional si cumple condiciones verificables. No equivale a proteccionismo ni exige desarrollar todo localmente.
Siete líneas de actuación posibles
- Evaluar el sistema completo. Incluir nube, modelos subyacentes, subencargados, soporte, telemetría y actualizaciones, no solo la interfaz o el marcado.
- Convertir interoperabilidad y salida en requisitos clínicos. Exportación de datos, anotaciones, configuraciones y registros; continuidad si termina el contrato; migración probada.
- Exigir control de versiones y trazabilidad. Saber qué modelo produjo cada resultado y qué cambió tras una actualización.
- Promover acuerdos de datos equilibrados. Finalidad, retorno de resultados, autoría, propiedad intelectual, acceso posterior y beneficio público.
- Participar en evidencia y estándares. Con ESR, sociedades afines, AEMPS, Ministerio, SNS y organismos técnicos, evitando duplicar lo que ya existe.
- Crear capacidad lingüística y clínica propia. Evaluar informes y asistentes en español y, cuando proceda, lenguas cooficiales; desarrollar conjuntos de prueba gobernados. No hace falta entrenar un modelo fundacional para poseer una capacidad estratégica.
- Mantener neutralidad institucional disciplinada. Analizar riesgos de jurisdicción y dependencia sin convertir una recomendación clínica en adhesión geopolítica ni presentar una propuesta como posición SERAM antes de su aprobación.
La futura estrategia de IA del SNS ya plantea coordinación entre niveles, registros, oficinas y relación con AEMPS, AEPD y AESIA. SERAM puede aportar la capa que la administración no sustituye: definición de necesidades radiológicas, evaluación profesional, factores humanos y criterios clínicos de adopción.
Una comunidad autónoma quiere contratar una plataforma que integre dictado, borrador de informe, comparación longitudinal y comunicación de hallazgos. Recibe tres propuestas:
- una plataforma de una gran empresa estadounidense sobre su propia nube;
- una solución de un fabricante asiático integrada con sus equipos;
- un consorcio europeo con componentes abiertos, pero menor madurez y soporte.
Se pregunta a SERAM cuál favorece la «soberanía tecnológica».
Respuesta débil
Elegir por bandera: «europea porque cumple valores europeos», «estadounidense porque es la más avanzada» o «asiática porque es más barata». Ninguna conclusión responde a quién controla realmente la cadena.
Análisis prudente
1. Definir lo que no puede perderse
Continuidad asistencial, privacidad, evidencia clínica, competencia profesional, acceso a datos y capacidad de cambiar de proveedor.
2. Dibujar la cadena real
Para cada opción: propiedad y control, nube, ubicación y jurisdicción, modelo fundacional, chips o servicios críticos, subencargados, acceso remoto, actualizaciones y soporte.
3. Comparar control, no etiquetas
¿Puede el comprador bloquear una actualización? ¿Obtiene registros utilizables? ¿Puede exportar informes estructurados, plantillas, anotaciones y auditorías? ¿Existe modo degradado? ¿Cuánto tarda una migración?
4. Comparar evidencia y coste total
Rendimiento en español, especialidades, subgrupos y centros reales; efectos sobre tiempos, omisiones y revisión humana; coste de integración, nube, supervisión, salida y futuras funciones.
5. Negociar arquitectura y contrato
Puede resultar mejor una solución multinacional modular y sustituible que una alternativa europea cerrada; o puede justificarse aceptar menor madurez a cambio de control, siempre que seguridad y utilidad alcancen el umbral clínico.
SERAM no debería avalar un proveedor. Podría proponer criterios comunes, un piloto comparable y condiciones mínimas de control, interoperabilidad, evidencia y salida.
Conclusión del caso: la soberanía no identifica automáticamente una marca. Es una propiedad de la arquitectura técnica, el contrato, la gobernanza y la capacidad interna.
Semáforo ejecutivo
| Proveedor extranjero con cadena transparente, portabilidad probada y salida viable |
Verde condicionado: la dependencia es conocida y gobernable. |
| Proveedor europeo que usa componentes críticos opacos y formatos propietarios |
Ámbar/rojo: el domicilio no garantiza soberanía. |
| Procesamiento local sin capacidad de actualizar, auditar ni mantener |
Ámbar: localización no equivale a control sostenible. |
| Acuerdo internacional con retorno de resultados, acceso científico y reglas de reutilización |
Verde condicionado: colaboración potencialmente equilibrada. |
| Datos y anotaciones a cambio de acceso temporal a una caja negra |
Rojo: alto riesgo de transferencia unilateral de valor. |
| Compra con registros, control de versiones, interoperabilidad y prueba de migración |
Verde: aumenta resiliencia y poder negociador. |
| Exclusión de un proveedor únicamente por nacionalidad, sin análisis de riesgo aplicable |
Rojo: débil técnica e institucionalmente. |
| Diversificación de proveedores sin capacidad interna para gobernarlos |
Ámbar: multiplica complejidad sin asegurar autonomía. |
Doce preguntas ante una decisión con dimensión geopolítica
- ¿Qué función clínica se está protegiendo y qué ocurriría si el servicio se interrumpe?
- ¿Quién controla cada capa: chips, nube, modelo, aplicación, datos y soporte?
- ¿Qué jurisdicciones y posibles accesos extraterritoriales son relevantes?
- ¿Qué componentes están sometidos a licencias, sanciones, exportaciones o decisiones de terceros?
- ¿Puede conocerse y fijarse la versión que produce cada resultado?
- ¿Qué datos, anotaciones, registros y configuraciones pueden exportarse en formato utilizable?
- ¿Existe modo degradado, proveedor alternativo y plan de salida probado?
- ¿Quién captura la propiedad intelectual y el valor generado por datos y trabajo clínico?
- ¿La evidencia representa población, equipos, idioma y flujo locales?
- ¿La compra fortalece capacidad interna o transfiere progresivamente el conocimiento al proveedor?
- ¿Qué estándar, organismo o alianza permitiría influir más que una actuación aislada?
- ¿Estamos haciendo una recomendación clínica trazable o expresando una preferencia política no aprobada?
Qué deberías poder explicar como coordinador
Tu síntesis puede ser:
La IA radiológica depende de una cadena global concentrada y sometida a intereses económicos, regulatorios y de seguridad. Estados Unidos busca mantener liderazgo y proyectar su ecosistema; China persigue autonomía y expansión industrial; Europa combina regulación con un giro hacia soberanía tecnológica; y otros actores utilizan escala, capital, energía, fabricación o sistemas sanitarios para ganar influencia. Para la radiología española, la respuesta no debe ser elegir tecnología por nacionalidad, sino asegurar soberanía clínica abierta: evidencia local, trazabilidad, interoperabilidad, acuerdos equilibrados sobre datos, capacidad de salida y participación profesional en estándares y contratación.
Tres medidas de alto rendimiento para la Comisión serían:
- incorporar un mapa de dependencias y jurisdicciones a cualquier plantilla de compra o implantación;
- defender portabilidad, control de versiones y salida probada como requisitos de seguridad clínica;
- explorar con socios europeos un marco de evaluación en español para informes, asistentes y modelos generativos.
Esto mantiene a la Comisión en su terreno legítimo: pacientes, práctica profesional, evidencia y resiliencia del sistema. La lectura geopolítica informa la decisión; no sustituye el procedimiento institucional necesario para convertirla en una posición de SERAM.
Fuentes esenciales
Estrategias nacionales y regionales
- The White House. America’s AI Action Plan: Winning the Race. 2025.
- The White House. National AI Legislative Framework. 2026.
- U.S. Bureau of Industry and Security. Semiconductor and AI-related export-control updates.
- European Commission. AI Continent Action Plan. 2025–2026.
- European Commission. European technological sovereignty package. 2026.
- European Commission. Cloud and AI Development Act. Propuesta de 2026.
- State Council of the People’s Republic of China. Action plan on AI cooperation and development. 2026.
- Mission of China to the United Nations. Global AI Governance Action Plan. 2025.
- UK Government. AI Opportunities Action Plan: One Year On. 2026.
- Government of India. IndiaAI Mission — compute, datasets, models and applications.
- UAE Government. Artificial intelligence in government policies and UAE AI Strategy 2031.
Salud, regulación y gobernanza internacional
- U.S. Food and Drug Administration. Artificial Intelligence in Software as a Medical Device. Actualización continua.
- International Medical Device Regulators Forum. AI/ML-enabled medical devices working group and harmonised principles.
- World Health Organization. Ethics and governance of artificial intelligence for health. 2021.
- OECD. AI Principles and interoperable governance. Actualizados en 2024.
- United Nations. Global Digital Compact. 2024–2026.
- Council of Europe. Framework Convention on Artificial Intelligence, Human Rights, Democracy and the Rule of Law. 2024.
- Ministerio de Sanidad. Estrategia de Inteligencia Artificial del Sistema Nacional de Salud. 2025–2026.
- Ministerio para la Transformación Digital y de la Función Pública. Estrategia de Inteligencia Artificial 2024.
Conclusión en una frase
La autonomía estratégica de la radiología no consiste en cerrar fronteras tecnológicas, sino en colaborar globalmente sin entregar el control clínico, los datos, el conocimiento ni la capacidad de elegir el siguiente proveedor.