Cartagenaeste

12 · Clasificación MDR + AI Act · justificación legal

Tesis: EvidenciaIA NO es producto sanitario bajo MDR 2017/745 ni sistema de IA de alto riesgo bajo AI Act 2024/1689 art. 6 + Anexo III. Es un sistema de IA de riesgo limitado sujeto a las obligaciones de transparencia del art. 50.

Base legal: combinación de las estrategias 1 (“consulta de evidencia, no de diagnóstico”) + 3 (“second opinion sin vínculo al paciente concreto”), con opción adicional de la estrategia 4 (art. 5(5) MDR · uso in-house) para despliegue formal en SMS Murcia.

Última revisión: 2026-05-05.

12.1 Las cuatro estrategias legales para una IA tipo OpenEvidence en la UE

A continuación se documentan las cuatro vías reconocidas por la doctrina actual (artificialintelligenceact.eu, pro.campus, mdxcro.com, comentario académico) para operar una herramienta funcionalmente equivalente a OpenEvidence sin convertirse en SaMD clase IIa/IIb. EvidenciaIA combina las estrategias 1 y 3 explícitamente; la estrategia 4 queda disponible como vía de despliegue institucional.

Estrategia 1 · Consulta de evidencia, no de diagnóstico

El modelo más limpio legalmente es el de Consensus o UpToDate: la herramienta NO diagnostica ni sugiere tratamientos sobre el paciente, sino que recupera y resume evidencia científica sobre condiciones o fármacos. El médico hace la pregunta, recibe literatura sintetizada y aplica su criterio.

Consecuencias regulatorias:

NO es producto sanitario bajo MDR (no tiene “intended purpose” diagnóstico ni terapéutico individual).
NO entra en el Anexo III del AI Act como sistema de alto riesgo (no es sistema de soporte a decisión clínica regulado).

Funcionalmente se siente igual que OpenEvidence para el médico, pero jurídicamente es muy diferente.

EvidenciaIA aplica esta estrategia:

Ver 01-system-purpose.md §1.2 (uso previsto) y §1.3 (NO uso previsto).
Las salvaguardas de safeguards.ts rechazan en tiempo de ejecución cualquier pregunta que solicite diagnóstico o tratamiento individual antes de invocar al modelo IA.
El system prompt de la síntesis (ragSynthesizer.ts) instruye explícitamente al modelo a “sintetizar ÚNICAMENTE el contenido de los abstracts” y a rechazar consultas individualizadas.

Estrategia 2 · Formación y simulación clínica

Si el contexto declarado es formación de profesionales (simulación de casos, entrenamiento diagnóstico), el AI Act la saca explícitamente del Anexo III de alto riesgo. Permite hacer diagnóstico diferencial, interpretación de imágenes, propuesta de tratamiento — pero en casos simulados o históricos anonimizados, no sobre pacientes reales en tiempo real.

Consecuencias regulatorias:

AI Act Anexo III no aplica a IA usada para fines exclusivamente formativos sobre casos no-individualizados.
Permite explorar funcionalidades más avanzadas (Dx diferencial sobre vignettes) sin escalar a alto riesgo.

EvidenciaIA NO se posiciona aquí actualmente, pero queda como reserva táctica si en el futuro se abre un módulo “Casos clínicos formativos” sobre vignettes anonimizados.

Estrategia 3 · Second opinion sin vínculo al paciente concreto

Si la herramienta nunca toca datos del paciente real (sin nombre, sin historial clínico cargado), sino que el médico describe un caso de forma anónima y recibe información general, el nexo entre la IA y el paciente se rompe legalmente. El médico es entonces quien hace la conexión mental, no el sistema. Esto la acerca más a una calculadora clínica avanzada (como MDCalc, que opera sin certificación SaMD de alto riesgo).

Consecuencias regulatorias:

Sin vínculo IA→paciente, no hay “intended purpose” de diagnóstico/terapia sobre un individuo concreto → no es SaMD.
La responsabilidad del salto cognitivo “información general → aplicar a mi paciente” recae en el clínico, no en el sistema.
Modelo MDCalc, BMJ Best Practice (consulta), DynaMed (consulta) — todos operan sin marcado CE como dispositivos médicos.

EvidenciaIA aplica esta estrategia explícitamente:

