Respuesta directa
En pocas palabras
Una política de admisión de artefactos de IA es una regla versionada y comprobable que decide si un modelo, dataset, imagen, configuración o bundle puede entrar a un registro, ambiente o despliegue. Recibe evidencia estructurada —digest, firma, identidad, provenance, evaluaciones, licencia, riesgo y aprobación— y devuelve una decisión explícita con motivos. Policy-as-code no es un archivo que sustituye al criterio humano: separa la lógica de decisión de la herramienta que la ejecuta, permite probar cambios antes de activarlos y deja trazabilidad sobre qué versión de la política evaluó qué sujeto. Un gate sólido rechaza entradas desconocidas, distingue error técnico de incumplimiento, controla excepciones y no presenta una decisión permitida como prueba de seguridad, cumplimiento o resultados comerciales.
Define la decisión y la frontera de admisión
Empieza por una decisión concreta: aceptar un artefacto en el registro, promoverlo a staging, desplegarlo en producción, habilitarlo para un recorrido o renovarlo después de un cambio. Cada punto tiene distinto riesgo y evidencia disponible. Una regla que intenta cubrir todo termina aceptando entradas ambiguas o bloqueando trabajo legítimo sin explicar por qué.
Fija sujeto, organización, producto, ambiente, región y acción solicitada. Decide qué componentes entran: imagen, modelo, dataset, índice, prompt o política versionada, configuración, evaluación y bundle. Policy-as-code debe evaluar un objeto identificable y una intención; no una etiqueta mutable como latest ni una descripción narrativa del cambio.
Separa la decisión de la ejecución
El motor de política recibe datos estructurados y devuelve allow, deny o una respuesta equivalente con razones. La CI, el registro, el admission controller o el orquestador ejecutan esa decisión. Esta separación evita copiar reglas divergentes en scripts, paneles y servicios, y permite cambiar la política sin reescribir cada punto de control.
Open Policy Agent está diseñado para desacoplar policy decision-making de policy enforcement y evaluar datos estructurados mediante reglas declarativas. Esa arquitectura no resuelve por sí sola identidad, disponibilidad ni distribución. Define quién prepara el input, quién confía en la respuesta, qué versión se usa y qué ocurre cuando el motor no responde.
| Criterio | Responsabilidad | Resultado esperado |
|---|---|---|
| Productor | Genera artefacto y evidencia | Sujeto por digest y attestations atribuibles |
| Motor | Evalúa reglas y datos | Decisión, motivos y versión de política |
| Enforcer | Permite o bloquea la acción | Estado real coherente con la decisión |
| Humano | Aprueba riesgo o excepción | Responsable, alcance y vencimiento |
| Auditoría | Reconstruye el caso | Input minimizado, decisión y evidencia enlazada |
Diseña un contrato de entrada estable y verificable
El input debe incluir sujeto y digest, tipo de artefacto, acción, ambiente, organización o producto cuando aplique, identidad solicitante y evidencia ya verificada. Añade builder, repositorio, workflow, referencia, predicate types, evaluaciones, riesgo, licencia, proveedor, fecha y aprobaciones. Distingue ausente, desconocido, no aplicable y falso; convertirlos todos en null oculta decisiones diferentes.
Valida esquema antes de evaluar reglas. Rechaza campos inesperados en zonas sensibles y versiona el contrato para migrarlo sin silencios. No envíes prompts reales, tokens, datasets personales ni secretos al motor si basta un identificador, clasificación o resultado firmado. La política necesita datos suficientes para decidir, no una copia completa del expediente.
Convierte provenance en expectativas explícitas
La política no debe limitarse a exigir que exista provenance. Comprueba que la firma sea válida, que el subject coincida con el digest, que el predicate type sea conocido y que builder, repositorio, build type, parámetros externos y referencia pertenezcan a valores esperados. Un campo desconocido puede introducir comportamiento no revisado y debe fallar de forma segura.
SLSA v1.2 recomienda comparar la procedencia con un root of trust y expectativas preconfiguradas. También advierte que confiar en el builder sigue siendo una decisión. Protege los cambios a esas expectativas con revisión reforzada; si una persona puede modificar simultáneamente código, workflow y allowlist, el gate solo documenta su propia evasión.
Escribe reglas por tipo de artefacto y nivel de riesgo
Una imagen puede requerir firma, provenance, SBOM, escaneo y base aprobada. Un modelo descargable puede exigir identidad, licencia, model card, evaluación y restricciones de uso. Un dataset puede necesitar data card, procedencia, derechos, clasificación y prueba de exclusión. Una configuración puede requerir revisión de permisos, destinos, herramientas y autoridad humana.
Organiza reglas comunes y extensiones por tipo, ambiente y criticidad. Evita un megabloque con decenas de excepciones. Cada regla expresa una condición, una razón comprensible, evidencia esperada y propietario. Cuando un requisito no aplica, la política debe demostrar por qué; no simplemente omitirlo.
Devuelve decisiones explicables y accionables
Una respuesta útil contiene decisión, códigos de regla, mensajes, severidad, campos faltantes, evidencia evaluada, versión de política y decision ID. El texto debe indicar qué corregir sin exponer secretos o estructura explotable. Diferencia deny por incumplimiento, error de input, fallo de verificación y fallo del servicio.
No uses solo un booleano. Dos denegaciones pueden requerir rutas opuestas: reconstruir con un builder autorizado o solicitar una excepción temporal. La interfaz traduce códigos estables a mensajes localizados, mientras los logs conservan identificadores para correlación. Las razones también permiten medir qué controles bloquean más promociones y si la política está bien calibrada.
Coloca controles donde todavía puedan impedir el cambio
Evalúa temprano en pull request y CI para dar feedback rápido; vuelve a evaluar el artefacto inmutable antes de publicarlo; y aplica enforcement en el punto de despliegue. La última decisión debe usar el digest real, no la etiqueta o el resultado de una fase anterior. Un check verde en CI no protege producción si otro canal puede desplegar directamente.
El policy-controller de Sigstore puede validar firmas y attestations durante admission de imágenes y resolver tags para evitar que cambie el objeto después de admitirlo. Es una implementación para Kubernetes, no una obligación arquitectónica. En otros entornos, el enforcer puede vivir en el registro, release service, API gateway o control plane, siempre que no exista una ruta paralela sin control.
Despliega la política en observe, warn y enforce
Empieza con datos históricos y shadow evaluation para saber qué habría bloqueado. Después activa warn en recorridos seleccionados, corrige inputs y falsos positivos, y pasa a enforce por ambiente o categoría. Sigstore policy-controller distingue comportamiento warn y enforce; permitir con advertencia sigue siendo una admisión y no debe contarse como bloqueo.
Define criterios de promoción de la propia política: cobertura mínima, tasa de errores técnicos, casos de prueba, responsables y plan de reversión. Un periodo de observación no debe volverse indefinido. Las reglas críticas, como identidad equivocada o digest inconsistente, pueden entrar en enforce antes que requisitos de documentación menos maduros.
Decide cuándo fallar cerrado, abierto o degradado
Si falta el motor, el repositorio de evidencia o el proveedor de identidad, la acción puede bloquearse, usar una política local firmada o entrar a un modo degradado limitado. La elección depende del riesgo y del punto de control. Un despliegue de producción suele requerir fail closed; una evaluación de desarrollo puede continuar con advertencia y sin derecho a promover.
Distingue indisponibilidad de una decisión deny. Añade timeout, caché acotada, última revisión conocida, protección contra replay y fecha máxima de evidencia. Prueba particiones de red y bundles inválidos. La continuidad no consiste en aceptar todo cuando falla el control, sino en conservar una ruta segura y explícita.
Versiona, firma y distribuye las políticas
Mantén reglas, datos, esquemas y pruebas en control de versiones con revisión. Publica un bundle identificable y promuévelo entre ambientes. OPA puede cargar policies y data desde bundles, reportar su revisión en decision logs y verificar firmas de bundles antes de activarlos. Si la firma falla, conserva la versión anterior y alerta.
Separa datos que cambian con frecuencia —allowlists, builders, riesgos aceptados— de reglas estables, pero versiona ambos en la decisión. Protege el canal de distribución y limita quién puede firmar. Una política perfectamente escrita pierde valor si un atacante sustituye el bundle o cambia el endpoint de descarga.
Prueba reglas, datos y rutas de evasión
Crea casos allow y deny para cada regla, además de inputs ausentes, tipos incorrectos, digests cambiados, issuer o identidad inesperados, predicate desconocido, evaluación vencida y excepción expirada. Ejecuta pruebas unitarias en cada cambio y replay contra decisiones históricas antes de promover un bundle.
Añade pruebas de integración sobre el enforcer. Confirma que un deny realmente impide publicar o desplegar, que un warn queda visible y que una etiqueta mutable se resuelve al digest evaluado. Intenta rutas administrativas, rollback, importaciones manuales y cuentas de servicio. La cobertura de código no demuestra cobertura de decisiones; mide reglas, combinaciones y fronteras de confianza.
Controla excepciones y break-glass sin crear una puerta permanente
Una excepción incluye regla afectada, sujeto o alcance, ambiente, razón, riesgo, controles compensatorios, aprobadores, inicio y vencimiento. El gate la evalúa como dato versionado y registra su uso. No aceptes comentarios libres como bypass ni excepciones globales para una identidad, repositorio o proveedor.
Break-glass es una ruta de emergencia más estrecha: autenticación reforzada, aprobación explícita, tiempo breve, alertas y revisión posterior. El objetivo no es hacer el gate opcional, sino permitir continuidad ante un escenario definido. La reversión debe restaurar el enforcement normal y comprobar que ningún artefacto temporal quedó promovido sin seguimiento.
Registra decisiones sin convertir el log en una fuga
Conserva decision ID, timestamp, sujeto, acción, resultado, reglas, bundle revision, evidencia referenciada y actor. OPA decision logs pueden incluir input, resultado y revisión de bundles para auditoría y depuración. Ese input puede contener información sensible, por lo que debe enmascararse, reducirse o descartarse antes de enviarlo al servicio de logs.
Define acceso, retención, integridad y correlación con release e incidente. No copies claves, tokens, prompts, contratos o registros personales completos. Un log de allow demuestra la decisión que tomó el motor, no que el enforcer la aplicó; enlaza ambos eventos para comprobar el efecto real.
Gobierna cambios y mide la eficacia del gate
Mide cobertura de acciones protegidas, allow, deny, warn, errores técnicos, bypass, excepciones, tiempo de resolución y antigüedad de la evidencia. Usa denominadores por ambiente, artefacto y riesgo. Un aumento de denegaciones puede indicar mayor detección, un cambio roto o inputs incompletos; necesita revisión, no una meta aislada.
Cada cambio de política tiene propietario, revisión, pruebas, impacto esperado, fecha, rollout y rollback. NIST SP 800-204D describe estrategias para integrar medidas de seguridad de la cadena de suministro en pipelines CI/CD. Es una referencia técnica de DevSecOps, no una receta única ni una certificación del gate.
Aplica policy-as-code a Cerravi con límites comprobables
En un release de Cerravi, un gate puede validar digest de imagen, builder y workflow autorizados, provenance, lockfile, estado de dependencias, migraciones, pruebas, configuración y aprobación. La entrada enlaza el mismo sujeto del AI/ML-BOM y la system card; la salida registra versión de política, razones y release. El flujo atómico conserva backup, healthcheck y rollback sin aceptar un cambio por una etiqueta mutable.
La decisión técnica no amplía la autoridad 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. Un allow significa que la evidencia satisfizo el gate, no que Cerravi garantice seguridad, cumplimiento o resultados comerciales.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué es una política de admisión de artefactos de IA?
Es una regla versionada que evalúa evidencia estructurada sobre un modelo, dataset, imagen o configuración y decide si puede entrar a un registro, ambiente o despliegue. La respuesta incluye motivos y versión de política para que la decisión pueda probarse y reconstruirse.
¿Cuál es la diferencia entre policy-as-code y un checklist?
Un checklist guía una revisión y puede requerir interpretación manual. Policy-as-code recibe un input definido, ejecuta reglas reproducibles y devuelve una decisión que un enforcer puede aplicar. Ambos pueden coexistir cuando una condición necesita juicio humano documentado.
¿Qué evidencia debe exigir el gate?
Depende del artefacto y riesgo, pero normalmente incluye digest, firma, identidad, provenance, builder, repositorio, workflow, evaluaciones, licencia, clasificación, estado de controles y aprobaciones. Exigir que exista una attestation sin validar su contenido no es suficiente.
¿Debe bloquearse producción si el motor de política no responde?
Para acciones críticas suele elegirse fail closed o una política local firmada y acotada. Desarrollo puede continuar en modo warn sin derecho a promover. La decisión se documenta por punto de control y se prueba con timeouts, red caída, bundle inválido y evidencia vencida.
¿Una decisión allow demuestra que el artefacto es seguro?
No. Demuestra que el input presentado cumplió una versión de política para una acción concreta. Puede haber evidencia incompleta, riesgos desconocidos o cambios posteriores. La decisión debe conservar límites, tiempo, sujeto, política y controles adicionales.