Nivel 6 · En profundidad — autenticidad ≠ aceptación ≠ conformidad

§4 — Autenticidad ≠ aceptación ≠ conformidad

Este es el corazón del proyecto final — el desenlace de todo el curso. Hay tres juicios diferentes, hechos por tres partes diferentes, que responden a tres preguntas diferentes. Confunde dos cualesquiera de ellos y confiarás en lo equivocado.

Juicio	La pregunta que responde	Quién lo hace	Salida	Retina (A)	Educación (B)
Autenticidad	¿Son los bytes exactamente lo que el poseedor de la clave privada firmó?	🔎 Aitor vía froga verify	firma VÁLIDA / código de salida 0	✅ auténtica	✅ auténtica
Aceptación	¿Se abre la barrera del pliego del comprador?	Servizo Atlante de Saúde (responsable del despliegue)	aceptada / bloqueada	❌ BLOQUEADA	✅ ACEPTADA
Conformidad	¿Se cumple cada cláusula de la ley?	Un organismo notificado acreditado	un certificado	⚠️ no conforme (brecha)	⚠️ no conforme (brecha)

Las dos entregas tienen firma VÁLIDA (autenticidad), pero su veredicto de barrera difiere — y ninguna es CONFORME (no hay organismo notificado en la cadena):

Venturalítica·demo.venturalitica.ai

●Ollomar (retina) · firma VÁLIDA · BLOQUEADA

Venturalítica·demo.venturalitica.ai

●EduAtlante (educación) · firma VÁLIDA · ACEPTADA

Lee la tabla por cada columna. El Proveedor A (retina) es auténtico + NO aceptado + NO conforme: sus firmas verifican perfectamente, pero su control bloqueante model-dr-sensitivity está en ROJO, así que la barrera del pliego queda cerrada — y aún lleva una brecha documentada hacia la conformidad plena. El Proveedor B (educación) es auténtico + aceptado + NO conforme: sus firmas verifican, su control bloqueante fairness-parity pasa así que la barrera del pliego se abre — pero aún tiene una brecha documentada hacia la conformidad plena. Ninguna entrega es «conforme»; la conformidad es un juicio separado, cláusula a cláusula que nadie en esta cadena ha emitido.

La barrera de aceptación es concreta y vive en cloud/lib/froga/delivery-acceptance.ts como deliveryAcceptance. Una entrega está ACEPTADA si y solo si (a) las firmas verifican (trusted) y (b) ningún control con enforcement gate/block está fallando. El orden importa: el fallo de firma se comprueba primero → bloqueada (firma); si no, un control de barrera fallido → bloqueada (control); si no, aceptada. Crucialmente, los controles audit/warn en rojo NO bloquean — solo los controles bloqueantes lo hacen.

`gapToFullConformance` se computa independientemente — y nunca voltea el veredicto

El motor también computa gapToFullConformance = (verdictKind === "gap") — y lo hace independientemente de la decisión de aceptar/bloquear; nunca cambia si una entrega está aceptada o bloqueada. Ambas entregas son gap, así que ambas llevan una brecha documentada hacia la conformidad plena — incluso el modelo de educación aceptado. Ese es el cerrojo de honestidad: «aceptada» significa que se cumplió el criterio del pliego, no plenamente conforme. El texto de interfaz de la nube etiqueta esta barrera «Aceptación — barrera del pliego» y afirma literalmente que la opinión de conformidad cláusula a cláusula «la emite el organismo notificado» — no esta barrera. La barrera abre una puerta de contratación; no cierra una cuestión de conformidad.

Por qué ambas verifican VÁLIDA pero difieren — la prueba de una frase

Si alguien te dice «la firma verifica, así que estamos listos», párale. Verificar responde ¿es auténtica? (ambas: sí). Aceptar responde ¿se abre nuestra barrera del pliego? (A: no, B: sí). Conformidad responde ¿cumple la ley cláusula a cláusula? (ambas: no establecida — queda una brecha, y solo un organismo notificado puede cerrarla). Tres preguntas, tres respuestas, nunca las colapses en una.

§5 — No hay organismo notificado en la cadena

Esta es la frontera más importante de todo el curso, y el proyecto final la enuncia con claridad: no hay organismo notificado en ningún punto de esta cadena de contratación.

🔎 Aitor verifica (prueba autenticidad) y lee el estado honesto (puede ver bloqueada vs aceptada, y la brecha documentada). No certifica. No está acreditado, no está designado en NANDO, y no tiene certificado que emitir. Su valor es exactamente su honestidad: puede establecer autenticidad para su mandante y hacer visible el estado abierto — incluyendo decirle al comprador «esta entrega es auténtica y está bloqueada» o «auténtica, aceptada, y aún llevando una brecha hacia la conformidad plena».

