Sécurité d'IA Certifiable : Portes de Déploiement Avec Preuve pour LLMs Utilisant des Outils
Il y a un mode de défaillance spécifique dans les LLMs modernes utilisant des outils qui ne reçoit pas assez d'attention : les données que le système génère ne sont pas statistiquement indépendantes des données que le moniteur voit ensuite. Le LLM émet une distribution de tokens. Le système échantillonne. Certains échantillons invoquent des outils. Les sorties d'outils retournent dans le contexte. La distribution suivante de tokens est conditionnée sur ces sorties. Tout est adaptatif, dépendant, récursif.
Le monitoring statistique standard suppose des observations indépendantes. La détection de dérive standard suppose une distribution de référence fixe. Les tests A/B standard supposent que le test n'influence pas les données. Aucune de ces hypothèses ne tient pour un LLM utilisant des outils en production. Le comportement même de l'agent — et les réponses des outils — change la distribution que le moniteur observe.
Le récent article Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Fradelos, février 2026) aborde cela frontalement. La contribution est un framework mathématique pour certifier la sécurité de cette classe exacte de systèmes, en utilisant un monitoring statistique anytime-valid (e-processus) explicitement conçu pour des données adaptatives et dépendantes.
Les mathématiques sont denses. Le pattern d'ingénierie est plus accessible. Cela vaut la peine d'être compris parce que l'alternative — faire semblant que le problème de dépendance n'existe pas — est le mode de défaillance silencieux de la plupart du monitoring d'IA actuel en production.
Pourquoi « Avec Preuve » Compte
L'idée centrale : à chaque point de décision — chaque fois que l'agent veut prendre une action, invoquer un outil, émettre une réponse — un certificat est construit montrant que l'action appartient à un ensemble sûr. Le runtime vérifie le certificat en temps polynomial. Si le certificat est valide, l'action procède. S'il ne l'est pas, le système soit retombe sur un défaut sûr (« dummy output »), soit projette l'action vers une alternative sûre proche (« convex repair »).
C'est la même idée que le code avec preuve dans les logiciels système : le producteur d'une action fournit un certificat qu'un vérificateur peut vérifier à bas coût. La confiance passe de « le producteur se comporte bien » à « le certificat est valide ».
Pour les systèmes d'IA, c'est opérationnellement important parce que :
- La vérification est moins chère que le réentraînement. Une fois le format du certificat fixé, la vérification est rapide. Réentraîner un modèle pour qu'il soit plus sûr est cher et incertain.
- Le vérificateur peut être fait confiance indépendamment du modèle. Un petit vérificateur simple, formellement spécifié peut être fait confiance à un niveau plus élevé qu'un grand modèle opaque.
- Le fallback est principielé. Quand le certificat échoue, le système sait échouer en sécurité, soit en émettant une sortie dummy, soit en projetant vers une alternative sûre.
Le Problème des Données Adaptatives
Le mouvement technique central de l'article est d'utiliser des e-processus (un type spécifique d'accumulateur de preuves statistiques basé sur les supermartingales) pour le monitoring. Les e-processus ont une propriété que les p-valeurs régulières n'ont pas : ils restent valides sous arrêt optionnel et collecte de données adaptative.
En termes simples : avec des tests statistiques réguliers, la validité du test dépend de votre engagement à l'avance sur combien de données vous collecterez et sur ce que vous testerez. Si vous regardez les données et décidez s'il faut continuer à collecter en fonction de ce que vous avez vu, vous avez cassé les garanties du test. C'est le problème de l'« arrêt précoce ».
Pour un système d'IA en production, vous ne pouvez pas éviter l'arrêt précoce. Vous monitorez en continu, vous allez agir sur le monitoring (alertes, throttling, blocage), et vos actions affectent les données que le moniteur observe. Les tests statistiques réguliers vous donnent des garanties qui ne tiennent pas dans ce régime.
Les e-processus tiennent. Ils donnent une validité uniforme dans le temps : vous pouvez monitorer en continu, arrêter quand vous voulez, et la garantie de faux positif s'applique encore. C'est la base mathématique qui fait fonctionner le monitoring de sécurité d'IA en continu.
L'implication pratique : si vous utilisez la détection de dérive basée sur les p-valeurs sur un système d'IA en production, vous opérez en dehors du régime valide de la méthode statistique. C'est quelque chose à quoi presque personne ne fait attention en 2026, et c'est le genre d'erreur qui produit à la fois une fausse confiance (quand cela ne mord pas) et de fausses alarmes inexpliquées (quand cela mord).
La Couche de Construction du Moniteur
L'article spécifie une construction canonique du moniteur avec quatre composants :
1. Logging de confiance
Chaque entrée, chaque sortie de modèle, chaque tool call, chaque réponse d'outil est loggée d'une manière que l'agent ne peut pas falsifier. Le log est le substrat pour tout le reste.
2. Aléatoire privé du moniteur
Le moniteur utilise des nombres aléatoires auxquels l'agent n'a pas accès. C'est la même idée que de garder secrète la graine d'un audit basé sur l'aléatoire vis-à-vis de l'audité. Cela empêche l'agent de jouer avec le moniteur en anticipant ce que le moniteur vérifiera.
3. Shadow sampling
Pour certaines vérifications, le moniteur échantillonne des sorties additionnelles du modèle avec le même prompt pour estimer la distribution de sortie. Ces échantillons fantômes n'atteignent pas l'utilisateur ; ils existent seulement pour caractériser la distribution de comportement que le modèle produit.
4. Réexécution d'outils
Pour les vérifications impliquant des résultats d'outils, le moniteur peut réexécuter des tool calls de manière déterministe (ou dans un environnement sandboxé) pour vérifier que la réponse était ce qu'elle aurait dû être.
Ces quatre ensemble donnent au moniteur assez de preuves indépendantes pour construire les certificats dont le runtime a besoin. Aucun d'eux n'est exotique ; les quatre sont à la portée de toute équipe qui prend le monitoring au sérieux. La contribution est de spécifier exactement ce qui est nécessaire et pourquoi.
Composition Modulaire : Pourquoi Cela Compte
Un mal de tête pratique en sécurité d'IA est la composition. Vous pouvez certifier que deux composants sont sûrs individuellement et avoir un système composite non sûr. Le cas classique : un outil qui est sûr d'appeler individuellement, appelé de nombreuses fois en succession rapide, peut produire des effets agrégés non sûrs (denial-of-service contre un système en aval, escalade par appels répétés, etc.).
L'article fournit un théorème de composition modulaire : sous des conditions spécifiques, les certificats de sécurité des composants se composent en un certificat de sécurité pour le système. Les conditions sont réelles et non triviales, mais explicites. Une équipe construisant des systèmes agentiques composites peut vérifier les conditions et savoir si leur composition est dans le régime où la sécurité des composants implique la sécurité du système.
Le cadrage honnête compte. L'article étiquette cela comme « un premier régime compositionnel » — ce qui signifie un point de départ utile, pas une théorie complète de la sécurité compositionnelle. Les équipes d'ingénierie devraient le traiter de la même façon : utile pour les cas qu'il couvre, pas une garantie pour les cas qu'il ne couvre pas.
Le Budget Global de Risque
Une contribution subtile mais importante : un corollaire qui alloue un budget global de risque à travers les temps de décision en runtime. Cela aborde le mode de défaillance « sûr par étape, non sûr en agrégat ».
Chaque point de décision a une petite probabilité de produire une action non sûre. Sommée sur des milliers ou millions de décisions, la probabilité agrégée d'au moins une action non sûre devient grande. L'article fournit un moyen d'allouer le budget global de risque à travers le calendrier de décisions pour que l'agrégat reste borné.
En pratique, cela signifie fixer des seuils de sécurité par action basés sur combien d'actions vous attendez que le système prenne, avec un suivi explicite du budget. Un système qui prend un million d'actions par jour et veut une probabilité agrégée d'action non sûre ≤1 % a besoin d'un seuil par action beaucoup plus serré qu'un système qui prend mille actions.
C'est le genre de comptabilité que la plupart des systèmes d'IA en production ne font pas explicitement. Ils fixent un seuil par action basé sur l'intuition et ne vérifient pas l'agrégat. CAST donne le framework pour le faire correctement.
Convex Repair : Quand le Certificat Échoue
Quand une action échoue à la certification, deux options existent :
- Fallback dummy : émet une sortie par défaut sûre. Conservateur, simple, dégrade souvent l'expérience utilisateur.
- Convex repair : projette la sortie non sûre vers le point le plus proche dans l'ensemble sûr. Requiert que l'ensemble sûr soit convexe et que la projection soit tractable.
L'article fournit des théorèmes de projection vers la sécurité dans des géométries KL/Bregman et de transport optimal, avec un chemin de tractabilité explicite pour la réparation basée sur le transport. Les maths disent : sous des conditions spécifiques, vous pouvez calculer une action qui est « aussi proche que possible » de l'action originale non sûre tout en étant dans l'ensemble sûr.
La conclusion d'ingénierie : quand vous concevez votre ensemble sûr, concevez-le convexe. Les ensembles sûrs convexes admettent une projection en temps polynomial. Les ensembles sûrs non convexes généralement non. C'est un choix de conception que vous faites en spécifiant la politique de sécurité, et il détermine si le convex repair est même disponible.
Ce que Cela Signifie pour les Équipes d'IA en Production
Trois actions pratiques pour toute équipe exécutant des systèmes LLM utilisant des outils en production :
1. Vérifiez votre méthodologie de monitoring
Si votre détection de dérive ou monitoring de sécurité utilise des méthodes basées sur les p-valeurs sur des données collectées adaptativement, les garanties statistiques ne tiennent pas. Soit passez à un monitoring basé sur les e-processus (la bonne réponse), soit soyez explicite que votre monitoring est heuristique plutôt que statistiquement rigoureux (une réponse intérimaire défendable).
2. Spécifiez l'ensemble sûr explicitement
L'expression « le modèle est sûr » n'a pas de signification précise. « Les sorties sont membres de l'ensemble S » oui. Spécifiez S en code ou description formelle. Ensuite vous pouvez vérifier l'appartenance, projeter les défaillances dans S et raisonner sur la composition.
3. Comptez le risque global
Si votre système prend de nombreuses actions, fixez les seuils par action basés sur le budget de risque agrégé, pas sur l'intuition par action. Les maths ne sont pas difficiles une fois que vous avez décidé du budget ; la discipline est de décider de le faire.
Où CAST Ne S'Applique Pas
L'article est explicite sur la portée : ce n'est pas une théorie de robotique, n'assume pas la superintelligence, et est positionné comme « confinement et certification grade-financier / grade-calcul-scientifique ». C'est pour des lois de sécurité explicitement spécifiées sur des systèmes LLM utilisant des outils.
C'est le régime où vit la plupart du déploiement d'IA en production en 2026. CAST est bien visé sur le problème pratique. Les équipes livrant des agents basés sur LLM qui touchent à de vrais outils — la majeure partie de l'IA agentique en production — devraient lire cet article et adapter les patterns.
L'alternative est un monitoring qui est mathématiquement faux sur les données qu'il traite. C'est le genre d'erreur qui produit des incidents que personne ne peut expliquer après coup.
Source : Fradelos, G. Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Genève, 12 février 2026). SSRN 6307158.
Vous exécutez des LLMs utilisant des outils en production et voulez un monitoring qui est réellement statistiquement valide pour les données que vous collectez ? Parlez à un CTO sur le déploiement de capacité d'ingénierie nearshore qui peut construire la sécurité certifiable dans le runtime.
