Nivel 6 · Cadena de suministro — el proyecto final

🟡 Parcial — Las dos entregas firmadas son repositorios públicos REALES (org Venturalitica), cada uno etiquetado a mano en HEAD como un único estado (sin arco V1→V2): vldemo-retina-delivery @ retina-delivery-v1.0.0-blocked y vldemo-quickstart-delivery @ quickstart-delivery-v1.0.0-accepted. Las transcripciones de `froga verify` mostradas abajo son REALES (froga 0.1.1) — ambas imprimen `firma VÁLIDA` y salen con 0. La barrera de reproducción nocturna re-ejecuta `froga verify` (afirmando código de salida 0) más un espejo de aceptación con jq sobre ambas etiquetas, afirmando BLOQUEADA para la entrega de retina y ACEPTADA para la de educación. Fronteras honestas: NO hay organismo notificado en la cadena (Aitor verifica, no certifica). El pliego como código SÍ está construido (`froga sign-pliego` + `froga conformance --against-pliego`: el umbral lo impone el pliego); siguen siendo HOJA DE RUTA la generación de cláusulas EU MCC-AI / el ligado eIDAS de clave a identidad legal / la transparencia Sigstore-Rekor / un grafo federado multi-proveedor / la retención probatoria a 10 años.

TL;DR

Este es el proyecto final (capstone). A lo largo de los Niveles 1-5, el equipo de un proveedor — Diego (Calidad) y Marta (ingeniera) — construyó y firmó un sistema de IA dentro de su propio repositorio git. Ahora amplía el plano hasta la cadena de contratación. Un organismo público receptor, Servizo Atlante de Saúde (org saude-atlante), está comprando IA a dos proveedores, y cada uno entregó replicando su repositorio firmado (mirror) — solo se mueven resúmenes y evidencia firmada; los pesados pesos del modelo quedan en custodia del proveedor. Proveedor A — Ollomar Diagnóstica S.L. entrega un cribador de retina (un dispositivo médico). Proveedor B — EduAtlante Analytics S.L. entrega un modelo de educación. Un auditor externo, Aitor, situado del lado del comprador, verifica cada entrega usando solo la clave pública del proveedor — sin claves privadas, sin tránsito de datos, sin llamadas de red. Aquí está el desenlace de todo el curso en una línea: ambas entregas verifican como auténticas (firma VÁLIDA, código de salida 0) — incluso la que está bloqueada — pero una está BLOQUEADA y otra ACEPTADA, y NINGUNA es «conforme». La barrera de aceptación es un criterio del pliego (firmas válidas y ningún control bloqueante en ROJO), no un certificado de conformidad; y no hay organismo notificado en ningún punto de esta cadena. Tres cosas distintas, que nunca deben confundirse: autenticidad (¿la firma cuadra?) ≠ aceptación (¿se abre la barrera del pliego del comprador?) ≠ conformidad (¿se cumple cada cláusula de la ley, según un juicio cláusula a cláusula?). Aitor prueba la primera, la barrera del pliego decide la segunda, y solo un organismo notificado acreditado puede emitir la tercera — algo que nadie en esta cadena hace.

Este nivel amplía el plano desde un proveedor hasta toda la cadena de contratación. Si no has conocido a un auditor externo o el encuadre de la cadena de suministro, lee primero esto:

Nivel 5 · Cribado de candidaturas — debuta AitorEl nivel anterior, donde apareció por primera vez el auditor externo Aitor: ejecutó `froga verify` con solo una clave pública para confirmar autenticidad y leer el estado abierto honesto — pero NO certificó. El Nivel 6 pone a Aitor en el centro, verificando DOS proveedores a lo largo de un traspaso de contratación.

La cadena de suministro — traspasos firmados entre organizacionesEl concepto sobre el que corre este proyecto final: una cadena federada de entregas firmadas (proveedor → comprador), donde solo resúmenes y evidencia firmada cruzan la frontera, los pesos quedan en custodia, y autenticidad / aceptación / conformidad son tres juicios distintos.

