Nivel 6 · El encuadre — el traspaso de contratación y las leyes de la cadena

§1 — El traspaso de contratación (tres actores)

Cada nivel anterior vivía dentro de una organización: el rol de Calidad de un proveedor y un ingeniero ejecutaban el bucle y firmaban el paquete. El proyecto final cambia la cámara. Ahora hay tres clases de actor, y lo interesante ocurre entre ellos.

• El proveedor. La organización que construyó y firmó el sistema de IA en su propio repositorio git. Hay dos aquí. Ollomar Diagnóstica S.L. construyó un cribador de retina; EduAtlante Analytics S.L. construyó un modelo de educación. Dentro de cada uno, el equipo que ya conoces — 🛡️ Diego y 🧑‍💻 Marta — hizo exactamente lo que enseñaron los Niveles 1-5: declaró el sistema, gobernó el riesgo, midió los controles y firmó el paquete con la propia clave del desarrollador.
• El responsable del despliegue (el organismo público receptor). Servizo Atlante de Saúde (identificador de organización saude-atlante), una AAPP ficticia, está contratando ambos sistemas. No construye nada; recibe, verifica y acepta (o rechaza).
• El auditor externo. 🔎 Aitor se sitúa del lado del comprador. Su trabajo es estrecho y afilado: confirmar que lo que el proveedor entregó es auténtico y leer su estado honesto — usando nada más que la clave pública del proveedor.

El traspaso en sí es git-nativo: cada proveedor replica su repositorio de entrega firmado (mirror) hacia el comprador. Lo que cruza la frontera es solo lo pequeño y firmado — el manifiesto, el registro de reconstrucción y las proyecciones de conformidad, cada uno con su firma separada. Los pesados bytes del modelo nunca viajan a través de la infraestructura de Venturalítica: git lleva solo un puntero y un hash (dvc.lock) que está a su vez anclado en la firma. El organismo receptor descarga los pesos reales del backend de MLOps (un DVC remote hoy) con dvc pull y comprueba el hash, o los re-deriva con froga reconstruct.

Qué cruza la frontera — y qué queda en custodia

La entrega no es un volcado de datos. A través de la frontera de la org viajan solo: .froga/bundle.json (el manifiesto firmado), .froga/reconstruct.json (cómo se construyó) y conformance/*.json (las proyecciones por norma) — cada uno con su .sig. Los pesos del modelo están referenciados por hash en dvc.lock, y ese hash está firmado, así que la manipulación es detectable — pero los bytes en sí quedan en el DVC remote del proveedor. El comprador los descarga por separado y comprueba el hash. La autenticidad se establece sobre los artefactos firmados; la custodia de datos nunca se mueve al verificador del comprador ni a Venturalítica.

§2 — Qué leyes gobiernan la cadena

Una cadena de contratación no se gobierna por un solo Artículo — se gobierna por quién-debe-qué a lo largo del traspaso. Sé preciso con cada uno.

• Ley de IA de la UE Art. 47 (Declaración UE de Conformidad / divulgación) — reencuadrado para una cadena. El Art. 47 va sobre el proveedor que declara conformidad. En un traspaso firmado esto se convierte en un acto de dos lados: el proveedor declara (firma su paquete y sus proyecciones de conformidad), y el comprador verifica la evidencia firmada en lugar de tomar la declaración por fe. La declaración sigue siendo del proveedor; la verificación da al comprador una razón criptográfica para creer que la declaración es auténtica (no si es correcta en derecho — eso es conformidad, §4).
• Arts. 9-15 revisitados — toda la columna vertebral, ahora leída por el comprador. Todo lo que construyeron los Niveles 1-5 — gestión de riesgos (Art. 9), gobernanza de datos (Art. 10), registro de actividades (Art. 12), transparencia (Art. 13), supervisión humana (Art. 14), exactitud/robustez (Art. 15) — es exactamente el dossier que el comprador ahora lee. El proyecto final no añade nuevos artículos a la columna vertebral; cambia quién los está mirando: el proveedor produjo la evidencia, el responsable del despliegue la audita.
• Art. 16 / Art. 25 (proveedor frente a responsable del despliegue) — quién posee qué. Esta es la columna vertebral de la cadena. El Art. 16 lista las obligaciones del proveedor (construir el sistema bien, ejecutar la evaluación de conformidad, elaborar la documentación, firmar la DoC). El Art. 25 gobierna al responsable del despliegue (y los casos en que un responsable del despliegue se convierte en proveedor). En nuestra cadena la división es limpia: el proveedor firma en su repositorio; Servizo Atlante de Saúde (responsable del despliegue) verifica y acepta. La decisión de aceptación es un acto del responsable del despliegue; no transfiere las obligaciones de conformidad del proveedor al comprador, y tampoco las extingue.
• Pliego como código — REAL hoy. El comprador impone el umbral bloqueante a través del propio pliego, no lo declara el proveedor. La AAPP firma su pliego OSCAL con froga sign-pliego (mismo esquema ECDSA-P256+DSSE que la evidencia) y 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.
• EU MCC-AI (Cláusulas Contractuales Modelo para la contratación de IA) — HOJA DE RUTA (generación de cláusulas). La UE publica Cláusulas Contractuales Modelo para la contratación pública de IA; el conjunto de Alto Riesgo tiene 21 artículos (su Art. 8 ≈ Art. 15 de la Ley de IA, exactitud/robustez). El pliego OSCAL que hoy se firma se redacta a mano; derivarlo automáticamente de las MCC-AI es lo que queda por construir. Nombramos MCC-AI para que conozcas esa frontera restante, no para reclamarla.
• in-toto / DSSE — REAL hoy. Las firmas que Aitor comprueba no son propietarias. Cada artefacto es un sobre DSSE in-toto (payloadType: application/vnd.in-toto+json) con una firma ECDSA-P256 sobre el DSSE PAE, un keyid igual a sha256(clave pública), y un subject digest in-toto igual a sha256(bytes del artefacto). Cualquier verificador in-toto puede comprobarlo — froga verify es un espejo de un contrato estándar, no un jardín amurallado.

Proveedor frente a responsable del despliegue — la división sobre la que corre la cadena

La línea de responsabilidad más importante de este nivel: el proveedor firma, el responsable del despliegue verifica y acepta. El Art. 16 mantiene la carga de conformidad en el proveedor (Ollomar, EduAtlante) — ellos lo construyeron, lo evaluaron, firmaron la DoC. El Art. 25 pone al responsable del despliegue (Servizo Atlante de Saúde) del lado de la aceptación: leer la evidencia firmada, decidir si tomar la entrega. El veredicto «aceptada» del comprador es una decisión de contratación contra el pliego, no una reasignación de las obligaciones legales del proveedor ni un certificado. Mezclar esto es el error más común de cadena — manténlos separados.