Respuesta directa
En pocas palabras
Verificar la procedencia e integridad de un artefacto de IA exige identificarlo por un digest criptográfico, obtener una declaración firmada sobre cómo fue producido y comprobar esa declaración contra una política propia. La verificación no termina cuando una herramienta muestra una firma válida: también debe confirmar la identidad esperada del firmante o builder, el emisor que la acreditó, el digest del sujeto, el tipo de attestation, el workflow autorizado y las condiciones de uso del release. La evidencia debe unir modelo, dataset, software, configuración, evaluaciones y despliegue sin inventar versiones que un proveedor no expone. Una firma válida no prueba que el artefacto sea seguro, preciso, legal, completo ni adecuado para vender; solo permite atribuir afirmaciones concretas y detectar ciertas alteraciones.
Empieza por la decisión que la evidencia debe sostener
Define para qué se verificará la procedencia: autorizar un release, aceptar un modelo de un proveedor, reconstruir un incidente, aprobar una actualización o responder qué atendió a una cuenta en una fecha. La pregunta determina qué sujetos, identidades, procesos y tiempos deben quedar vinculados. Guardar firmas sin una decisión y una política produce archivos que nadie sabe interpretar.
Fija producto, release, ambiente, región, recorrido y periodo. Incluye los artefactos que pueden cambiar el comportamiento: código, imagen de contenedor, modelo, dataset, índice, prompt o política versionada, configuración, evaluación y manifiesto de despliegue. Separa evidencia generada por la organización, declarada por un tercero y observada en runtime.
Distingue hash, firma, identidad, attestation y provenance
Un hash o digest identifica bytes; si cambia el contenido, cambia el digest con una probabilidad práctica extremadamente alta. Una firma vincula contenido con una clave. Un certificado o una identidad federada aporta información sobre quién controlaba esa clave o sesión. Una attestation contiene una afirmación estructurada y firmada. Provenance es una clase de información que describe dónde, cuándo y cómo se produjo un artefacto.
Ninguna pieza sustituye a las demás. Comparar un hash descargado desde el mismo canal comprometido no establece un origen independiente. Verificar una firma sin restringir identidad e issuer acepta a cualquier firmante técnicamente válido. Leer provenance sin comprobar su firma deja una declaración modificable. Aceptar todo lo firmado por una identidad conocida ignora qué proceso produjo el objeto.
| Criterio | Pregunta | Límite |
|---|---|---|
| Digest | ¿Son los mismos bytes? | No identifica por sí solo al productor ni evalúa el contenido. |
| Firma | ¿La clave firmó esta declaración? | No prueba que la clave estuviera autorizada o sin comprometer. |
| Identidad | ¿A quién se vinculó la firma? | No demuestra que el proceso o artefacto sean aceptables. |
| Attestation | ¿Qué afirmación estructurada se firmó? | Su valor depende del predicate, la fuente y la política. |
| Provenance | ¿Cómo se produjo el artefacto? | No garantiza seguridad, calidad ni completitud de dependencias. |
Identifica cada sujeto por digest y no por una etiqueta mutable
La unidad verificable es el sujeto exacto: una imagen, archivo de pesos, dataset empaquetado, índice, manifiesto o bundle. Registra algoritmo y digest junto con nombre y versión legible. Las etiquetas como latest, production o nombre-modelo son referencias de conveniencia; pueden apuntar a bytes distintos con el tiempo y no deben sostener una aprobación histórica.
Cuando varios archivos forman una unidad, define un manifiesto determinista o un bundle y firma su digest. Conserva cómo se ordenaron rutas, metadatos y exclusiones para poder recalcularlo. No metas secretos, datos personales ni muestras sensibles solo para que formen parte de la firma: usa referencias controladas y evidencia con acceso separado.
Conecta modelos, datos, código, configuración y herramientas
La salida no explica por sí sola sus entradas. Relaciona el sujeto con repositorio y commit, imagen base, lockfile, herramienta de build, modelo de origen, datasets, transformaciones, parámetros, configuración y evaluaciones. En un sistema RAG incluye la versión del corpus, pipeline de preparación e índice cuando sean artefactos controlables.
SPDX 3.0.1 permite describir una instancia de build con entradas, salidas, agente que la invocó, host, configuración y herramientas. Elige relaciones que tu organización pueda producir y verificar; no conviertas campos opcionales en hechos inventados. Una dependencia no observable se registra como desconocida, con dueño y tratamiento, no como una versión aproximada.
Define qué builder y qué workflow están autorizados
Identifica el servicio que ejecuta el build y la definición inmutable o versionada del workflow. Restringe repositorio, referencia, archivo de pipeline, entorno, runner y parámetros externos que una persona puede controlar. Los parámetros internos sensibles pueden quedar fuera de la vista pública, pero el verificador necesita suficientes señales para distinguir un proceso aprobado de otro que solo usa el mismo nombre.
La confianza es transitiva. Si el builder puede ser modificado por administradores, acciones de terceros, imágenes base o secretos compartidos, esas piezas forman parte de la base de confianza. SLSA señala que provenance ayuda a rastrear el proceso, pero no elimina la necesidad de confiar en el builder que la genera.
Genera provenance desde el plano de control, no desde el artefacto
La attestation debe producirse por un servicio que observa el build y conoce su identidad, no por un script dentro de una tarea que puede declarar cualquier cosa. La declaración vincula el digest de salida con la definición del build, parámetros, dependencias resueltas, builder y detalles de ejecución. Conserva su tipo y versión de esquema para que el consumidor sepa qué semántica verificar.
SLSA Build Provenance usa una declaración con sujetos y un predicate de procedencia. La lista de dependencias resueltas sigue siendo de mejor esfuerzo: una attestation conforme puede no descubrir cada dependencia transitiva o dinámica. Documenta cobertura, colectores y huecos en lugar de presentar el archivo como un mapa completo.
Firma con una identidad controlada y reduce la exposición de claves
Prefiere claves administradas, identidades de workload o firma sin clave persistente cuando el ecosistema y la operación lo permitan. Separa la identidad de desarrollo de la identidad que atestigua el build. Limita permisos, registra uso, rota credenciales y define qué ocurre si una clave, cuenta o emisor se compromete.
En un flujo keyless, una autoridad certifica una identidad obtenida de un proveedor OIDC y la firma se acompaña con evidencia de transparencia. El verificador todavía debe fijar la identidad esperada y el issuer esperado. La comodidad de no distribuir una clave pública estática no convierte cualquier certificado válido en autorización para publicar Cerravi.
Verifica firma, identidad, issuer, digest y claims
La verificación mínima comprueba la firma sobre la attestation, la cadena o mecanismo de identidad, el issuer admitido y la identidad exacta del firmante. Después confirma que el sujeto contiene el digest calculado localmente y que el predicateType es el que la política entiende. Rechaza algoritmos, formatos y tipos desconocidos salvo una excepción explícita.
Cosign puede verificar firmas y attestations y, en flujos de identidad, exige proporcionar la identidad del certificado y el issuer OIDC esperados. Desactivar la comprobación de claims puede servir para diagnóstico, pero no equivale a aprobar la identidad, el digest y la política. Guarda la salida de verificación sin exponer tokens ni credenciales.
Convierte la verificación en una política de admisión
Una política traduce evidencia en una decisión reproducible. Define qué parejas de firmante y builder se aceptan, desde qué repositorios, con qué workflow, tipo de attestation y antigüedad. Añade requisitos por riesgo: evaluación aprobada para un modelo, licencia revisada para un dataset, escaneo vigente para una imagen y revisión humana para un cambio de autoridad.
Ejecuta el gate antes de promover a producción y registra resultado, versión de política y evidencia evaluada. Un fail cerrado protege integridad, pero necesita un procedimiento de excepción con alcance, compensación, responsable y vencimiento. Evita una regla global que acepte cualquier artefacto firmado por la empresa; una identidad legítima puede firmar objetos fuera de su propósito.
Enlaza provenance con AI/ML-BOM, cards y evaluaciones
El AI/ML-BOM enumera componentes y relaciones del release; provenance explica cómo se produjo un artefacto; la model card y data card describen uso, evaluación, procedencia y límites; la system card documenta el comportamiento integrado. Usa identificadores y digests comunes para evitar cuatro historias incompatibles sobre el mismo sistema.
Firma también los manifiestos que enlazan resultados de evaluación, pero no reduzcas una evaluación a su firma. Deben seguir visibles población, método, versión, métricas, umbrales, fallas y aprobación. La firma ayuda a detectar sustitución; no convierte una prueba incompleta en evidencia suficiente.
Trata proveedores, APIs y versiones no observables sin inventar precisión
Un proveedor puede entregar una imagen firmada, un modelo descargable o una API cuyo backend cambia sin exponer un digest. Para objetos descargables verifica digest, identidad, attestation, licencia y canal. Para SaaS registra endpoint, alias, región, fecha, contrato, metadatos observables y aviso de cambios; solicita evidencia del proveedor, pero no presentes una versión interna como verificable si no lo es.
Compensa los huecos con pruebas de comportamiento, monitoreo, límites contractuales, fallback y un plan de salida. Conserva lo declarado por el proveedor separado de lo comprobado por tu organización. La imposibilidad de verificar bytes no obliga a rechazar siempre el servicio, pero sí cambia el riesgo y la afirmación que puede hacerse ante un cliente.
Conserva attestations, logs y políticas como evidencia auditable
Guarda artefacto, attestation, material de verificación, resultado, política, aprobación y timestamps con retención acorde al release. Protege el repositorio contra modificación y borrado no autorizado. Un log de transparencia puede ayudar a detectar reescrituras o firmas omitidas, pero no reemplaza las reglas de identidad ni la custodia de evidencia interna.
Define acceso por audiencia. Ingeniería necesita detalles del build; seguridad, señales de identidad y excepción; producto, vínculo con evaluaciones; compras, evidencia del proveedor; auditoría, historial de decisiones. Una vista para clientes puede mostrar sujetos y verificaciones relevantes sin publicar secretos, rutas internas o arquitectura explotable.
Prepara rotación, revocación, incidente y reconstrucción
Ensaya qué hacer si una clave, identidad, action, runner o proveedor se compromete. Localiza todos los artefactos firmados durante el periodo, detén promociones, rota confianza, reemite solo lo reconstruido y conserva la evidencia original. Revocar una clave no borra automáticamente artefactos ya desplegados ni determina cuáles fueron afectados.
Durante un incidente, compara el digest activo con el aprobado, recupera provenance y reconstruye el camino hasta fuentes y dependencias. Mantén el release afectado aislado de la versión actual. NIST SP 800-218A incorpora prácticas específicas de desarrollo seguro para modelos de IA generativa y debe usarse junto con el SSDF base; es orientación voluntaria, no una certificación del artefacto.
Mide cobertura y fallas con denominadores claros
Mide proporción de sujetos de producción identificados por digest, builds con provenance verificable, promociones bloqueadas, excepciones abiertas, identidades próximas a rotar, dependencias desconocidas y tiempo para reconstruir un release. Divide por tipo de artefacto y criticidad; un porcentaje agregado puede ocultar que todos los modelos externos carecen de evidencia.
Revisa falsos positivos y rutas de bypass. Si el equipo puede copiar una imagen directamente al runtime, el gate de CI no cubre producción. Si la política nunca falla, prueba con identidad, issuer, digest, predicate y workflow incorrectos. La métrica útil demuestra que el control detecta una condición relevante y que la respuesta funciona.
Aplica la cadena a Cerravi sin convertirla en una promesa comercial
Para un release de Cerravi, la cadena debe vincular commit, lockfile, imagen desplegada, configuración autorizada, migraciones, contenido versionado, evaluaciones y servicios realmente configurados. Cada objeto controlable usa digest; cada promoción verifica identidad, issuer, provenance y política; cada dependencia no observable se registra con su tratamiento. El AI/ML-BOM y la system card enlazan los mismos identificadores.
Esta evidencia no cambia los límites públicos del producto. Cerravi organiza contexto comercial y propone siguientes pasos para revisión humana; los recorridos públicos no envían mensajes ni cambian etapas automáticamente. Las propuestas usan productos y precios disponibles y solicitan confirmación cuando falta un importe. Forecast aplica reglas transparentes del CRM, no se presenta como un modelo predictivo entrenado y no garantiza cierres. La cadena demuestra relaciones y verificaciones concretas del release, no seguridad absoluta, cumplimiento legal ni resultados comerciales.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuál es la diferencia entre hash, firma y provenance?
El hash identifica bytes; la firma vincula una declaración con una clave o identidad; y provenance describe cómo se produjo un artefacto. Para una decisión confiable se verifica el digest del sujeto, la firma, la identidad, el issuer, el contenido de la attestation y la política aplicable.
¿Una firma válida demuestra que el artefacto de IA es seguro?
No. Demuestra que una clave firmó cierto contenido y, con controles adicionales, permite atribuirlo a una identidad. No prueba ausencia de vulnerabilidades, calidad del modelo, licitud de datos, completitud de dependencias ni adecuación para un caso de uso.
¿Qué debe comprobar un gate antes de desplegar?
Debe comprobar firma, identidad, issuer, digest del sujeto, tipo de attestation, builder, workflow, repositorio, referencia y requisitos propios como evaluación, licencia o excepción vigente. Aceptar cualquier firma técnicamente válida no es una política suficiente.
¿Puede verificarse la versión interna de un modelo servido por API?
Solo si el proveedor expone una identidad inmutable y evidencia verificable de esa versión. Si la API usa un alias mutable o no revela el snapshot, se documentan endpoint, alias, fecha y metadatos observables, y se compensan los huecos con contrato, pruebas, monitoreo y fallback sin inventar un digest.
¿Cómo se relaciona provenance con un AI/ML-BOM y una system card?
El AI/ML-BOM enumera componentes y relaciones; provenance explica cómo se produjo un artefacto; y la system card describe el comportamiento del sistema completo. Deben compartir identificadores, digests y release, mientras conservan propósitos y límites separados.