Aseguramiento de la cadena de suministro: entrega ≠ conformidad

⚡ TL;DR

Cuando una organización compra un sistema de IA a otra, el comprador tiene un problema de confianza: ¿cómo sabes que lo que recibiste es exactamente lo que el proveedor construyó, y que es lo bastante bueno para aceptarlo? La respuesta que da este curso es la entrega git-nativa. El proveedor construye y firma criptográficamente la evidencia del sistema en su propio repositorio, y luego entrega replicando el repositorio (mirror) — solo cruzan el traspaso los resúmenes (digests) y la evidencia firmada; los pesados pesos del modelo quedan en custodia del proveedor, referenciados por un hash anclado (dvc.lock). El comprador ejecuta froga verify con solo la clave pública del proveedor — ninguna clave privada cambia de manos, nada se ejecuta en la red, ningún dato transita. Pero aquí está la lección, y son tres lecciones en una. Una firma verificada prueba autenticidad — la evidencia es byte a byte lo que el firmante comprometió. No prueba que la entrega esté aceptada — esa es la decisión de la barrera del pliego del comprador (firmas válidas y ningún control bloqueante en ROJO). Y ninguna de las dos prueba conformidad — que el producto realmente cumple la ley, un juicio cláusula a cláusula que, para las clases de alto riesgo, solo un organismo notificado acreditado puede emitir. Una entrega puede ser auténtica y estar aceptada y seguir llevando una brecha documentada hacia la conformidad plena. Tres barreras distintas — no las colapses. Y la frontera: no hay organismo notificado en esta cadena.

🎯 Al terminar sabrás…

• Describir el traspaso git-nativo: el proveedor firma la evidencia en su repositorio y entrega por réplica (mirror); solo cruzan resúmenes + evidencia firmada, mientras los pesos quedan en custodia tras un hash anclado.
• Explicar qué comprueba froga verify — un sobre in-toto/DSSE, ECDSA-P256, keyid == sha256(clave pública) — y que es solo-de-clave-pública, local y no mueve ningún dato.
• Distinguir las tres cosas que la cadena puede establecer — autenticidad ≠ aceptación ≠ conformidad — y por qué una entrega verificada y aceptada puede seguir siendo no conforme.
• Enunciar la frontera con honestidad: no hay organismo notificado en esta cadena; un auditor que ejecuta froga verify confirma autenticidad pero no certifica.
• Situar la división proveedor/responsable del despliegue (Ley de IA de la UE Art. 16 / Art. 25, divulgación bajo Art. 47) a lo largo del traspaso — y nombrar lo que es hoja de ruta, no construido.

El traspaso: evidencia firmada, custodia conservada

Un proveedor construye un sistema de IA y un comprador lo quiere. El traspaso ingenuo lo envía todo — código, pesos, datos, informes — y espera que el comprador confíe en el paquete. El traspaso git-nativo es más esbelto y más fiable.

El proveedor gobierna el sistema en su propio repositorio git, y al final firma la evidencia bajo .froga/ — el paquete (bundle), el registro de reconstrucción, los resultados de conformidad por norma, cada uno con una firma separada. La entrega es entonces solo replicar el repositorio (mirror) hacia el comprador. Solo cruzan el traspaso resúmenes y evidencia firmada. Los pesados pesos del modelo y los conjuntos de datos no lo hacen — git lleva solo un puntero más un hash (dvc.lock), y ese hash está a su vez anclado dentro de la firma.

Los pesos quedan en custodia del proveedor, tras su backend de MLOps (un DVC remote). El comprador descarga los bytes y los comprueba contra el hash anclado, o los re-deriva de forma determinista — nunca a través de ninguna infraestructura de un tercero o intermediario. Así que el comprador acaba con un registro pequeño y verificable que compromete al proveedor con exactamente los pesos que construyó, sin que esos pesos hayan tenido que fluir nunca por un intermediario no confiable.

Qué cruza realmente el cable

Dos cosas, y solo dos: resúmenes (hashes que nombran los artefactos) y evidencia firmada (el dossier .froga/ con sus ficheros .sig). El grueso — pesos del modelo, datos de entrenamiento — se queda donde está. El comprador confía en un hash anclado en una firma, luego descarga o re-deriva los bytes y los comprueba contra ese hash. El traspaso es pequeño porque la confianza no requiere enviar los bytes pesados; requiere comprometerse con ellos, criptográficamente.

Verificar con una clave pública

froga verify lee el dossier firmado bajo .froga/ y comprueba todos los artefactos presentes. Cada firma es un sobre DSSE in-toto — un formato estándar, no una comprobación propietaria:

• el tipo de payload es application/vnd.in-toto+json;
• la firma es ECDSA-P256 sobre el DSSE PAE (pre-authentication encoding);
• el keyid es igual a sha256(clave pública), de modo que la clave que firmó queda nombrada por su propio hash;
• el subject digest in-toto es igual a sha256(los bytes del artefacto), vinculando la declaración al fichero exacto.

