Nivel 3 · En profundidad — Arts. 15 y 14, y el cruce MDR

§4 — Artículo 15 en profundidad: una barrera real y bloqueante — con límites honestos

El Nivel 2 encontró los artículos 9 a 13 levemente. La superposición es donde un artículo va en profundidad, y el primer artículo profundo del Nivel 3 es el Art. 15 (exactitud, robustez, ciberseguridad) — revelado por la barrera de sensibilidad en retinopatía diabética.

Este control es el artículo genuino: objetivo (un recall_score medido, no una autodeclaración), bloqueante (enforcement: block — un ROJO sale con código de error y el residual no se confirma) y respaldado por un análisis de potencia real (bootstrap por clúster de paciente, para que los ojos correlacionados de un mismo paciente no inflen la muestra). V1 ROJO (0,4165) → V2 VERDE limpio (0,8847, IC bajo 0,8516) es un riesgo real tratado y reevaluado. Eso es el Art. 15 funcionando como está previsto.

Pero la honestidad significa declarar los límites en voz alta, no esconderlos detrás del verde:

• La especificidad no se mide. La barrera es sensibilidad (recall) únicamente. Si el sistema también evita sobrederivaciones de ojos sanos (especificidad / TNR) no está en la barrera — la demostración del SDK no tiene métrica de especificidad, así que su ausencia está declarada, no disimulada.
• El VPP es solo de auditoría. El valor predictivo positivo (la contrapartida del recall en cuanto a sobrederivación) sí se mide, pero no entra en la barrera. La V2 maximiza el recall por diseño, así que su VPP es modesto — divulgado explícitamente, no en la barrera para quedar bien.
• Un único pliegue, una única semilla. La evidencia es un único pliegue del 20%, semilla = 42. Sin validación cruzada, sin múltiples semillas.
• Una sola población. La cohorte es ODIR-5K — una cohorte de un único país (China). No hay validación externa, temporal ni de población de la UE, y la barra de 0,80 es una referencia clínica, no un umbral aprobado por el regulador.

Una barrera técnica aprobada no es prueba de seguridad clínica

La barrera del Art. 15 demuestra algo real, medido y bloqueante: este modelo, sobre esta cohorte de validación, deriva ≥ 88% de los casos verdaderos de retinopatía diabética, y la evidencia es suficientemente sólida para demostrarlo. No demuestra que el dispositivo sea clínicamente seguro y eficaz para su población objetivo — eso es un juicio de beneficio-riesgo clínico (MDR Anexo XIV) fuera de cualquier motor de gestión del riesgo. Una barrera de sensibilidad en verde es necesaria, no suficiente. El §6 retoma por qué eso es exactamente el trabajo del organismo notificado y de la evaluación clínica, no del motor.

§5 — Artículo 14 en profundidad: supervisión humana organizativa, no objetivo-requerida

El segundo artículo profundo de la superposición es el Art. 14 (supervisión humana) — y es profundo de una forma distinta al Art. 15. Donde el Art. 15 es una barrera objetiva, medida y bloqueante, el Art. 14 aquí es organizativo y declarado, y — lo importante — eso es legítimo, no una salida fácil.

El riesgo es risk.insufficient-human-oversight: el sistema de cribado no puede convertirse en un diagnóstico final. El tratamiento es un conjunto de medidas organizativas, declaradas ex ante en el manifiesto (evaluation: manual, enforcement: audit):

• HITL (humano en el bucle). El oftalmólogo confirma o revoca cada derivación que propone el sistema; el clínico puede invalidar el modelo.
• Revisión clínica. Se asigna un rol revisor nombrado a cada decisión de derivación.
• Formación contra el sesgo de automatización. Los clínicos reciben formación para evitar confiar en exceso en la salida automatizada.

Estos no son barreras medidas — son compromisos declarados, solo de auditoría, que aparecen en el dossier del Anexo IV en lugar de bloquear el pipeline. Y ese es el tratamiento honesto y correcto para el Art. 14, por una razón específica.

Por qué 'declarado' es legítimo para el Art. 14 — y cómo el motor lo comprueba igualmente

El Art. 15 tiene métricas medibles (recall, precisión), así que el motor aplica barreras sobre ellas objetivamente. El Art. 14 no tiene una norma armonizada citada para él contra la que el motor pueda proyectar veredictos objetivos — así que la autodeclaración es la ruta legítima: el fabricante declara el diseño de supervisión y se responsabiliza de él, exactamente como lo haría en un dossier real. Aun así, el motor no se queda callado: sus veredictos del Art. 14 se apoyan en indicadores indirectos — comprueba que haya una aprobación presente en el paquete y que exista un plan de seguimiento, como evidencia estructural de que la obligación de supervisión está en el ámbito y atendida. El encuadre honesto: el Art. 14 aquí está declarado y auditado, nunca disfrazado de control medido. Contrasta con el Art. 15, que sí está medido — la proyección siempre muestra cuál es cuál.

