Nivel 3 · Práctica y cierre
This content is not available in your language yet.
Observa la evidencia
Sección titulada «Observa la evidencia»Aquí no hay «ejecútalo tú mismo» — el reentrenamiento usa GPU. En su lugar, observa la evidencia confirmada y verifícala tú mismo solo con git y froga (sin GPU, sin conjunto de datos). El motor vuelve a derivar el veredicto a partir de las salidas confirmadas, que es exactamente lo que hace la barrera de reproducción nocturna:
Con el repositorio ya situado en el hito (el chip está en el arco), verifica y re-deriva el veredicto:
# 1. Verifica la evidencia firmada (sin GPU, sin conjunto de datos — solo el paquete confirmado)froga verify # comprueba bundle.json contra su firma
# 2. Vuelve a derivar el veredicto de la barrera desde las SALIDAS CONFIRMADAS (Outcome::Reused — sin reentrenamiento)froga run # lee las métricas confirmadas → VERDE (recall 0,8847, IC bajo 0,8516)
# 3. Lee la evidencia a mano# .froga/bundle.json → control_results[model-dr-sensitivity]: recall 0,8847, passed:true,# power.ci_low 0,8516 (> 0,80) → verde limpio# → means_of_conformance lista eu/mdr@2017 con sus cláusulas RGSF (el cruce documental)# → overall_residual: HIGH / within (lifecycle: draft, approval: null)
# 4. Compara los otros dos hitos — el motor vuelve a derivar rojo, verde, verde:git checkout retina-v1.0.0-red && froga run # ROJO (recall 0,4165, passed:false)git checkout retina-v2.0.0-request && froga run # VERDE, pero sigue en draft / approval:nullEl paso 3 es el núcleo honesto de «mirar, no ejecutar»: froga run toma la ruta Reused sobre las salidas confirmadas, así que el motor actual vuelve a derivar el mismo color sin GPU. Una tarea de CI nocturna hace exactamente esto para las tres etiquetas y afirma rojo / verde / verde — así que la evidencia que acabas de leer está verificada automáticamente para que siga reproduciéndose. Lo que no deberías ver en retina-v2.0.0-request es un approve: el ciclo está honestamente pausado.
Los actos de cierre sí puedes ejecutarlos tú (operan sobre el paquete confirmado, sin GPU ni conjunto de datos). Cada bloque de abajo es el paso REAL del guion steps/ —el mismo que construye el repositorio publicado, no una copia a mano—: Marta emite la conformidad por norma aplicable + el reconstruct firmados, y solicita la aprobación. Ahí termina el guion:
patch: entitlement.patchfroga conformance --standard eu/pren-18228@2026 --outmay failfroga conformance --standard iso/23894@2023 --outmay failfroga conformance --standard eu/ai-act@2024 --outmay failfroga conformance --standard eu/mdr@2017 --outmay failfroga conformance --standard eu/pren-18283@2026 --outmay failfroga conformance --standard eu/pren-18282@2026 --outmay failfroga reconstruct --outmay failgit add -Agit commit -m ".froga: conformance + reconstruct firmados"
solicitud de aprobación (el acto lo commitea froga request)No hay paso de aprobación después, y no lo hay a propósito: un clase IIa no se cierra por autodeclaración. El acto de solicitud es quien la CLI atribuye —Marta lo firma— y ahí queda el ciclo, en «solicitado», anclado en retina-v2.0.0-request.
Lo que acabas de ver
Sección titulada «Lo que acabas de ver»Tu primera superposición: un sistema de cribado de retinopatía diabética bajo dos regímenes a la vez — de alto riesgo bajo la Ley de IA de la UE (vía Art. 6(1) + Anexo I, la ruta de seguridad de productos) y un dispositivo médico MDR clase IIa. El riesgo de seguridad del paciente era real (recall V1 0,4165, perdiendo la mayoría de los casos de retinopatía diabética sobre imágenes reales ODIR-5K), el tratamiento fue un cambio de código versionado (reentrenamiento con equilibrado de clases + umbral 0,30), y V2 cerró en VERDE limpio — recall 0,8847, bootstrap IC bajo 0,8516 > 0,80 — demostrablemente, no por afirmación, porque la cohorte era suficientemente grande (en contraste con el ámbar honesto del Nivel 2 con n = 99). El Art. 15 fue en profundidad como una barrera real y bloqueante con sus límites declarados (especificidad no medida, VPP solo de auditoría, un único pliegue/semilla, una sola población). El Art. 14 fue en profundidad como supervisión organizativa declarada y legítima. El motor emitió un cruce documental MDR firmado — documentación, no un veredicto de conformidad — y sin DORA (no es una entidad financiera). Y entonces el ciclo se pausó en «solicitado»: un dispositivo clase IIa no puede cerrarse sin un organismo notificado externo que el motor no es. Esa parada honesta es toda la lección del Nivel 3 — la parte más difícil del cumplimiento es saber, y decir, dónde termina tu evidencia.
Autocomprobación
Sección titulada «Autocomprobación»¿Qué hace al Nivel 3 una 'superposición' y cómo se activa la clasificación de alto riesgo aquí en comparación con el Nivel 2?
Es una superposición porque un mismo sistema está sujeto a dos regímenes a la vez: la Ley de IA de la UE (que lo gobierna como sistema de IA) y el MDR (que lo gobierna como dispositivo médico, clase IIa) apilado encima. La activación difiere del Nivel 2. La selección de estudiantes era de alto riesgo por su uso — Anexo III §3 (educación). El sistema de cribado de retina lo es porque es un componente de seguridad de un dispositivo médico, así que la activación es Art. 6(1) + Anexo I (la ruta de seguridad de productos). El mismo hecho — «esto es un dispositivo médico» — lo hace a la vez de alto riesgo bajo la Ley de IA (vía Art. 6(1)) y un dispositivo MDR por sí mismo. (Sin DORA: el operador es una clínica, no una entidad financiera.)
El motor emite un documento MDR firmado para este sistema. ¿Por qué eso es un 'cruce documental, no un veredicto', y por qué no debes decir nunca que el sistema está 'gobernado por el MDR'?
Porque el invariante del motor es que no calcula conformidad — proyecta evidencia ya firmada. 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 — documentación que un fabricante prepara para un organismo notificado, no una declaración de que el dispositivo es conforme al MDR. Estructuralmente, 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. Llamar al sistema «gobernado por el MDR» porque lleva el cruce documental reclama en exceso una capacidad que el motor no tiene; el veredicto de conformidad pertenece a la ruta propia del MDR — para un dispositivo clase IIa, un organismo notificado externo. Titúlalo: «cruce documental firmado, NO un veredicto de conformidad».
V2 cerró en VERDE limpio — la barrera de seguridad del paciente pasó y el IC superó la línea. ¿Por qué el ciclo se pausa entonces en 'solicitado' en lugar de aprobarse?
Porque un dispositivo médico clase IIa no puede cerrar su ciclo de conformidad sobre la propia atestación del fabricante. El procedimiento de evaluación de conformidad del MDR (Art. 52) exige que un organismo notificado acreditado e independiente evalúe la evidencia y emita un certificado antes de que el dispositivo pueda comercializarse — y el motor no es un organismo notificado. Firma con la propia clave del desarrollador (un firmante ficticio Dev Demo), lo que es autodeclaración, lo contrario de la evaluación de tercero independiente que exige el MDR; y el MDR también exige una evaluación clínica (Anexo XIV) que vive fuera de cualquier motor de gestión del riesgo. Una barrera técnica en verde es necesaria pero no suficiente. Así que lo más honesto que puede hacer el ciclo de vida es pausarse en «solicitado» (estado draft, approval: null): todo lo que hay antes del organismo notificado está hecho y firmado, y el ciclo espera en el límite que no puede cruzar. Esa pausa es la brecha del organismo notificado, escrita en la máquina de estados.
A dónde ir ahora
Sección titulada «A dónde ir ahora»Ya has conocido tu primera superposición, dos artículos en profundidad (15 y 14) y la brecha honesta del organismo notificado. Las demás superposiciones apilan regímenes diferentes sobre la misma columna vertebral: