Nivel 6 · Cierre del curso
Lo que acabas de ver
Sección titulada «Lo que acabas de ver»El proyecto final. Un organismo público receptor — Servizo Atlante de Saúde — contrató IA a dos proveedores, cada uno de los cuales construyó y firmó un sistema de IA en su propio repositorio git (ese trabajo fue los Niveles 1-5) y entregó replicando el repositorio. Proveedor A — Ollomar Diagnóstica S.L. entregó un cribador de retina (un dispositivo médico, con un cruce documental de MDR); Proveedor B — EduAtlante Analytics S.L. entregó un modelo de educación (conjunto de normas de la Ley de IA, sin MDR). El auditor externo, Aitor, verificó cada uno con solo la clave pública del proveedor — sin claves privadas, sin tránsito de datos, sin red. Ambas entregas imprimieron firma VÁLIDA y salieron con 0 — la entrega de retina 7/7, la de educación 6/6 — probando autenticidad para ambas. Y sin embargo: la entrega de retina está BLOQUEADA (su control bloqueante model-dr-sensitivity está en ROJO — recall 0.414 < 0.80, Art. 15 de la Ley de IA), mientras que la de educación está ACEPTADA (su control bloqueante fairness-parity está en VERDE, ningún bloqueante en ROJO). Ninguna es «conforme» — gapToFullConformance se computa independientemente, nunca voltea el veredicto, y es verdadero para ambas. Así que aterrizaron las tres cosas distintas: autenticidad (el verify de Aitor) ≠ aceptación (la barrera del pliego del comprador = firmas válidas + ningún bloqueante en ROJO) ≠ conformidad (un juicio cláusula a cláusula que solo un organismo notificado puede emitir — y no hay ninguno en esta cadena). Proveedor frente a responsable del despliegue (Art. 16 / Art. 25) dividió las responsabilidades: el proveedor firma, el comprador verifica y acepta. El cruce documental de MDR es un cruce documental únicamente, nunca «MDR gobernada». El pliego como código ya está construido (froga sign-pliego + froga conformance --against-pliego: el umbral lo impone el pliego, no el proveedor); y las fronteras restantes se nombraron con honestidad: la generación de cláusulas EU MCC-AI, eIDAS (hoy la clave está anclada/TOFU, no atribuida legalmente), Sigstore/Rekor, un grafo federado, y la retención a 10 años — todo hoja de ruta. La línea que hay que retener: una firma válida prueba que los bytes son auténticos; no abre la barrera del pliego, y no certifica la ley.
Autocomprobación
Sección titulada «Autocomprobación»Enuncia los tres juicios distintos sobre los que gira este nivel — autenticidad, aceptación, conformidad — y sitúa CADA una de las dos entregas en los tres.
Autenticidad = ¿son los bytes exactamente lo que el poseedor de la clave privada firmó? Establecida por el froga verify de Aitor (firma VÁLIDA, código de salida 0). Aceptación = ¿se abre la barrera del pliego del comprador? Decidida por deliveryAcceptance = las firmas verifican y ningún control bloqueante en ROJO. Conformidad = ¿se cumple cada cláusula de la ley? Un juicio cláusula a cláusula que solo un organismo notificado acreditado puede emitir. Ahora las dos entregas: el Proveedor A (Ollomar, retina) es auténtico (7/7 firma VÁLIDA, código de salida 0) + NO aceptado (bloqueante model-dr-sensitivity en ROJO, recall 0.414 < 0.80 → BLOQUEADA) + NO conforme (lleva una brecha documentada). El Proveedor B (EduAtlante, educación) es auténtico (6/6 firma VÁLIDA, código de salida 0) + aceptado (bloqueante fairness-parity en VERDE, ningún bloqueante en ROJO) + NO conforme (aún lleva una brecha documentada — gapToFullConformance es verdadero y se computa independientemente de la decisión de aceptar/bloquear). Ninguna entrega es «conforme»; la conformidad es un juicio separado que nadie en esta cadena emitió.
Ambas entregas imprimen `firma VÁLIDA` y salen con 0 — pero una está BLOQUEADA y otra ACEPTADA. ¿Cómo pueden ser ambas auténticas mientras su aceptación difiere?
Porque verificar prueba autenticidad, no aceptación — responden preguntas diferentes. froga verify comprueba la firma DSSE in-toto de cada artefacto: keyid == sha256(clave pública), una firma ECDSA-P256 válida sobre el DSSE PAE, y el subject digest in-toto == sha256(bytes del artefacto). Sale con 0 si y solo si todos los artefactos presentes verifican — así que ambas entregas pasan (retina 7/7, educación 6/6) porque en ambos casos los bytes son exactamente lo que el firmante firmó. La aceptación es un juicio separado hecho por la barrera del pliego del comprador (deliveryAcceptance): aceptada si y solo si las firmas verifican y ningún control bloqueante está en ROJO. El control bloqueante model-dr-sensitivity de la entrega de retina está en ROJO (recall 0.414 < 0.80), así que la barrera del pliego queda cerrada → BLOQUEADA; el control bloqueante fairness-parity de la entrega de educación está en VERDE sin ningún bloqueante en ROJO → ACEPTADA. Una entrega perfectamente auténtica puede ser una perfectamente bloqueada: la autenticidad es un hecho criptográfico sobre los bytes; la aceptación es un juicio sobre el contenido contra el pliego.
¿Por qué no hay organismo notificado en esta cadena, y por qué 'aceptada' (o incluso 'auténtica') NO significa 'conforme'?
Porque Aitor verifica pero no certifica, y la barrera de aceptación es una barrera del pliego, no un certificado CE. Aitor es un auditor externo del lado del comprador: con solo la clave pública prueba autenticidad y lee el estado honesto (bloqueada / aceptada / la brecha documentada) — pero no tiene acreditación, no está en NANDO, y no tiene certificado que emitir. El veredicto «aceptada» del comprador es una decisión de contratación (firmas válidas + ningún bloqueante en ROJO contra el pliego), no una evaluación de conformidad — el texto de interfaz de la nube incluso afirma literalmente que la opinión de conformidad cláusula a cláusula «la emite el organismo notificado», no esta barrera. La conformidad es un juicio separado, cláusula a cláusula, que solo un organismo notificado acreditado e independiente puede hacer — y no hay ninguno en esta cadena. Así que «auténtica» significa los bytes son lo que el firmante firmó, «aceptada» significa se cumplió el criterio del pliego, y ninguna significa el producto cumple la ley cláusula a cláusula — gapToFullConformance es verdadero para ambas entregas, computado independientemente y sin voltear nunca el veredicto de aceptar/bloquear. El cruce documental de MDR del cribador de retina es un cruce documental únicamente (nunca «MDR gobernada»); un dispositivo de Clase IIa según MDR necesitaría un organismo notificado bajo el procedimiento del MDR (Art. 52) que esta cadena no tiene.
A dónde ir ahora
Sección titulada «A dónde ir ahora»Has llegado al final del curso. A lo largo de seis niveles fuiste de la columna vertebral ISO-pura (N1) al armazón de alto riesgo (N2), pasando por tres superposiciones — salud/MDR (N3), finanzas/DORA (N4), empleo (N5) — y ahora a la cadena de contratación (N6), donde aterrizó todo el sentido: autenticidad ≠ aceptación ≠ conformidad, verificada por un auditor que no certifica, sin organismo notificado en la cadena. Para profundizar en los mecanismos que tocó este proyecto final: