L'admission des modèles exige un état non résolu

Une décision d'admission de modèle d'IA doit préciser quelles preuves permettent à l'artefact d'avancer. Lorsqu'un chargement ne produit aucun événement bloqué mais que l'inspection statique identifie toujours un élément global dangereux, une approbation compresse deux constats distincts en une seule réponse rassurante. Je veux que le constat non résolu survive à la décision, avec un compte rendu clair de ce qui reste à établir.

Nous avons conçu Crucible, notre démonstration locale de Model Vetting Firewall, autour de cette distinction. Elle utilise des artefacts synthétiques, notamment un fichier qu'un scanner de signatures ne signale pas mais dont le chargement tente une opération de base de données, et un autre avec une branche conditionnelle qui reste non exécutée. Le premier démontre pourquoi une tentative observée compte. Le second expose le problème de conception le plus difficile : décider quoi faire lorsque les contrôles disponibles sont en désaccord sans prétendre que le désaccord a été réglé.

Les preuves modifient la décision

Dans l'exemple de base de données synthétique, PickleScan ne signale pas l'artefact. Pendant le chargement, un hook d'audit CPython configuré enregistre et bloque une tentative d'opération de base de données SQLite. Le pipeline local renvoie QUARANTINE et n'émet aucune signature. L'opération de base de données n'a pas réussi ; la preuve utile réside dans l'effet tenté et son blocage consigné.

Cela donne à la décision d'admission une raison que le résultat vierge du scanner ne peut pas fournir. Une équipe peut pointer l'opération interdite plutôt que de demander au label du scanner de répondre à chaque question sur le chargement. Le scanner reste utile à titre de comparaison, mais l'absence de signalement n'annule pas une tentative bloquée et observée.

Je préfère cette séparation car elle rend la décision inspectable. Un examinateur doit pouvoir suivre la relation entre une constatation et un résultat. « Le hook configuré a bloqué cette tentative d'opération de base de données » est une déclaration circonscrite. Elle identifie la preuve, le mécanisme et la raison du verdict local. Une étiquette de sécurité générique masquerait ces relations.

L'observation crée également sa propre frontière de confiance. Ici, l'exécuteur tente le chargement dans un sous-processus Python et surveille les événements d'audit configurés. Il s'agit d'une instrumentation de démonstration, avec séparation des processus, plutôt que d'un confinement au niveau du système d'exploitation ou d'un conteneur. Une conception de production devrait établir comment l'exécuteur d'observation est lui-même isolé avant de lui confier des artefacts non approuvés. Ajouter des preuves comportementales ne supprime pas l'obligation d'examiner l'environnement qui les recueille.

Un chargement silencieux soulève une question plus difficile

Le banc d'essai synthétique conditionnel aboutit à un résultat différent. L'inspection statique détecte builtins.eval, un élément global figurant sur la liste dangereuse configurée de la démonstration. Le chargement observé n'enregistre aucun événement dangereux bloqué car la branche conditionnelle n'est pas exécutée dans cet environnement. Le pipeline achemine l'artefact vers REVIEW, sans signature. Aucune enquête humaine n'a été menée par cette voie.

Il y a trois réponses défendables à considérer, et chacune engage des coûts différents. L'approbation accepte l'incertitude. Le rejet évite d'utiliser cet artefact mais peut écarter un élément qu'une enquête plus étroite pourrait expliquer. Un examen approfondi retarde la décision et exige de définir quelles preuves supplémentaires pourraient la modifier.

Dans ce cas, je préfère l'examen car l'incertitude est précise. Il existe une préoccupation statique identifiée et une lacune d'observation identifiée. L'exécution silencieuse n'explique pas pourquoi l'élément global dangereux est présent ni ce qui se passe si la branche est atteinte. L'approbation exigerait d'accepter cette lacune. Un rejet immédiat pourrait constituer une politique organisationnelle raisonnable, mais ce serait un choix d'exclure l'artefact sur une preuve statique non résolue, plutôt que la preuve qu'un effet interdit s'est produit.

La distinction compte lorsqu'une équipe rédige sa politique d'admission. L'absence d'observation d'un effet ne doit pas devenir silencieusement le constat que l'effet ne peut pas se produire. De même, un soupçon ne doit pas devenir silencieusement la preuve d'une attaque réussie. REVIEW offre un espace pour conserver ces deux faits pendant que l'organisation choisit le niveau d'incertitude qu'elle peut accepter.