Prerrequisitos

Toda la columna vertebral (Niveles 1 y 2 para el armazón de alto riesgo de los Artículos 9-15), ¿Qué es una superposición?, e idealmente las tres superposiciones (Nivel 3 retina/MDR, Nivel 4 crédito/DORA, Nivel 5 talento/empleo), más ¿Qué es un riesgo? para el vocabulario ROJO / ÁMBAR / VERDE. Una nota sobre los materiales:

Este nivel es MIRAR, no ejecutar. Aquí no construyes ni firmas nada — los dos proveedores ya lo hicieron en sus propios repositorios (eso fue los Niveles 1-5). Te sientas en el asiento del comprador: clonas cada entrega, lees los dossiers confirmados y ejecutas las transcripciones reales de froga verify mostradas en el §3. El veredicto de aceptación (bloqueada / aceptada) se lee de la evidencia confirmada, reflejado por la barrera nocturna.
Aitor (auditor externo, verificación solo-de-clave-pública) es ahora la figura central, del lado del comprador. Diego y Marta están dentro de un proveedor — construyeron y firmaron el sistema en los niveles anteriores; aquí su trabajo es el input que Aitor verifica.

Al terminar sabrás…

Describir el traspaso de contratación de tres actores: un proveedor firma en su propio repositorio, un responsable del despliegue (el organismo público receptor) verifica y acepta, y un auditor externo (Aitor) comprueba la autenticidad con solo una clave pública — y decir qué cruza la frontera (resúmenes + evidencia firmada) y qué no (los pesos del modelo).
Ejecutar (y leer) las transcripciones reales de froga verify para ambas entregas, y explicar por qué ambas imprimen firma VÁLIDA y salen con 0 aunque una entrega esté bloqueada.
Mantener separadas las tres cosas distintas: autenticidad ≠ aceptación ≠ conformidad — y situar cada una de las dos entregas en los tres ejes.
Explicar la barrera de aceptación como un criterio del pliego (firmas válidas y ningún control bloqueante en ROJO) — y por qué gapToFullConformance se computa independientemente y nunca voltea la decisión de aceptar/bloquear.
Decir por qué no hay organismo notificado en la cadena: Aitor verifica y lee el estado honesto pero no certifica (sin acreditación, no está en NANDO), y el cruce documental de MDR en la entrega de retina es un cruce documental únicamente, nunca «MDR gobernada».
Explicar cómo el pliego impone el umbral: la AAPP firma su pliego OSCAL con froga sign-pliego y el comprador comprueba la entrega con froga conformance --against-pliego (exit ≠ 0 si falla un control block) — el umbral lo impone el pliego, no lo declara el proveedor.
Nombrar las fronteras de hoja de ruta con honestidad: la generación de cláusulas EU MCC-AI a partir del pliego, el ligado eIDAS clave↔identidad-legal (hoy el comprador ancla la clave fuera de banda = TOFU), la transparencia Sigstore/Rekor, un grafo federado multi-proveedor, y la retención a 10 años.

Las lecciones de este nivel

El encuadre — el traspaso de contratación y las leyes de la cadenaUn organismo público receptor contrata IA a dos proveedores que construyeron y firmaron su sistema en su propio repositorio git; qué leyes gobiernan la cadena de suministro.

La verificación con clave públicaAitor, auditor externo, verifica cada entrega con SOLO la clave pública del proveedor (sin claves privadas, sin tránsito de datos): ambas verifican como auténticas, pero una queda BLOQUEADA y otra ACEPTADA.

En profundidad — autenticidad ≠ aceptación ≠ conformidadLas tres cosas distintas (verificar ≠ la barrera del pliego ≠ el juicio cláusula a cláusula), por qué no hay organismo notificado en la cadena y qué está en custodia frente a qué es hoja de ruta.

Cierre del cursoRepasa el desenlace del proyecto final (autenticidad ≠ aceptación ≠ conformidad) y autocomprueba lo aprendido en todo el curso.