🤖 machine learning

Who Analyses the Analyser? Self-Validating LLM Hazard Analysis with Constitutional Meta-STPA

Cet article traite de la lacune critique de l'analyse des outils d'IA utilisés pour l'analyse de sécurité en introduisant la « Constitutional Meta-STPA », un cadre d'auto-validation qui applique l'Analyse de Processus Systémique-Théorique (STPA) à lui-même pour dériver et appliquer une constitution de gouvernance, garantissant ainsi que l'analyste assisté par LLM est rigoureusement audité pour les hallucinations et les contraintes invérifiables.

Auteurs originaux : Samuel Tetteh, Udip Shrestha, Joshua R. Waite, Cody Fleming

Publié 2026-07-10

📖 7 min de lecture🧠 Analyse approfondie

CC0 1.0

Auteurs originaux : Samuel Tetteh, Udip Shrestha, Joshua R. Waite, Cody Fleming

Article original placé dans le domaine public sous CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous ayez construit un assistant robotique super intelligent dont le travail est d'inspecter d'autres machines pour détecter des failles de sécurité. Il est excellent pour trouver des engrenages cassés dans les voitures ou des fuites de valves dans les pompes. Mais voici le hic : personne n'a jamais demandé : « Qui vérifie le robot ? »

Ce document pose précisément cette question : Qui analyse l'analyste ?

Les auteurs ont réalisé que, bien que tout le monde fasse confiance à ces outils d'IA pour rédiger des rapports de sécurité, les outils eux-mêmes peuvent être défaillants. Ils pourraient inventer de fausses règles de sécurité, oublier de consigner leur travail ou donner une réponse assurée qui est en réalité un non-sens. C'est comme embaucher un détective qui n'écrit jamais ses indices et qui, parfois, invente des preuves.

Le robot auto-inspecteur

Pour corriger cela, l'équipe a construit une version spéciale de leur outil de sécurité qui retourne le microscope sur lui-même. Ils ont utilisé une méthode appelée STPA (une façon rigoureuse de trouver les risques de sécurité) pour analyser la conception même de l'outil d'IA.

Pensez à un robot qui construit une carte de son propre cerveau, trouve ses points faibles, puis écrit un livre de règles pour lui-même basé sur ces découvertes. Ils ne se sont pas contentés de deviner les règles ; ils ont laissé l'outil générer ses propres règles grâce à sa propre « analyse de sécurité » de lui-même.

Le livre de règles en deux parties

L'outil a abouti à une « Constitution » (un livre de règles) composée de deux couches distinctes :

Les « Principes de l'outil » (la couche de comportement) : Ce sont 21 règles sur la manière dont l'IA doit agir lorsqu'elle fait son travail. Par exemple : « Ne pas inventer de normes de sécurité », « Être spécifique sur ce que vous ne pouvez pas faire » et « Toujours vérifier votre travail ».
Les « Principes de méta-sécurité » (la couche de gouvernance) : Ce sont 8 règles sur la manière dont la machine qui fait tourner l'IA doit se comporter. Celles-ci incluent des choses comme : « Tenir un journal permanent de chaque question et réponse », « Verrouiller la version spécifique du cerveau que vous utilisez pour qu'elle ne change pas en cours de tâche » et « Ne pas laisser l'IA exporter un rapport à moins qu'il ne passe une liste de contrôle stricte ».

La grande surprise : Ce n'est pas de la magie, c'est du muscle

Les auteurs ont testé cela en demandant à différents modèles d'IA d'analyser l'outil lui-même. Voici ce qu'ils ont trouvé :

Les modèles forts : Lorsqu'ils ont utilisé les modèles d'IA les plus avancés (un « ensemble frontal » de deux modèles de haut niveau), l'outil a réussi à trouver 18 des 21 règles de comportement et la totalité des 8 règles de gouvernance simplement en examinant sa propre conception.
Les modèles faibles : Lorsqu'ils ont utilisé des modèles plus faibles et moins coûteux, ils n'ont trouvé que 12 des 21 règles de comportement et seulement 3 des 8 règles de gouvernance.

La conclusion : Les règles elles-mêmes n'étaient pas le problème ; c'était le cerveau effectuant l'analyse qui l'était. La « constitution » fonctionne, mais seulement si l'IA est assez intelligente pour trouver ses propres failles.

Qu'est-ce qui rend réellement l'IA plus sûre ?

L'équipe a mené un test délicat avec 20 « sondes adverses » — des questions piégeuses conçues pour inciter l'IA à être peu sûre ou à mentir. Ils ont testé l'IA avec différentes versions du livre de règles :

