Un hospital que compra un sistema de apoyo al diagnóstico redacta, casi siempre, el mismo tipo de pliego que redactaría para comprar un servidor: especificaciones técnicas, criterios de adjudicación, garantía, mantenimiento. Esto que pongo de relieve es lo que veo en mi quehacer diario. Nada de eso está mal. Lo que falta es otra cosa: el pliego trata como software lo que el Reglamento Europeo de IA ya trata como un sistema de alto riesgo.

La diferencia no es semántica.

Los sistemas de IA destinados a diagnóstico, priorización de listas de espera, triaje asistido o apoyo a decisiones clínicas están clasificados como alto riesgo en el Anexo III del Reglamento (UE) 2024/1689. Eso significa que, antes de que ese sistema llegue a ningún paciente, tiene que haber pasado una evaluación de conformidad, llevar marcado CE específico para IA y contar con documentación técnica que acredite cómo fue entrenado, con qué datos y con qué límites de rendimiento. Nada de esto se improvisa después de la adjudicación: o está exigido en el pliego desde el primer momento, o el hospital está comprando una promesa, no una garantía.

El Reglamento separa aquí dos papeles que la mesa de contratación suele confundir. El proveedor del sistema es, en su lenguaje, el provider: quien lo diseña, lo entrena y responde de su conformidad. El hospital que lo adquiere y lo pone en funcionamiento es el deployer: quien responde de cómo se usa. Un pliego que no reparte con claridad qué acredita el proveedor antes de entregar y qué debe verificar el hospital después de recibir deja una zona gris. Y en esa zona gris, cuando el sistema falla, cada parte señala a la otra.

El punto más delicado, y el que casi ningún pliego recoge todavía, es la supervisión humana. El Reglamento no exige simplemente «que un médico revise» la salida del sistema: exige que esa supervisión sea efectiva, es decir, que la persona que supervisa tenga formación suficiente para detectar un error, tiempo real para ejercer esa revisión y capacidad efectiva de anular la recomendación del sistema. Un pliego que se limita a incluir la frase «supervisión humana garantizada» sin definir cómo se forma, cómo se audita y cómo se documenta esa supervisión no está cumpliendo el Reglamento: está citándolo.

Esto tiene una consecuencia práctica que conviene decir sin rodeos: cuando un sistema de IA de alto riesgo falla en un hospital público, la pregunta que el juez va a hacer no es solo si el proveedor certificó bien su producto. Es si el pliego exigió esa certificación, si el hospital la verificó antes de poner el sistema en marcha, y si la supervisión humana prevista funcionó de verdad o era una casilla marcada en el expediente. La responsabilidad patrimonial del artículo 32 de la Ley 40/2015 no distingue entre el fallo del algoritmo y el fallo de quien debía vigilarlo.

Y el calendario, aunque ha cambiado, no da motivos para relajarse. El Reglamento entró en aplicación general el 2 de agosto de 2026 —esa fecha ya ha pasado—, pero el Ómnibus Digital sobre IA aplazó el grueso de las obligaciones de alto riesgo del Anexo III, que es donde vive buena parte de la IA clínica, hasta el 2 de diciembre de 2027; los sistemas integrados en productos regulados, como ciertos dispositivos médicos, esperan hasta agosto de 2028. No es una moratoria: es tiempo. Y el tiempo que da un aplazamiento normativo no se usa esperando a que falten semanas para el plazo, se usa ahora, en el pliego que se redacta hoy, porque la evaluación de conformidad, la documentación técnica y los protocolos de supervisión no se improvisan en un mes.

España, además, ya tiene interlocutor para esto. La Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) es la autoridad nacional competente para vigilar el cumplimiento del Reglamento en territorio español, y eso convierte la gobernanza de la IA sanitaria en algo más que una buena práctica interna: es una obligación con destinatario institucional. Un hospital que contrata IA de alto riesgo debería poder responder, sin titubeos, a cinco preguntas:

• Qué sistemas de IA tiene en uso y con qué nivel de riesgo.
• Quién es, dentro de la organización, el responsable formal de su gobernanza.
• Dónde está la documentación que acredita el cumplimiento del Reglamento.
• Qué canal existe para reportar un incidente a AESIA.
• Quién, en la dirección del centro, firma esa responsabilidad.

Si alguna de esas cinco preguntas no tiene respuesta clara hoy, el pliego que se está tramitando ahora mismo es la última oportunidad de subsanarlo antes de que sea una inspección, o una sentencia, quien las formule.

Lo mínimo que un pliego de IA sanitaria tendría que exigir hoy:

Primera. Acreditación de la clasificación de riesgo del sistema, conforme al Anexo III, antes de la adjudicación —no como condición resolutoria a posteriori, cuando el daño ya se ha producido. Pedirla después de firmar el contrato no protege al hospital: solo documenta que se firmó a ciegas.

Segunda. Evaluación de conformidad y marcado CE de IA, con la documentación técnica accesible para el hospital y no solo para el proveedor: quien deba responder por el sistema necesita poder auditarlo, no limitarse a confiar en la palabra de quien se lo vendió.

Tercera. Reparto contractual expreso entre las obligaciones del provider y las del deployer, sin zonas de responsabilidad compartida y sin asignar. Si el pliego no dice quién responde de qué, lo decidirá un juzgado, y lo hará después del daño, no antes.

Cuarta. Protocolo de supervisión humana con formación específica, tiempo asignado y registro auditable de cada revisión y cada anulación. Sin ese registro, la supervisión humana es una afirmación de parte, no una garantía verificable.

Quinta. Cláusula de reentrenamiento: qué ocurre cuando el sistema cambia de comportamiento respecto al que fue evaluado, porque un sistema que aprende no es el mismo que se adjudicó. Un pliego que no prevé esto está regulando una fotografía, no un sistema vivo.

Sexta. Coordinación expresa de esa responsabilidad con las obligaciones de continuidad y notificación que ya exige NIS2 —no como norma redundante, sino como capa distinta del mismo riesgo: NIS2 protege que el sistema siga funcionando; el AI Act protege que, mientras funciona, lo haga bien.

Ninguna de estas seis exigencias es una ocurrencia: están ya en el Reglamento, en vigor de forma escalonada desde 2024. Lo que falta no es norma. Es que llegue de la sala de máquinas normativa a la mesa de contratación antes de que sea un tribunal —o AESIA— quien la traduzca.

Julio Ángel de Santiago Angulo, Técnico de la Función Administrativa y Letrado habilitado para el asesoramiento jurídico en contratación pública en el ámbito del Servicio Canario de la Salud