OpenEvidence en Europa

Lo que la retirada deja ver.

OpenEvidence dejó de estar disponible en la Unión Europea y Reino Unido. En los registros públicos no figura una prohibición formal de ninguna autoridad. La empresa decidió retirarse por su cuenta. Lo que hubo fue un proveedor evaluando el coste de cumplir con el marco europeo y concluyendo que no le compensaba.

OpenEvidence se presenta como un asistente de IA para profesionales sanitarios. Por fuera parece un buscador médico evolucionado. La cosa cambia cuando se acerca al punto de atención. Documenta visitas, procesa contexto del paciente, sugiere conductas. Para entonces ya no es un sistema de búsqueda, es un dispositivo que interviene en la práctica clínica.

En Europa la IA médica no está prohibida, está regulada en serio. El Reglamento de IA encuadra buena parte de los sistemas usados en sanidad como alto riesgo del Anexo III, con obligaciones de gestión de riesgos, calidad de datos, supervisión humana, ciberseguridad y documentación técnica. Encima opera el Reglamento de Productos Sanitarios, cuya Regla 11 (MDCG 2019-11) clasifica el software con función diagnóstica o de apoyo a decisiones como dispositivo médico, generalmente en clase IIa o superior. Cumplir con eso requiere una arquitectura que pocas startups tienen lista al lanzamiento.

El terreno más sensible es la protección de datos. Una consulta clínica cae bajo el artículo 9 del RGPD, que prohíbe el tratamiento de datos de salud salvo excepciones tasadas. Si la herramienta recibe prompts con información del paciente o documentos médicos, no alcanzan unas condiciones de uso. Hace falta base jurídica específica, evaluación de impacto del artículo 35, política de minimización, retención definida y una respuesta clara sobre si esos datos van a usarse para entrenamiento de modelos. La respuesta a esa pregunta cambia toda la calificación del tratamiento.

Después aparece la cuestión de la infraestructura. Muchas plataformas de IA corren sobre cloud estadounidense, lo que activa la regulación de transferencias internacionales bajo los artículos 44 y siguientes del RGPD. Invocar el Data Privacy Framework como cláusula mágica no resuelve el problema. Hay que mapear roles, identificar responsable, encargado y subencargados, documentar la evaluación de impacto en transferencia y demostrar que los accesos del proveedor no convierten al servicio en un canal de salida de información clínica.

Otro punto crítico es la calificación regulatoria. La autoridad europea no se queda con el disclaimer. Mira cómo se comercializa la herramienta y cómo se usa de verdad en consulta. Una herramienta que afirma no constituir consejo médico, pero al mismo tiempo se promociona como copiloto clínico, activa rápido la sospecha de software como producto sanitario. Cuando un sistema influye en diagnóstico, tratamiento o seguimiento, el listón sube. Hace falta evaluación clínica conforme al Reglamento de Productos Sanitarios, sistema de gestión de calidad alineado con ISO 13485, vigilancia posterior a la comercialización y trazabilidad de cambios del modelo. En medicina, una respuesta plausible y bien redactada puede hacer más daño que un error evidente.

La mirada desde la clínica trae un matiz importante. En pediatría, y más todavía en neonatología, muchos modelos generales se apoyan en literatura y datos de población adulta. Un sistema que responde con seguridad sobre un cuadro neonatal puede estar extrapolando desde un corpus que no representa esa población. La validación clínica tiene que probar que la herramienta funciona en la población concreta en la que va a usarse, con sus comorbilidades y presentaciones atípicas.

También importa cómo se integra la herramienta en el flujo de trabajo. No es lo mismo responder consultas sueltas que resumir visitas, leer historiales y proponer conductas en el momento de la atención. Cuanto más cerca del acto clínico, más alta la exigencia. La supervisión humana del Reglamento de IA, escrita solo en una cláusula, es retórica vacía. Si el flujo está pensado para que el profesional acepte la sugerencia con un clic, la supervisión existe en el papel pero no en la práctica.

Al riesgo clínico hay que sumarle el técnico. Alucinaciones que citan fuentes inexistentes, memorias no deseadas, sesgos del corpus de entrenamiento e inyección de prompts a través del propio input del usuario. La recuperación aumentada con literatura licenciada, el enfoque atribuido a OpenEvidence, ayuda pero no resuelve. Una respuesta con cita académica puede seguir siendo inadecuada para un paciente concreto.

Y queda la ciberseguridad. Una plataforma que recibe información clínica se vuelve blanco de ataque casi automáticamente. Si además se integra con historia clínica electrónica, el perímetro se amplía. Control de accesos basado en roles, segregación de clientes, registros de auditoría que no dependan de la voluntad del proveedor, defensa contra prompt injection cuando el input incluye documentos del paciente. En protección de datos, la prueba del cumplimiento recae sobre quien trata los datos.

Lo que el caso OpenEvidence muestra es algo más amplio. Europa está pidiendo que la tecnología sanitaria se comporte como tecnología sanitaria. La promesa comercial no sustituye la validación clínica. El consentimiento del usuario tampoco resuelve por sí solo el tratamiento de datos sensibles, y aceptar un disclaimer no cambia la finalidad regulatoria del producto.

Volver a operar en el mercado europeo exige una hoja de ruta que pocas startups asumen al inicio. Finalidad prevista bien definida, separación entre usos informativos y clínicos, rol claro en protección de datos, arquitectura documentada, validación en población europea y, cuando corresponda, marcado CE bajo el Reglamento de Productos Sanitarios. No alcanza con traducir la política de privacidad ni abrir un centro de datos en Frankfurt. Lo que hace falta es rediseñar el producto desde cero para un mercado donde el cumplimiento se prueba con documentos y procesos auditables.

La pregunta de fondo ya no es si la IA puede ayudar en medicina. Sí puede. Lo que se discute es cómo se usa, con qué datos, con qué validación y quién responde cuando algo sale mal.

Fecha: 5 de mayo de 2026

Escrito por: María Noel Arana, Mariano E. Torres Ponce