Sans règles : L'IA a obtenu un score de sécurité moyen de 1,03.
Règles génériques : L'ajout d'une liste générique du type « soyez utile et honnête » n'a pas aidé du tout (score : 1,05).
Les 21 Principes de l'outil : Lorsqu'ils ont ajouté les 21 règles de comportement spécifiques, le score de sécurité a bondi à 1,85. C'est une amélioration de 79 %, et c'est un gain énorme et statistiquement significatif.
Les 8 Règles de gouvernance : L'ajout des 8 règles de gouvernance (le journal de bord et le verrouillage de version) n'a pas modifié le score sur ces questions pièges spécifiques.

La leçon : Ce sont les règles de comportement spécifiques (les 21 Principes de l'outil) qui empêchent réellement l'IA de commettre des erreurs dans ses réponses. Les règles de gouvernance (les 8 Principes de méta-sécurité) sont cruciales pour le système (comme la conservation d'une piste d'audit), mais elles ne rendent pas magiquement les réponses textuelles de l'IA plus sûres en elles-mêmes.

Qu'en est-il de la « Couverture » ?

Les auteurs ont également examiné une idée courante dans la sécurité de l'IA : « Si nous faisons simplement en sorte que l'IA coche plus de cases, elle sera plus sûre. » Ils ont mesuré combien de règles l'IA « couvrait » dans son analyse.

Ils ont trouvé quelque chose d'étrange : plus de règles dans le prompt ne signifiait pas toujours une plus grande couverture de sécurité.

Lorsqu'ils ont testé l'IA sur une machine matérielle standard (comme un frein de voiture), les règles de « Méta-sécurité » (concernant les journaux et les versions) ont obtenu un score de 0 sur 8. L'IA ne les a pas mentionnées car une voiture n'a pas de journal d'audit.
Lorsque l'IA a analysé elle-même, le score est passé à 6 sur 8.

Cela a prouvé que la « couverture » n'est pas un curseur magique que l'on peut augmenter pour rendre les choses plus sûres. C'est un détecteur. Il vous indique quel genre de système vous regardez. Si l'IA parle de journaux d'audit, elle analyse un outil d'IA. Si elle est silencieuse sur les journaux, elle analyse une machine. Vous ne pouvez pas simplement forcer l'IA à dire « j'ai vérifié les journaux » pour la rendre plus sûre ; les journaux doivent réellement exister.

Le moment « Oups »

Les auteurs ont également été très honnêtes concernant une erreur qu'ils ont commise. Auparavant, ils pensaient qu'ajouter plus de règles rendrait l'IA capable de trouver plus de problèmes de sécurité de manière linéaire (comme une dose de médicament). Mais lorsqu'ils ont refait le test avec des paramètres fixes et stricts, cette idée de « dose-réponse » a disparu. Ils ont découvert que le nombre de problèmes trouvés diminuait ou restait stable à mesure qu'ils ajoutaient des règles. Ils ont publié ce résultat « raté » ouvertement, montrant que parfois, l'IA devient simplement plus concentrée et cesse de divaguer, plutôt que de trouver plus de problèmes.

L'essentiel

Ce document ne prétend pas avoir « résolu » la sécurité de l'IA. À la place, il a construit un outil qui :

Écrit son propre livre de règles en analysant sa propre conception.
Prouve que les règles de comportement spécifiques (les 21 Principes de l'outil) rendent les réponses de l'IA beaucoup plus sûres (un bond de 79 %).
Montre que les règles génériques du type « soyez gentil » ne fonctionnent pas.
Publie tout : le code, le livre de règles et les journaux, afin que quiconque puisse rejouer exactement les mêmes expériences.

Les auteurs concluent que si vous construisez un outil de sécurité d'IA, vous avez besoin des règles de comportement spécifiques pour empêcher l'IA d'halluciner, et vous avez besoin des règles de gouvernance pour maintenir une piste de papier. Mais vous avez également besoin d'un modèle d'IA vraiment intelligent pour faire le travail en premier lieu. Sans un cerveau capable, même le meilleur livre de règles ne vous sauvera pas.

Résumé Technique : Meta-STPA Constitutionnelle

1. Énoncé du Problème

Les modèles de langage de grande taille (LLM) sont de plus en plus utilisés pour automatiser la génération d'artefacts d'analyse de sécurité (pertes, dangers, Actions de Contrôle Non Sûres [UCA] et contraintes) au sein de cadres rigoureux tels que l'Analyse de Processus Systémique par la Théorie (STPA). Cependant, un angle mort critique subsiste : alors que les systèmes cibles (ex. : avions, dispositifs médicaux) sont analysés, les outils assistés par LLM effectuant l'analyse sont rarement scrutés. Ces outils sont eux-mêmes des systèmes à sécurité critique capables d'halluciner des normes, d'émettre des contraintes invérifiables et de faillir à maintenir des pistes d'audit. L'article pose la question fondamentale suivante : « Qui analyse l'analyste ? » La littérature actuelle manque d'une méthode pour analyser formellement l'outil d'analyse assisté par IA, le laissant vulnérable aux actions de contrôle non sûres mêmes que la STPA est conçue pour prévenir.

2. Méthodologie : Meta-STPA Constitutionnelle

Les auteurs proposent la Meta-STPA Constitutionnelle, une méthodologie en boucle fermée qui applique la STPA à la classe des outils de sécurité assistés par IA pour dériver leur propre constitution de gouvernance.

2.1. Le Processus Meta-STPA

Au lieu d'analyser un système physique, l'outil traite le pipeline de sécurité de l'IA comme le système sous analyse.

Contrôleurs : Le LLM, la couche de validation, le harnais de vote, la porte d'exportation et l'ingénieur d'astreinte.
Actions de Contrôle : Génération de pertes/dangers/UCA, signalement d'erreurs, rapport de désaccord entre modèles, et exportation de rapports.
Dérivation : En parcourant les quatre types d'UCA sur ces actions de contrôle, le système identifie des dangers uniques aux outils d'IA (ex. : appels LLM non journalisés, dérive silencieuse de version, descriptions altérées).
Génération de Contraintes : Chaque danger identifié produit une contrainte de sécurité, formant une constitution de gouvernance.

2.2. La Structure de la Constitution

La constitution dérivée se compose de 29 principes liés à des points d'application par le code :

21 Principes d'Outil (TP) : Une couche comportementale façonnant le contenu de l'analyse (ex. : énumération systématique, absence de fabrication, contraintes mesurables).
8 Principes de Méta-Sécurité (MSP) : Une couche de gouvernance régissant la machinerie de l'outil (ex. : journalisation d'audit, manifestes d'exécution, verrouillage de la version du modèle, vote par correspondance sémantique, exportation filtrée par validateur).

2.3. L'Implémentation du Pipeline

L'outil opère selon un pipeline en cinq étapes ( $\Pi$ ) faisant correspondre une description de système ( $S$ ) et une constitution ( $C$ ) à un artefact ( $A$ ) :

Génération par LLM : Génération libre de pertes, dangers et structures de contrôle.
Énumération Déterministe : Le moteur crée des emplacements fixes pour chaque triple (contrôleur, action, type d'UCA). Le LLM doit remplir ces emplacements avec une UCA concrète ou une justification explicite de « non applicable ». Cela garantit une complétude structurelle indépendante de la diligence du modèle.
Génération de Contraintes : Un emplacement de contrainte est créé par UCA non-N/A.
Validation : Huit validateurs déterministes (regex/structure) vérifient la complétude, le langage vague, l'excès de confiance et l'absence de preuves.
Filtrage (Gating) : Un « Exportation Filtrée par Validateur » (MSP-07) bloque les artefacts redistribuables (PDF, e-mails) si des erreurs de validation existent, à moins qu'un ingénieur ne fournisse un dépassement enregistré.

2.4. Reproductibilité et Audit

Manifestes : Chaque exécution génère un manifeste de run.json verrouillant la version de l'outil, le modèle, la graine (seed), la température et les empreintes SHA-256 de la description du système et de la constitution.
Journaux d'Audit : Chaque appel LLM est journalisé avec les empreintes SHA-256 des prompts/réponses, le nombre de tokens et la latence.
Vote Sémantique : Pour gérer le désaccord entre modèles, l'outil utilise un comparateur de similitude Jaccard de jetons (seuil $\tau=0.4$ ), permettant la gestion des synonymes tout en maintenant le déterminisme.

3. Contributions Clés

Méthode Meta-STPA : Une méthode qui dérive la constitution de gouvernance d'un outil de sécurité en appliquant la STPA à l'outil lui-même, aboutissant à une constitution de 29 principes publiée.
Évaluation Comportementale Contrôlée : Une expérience isolant l'impact des couches constitutionnelles, démontrant que les principes d'outil spécifiques à la tâche améliorent significativement le comportement de sécurité, tandis que les préambules génériques « utiles/inoffensifs » n'ont pas d'effet.
Cadre de Couverture : Une définition formelle de la « couverture marginale de la constitution » avec un lemme de validité. L'article rapporte un résultat négatif : la couverture lexicale n'est pas monotone par rapport à la force de la constitution sur un système fixe, mais agit comme un discriminateur de système (distinguant les outils d'IA du matériel).
Artefact de Reproductibilité Totale : Publication du code, des constitutions, des manifestes et des appels avec graines fixes permettant de rejouer chaque résultat à partir d'une seule ligne de commande.

4. Résultats Expérimentaux

4.1. Auto-Dérivation (L'outil peut-il s'analyser lui-même ?)

Modèles de Pointe Forts : Un ensemble de vote composé de claude-opus-4.8 et claude-sonnet-4 a récupéré 18/21 des Principes d'Outil canoniques et tous les 8/8 Principes de Méta-Sécurité de la conception même de l'outil.
Modèles Faibles : Une paire plus faible (gpt-4o-mini + gpt-4o) n'a récupéré que 12/21 des principes d'outil et 3/8 des principes de méta-sécurité.
Conclusion : La couche méta est limitée par le modèle, et non par la constitution. Les principes sont récupérables de la conception par des modèles capables, et ne sont pas simplement affirmés.
Généralisation : Appliqué à un second outil d'IA indépendant (un assistant de revue de code), l'ensemble fort a récupéré tous les 8/8 principes de gouvernance, confirmant qu'il s'agit de propriétés de la classe des outils d'IA, et non d'artefacts de la conception d'un outil spécifique.

4.2. Impact Comportemental (La constitution change-t-elle le comportement ?)

Configuration : 20 sondes adverses ont été testées contre cinq variantes de constitution (Aucune, Générique, Principes d'Outil, Outil+Générique, Complet).
Résultats :
- L'ajout des 21 Principes d'Outil (cv2) a élevé le score de sécurité moyen de 1.03 à 1.85 (+79 %, $p<0.001$ , $d=1.29$ ).
- Les préambules génériques « utiles/inoffensifs » (cv1) n'ont montré aucune amélioration significative par rapport à l'absence de constitution.
- L'ajout des 8 Principes de Méta-Sécurité (MSP) aux Principes d'Outil n'a pas amélioré davantage les scores adverses en un seul tour, car les MSP régissent la machinerie au moment de l'analyse (journalisation, filtrage) et non la génération de texte elle-même.

4.3. Couverture et Validité de Construit

Non-Monotonie : Sur un système fixe, l'augmentation de la force de la constitution n'a pas augmenté linéairement la méta-couverture lexicale. En fait, le contrôle vide (cv0) a souvent fait apparaître plus de méta-dangers car ces dangers sont intrinsèques à la structure de l'outil d'IA.
Discrimination de Système : La méta-couverture était de 0/8 pour les systèmes matériels (AEB, pompe à perfusion, UAV) mais est montée à 6/8 pour l'auto-système d'IA. Cela confirme que la couverture est un discriminateur entre les outils d'IA et le matériel, et non une métrique de « dose » à maximiser.
Reproductibilité : Sous des graines fixes, l'outil a montré une grande stabilité entre les fournisseurs (gemini-2.5-flash était exactement reproductible ; claude-sonnet-4 présentait une faible variance).

5. Signification et Revendications

L'article prétend répondre à « Qui analyse l'analyste ? » en démontant que l'analyste peut s'analyser lui-même.

Constitution Fondée : Les principes de gouvernance ne sont pas des assertions fabriquées à la main mais sont dérivés de la conception même de l'outil via la STPA.
Sécurité Opérationnelle : La constitution est appliquée via du code (validateurs, filtrage, manifestes) plutôt que par de simples instructions de prompt.
Capacité du Modèle comme Goulot d'Étranglement : La capacité à récupérer les principes de gouvernance dépend de la capacité du LLM sous-jacent, et non de la formulation de la constitution.
Transparence : Les auteurs rapportent ouvertement l'échec de la réplication d'un résultat exploratoire antérieur (une hausse monotone de la couverture), requalifiant la métrique de couverture en un discriminateur de système plutôt qu'en une courbe dose-réponse.

L'article conclut que pour que les outils d'analyse assistés par IA soient dignes de confiance, ils doivent inclure une couche comportementale spécifique à la tâche (Principes d'Outil) et un substrat de méta-sécurité (Principes de Méta-Sécurité) qui soit codé en dur dans le flux d'exécution de l'outil, garantissant que les propres contraintes de sécurité de l'outil soient auditables et exécutoires.