Las salvaguardas (safeguards.ts) rechazan input con DNI/NIE, fechas de nacimiento, teléfonos.
Las salvaguardas rechazan formulaciones “mi paciente”, “qué le pongo”, “qué le receto”.
La pregunta llega anónima al modelo IA por construcción (validación regex pre-modelo).
El log evidencia_consultas registra patient_link_broken: true como evidencia procedimental de que el sistema no creó vínculo paciente→IA.

Estrategia 4 · Uso interno en entorno sanitario acreditado (B2B in-house)

Las herramientas de IA desplegadas dentro de un sistema hospitalario o centro de salud como herramienta interna NO están obligadas a obtener Marcado CE si el propio centro sanitario las desarrolla o encarga para uso propio, bajo el artículo 5(5) del MDR. Podrías venderla como un proyecto de implementación a medida para clínicas o centros de salud, no como producto comercial empaquetado. La responsabilidad recae en el centro, no en ti como fabricante.

Consecuencias regulatorias:

Art. 5(5) MDR: exención “in-house” cuando un centro sanitario desarrolla o encarga la herramienta para uso propio.
La responsabilidad clínica reside en el centro, no en el desarrollador/encargado.
No requiere marcado CE ni notified body.
Permite a la herramienta funcionar incluso con capacidades que serían SaMD si se vendiesen B2C.

EvidenciaIA tiene esta vía abierta:

Aunque el posicionamiento por defecto es Estrategia 1 + 3 (público para profesionales autenticados de cualquier centro), nada impide que SMS Murcia / HSL Cartagena adopten EvidenciaIA como herramienta interna bajo art. 5(5). La negociación queda en roadmap.md.

12.2 Combinación elegida: 1 + 3 (operación pública por defecto)

EvidenciaIA opera por defecto bajo Estrategia 1 + Estrategia 3 simultáneamente:

Mecanismo	Estrategia 1 (consulta de evidencia)	Estrategia 3 (sin vínculo al paciente)
Input del usuario	Validado contra patrones diagnósticos/terapéuticos individuales	Validado contra patrones PII (DNI, NIE, fecha, teléfono)
Procesamiento IA	System prompt instruye “sintetizar abstracts, no diagnosticar”	Modelo recibe pregunta anónima sin metadatos del paciente
Output	Síntesis con citas verificables, no recomendación individual	Información general aplicable; el clínico hace el salto
UI	Disclaimer art. 50 + GRADE + tooltip de citas	Banner permanente “no SaMD · no sustituye juicio clínico”
Logging	`evidencia_consultas` con `rechazada` + `motivo_rechazo`	`patient_link_broken: true` por defecto + safeguards anti-PII

Resultado: funcionalmente OpenEvidence-like, jurídicamente fuera del MDR + fuera del Anexo III del AI Act.

12.3 Mecanismos técnicos que articulan estas estrategias

Para Estrategia 1 (consulta de evidencia)

safeguards.ts rechaza 6 patrones diagnósticos: “qué tiene mi paciente”, “diagnóstico de mi paciente”, “tiene cáncer/tumor/infarto/ictus”, “es maligno/benigno”, “es un cáncer”, “diagnóstico diferencial de este/mi/un paciente”.
safeguards.ts rechaza 5 patrones terapéuticos individuales: “qué le receto/prescribo/pongo/doy/administro”, “qué dosis le pongo a mi paciente”, “es urgente operar/intervenir/derivar”, “tengo que operarlo”, “a qué hospital lo derivo”.
System prompt de ragSynthesizer.ts declara explícitamente: “NO eres un médico ni das consejos médicos · NO recomiendas tratamientos, diagnósticos ni actuaciones para pacientes concretos · Sintetizas ÚNICAMENTE el contenido de los abstracts”.
Si la pregunta es individualizada, el modelo está instruido a responder: “Esta consulta requiere juicio clínico individualizado y queda fuera del alcance de EvidenciaIA. Te puedo ayudar a buscar evidencia sobre [reformulación general]”.

Para Estrategia 3 (vínculo IA→paciente roto)