La barrera de aceptación es la barrera del pliego, no un certificado CE. Cuando Servizo Atlante de Saúde marca la entrega de educación como «aceptada», eso es una decisión de contratación contra su pliego (firmas válidas + ningún bloqueante en ROJO). No es una evaluación de conformidad, y no es un marcado CE. Para la entrega de retina esto importa doblemente: el cribador es un dispositivo médico, y su entrega incluye un cruce documental de MDR (conformance/eu_mdr_2017.json, el 7º artefacto firmado). Ese cruce documental es un cruce documental únicamente — nunca lo leas como «MDR gobernada». Un dispositivo de Clase IIa según MDR no puede autodeclarar; su procedimiento de evaluación de conformidad del MDR (Art. 52) lo envía a un organismo notificado para una evaluación de conformidad por un tercero que incluye una evaluación clínica. Nada en esta cadena hace eso. La entrega de retina está honestamente bloqueada en su barrera de exactitud y, aun si esa barrera estuviera en verde, seguiría requiriendo un organismo notificado que simplemente no está presente.

Verificar no es certificar — y aceptar no es certificar

Dos fronteras, una regla. El verify de Aitor confirma que la evidencia es lo que el firmante dice que es — no que el producto cumple la ley. La barrera de aceptación del comprador confirma que se cumple el criterio del pliego — no que el producto es conforme. Solo un organismo notificado acreditado e independiente puede emitir el certificado reconocido (para las clases de mayor riesgo), y no hay ninguno en esta cadena. Así que lo máximo que puedes decir con verdad al final de este traspaso es: las entregas son auténticas, una superó la barrera del pliego y otra no, y ambas aún llevan una brecha documentada hacia la conformidad plena que solo un organismo notificado podría cerrar. Ese es el techo honesto de una cadena de suministro firmada sin un organismo notificado.

Organismo notificado o autodeclaraciónLa línea afilada de la que depende esta sección: verificar una firma (autenticidad) y la barrera de aceptación de un comprador (contratación) son ambas distintas de una evaluación de conformidad por un tercero a cargo de un organismo notificado acreditado — algo que nadie en esta cadena realiza.

§6 — Qué está en custodia, y qué es hoja de ruta

Dos honestidades con las que cerrar: dónde viven realmente los bytes pesados, y qué fronteras están nombradas pero no construidas.

Custodia. Git lleva solo un puntero + hash para el modelo: dvc.lock, cuyo hash está anclado en la firma. Los pesados bytes del modelo viajan vía el backend de MLOps (un DVC remote hoy) y nunca a través de la infraestructura de Venturalítica. El organismo receptor hace dvc pull y comprueba el hash contra el dvc.lock firmado, o re-deriva el artefacto con froga reconstruct. Así que la cadena de suministro mueve confianza (resúmenes firmados) sin mover datos (los pesos) — que es exactamente lo que permite a Aitor verificar con una clave pública sola.

Pliego como código — REAL hoy. El umbral bloqueante lo impone el pliego, no el proveedor. La AAPP firma su pliego OSCAL con froga sign-pliego (mismo esquema ECDSA-P256+DSSE que la evidencia) y el comprador comprueba la entrega del licitador con froga conformance --against-pliego <pliego> --aapp-pubkey <hex>: verifica la firma del pliego, intersecta las cláusulas que el pliego marca como block con la evidencia de conformidad firmada del licitador, y sale con código ≠ 0 si falla alguna. La autenticidad de las firmas sigue sin implicar aceptación ni conformidad — son tres comprobaciones distintas.

Hoja de ruta — nombrado, NO construido. Estas son fronteras reales; no presentes ninguna de ellas como entregada:

• Generación de cláusulas EU MCC-AI — generar las Cláusulas Contractuales Modelo de Alto Riesgo (21 artículos) a partir del pliego. No construido (el pliego que hoy se firma se redacta a mano en OSCAL, no se deriva de las MCC-AI).
• eIDAS (clave ↔ identidad legal) — ligar una clave de firma a una entidad legal. Hoy el comprador ancla la clave pública fuera de banda — confianza-en-el-primer-uso (TOFU), no eIDAS. Aitor sabe qué clave firmó; no tiene un certificado legal de que esa clave pertenece a esa empresa.
• Transparencia Sigstore / Rekor — un registro de transparencia público y de solo-añadir de las firmas. No construido; las firmas hoy son separadas y se verifican localmente.
• Grafo federado multi-proveedor — un único grafo firmado a través de muchos proveedores y niveles (subencargado → proveedor → comprador). No construido; hoy son dos entregas independientes punto-a-punto.
• Retención probatoria a 10 años — retención a largo plazo, duradera y a prueba de manipulación, de los dossiers firmados. No construido.

La clave que Aitor ancla es TOFU, no eIDAS

Sé preciso sobre qué te compra la autenticidad. froga verify prueba que los bytes fueron firmados por el poseedor de una clave privada específica. No prueba que esa clave pertenece a Ollomar Diagnóstica (o EduAtlante). Hoy el comprador ancla la clave pública del proveedor fuera de banda y confía en ella en el primer uso (TOFU). Ligar clave → identidad legal es eIDAS — y eso es hoja de ruta. Así que el enunciado honesto es: auténtica, firmada por la clave anclada — no legalmente atribuida a la empresa hasta que eIDAS cierre esa brecha.