Es solo-de-clave-pública (el comprador nunca ve una clave privada), local (sin llamada de red) y no mueve ningún dato. El código de salida es 0 si y solo si todos los artefactos presentes verifican; un artefacto presente al que le falta su .sig falla, así que no puedes descartar silenciosamente una firma. Como es in-toto/DSSE puro, cualquier verificador in-toto puede comprobar el mismo sobre — el comprador no queda atado a una herramienta específica de froga.

Lo que un froga verify en verde prueba es exactamente una cosa: autenticidad. La evidencia es byte a byte lo que el firmante comprometió, sin manipular. Fíjate en lo que no prueba — una entrega bloqueada (con una barrera en ROJO) sigue verificando como auténtica. La autenticidad va sobre quién comprometió qué, no sobre si pasa.

Tres cosas, no una: autenticidad ≠ aceptación ≠ conformidad

Este es el corazón de la página. La cadena de suministro puede establecer tres cosas diferentes, y el error más común es colapsarlas en una.

Tres barreras, tres preguntas distintas

La autenticidad pregunta «¿es esta evidencia realmente lo que el firmante comprometió?» — la responde froga verify con la clave pública. La aceptación pregunta «¿pasa la barrera del pliego del comprador?» — una decisión de contratación, no un certificado. La conformidad pregunta «¿cumple el producto realmente la ley, cláusula a cláusula?» — para las clases de alto riesgo, el juicio de un organismo notificado acreditado. Una entrega puede ser auténtica y estar aceptada y seguir siendo no conforme, porque puede quedar una brecha documentada. Nunca dejes que un solo tic verde sustituya a las tres.

Cosa	Pregunta	Quién / qué la responde	Lo que NO es
Autenticidad	¿Es esta evidencia exactamente lo que el firmante comprometió?	froga verify, solo-de-clave-pública	No es aceptación; una entrega bloqueada sigue verificando
Aceptación	¿Pasa la barrera del pliego del comprador?	La decisión de contratación del comprador: firmas válidas Y ningún control enforcement: gate en ROJO	No es un certificado de conformidad
Conformidad	¿Cumple el producto la ley, por cláusula?	Un organismo notificado acreditado (clases de alto riesgo)	No es la barrera del comprador; no es lo que una firma prueba

La barrera de aceptación es precisa: una entrega está ACEPTADA si y solo si (a) las firmas verifican Y (b) ningún control bloqueante (enforcement: gate) está en ROJO. Los controles de auditoría / warn no bloquean. Y crucialmente, la brecha hacia la conformidad plena (gapToFullConformance) se computa independientemente de la aceptación y nunca la cambia — una entrega ACEPTADA puede seguir llevando una brecha documentada hacia la conformidad plena. La barrera del comprador es un criterio del pliego, no un certificado.

Sin organismo notificado en la cadena

Aquí está la frontera, enunciada con claridad: no hay organismo notificado en este traspaso. Un comprador — o un auditor externo que actúa por el comprador — puede ejecutar froga verify con solo la clave pública, confirmar que la evidencia del proveedor es auténtica y leer el estado honesto (qué barreras están en verde, cuáles en ROJO, qué brecha queda). Esa verificación por un tercero es real y útil.

Pero no es certificación. El auditor no está acreditado para certificar, y la barrera de aceptación del comprador es una decisión de contratación, no de conformidad. Para las clases de alto riesgo, solo un organismo notificado acreditado puede emitir un certificado de conformidad reconocido — y no hay tal organismo en esta cadena. Verificar una firma confirma que la evidencia es lo que el firmante dice que es; una evaluación de organismo notificado confirma que el producto cumple el reglamento. La cadena puede establecer autenticidad y hacer visibles las brechas; no puede cerrar la cuestión de la conformidad para las clases de alto riesgo.

La parada honesta, de nuevo

Esta es la misma frontera que encuentras en la página de organismo notificado, ahora con forma de comprador/vendedor. El proveedor autodeclara y firma; el comprador verifica y acepta; un auditor puede re-verificar. Ninguno de ellos es un organismo notificado. La cadena es honesta precisamente porque no disfraza la aceptación de certificación.

Proveedor frente a responsable del despliegue, y qué es hoja de ruta

El traspaso también divide las obligaciones legales. Bajo la Ley de IA de la UE, el proveedor es típicamente el proveedor (Art. 16) y el comprador el responsable del despliegue (Art. 25); el proveedor declara conformidad y la divulga (Art. 47), el comprador verifica la evidencia firmada y opera el sistema. La firma es lo que hace esa división auditable: las obligaciones del proveedor están confirmadas en el paquete que firma, y el responsable del despliegue puede comprobar exactamente lo que está asumiendo.