safeguards.ts rechaza 4 patrones PII: DNI, NIE, fecha dd/mm/yyyy, teléfono español.
La pregunta sanitizada (sin PII) es la única que viaja al modelo IA y a las APIs externas (PubMed, etc.).
No se almacenan ni transmiten: nombres, NHC, número de cama, diagnóstico individual, fechas de visita.
En cada respuesta, el log persiste patient_link_broken: true como evidencia procedimental de la ausencia de vínculo.
En el disclaimer art. 50, el lenguaje refuerza: “El médico describe el caso de forma anónima; el sistema responde con literatura general. La conexión IA→paciente la hace el clínico, no el software”.

12.4 ¿Y si el clínico aún así nos cuenta del paciente?

Capa adicional de defensa (defense in depth):

Validación regex pre-modelo: si el texto contiene patrón PII reconocible, rechazo inmediato sin tocar IA.
Truncado de pregunta a 500 caracteres: limita la cantidad de contexto clínico que un usuario puede pegar.
Sin ingestión de archivos: el textarea es texto puro; no hay upload de PDF/imagen/historial. La superficie de exfiltración accidental es mínima.
System prompt instruye al modelo a NO procesar contenido PII aunque llegue: si detecta nombre+DNI+NHC, debe responder con la respuesta de rechazo individualizada.
Logging permite auditoría retrospectiva: si en 6 meses surge un incidente, podemos demostrar que el sistema rechazó X% de inputs sospechosos.

12.5 Cómo presentar esto a SMS Murcia / UMU / auditor

Resumen de una página para llevar a una reunión:

¿Qué es EvidenciaIA? Herramienta formativa de búsqueda bibliográfica con síntesis IA. NO produce diagnóstico ni tratamiento individual.
¿Por qué NO es producto sanitario? Combina Estrategia 1 (consulta de evidencia, NO diagnóstico) + Estrategia 3 (vínculo IA→paciente roto por construcción técnica).
¿Cómo se garantiza? Salvaguardas regex pre-modelo + system prompt restrictivo + logging completo + bias audit harness ejecutable + dossier público en docs/aiact/.
¿Cómo se diferencia jurídicamente de OpenEvidence? OpenEvidence se posiciona como CDSS (USA, sin marcado CE conocido en UE). EvidenciaIA se posiciona como herramienta formativa de evidencia sin vínculo al paciente. Funcional ≠ Jurídico.
¿Vía de despliegue institucional? Si SMS Murcia adopta la herramienta como uso interno bajo art. 5(5) MDR, la responsabilidad clínica es del centro y no requiere marcado CE.

12.6 Cuándo SÍ pasaría a ser producto sanitario

Si en algún momento futuro se introducen las siguientes funcionalidades, EvidenciaIA pasaría a ser SaMD y requeriría reclasificación + marcado CE:

Diagnóstico diferencial sobre paciente concreto: el clínico introduce datos de un paciente real (incluso anonimizados pero individualizables) y la IA propone diagnósticos.
Recomendación de dosis/fármaco/derivación para un paciente concreto.
Triaje sintomático con vínculo a un paciente identificable (incluso por uid/NHC).
Predicción de outcome individual (riesgo cardiovascular a 10 años de un paciente concreto, p.ej.).
Procesamiento de imágenes médicas con output diagnóstico.

Cualquiera de estos cambios obligaría a:

Re-evaluar la clasificación MDR (probablemente clase IIa o IIb).
Iniciar proceso de marcado CE (notified body, ISO 13485, IEC 62304, ISO 14971, clinical evaluation).
Re-evaluar la clasificación AI Act (probablemente sistema de alto riesgo, Anexo III).
Revisar este dossier completo y re-emitir.

Política: cualquier propuesta de añadir funcionalidad de las anteriores requiere Plan + revisión legal antes de codificar.

12.7 Referencias

Reglamento (UE) 2017/745 — Reglamento sobre Productos Sanitarios (MDR), especialmente art. 5(5) (uso in-house) y Anexo VIII (reglas de clasificación).
Reglamento (UE) 2024/1689 — Reglamento de Inteligencia Artificial (AI Act), especialmente art. 6 (sistemas de alto riesgo), art. 50 (transparencia) y Anexo III (lista de sistemas de alto riesgo).
Comentario doctrinal: artificialintelligenceact.eu, pro.campus, mdxcro.com (sobre las cuatro estrategias).
Modelos comparables operando sin marcado CE como referencia: Consensus, UpToDate, MDCalc, BMJ Best Practice, DynaMed.