El clasificador EU AI Act que nadie había escrito
Una herramienta abierta que convierte la descripción en lenguaje natural de un sistema de IA sanitario en un veredicto regulatorio auditable, con base legal citada, Anexo III mapeado y un PDF listo para pasar por un comité de cumplimiento.
Clasificar un sistema bajo EU AI Act no es trivial
El Reglamento 2024/1689 (EU AI Act) entró en vigor en agosto de 2024 y es, a fecha de hoy, la regulación más estricta del mundo sobre sistemas de inteligencia artificial. Para los sistemas sanitarios el impacto es inmediato: la mayoría cae como high-risk vía Anexo III, y eso obliga a gestión de riesgos, documentación técnica, gobernanza de datos, supervisión humana, registro en la base de datos de la UE y marcado CE cuando aplica MDR.
El problema práctico es que clasificar un sistema bajo el EU AI Act no se puede hacer con una tabla de Excel. Depende del propósito concreto, del contexto asistencial, de si el sistema toma decisiones autónomas o solo asiste, de si cae también bajo MDR como producto sanitario, de si entra en las prohibiciones del Artículo 5. Cada una de esas condiciones puede mover el veredicto entre cuatro niveles de riesgo con consecuencias regulatorias muy distintas.
En el mercado existen herramientas comerciales de compliance, pero son caras, opacas y suelen estar orientadas a grandes corporaciones. Para una startup HealthTech, un hospital que quiere auditar un proveedor o un investigador clínico, no hay una herramienta abierta que dé un veredicto auditable con la base legal citada artículo por artículo. Ese vacío es lo que el proyecto intenta cerrar.
Niveles de riesgo bajo el EU AI Act (prohibido · alto · limitado · mínimo). Cada condición del sistema puede mover el veredicto entre ellos con consecuencias regulatorias muy distintas.
Por qué un LLM solo no resuelve esto
La tentación inicial es obvia: pasar la descripción del sistema a un LLM potente y pedirle un veredicto. Funciona razonablemente bien en el 80% de los casos, y falla ruidosamente en el 20% restante, que son precisamente los casos frontera donde importa acertar.
Hay tres problemas estructurales. Primero, alucinación legal: un LLM puede citar un artículo que no existe o que no dice lo que afirma. En un informe regulatorio esto es inaceptable. Segundo, falta de trazabilidad: la misma entrada puede dar dos veredictos distintos en dos ejecuciones, algo que cualquier auditor rechazará. Tercero, degradación silenciosa: si el modelo se actualiza, el veredicto puede cambiar sin aviso, lo que rompe la reproducibilidad que exige el propio EU AI Act en sistemas auditables.
La decisión de diseño fue combinar LLM con motor de reglas estático bajo una arquitectura que garantiza no-degradación. El LLM propone, las reglas validan. Si el LLM da un veredicto que las reglas consideran inconsistente con la jurisprudencia codificada, gana la regla. Si hay discrepancia entre ambos, se escala a revisión humana y se registra.
El pipeline en dos etapas
La primera etapa es un agente Claude Sonnet 4.5 con prompt estructurado que recibe la descripción en lenguaje natural del sistema y devuelve un JSON con: propósito funcional, contexto asistencial, nivel de autonomía, datos que procesa, usuarios finales y salida clínica. No clasifica todavía. Solo extrae hechos verificables.
La segunda etapa es un motor de reglas escrito en Python que toma ese JSON y aplica la lógica del reglamento artículo por artículo. Primero comprueba Artículo 5 (prohibiciones: manipulación cognitiva, categorización biométrica, reconocimiento emocional en entornos clínicos). Después comprueba Anexo III (alta riesgo: dispositivos médicos bajo MDR, triaje de servicios esenciales, evaluación biométrica remota). Después los criterios de riesgo limitado y mínimo.
La salida final incluye: nivel de riesgo (PROHIBITED / HIGH_RISK / LIMITED_RISK / MINIMAL_RISK), categorías del Anexo III aplicables, flags del Artículo 5, base legal con cita textual por artículo, lista de requisitos de cumplimiento priorizados, y flag SaMD cuando el sistema cae bajo MDR. Todo ello se genera también como informe PDF auditable con WeasyPrint.
La invariante de no-degradación es explícita: el motor de reglas nunca puede devolver un veredicto menos restrictivo que el propuesto por el agente LLM. Si el agente dice HIGH_RISK y las reglas dicen LIMITED_RISK, gana HIGH_RISK. La lógica es deliberada: en dudas de clasificación regulatoria, el error conservador siempre es menos dañino que el permisivo.
Por qué el criterio clínico cambia la clasificación
Una herramienta de compliance escrita sin criterio clínico tiende a clasificar casi todo como alto riesgo. Es el reflejo conservador del abogado regulatorio: ante la duda, sube la categoría. El problema es que eso paraliza innovación legítima que no supone riesgo clínico real, y hunde proyectos HealthTech que podrían desplegarse con categoría limitada bajo condiciones razonables.
El criterio clínico permite matizar dos cosas que la lectura jurídica pura pasa por alto. Primero, el contexto de uso real: un sistema de triaje automático en urgencias no es lo mismo que un sistema de priorización de listas de espera quirúrgicas. Ambos tocan triaje asistencial, pero el primero tiene impacto inmediato sobre vida del paciente y el segundo tiene capas de revisión humana que cambian el perfil de riesgo. Segundo, la cadena de decisión: un sistema que recomienda versus un sistema que decide versus un sistema que filtra pacientes antes de que lleguen al clínico.
En ClinAI Classifier, esa lectura clínica está codificada en el prompt del agente y en los chequeos del motor de reglas. No son abstracciones legales. Son las mismas preguntas que yo me hago cuando reviso un producto sanitario con un equipo de Medical Affairs: ¿cuándo se usa?, ¿quién confirma?, ¿qué pasa si falla?, ¿el paciente llega a saberlo?
Para quién resuelve un problema
Para una startup HealthTech, ClinAI Classifier es la primera herramienta que permite hacer una pre-auditoría regulatoria en quince minutos sin contratar a un despacho. El informe PDF no sustituye al asesor legal; lo prepara. Cuando el equipo legal llega, llega con un documento base sobre el que trabajar, no desde cero. Eso reduce el tiempo de validación regulatoria de semanas a días.
Para un hospital que evalúa un proveedor, el clasificador permite auditar la narrativa comercial del fabricante contra la norma europea. Muchos pliegos de licitación pública ya exigen declaración de conformidad EU AI Act; el comprador público puede usar esta herramienta para verificar que la declaración del proveedor coincide con la clasificación independiente.
Para una consultora que diseña pliegos o memorias técnicas, la herramienta es un punto de partida para redactar requisitos técnicos ajustados al nivel de riesgo real del sistema. Un pliego que exige requisitos de alto riesgo cuando el sistema es de riesgo limitado encarece el proyecto sin aportar seguridad adicional. Un pliego que exige de menos expone al comprador público.
Stack y marco regulatorio
| Lenguaje | Python 3.11 |
| Agente LLM | Claude Sonnet 4.5 vía Anthropic API |
| Backend | FastAPI · motor de reglas estático en Python |
| Frontend demo | Streamlit desplegado en Hugging Face Spaces |
| Generación PDF | WeasyPrint · plantilla HTML/CSS editorial |
| Contenedorización | Docker · reproducibilidad en entornos corporativos |
| Marco regulatorio | EU AI Act (Reglamento 2024/1689) · Anexo III · Artículo 5 · SaMD · MDR |
¿Tu equipo necesita clasificar un sistema bajo EU AI Act?
Puedo revisar la clasificación, validar el encaje Anexo III y ayudaros a preparar la documentación técnica que exige el reglamento. Tanto para HealthTech en fase de despliegue como para consultoras que estén redactando pliegos.