Respuesta directa
En pocas palabras
Un registro de artefactos de IA conserva objetos versionados —modelos, datasets, imágenes, prompts, configuraciones y evaluaciones— junto con su identidad, evidencia y estado operativo. La promoción no debe reconstruir ni renombrar silenciosamente el objeto: mueve o autoriza el mismo digest después de verificar políticas, pruebas y aprobaciones. Los tags y aliases ayudan a seleccionar una versión, pero son referencias mutables y no sustituyen al digest. Un diseño seguro separa ambientes y permisos, adjunta firmas y attestations al sujeto exacto, registra cada cambio de referencia y permite revertir a un artefacto ya conocido sin borrar la historia.
Define qué registra el sistema y qué significa promover
Empieza por el objeto de control. Un registro puede almacenar imágenes, modelos, datasets, índices, prompts, configuraciones, políticas, paquetes de evaluación y documentación técnica. Cada tipo necesita formato, propietario, metadatos y reglas propias. Un catálogo que solo contiene nombres y enlaces ayuda a descubrir, pero no demuestra que el contenido descargado sea el aprobado.
Promover significa autorizar un objeto ya identificado para un ambiente, recorrido o audiencia nuevos. No significa volver a entrenar, reconstruir, comprimir o descargar desde otra fuente. Si el contenido cambia, existe otro artefacto y debe recibir identidad, evidencia y evaluación propias. Define también registrar, validar, poner en cuarentena, aprobar, desplegar, retirar y eliminar para que los equipos no usen una misma palabra para efectos distintos.
Usa una identidad inmutable para cada contenido
El digest identifica el contenido; el nombre, versión legible, tag o alias facilitan encontrarlo. La OCI Distribution Specification define el digest como identificador derivado de un hash criptográfico y el tag como puntero legible a un manifest. Un mismo manifest puede tener varios tags y un tag puede reasignarse. Por eso el release, la política y el runtime deben registrar el digest resuelto.
Calcula y verifica el digest en carga, copia y descarga. Conserva algoritmo, tamaño, media type y manifest o metadatos necesarios para interpretar el objeto. Rechaza referencias ambiguas y evita latest en producción. Una versión semántica puede formar parte del nombre, pero no sustituye la comprobación del contenido: dos archivos llamados modelo-2.1 no son equivalentes por compartir etiqueta.
| Criterio | Uso correcto | Límite |
|---|---|---|
| Digest | Fijar el contenido exacto | No explica calidad, origen o aprobación |
| Versión | Comunicar una secuencia estable | Depende de reglas de publicación |
| Tag | Descubrimiento y automatización acotada | Puede moverse a otro manifest |
| Alias | Seleccionar champion, candidate o rollback | Es mutable y necesita historial |
| Estado | Mostrar validación o ciclo de vida | No identifica el objeto ni el despliegue |
Separa ambientes, organizaciones y dominios de confianza
Decide si dev, staging y production viven en repositorios, namespaces, cuentas o registros distintos. La frontera debe permitir permisos, retención, claves, red y monitoreo diferentes. Un único espacio con carpetas visuales no separa ambientes si la misma credencial puede sobrescribir producción desde una laptop de desarrollo.
Añade organización, producto, caso de uso, región y sensibilidad cuando afecten autoridad o residencia. Evita copiar artefactos entre clientes para ahorrar almacenamiento si no existe aislamiento comprobable. Documenta desde qué frontera puede promoverse, qué destino acepta el objeto y quién administra cada lado. La ruta inversa también importa: producción no debe contaminar desarrollo con datos o derivados sensibles sin una decisión específica.
Diseña un modelo de metadatos que pueda validarse
Cada entrada necesita tipo, digest, tamaño, formato, creador, fecha, fuente, licencia, propietario, propósito, ambientes permitidos, clasificación y relaciones. Para modelos añade framework, tarea, base, adaptadores y model card; para datasets, data card, procedencia, población, derechos y transformaciones; para prompts y configuraciones, esquema, herramientas, fuentes y permisos.
Separa metadatos declarados de hechos verificados. Una etiqueta validation_status=passed puede registrar una decisión, pero debe enlazar prueba, versión, criterio y autoridad. Versiona el esquema y valida campos obligatorios por tipo. No guardes secretos o datos personales completos como annotations. Usa identificadores y referencias con acceso cuando la evidencia necesite protección adicional.
Adjunta evidencia al sujeto exacto sin mezclarla con el objeto
Firmas, provenance, SBOM, AI/ML-BOM, attestations y reportes de evaluación deben referirse al digest del sujeto. OCI 1.1 permite asociar manifests mediante subject y recuperarlos con la Referrers API, filtrando por artifactType. Esto mantiene la evidencia como objetos separados y evita modificar el artefacto que pretende describir.
Sigstore Cosign almacena firmas mediante referrers de OCI 1.1 y normalmente las coloca en el mismo repositorio del objeto firmado. Comprueba compatibilidad del registro, copia los referrers junto con el sujeto y verifica después del traslado. Una firma que quedó en el origen no protege automáticamente la copia si la herramienta de promoción solo movió el manifest principal.
Separa estados de revisión, aliases y ambientes
Pendiente, validado, rechazado, en cuarentena y retirado describen el ciclo de revisión. Candidate, champion y rollback son aliases operativos. Dev, staging y production son ambientes con controles distintos. Mezclarlos en una sola lista produce transiciones ambiguas y permisos imposibles de explicar.
MLflow recomienda tags y aliases para organizar versiones y señala que sus stages fijos están deprecados. También describe ambientes separados con controles de acceso. Es una implementación concreta, no un requisito para todos los registros. La lección general es mantener identidad, estado, selección y ambiente como dimensiones independientes y registrar cada cambio de alias.
Promueve el mismo digest en lugar de reconstruir
Construye o entrena una vez dentro de una ruta controlada. Después valida, firma y promueve ese resultado exacto. Volver a ejecutar el build para production introduce otra marca de tiempo, dependencia, capa o aleatoriedad; aunque el código sea igual, el digest puede cambiar y la evidencia anterior deja de describir el objeto desplegado.
La promoción puede copiar el manifest y sus blobs a un repositorio de mayor confianza o autorizar el digest existente para el nuevo ambiente. En ambos casos verifica digest, firmas, attestations y relaciones al terminar. Registra origen, destino, solicitante, política, decisión y momento. Si el registro deduplica contenido, conserva igualmente el evento de promoción: ahorrar bytes no debe borrar la historia operativa.
Aplica mínimo privilegio y segregación de funciones
Separa cargar, adjuntar evidencia, validar, aprobar, mover aliases, promover, desplegar, retirar y eliminar. La identidad que produce un modelo no debería poder marcar su propia evaluación como aprobada y mover champion en producción. Usa cuentas de servicio por pipeline, credenciales breves y permisos limitados por repositorio, acción y ambiente.
Protege también operaciones menos visibles: sobrescribir tags, borrar manifests, cambiar retención, replicar a otra región, modificar webhooks y administrar claves. Las acciones de emergencia necesitan autenticación reforzada, alerta y revisión posterior. Prueba permisos denegados; una matriz teórica no demuestra que el registry o la API apliquen la separación.
Coloca un gate de política antes de cada promoción material
El gate recibe el digest, acción, origen, destino, identidad y evidencia verificada. Evalúa reglas por tipo y riesgo: firma e identidad, provenance, licencia, evaluaciones, clasificación, vulnerabilidades, aprobación y vigencia. Dev puede aceptar evidencia parcial con advertencia; production debe usar requisitos explícitos y fallar de acuerdo con un modo documentado.
La política devuelve allow, deny o escalate con motivos y versión. El servicio de promoción aplica la decisión y confirma el efecto. No permitas rutas manuales que copien directamente al namespace protegido. Si existe una excepción, limita sujeto, destino, regla, responsable y vencimiento; un tag especial sin control no es una excepción gobernada.
Controla tags y aliases como cambios de producción
Un alias como champion permite desacoplar una referencia estable de la versión seleccionada, pero moverlo puede cambiar el comportamiento del siguiente proceso que lo resuelva. MLflow documenta que un alias puede reasignarse y que una carga futura obtendrá la nueva versión. Trata esa reasignación como una operación auditable, no como edición de metadatos sin impacto.
Resuelve el alias a digest en el momento acordado y conserva ambos valores. Define quién puede moverlo, qué gate aplica, cómo se evita una carrera y qué consumidores actualizan en caliente. Para despliegues reproducibles, el runtime usa el digest; el alias expresa intención y facilita descubrir candidate, champion o rollback. Nunca reconstruyas la historia leyendo solo el valor actual del alias.
Prueba replicación, disponibilidad y consistencia
Si replicas entre regiones o proveedores, determina qué viaja: manifest, blobs, referrers, annotations, firmas, logs y políticas. Mide retraso y orden. Un alias puede llegar antes que sus blobs o una firma después del sujeto. No declares disponible una versión hasta comprobar que el destino puede resolver y verificar el conjunto requerido.
Define el comportamiento ante registro caído, copia incompleta, digest mismatch, referrer ausente o región aislada. Un caché mejora continuidad, pero necesita digest fijo, vigencia y revocación. Evita que el fallback descargue una etiqueta distinta. Prueba recuperación y reconciliación con inventarios de origen y destino, no solo una carga exitosa.
Diseña cuarentena, retención y eliminación sin romper evidencia
La cuarentena impide nuevas promociones y despliegues mientras conserva el objeto para análisis. Retirar deja de seleccionar una versión; eliminar borra contenido y puede afectar releases, investigaciones o derechos contractuales. Define condiciones, autoridad, plazos y dependencias para cada acción. Un artefacto vulnerable no siempre debe desaparecer antes de reconstruir qué lo utilizó.
Protege versiones activas y de rollback contra garbage collection. Recorre referencias antes de borrar: releases, aliases, deployments, evaluaciones, incidentes y obligaciones de conservación. Las firmas o cards huérfanas pierden contexto; un sujeto sin evidencia puede dejar de cumplir policy. Minimiza retención, pero registra tombstone, razón, aprobador y alcance cuando el borrado sea material.
Mantén rollback y restauración como recorridos comprobables
Rollback selecciona un digest previamente aprobado; no busca el último archivo que parezca estable. Conserva al menos la versión activa y una anterior compatible, sus manifests, blobs, evidencia, configuración, migraciones y criterio de uso. Verifica que la política todavía permita el objeto o documenta una ruta de emergencia acotada.
Prueba restaurar metadatos y contenido desde backup en un entorno aislado. Reconcilia digests, referrers, aliases, permisos y logs. Un backup del blob store sin la base de metadatos puede ser difícil de interpretar; una base sin blobs tampoco sirve. Mide RTO, RPO y espacio, y confirma que una restauración no reasigne silenciosamente aliases de producción.
Reconcilia runtime, registro y decisiones con métricas útiles
Registra quién cargó, verificó, promovió, movió un alias, desplegó, retiró o eliminó; incluye digest, origen, destino, policy revision, decision ID y resultado. Relaciona el evento del registro con el release y con el digest observado en runtime. Un estado approved sin despliegue y un runtime con digest no registrado son hallazgos distintos.
Mide cobertura por digest, artefactos sin propietario, evidencia faltante o vencida, promociones bloqueadas, aliases movidos fuera de pipeline, discrepancias de runtime, excepciones, cuarentena, tiempo de promoción y restauraciones probadas. NIST AI RMF Playbook describe el inventario de sistemas de IA como una base organizada de artefactos útiles para mantenimiento e incidentes. Úsalo como referencia voluntaria; no convierte el registro técnico en inventario completo ni certifica el proceso.
Aplica el patrón al release de Cerravi
En Cerravi, un release puede registrar imagen de aplicación, migración, lockfile, configuración pública, pruebas, AI/ML-BOM, system card y evidencia de procedencia bajo identificadores relacionados. El candidato se construye una vez, se valida por digest, pasa el gate y se promueve con backup, readiness, journal y rollback. Las etiquetas de Docker facilitan operación, pero el manifest digest y el release ID sostienen la reconciliación.
El registro no amplía lo que hace el producto. Cerravi organiza contexto 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 piden confirmación cuando falta un importe. Forecast usa reglas transparentes del CRM, no se presenta como modelo predictivo entrenado y no garantiza cierres. Registry, firma y aprobación aportan trazabilidad; no garantizan seguridad, cumplimiento o resultados comerciales.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué es un registro de artefactos de IA?
Es un sistema que almacena y organiza objetos versionados como modelos, datasets, imágenes, prompts y configuraciones junto con identidad, metadatos, evidencia, permisos y estado. Debe permitir recuperar el contenido exacto por digest y reconstruir quién lo promovió o utilizó.
¿Cuál es la diferencia entre digest, tag y alias?
El digest identifica contenido exacto mediante un hash. Un tag es un puntero legible a un manifest y puede reasignarse. Un alias es una referencia operativa como candidate, champion o rollback que también puede moverse. Releases y auditoría deben conservar el digest resuelto.
¿Por qué no se debe reconstruir el modelo al pasar a producción?
Porque una nueva ejecución puede cambiar dependencias, capas, timestamps o aleatoriedad y producir otro digest. Las pruebas, firmas y aprobaciones del candidato ya no describirían el objeto desplegado. Se debe promover o copiar el mismo contenido y verificarlo en destino.
¿Las firmas y attestations se copian automáticamente con el artefacto?
Depende del registro y de la herramienta. En OCI 1.1 pueden almacenarse como referrers asociados al subject digest, pero una copia que solo traslada el manifest principal puede omitirlos. La promoción debe copiar, descubrir y verificar el conjunto requerido en destino.
¿Un alias champion identifica de forma inmutable la versión de producción?
No. El alias expresa qué versión se selecciona ahora y puede reasignarse. Cada cambio necesita autorización e historial. El despliegue y los registros deben conservar el digest exacto que el alias resolvió para poder reproducir y auditar el estado.