---

§6 — El cruce documental MDR y la brecha del organismo notificado (el pago del nivel)

Ahora la superposición da sus frutos — y también la honestidad. El sistema declaró eu/mdr@2017, así que el motor proyecta sus riesgos y controles medidos sobre las cláusulas RGSF del MDR (Anexo I) y firma esa correspondencia. En el paquete confirmado puedes verlo directamente: el bloque means_of_conformance lista eu/mdr@2017 con sus cláusulas RGSF — eu/mdr@2017#gspr-17.1 (rendimiento/repetibilidad del SaMD, citado por el control de sensibilidad), eu/mdr@2017#gspr-9 (rendimiento consistente en la población, citado por los controles de equidad), eu/mdr@2017#mdr.gspr-8-residual-risk. El plano de control representa esto en el documento MDR completo — una lista RGSF + plan de poscomercialización + inventario SOUP — ensamblado a partir del paquete firmado.

Pero lee qué es ese documento — y qué no es:

El documento MDR es un cruce documental firmado, NO un veredicto de conformidad

La propia regla del motor (el ensamblador MDR del plano de control la enuncia como invariante): no calcula conformidad — proyecta evidencia ya firmada. Así que la salida MDR es un cruce documental firmado: una correspondencia fiel y verificable de lo que se midió y declaró sobre las cláusulas RGSF del MDR. Es documentación, del tipo que un fabricante prepara para un organismo notificado — no una declaración de que el dispositivo es conforme al MDR. La razón es estructural: el MDR es derecho vinculante, no una norma armonizada de gestión del riesgo en IA citada para el artículo 9, así que se sitúa fuera de la cadena de autoridad de veredictos del motor y no confiere ninguna presunción. Titúlalo como hace la demostración: «cruce documental firmado, NO un veredicto de conformidad». Decir que un sistema está «gobernado por el MDR» porque lleva este cruce documental es exactamente la reclamación excesiva que este curso rechaza.

Y el cruce documental es honesto sobre sus propios huecos — estas son las brechas que un organismo notificado abriría:

• Sin organismo notificado. Un dispositivo clase IIa necesita un organismo notificado acreditado e independiente (MDR Art. 52; Ley de IA Art. 31 sobre independencia). El firmante de la demostración es Dev Demo — ficticio, y la propia clave del fabricante, no un tercero independiente. Autofirmar es autodeclaración, que la clase IIa no puede usar.
• Sin evaluación clínica. El MDR (Anexo XIV) exige una evaluación clínica — una determinación de beneficio-riesgo de que el dispositivo es clínicamente seguro y eficaz. Eso es un juicio científico-clínico fuera del motor. Una barrera de sensibilidad aprobada ≠ beneficio-riesgo clínico.
• Cláusulas RGSF marcadas como brechas. Varias cláusulas del MDR (robustez ciberseguridad/adversarial, rendimiento clínico completo) el cruce documental las marca honestamente como brecha, no como «cubierto». (La auditoría de evidencia del organismo notificado en docs/security/2026-06-12-notified-body-evidence-audit.md las enumera desde la óptica de un auditor.)

Por eso el hito 4 se pausó en «solicitado»: la brecha no es un párrafo en un informe, es el estado no cerrable del ciclo de vida. El motor lleva al fabricante hasta la puerta del organismo notificado — gobernado, medido, documentado, firmado — y entonces se detiene honestamente.

El mapa de modalidades — dónde se sitúa este nivel

El curso nombra la clase de tratamiento y la clase de control en cada nivel. Aquí:

• Modalidad de tratamiento: un cambio de código — reentrenamiento con equilibrado de clases más un umbral de decisión 0,30. Contrasta con el Nivel 1 (un cambio de parámetro) y el Nivel 2 (un cambio de aprendiz con fairlearn). Los tres son commits versionados; el tratamiento es el git diff, sea cual sea su forma.
• Control de barrera: Art. 15 — sensibilidad en retinopatía diabética (recall) — objetivo, bloqueante, medido con un IC bootstrap por clúster (que es lo que hace que «VERDE limpio» sea demostrable en lugar de meramente afirmado).
• Control organizativo: Art. 14 — HITL + revisión clínica + formación contra el sesgo de automatización — declarado, solo de auditoría, legítimo porque ninguna norma armonizada está citada para el Art. 14.

---