El pliego como código ya está construido: el comprador impone el umbral bloqueante a través del propio pliego. La AAPP firma su pliego OSCAL con froga sign-pliego y comprueba la entrega del licitador con froga conformance --against-pliego <pliego> --aapp-pubkey <hex> (exit ≠ 0 si falla un control block). Lo que queda por construir es derivar el pliego automáticamente de las Cláusulas Contractuales Modelo para IA de la UE.

Otras piezas están nombradas aquí pero todavía no construidas — enséñalas como hoja de ruta, no como funcionalidades:

• Identidad ligada a eIDAS. Hoy el comprador ancla la clave pública del proveedor fuera de banda (out-of-band) — confianza-en-el-primer-uso (trust-on-first-use), no eIDAS. La hoja de ruta son firmas cualificadas eIDAS que ligan la clave a una identidad legal.
• Registros de transparencia. Un registro público de solo-añadir (Sigstore / Rekor) permitiría a cualquiera comprobar que una firma se registró, no solo verificarla localmente. No construido.
• Grafo federado multi-proveedor. Hoy esto es un traspaso único (un proveedor → un comprador). Un grafo de atestaciones federado a través de muchos proveedores (subproveedores, componentes) es hoja de ruta.

Autocomprobación

❓ La cadena de suministro puede establecer tres cosas diferentes. ¿Cuáles son, y por qué no debes colapsarlas?

Autenticidad — «¿es esta evidencia exactamente lo que el firmante comprometió?» — la responde froga verify con la clave pública. Aceptación — «¿pasa la barrera del pliego del comprador?» — es decir, firmas válidas y ningún control bloqueante (enforcement: gate) en ROJO; una decisión de contratación, no un certificado. Conformidad — «¿cumple el producto realmente la ley, por cláusula?» — que, para las clases de alto riesgo, solo un organismo notificado acreditado puede certificar. No debes colapsarlas porque una entrega puede ser auténtica y estar aceptada y seguir siendo no conforme: puede quedar una brecha documentada hacia la conformidad plena, y gapToFullConformance se computa independientemente de la aceptación y nunca la cambia. Tres barreras distintas.

❓ ¿Qué prueba exactamente `froga verify` — y qué no prueba?

Prueba autenticidad solo: todos los artefactos presentes bajo .froga/ son byte a byte lo que el firmante comprometió. Cada firma es un sobre DSSE in-toto estándar (application/vnd.in-toto+json, ECDSA-P256, keyid == sha256(clave pública), subject digest == sha256(bytes del artefacto)); la comprobación es solo-de-clave-pública, local y no mueve ningún dato, y sale con 0 si y solo si todos los artefactos presentes verifican (un artefacto presente al que le falta su .sig falla). No prueba aceptación (la barrera del pliego del comprador) ni conformidad (la ley, por cláusula). Una entrega bloqueada — con una barrera en ROJO — sigue verificando como auténtica, que es exactamente el punto: la autenticidad va sobre quién comprometió qué, no sobre si pasa.

❓ Las firmas de una entrega verifican y el comprador la acepta. ¿Por qué podría seguir siendo no conforme?

Porque la aceptación no es conformidad. La aceptación significa que se cumplió el criterio del pliego del comprador — firmas válidas y ningún control bloqueante en ROJO — que es una decisión de contratación, no un certificado. La conformidad significa que el producto cumple la ley cláusula a cláusula, que para las clases de alto riesgo solo un organismo notificado acreditado puede certificar — y no hay organismo notificado en esta cadena. El motor incluso computa la brecha hacia la conformidad plena (gapToFullConformance) independientemente de la aceptación, así que una entrega ACEPTADA puede llevar una brecha documentada. Auténtica + aceptada + aún-no-conforme es un estado perfectamente coherente (y honesto).

A dónde ir ahora

Nivel 6 · El proyecto final de la cadena de suministroEsta página aplicada de principio a fin: un proveedor firma y entrega por réplica, un comprador verifica con la clave pública y ejecuta su barrera del pliego, y las tres cosas — autenticidad, aceptación, conformidad — se mantienen honestamente distintas, con la brecha documentada y el organismo notificado ausente a la vista.

Organismo notificado o autodeclaraciónLa frontera de esta cadena: por qué un auditor que ejecuta froga verify confirma autenticidad pero no certifica, y por qué solo un organismo notificado acreditado e independiente puede cerrar la cuestión de la conformidad para las clases de alto riesgo.

Ley de IA de la UE — la columna vertebralLa referencia para la división proveedor/responsable del despliegue (Art. 16 / Art. 25), la divulgación bajo el Art. 47, y cómo el motor proyecta la Ley sobre el paquete firmado — incluido por qué un veredicto ROJO y una firma todavía válida no son lo mismo.

Firmar y verificarLa guía práctica de la firma y verificación que hace fiable el traspaso: el sobre in-toto/DSSE, ECDSA-P256, verificación solo-de-clave-pública, y cómo anclar la clave de un proveedor (confianza-en-el-primer-uso hoy).