La admisión de modelos necesita un estado no resuelto
Una decisión de admisión de modelos de IA debe establecer qué evidencia permite que el artefacto avance. Cuando una carga no produce ningún evento bloqueado pero la inspección estática aún identifica un elemento global peligroso, la aprobación comprime dos hallazgos diferentes en una única respuesta tranquilizadora. Quiero que el hallazgo no resuelto sobreviva a la decisión, con una justificación clara de lo que aún queda por determinar.
Construimos Crucible, nuestra demo local de Model Vetting Firewall, en torno a esta distinción. Utiliza artefactos sintéticos, incluido un archivo que un escáner de firmas no marca pero cuya carga intenta una operación en base de datos, y otro con una rama condicional que permanece sin ejecutarse. El primero demuestra por qué importa un intento observado. El segundo expone el problema de diseño más difícil: decidir qué hacer cuando las comprobaciones disponibles discrepan sin fingir que el desacuerdo se ha resuelto.
La evidencia cambia la decisión
En el ejemplo de base de datos sintética, PickleScan no marca el artefacto. Durante la carga, un hook de auditoría de CPython configurado registra y bloquea un intento de operación en base de datos SQLite. El pipeline local devuelve QUARANTINE y no emite ninguna firma. La operación en base de datos no tuvo éxito; la evidencia útil es el efecto intentado y su bloqueo registrado.
Eso le da a la decisión de admisión una razón que el resultado limpio del escáner no puede aportar. Un equipo puede señalar la operación prohibida en lugar de pedirle a la etiqueta del escáner que responda a todas las preguntas sobre la carga. El escáner sigue siendo útil como comparación, pero la ausencia de una alerta no cancela un intento bloqueado y observado.
Prefiero esta separación porque hace que la decisión sea inspeccionable. Un revisor debería poder seguir la relación entre un hallazgo y un resultado. «El hook configurado bloqueó este intento de operación en base de datos» es una afirmación acotada. Identifica la evidencia, el mecanismo y el motivo del veredicto local. Una etiqueta de seguridad genérica dejaría ocultas esas relaciones.
La observación también crea su propio límite de confianza. Aquí, el ejecutor intenta la carga en un subproceso de Python y supervisa los eventos de auditoría configurados. Eso es instrumentación de demostración, con separación de procesos, en lugar de contención a nivel de sistema operativo o contenedor. Un diseño de producción tendría que determinar cómo se aísla el propio worker de observación antes de confiarle artefactos no confiables. Agregar evidencia conductual no elimina la obligación de examinar el entorno que la recopila.
Una carga silenciosa deja una pregunta más difícil
El fixture sintético condicional llega a un resultado diferente. La inspección estática encuentra builtins.eval, un elemento global en la lista de elementos peligrosos configurada en la demo. La carga observada no registra ningún evento peligroso bloqueado porque la rama condicional no se ejecuta en este entorno. El pipeline redirige el artefacto a REVIEW, sin firma. No se ha completado ninguna investigación humana por esa vía.
Hay tres respuestas defendibles a considerar, y cada una invierte algo diferente. La aprobación acepta la incertidumbre. El rechazo evita usar este artefacto, pero puede descartar algo que una investigación más detallada podría explicar. Una revisión adicional retrasa la decisión y exige que alguien defina qué evidencia adicional podría cambiarla.
En este caso, prefiero la revisión porque la incertidumbre es específica. Hay una preocupación estática identificada y una brecha de observación identificada. La ejecución silenciosa no explica por qué está presente el elemento global peligroso ni qué sucede si se alcanza la rama. La aprobación requeriría aceptar esa brecha. Un rechazo inmediato podría ser una política organizacional razonable, pero sería la elección de excluir el artefacto basándose en evidencia estática no resuelta, en lugar de una prueba de que ocurrió un efecto prohibido.
La distinción importa cuando un equipo redacta su política de admisión. La falta de observación de un efecto no debe convertirse silenciosamente en la conclusión de que el efecto no puede ocurrir. Del mismo modo, la sospecha no debe convertirse silenciosamente en prueba de un ataque exitoso. REVIEW proporciona un espacio para conservar ambos hechos mientras la organización elige cuánta incertidumbre puede tolerar.
REVIEW necesita un criterio de salida
El estado de revisión por sí solo puede convertirse en un área de espera costosa. Solo gana su lugar cuando el registro explica la pregunta no resuelta y la próxima decisión que alguien debe tomar. En este ejemplo, la pregunta se refiere al elemento global estático y a la rama no ejercitada. Repetir la misma carga silenciosa sin cambiar lo que se investiga añadiría otra observación sin responder a esa pregunta.
En un proceso empresarial hipotético, un equipo podría inspeccionar la rama, buscar una explicación confiable del proveedor del artefacto o elegir un artefacto de reemplazo con una ruta de carga más inspeccionable. Esas son respuestas propuestas, no flujos de trabajo que esta demo complete. Cada una tiene un costo: una inspección más profunda requiere experiencia, la evidencia del proveedor exige su propia validación y el reemplazo puede sacrificar la funcionalidad necesaria. La elección depende de qué evidencia pueda obtener el equipo y de qué incertidumbre permita su política.
Quiero que esa elección sea explícita. Si ninguna investigación disponible puede resolver la inquietud dentro de las limitaciones del equipo, rechazar el artefacto puede ser el final apropiado de la revisión. REVIEW no debería prometer que cada archivo obtenga finalmente la aprobación. Su propósito es evitar que una pregunta no resuelta desaparezca en un veredicto y hacer que la decisión final sea responsable ante una política declarada.
La misma disciplina se aplica a las explicaciones de la IA. En la demo, un asesoramiento combinado de analista y challenger puede aportar prudencia y trasladar un resultado base ALLOW a REVIEW; no puede eliminar QUARANTINE. La presentación grabada utiliza asesoramiento de Codex en caché junto con comprobaciones recién configuradas. Un registro de referencia sintético ilustra el peligro de tratar la narrativa como autoridad: su asesoramiento recomienda la firma y la promoción, mientras que el resultado estructurado final es REVIEW y no se emite ninguna firma.
Por lo tanto, un consumidor de admisión debe leer el veredicto estructurado, el motivo del filtro y el campo de firma real. Un texto explicativo útil puede detallar una decisión, pero la prosa no debe convertirse en un segundo permiso contradictorio para hacer avanzar un artefacto. Un proceso de revisión que confía más en la frase de recomendación que en la puerta final ha perdido la distinción que debía preservar.
La aprobación también tiene un límite
El diccionario de pesos limpios sintéticos recibe ALLOW y una firma sobre el nombre del modelo, el hash del artefacto y la carga útil del inventario utilizando una clave de desarrollo local. La procedencia de sus datos de entrenamiento y el historial de ajuste fino siguen siendo UNKNOWN. Solo ALLOW recibe esa firma; REVIEW y QUARANTINE no la reciben.
Esto importa tanto para la salida de la revisión como para la ruta limpia. Resolver una inquietud de carga no establecería, por sí solo, el historial de entrenamiento. Una firma puede autenticar la carga útil local especificada con respecto a su clave mientras una pregunta previa sigue sin respuesta. Un equipo debe preguntarse por separado si la evidencia de admisión es suficiente para la decisión de carga y si la procedencia faltante es aceptable para el uso previsto. Una comprobación aprobada no debe resolver una pregunta que nunca examinó.
La guía de Crucible muestra estos ejemplos locales y sus evidencias. La integración con registros, la aplicación de la admisión empresarial y la custodia de firmas en producción siguen siendo trabajos ajenos a esta demo. Su valor reside en el límite de decisión que hace visible, más que en la afirmación de que la implementación local proporcione todos los controles que necesitaría una empresa.
Aquí está el video del fundador mostrando la demo local sintética de evaluación de modelos.
Para un equipo de plataforma que evalúa un diseño de admisión, comenzaría con el caso cuya evidencia no cuadra con claridad. Pregúntese qué mantiene visible el hallazgo no resuelto, quién decide si una mayor investigación vale su costo y qué evidencia puede cambiar el resultado. Un camino limpio es fácil de describir. El camino no resuelto revela si el sistema preserva la incertidumbre el tiempo suficiente para que se tome una decisión responsable.