REVIEW a besoin d'un critère de sortie

Un statut d'examen à lui seul peut devenir une zone d'attente coûteuse. Il ne mérite sa place que lorsque le dossier explique la question non résolue et la prochaine décision à prendre. Dans cet exemple, la question concerne l'élément global statique et la branche non exécutée. Répéter le même chargement silencieux sans modifier ce qui est examiné ajouterait une autre observation sans répondre à cette question.

Dans un processus d'entreprise hypothétique, une équipe pourrait inspecter la branche, solliciter une explication fiable auprès du fournisseur de l'artefact, ou choisir un artefact de remplacement avec un chemin de chargement plus inspectable. Ce sont des réponses proposées, non des flux de travail que cette démonstration accomplit. Chacune a un coût : une inspection plus approfondie exige une expertise, les preuves du fournisseur nécessitent leur propre validation, et un remplacement peut sacrifier des fonctionnalités nécessaires. Le choix dépend des preuves que l'équipe peut obtenir et de l'incertitude autorisée par sa politique.

Je veux que ce choix soit explicite. Si aucune enquête disponible ne peut résoudre le problème dans les limites des contraintes de l'équipe, le rejet de l'artefact peut être la fin appropriée de l'examen. REVIEW ne doit pas promettre que chaque fichier finit par obtenir une approbation. Son but est d'empêcher qu'une question non résolue ne disparaisse dans un verdict et de rendre la décision finale responsable devant une politique déclarée.

La même discipline s'applique aux explications de l'IA. Dans la démonstration, un avis combiné d'analyste et de challenger peut inciter à la prudence et faire basculer un résultat de base ALLOW vers REVIEW ; il ne peut pas lever QUARANTINE. La présentation enregistrée utilise des avis Codex mis en cache aux côtés de contrôles configurés récents. Un enregistrement de référence synthétique illustre le danger de traiter le récit comme une autorité : son avis recommande la signature et la promotion, alors que le résultat structuré final est REVIEW et qu'aucune signature n'est émise.

Un consommateur d'admission doit donc lire le verdict structuré, la raison de la porte et le champ de signature effectif. Une prose utile peut expliquer une décision, mais elle ne doit pas devenir une seconde autorisation contradictoire de faire progresser un artefact. Un processus d'examen qui fait davantage confiance à la phrase de recommandation qu'à la porte finale perd la distinction qu'il était censé préserver.

L'approbation a également une limite

Le dictionnaire synthétique de poids sains reçoit ALLOW et une signature sur le nom de son modèle, le hachage de l'artefact et la charge utile de l'inventaire à l'aide d'une clé de développement locale. La provenance de ses données d'entraînement et l'historique de réglage fin restent UNKNOWN. Seul ALLOW reçoit cette signature ; REVIEW et QUARANTINE ne la reçoivent pas.

Cela compte autant pour la sortie de l'examen que pour la voie saine. Résoudre un problème de chargement n'établirait pas, en soi, l'historique d'entraînement. Une signature peut authentifier la charge utile locale spécifiée par rapport à sa clé alors qu'une question en amont reste sans réponse. Une équipe doit se demander séparément si les preuves d'admission sont suffisantes pour la décision de chargement et si la provenance manquante est acceptable pour l'utilisation prévue. Un contrôle approuvé ne doit pas trancher une question qu'il n'a jamais examinée.

Le guide Crucible présente ces exemples locaux et leurs preuves. L'intégration au registre, l'application de l'admission en entreprise et la garde des signatures en production restent des travaux extérieurs à cette démonstration. Sa valeur réside dans la frontière décisionnelle qu'elle rend visible, plutôt que dans la prétention que l'implémentation locale fournirait tous les contrôles nécessaires à une entreprise.

Voici la vidéo du fondateur montrant la démonstration locale d'évaluation synthétique de modèles.

Pour une équipe de plateforme évaluant une conception d'admission, je commencerais par le cas dont les preuves ne s'alignent pas nettement. Demandez ce qui maintient la constatation non résolue visible, qui décide si une enquête approfondie vaut son coût, et quelles preuves peuvent changer le résultat. Une voie claire est facile à décrire. La voie non résolue révèle si le système préserve l'incertitude assez longtemps pour qu'une décision responsable soit prise.