Méthodes de sécurité industrielle Trouver des risques d'IA | Fondation Nakada pour sauver l'humanité

Q: Méthodes de sécurité industrielle Trouver des risques d'IA | Fondation Nakada pour sauver l'humanité

STPA (System Theoretic Process Analysis) is a hazard analysis method developed at MIT for complex sociotechnical systems. It maps control structures (who commands what, who monitors what, how information flows) rather than analyzing individual component failure probabilities. It is the standard method in aviation, nuclear power, and aerospace for identifying how a system can lose control even when all individual components work as designed. A June 2026 paper accepted at ICML applied STPA along with FRAM and STECA to a frontier AI coding agent scenario, finding that the control structure failures it identified were entirely invisible to standard model-level AI safety evaluation.

Q: Méthodes de sécurité industrielle Trouver des risques d'IA | Fondation Nakada pour sauver l'humanité

The paper defines AI loss of control as the erosion of meaningful human oversight over AI system behavior, distinct from a single dramatic failure event. In the context of a frontier coding agent, loss of control can occur through three accumulating mechanisms: governance responsibilities that cannot be externally verified, monitoring delays that undermine the ability to intervene before harm occurs, and operational variability that erodes the accuracy of safeguard calibrations over time. Each mechanism on its own is manageable; all three interacting together constitute systemic loss of control.

Q: Méthodes de sécurité industrielle Trouver des risques d'IA | Fondation Nakada pour sauver l'humanité

The June 2026 paper identified three risks that standard model evaluations do not detect. First, governance verification gap: accountability in frontier AI deployments relies substantially on self-reported compliance by the deploying lab. External verifiers cannot independently confirm that safety commitments are being honored at the operational level. Second, monitoring delay problem: the latency between an AI agent taking an action and a human monitor receiving the alert is long enough that intervention often arrives after the relevant harm pathway is already established. Third, operational variability drift: the statistical calibration of safeguards is done on representative samples at deployment time, but operational conditions shift (users change behavior, tasks change, edge cases accumulate) eroding the accuracy of calibrations that were once well-tuned without triggering any alert.

Q: Méthodes de sécurité industrielle Trouver des risques d'IA | Fondation Nakada pour sauver l'humanité

Model-level evaluations test what a model does in response to inputs, whether it produces safe outputs, whether it refuses harmful requests, whether it stays within specified constraints. They evaluate the model as a component. Systemic risks emerge from the structure connecting components together: how oversight responsibilities are distributed, what information flows to whom at what speed, how operational context changes the effectiveness of controls over time. These structural properties are not tested by evaluating model outputs because they exist at the level of the deployment system rather than the model. The June 2026 ICML paper argues that model-level evaluation should be paired with systems-level hazard analysis as a mandatory component of frontier ASI governance.

Trois méthodes de sécurité industrielle ont été appliquées à l'IA.
Ils ont trouvé des risques que les évaluations de modèles ne peuvent pas voir.

Les méthodes de sécurité industrielle (STPA, FRAM, STECA) appliquées à un agent de codage de pointe ont identifié trois risques systémiques que les tests de modèle ne détectent pas : l'autodéclaration non vérifiable du laboratoire, une surveillance trop lente pour intervenir et des mesures de protection qui deviennent silencieusement obsolètes.

L'aviation n'est pas devenue sûre en testant si chaque boulon pouvait supporter sa charge nominale. Elle est devenue sûre en se demandant comment les pièces interagissent, qui est autorisé à commander quoi et comment les opérations réelles s'écartent des conditions supposées par le dossier de sécurité. Cette discipline s'appelle la sûreté des systèmes. Sa boîte à outils comprend la STPA, la FRAM et la STECA, des méthodes que les industries réglementées exigent déjà.

La sécurité de l’IA ne les a majoritairement pas importés. Un article de 2026 le fait.

Luca Carlucci, James Fillingham, Robert Walpole et Bartłomiej Kryś appliquent ces trois méthodes à un agent de codage de pointe dans un environnement de production réaliste (laboratoire, client d'entreprise, développeurs) dans "Une approche de pensée systémique du risque de perte de contrôle lié à l'IA avancée" (arXiv:2606.13474 ; ICML 2026 Technical ASI Governance Workshop). Ils identifient trois dangers que les tests de modèles ordinaires n’ont jamais été conçus pour détecter.

Les trois méthodes, en langage clair

STPA

Analyse des processus selon la théorie des systèmes

Cartographie qui commande quoi, qui surveille quoi, et où circulent les informations. Trouve les façons dont le contrôle échoue même lorsque chaque composant fonctionne comme prévu.

FRAM

Méthode d'analyse de résonance fonctionnelle

Traite le système comme des fonctions couplées, pas comme une liste de pièces. Montre comment des variations ordinaires du quotidien peuvent se combiner en un mauvais résultat au niveau du système.

STECA

Évaluation socio-technique pour les applications critiques

Étend la STPA aux personnes, aux incitations et aux institutions. Met au jour les lacunes de responsabilité qui se situent entre organigrammes et code.

Le scénario qu'ils ont utilisé

Ils ont appliqué les trois méthodes à un agent de codage de pointe dans un travail logiciel en production : horizon long, utilisation d'outils, avec de vraies bases de code et des services externes, supervisé par un laboratoire, des clients d'entreprise et des développeurs. C'est ainsi que ces systèmes sont déjà livrés. Le risque de perte de contrôle au niveau des systèmes est encore à peine analysé.

Trois résultats que les évaluations de modèles manquent

Constat 1

Personne en dehors du labo ne peut vérifier le récit de sécurité

Dans leur dispositif, le laboratoire prend les engagements de sécurité, rédige les règles d'utilisation et surveille les violations. Les régulateurs, clients et auditeurs ne peuvent pas vérifier indépendamment les opérations. L'auto-déclaration est la principale boucle de rétroaction.

STECA signale cela comme une structure de contrôle défaillante. Une action de contrôle ne fonctionne que si quelqu'un peut vérifier si elle a produit l'effet attendu. Quand la partie responsable de la sécurité est aussi la principale source de preuves que la sécurité est assurée, la boucle est compromise. C'est un fait de conception, pas une affirmation selon laquelle tel ou tel laboratoire serait malhonnête.

Constat 2

La surveillance est trop lente pour intervenir

STPA cartographie l'écart entre un agent agissant et un humain apprenant qu'il a agi. Dans les exécutions multi-étapes en temps réel, l'agent a souvent déjà appelé un outil, écrit du code ou poussé un changement avant qu'un réviseur voie l'alerte.

L'aviation appelle cela sortir de la boucle. L'autorité formelle pour arrêter le système reste sur le papier. L'autorité fonctionnelle ne suit pas. C'est ce à quoi pourrait ressembler aujourd'hui la supervision en temps réel des agents de codage de pointe.

Constat 3

Les garde-fous deviennent silencieusement obsolètes

Le FRAM se concentre sur la variation ordinaire. Les garde-fous sont calibrés sur l'aspect du système au moment du déploiement. Puis les prompts changent, le mix de tâches change, les cas limites s'accumulent et la distribution réelle s'éloigne de l'échantillon utilisé au lancement.

Rien n'alarme. Les mesures de sécurité font toujours exactement ce pour quoi elles ont été conçues face aux conditions d'hier. L'écart grandit silencieusement jusqu'à ce qu'un cas nouveau rencontre une règle qui ne correspond plus.

Ce que cela signifie pour la gouvernance

Les tests de modèle demandent ce que le système fait sur des entrées données. Ils ne cartographient pas la structure de contrôle qui l’entoure, qui est responsable de quoi, ni comment les opérations dérivent après la mise en production. Les scores de capacité et les équipes rouges restent nécessaires. Ils ne suffisent pas.

La demande du document est simple : associer une analyse des dangers au niveau du modèle et une analyse des dangers au niveau des systèmes comme partie obligatoire de l’évaluation de sécurité. STPA, FRAM et STECA constituent un point de départ concret. À l’échelle d’un seul agent de codage jusqu’à une économie entière, le même angle mort est ce qui rend désautonomisation progressive difficile à voir avant qu'il ne soit trop tard.

Pour la Fondation, la leçon porte sur la conception, pas sur un article isolé. L'inspection indépendante, les règles de calcul et la vérification externe existent pour que la sécurité ne repose pas sur un laboratoire qui s'auto-évalue. C'est pourquoi notre plan place au centre limites contraignantes et vérification, et non une auto-évaluation volontaire seule. Lisez l’article si vous voulez le détail complet de la méthode: arXiv:2606.13474. Puis mettez la découverte au travail dans la loi et les institutions, pas seulement dans une citation d'atelier.

Questions fréquentes.

Qu'est-ce que la STPA et pourquoi est-elle pertinente pour la sécurité de l'IA?

La STPA (System Theoretic Process Analysis) est une méthode d'analyse des dangers mise au point au MIT pour les systèmes sociotechniques complexes. Elle cartographie les structures de contrôle (qui commande quoi, qui surveille quoi, comment circule l'information) plutôt que d'analyser les défaillances de composants individuels. Elle est standard en aviation, dans le nucléaire et l'aérospatiale pour identifier comment un système peut perdre le contrôle même lorsque tous les composants individuels fonctionnent comme prévu. Un article de juin 2026 accepté à l'ICML a appliqué la STPA ainsi que la FRAM et la STECA à un agent de codage d'IA de pointe et a constaté que les défaillances de structure de contrôle identifiées étaient entièrement invisibles aux évaluations de sécurité de l'IA au niveau du modèle standard.

Qu'est-ce que la perte de contrôle de l'IA telle que définie dans cet article?

L'article définit la perte de contrôle de l'IA comme l'érosion d'une supervision humaine significative sur le comportement des systèmes d'IA, distincte d'un unique événement d'échec dramatique. Dans le contexte d'un agent de codage de pointe, la perte de contrôle survient par trois mécanismes cumulatifs : des responsabilités de gouvernance qui ne peuvent pas être vérifiées de l'extérieur, des délais de surveillance qui compromettent la capacité d'intervenir avant qu'un dommage ne survienne, et une variabilité opérationnelle qui érode la précision du calibrage des sauvegardes au fil du temps. Chaque mécanisme pris isolément est gérable ; les trois interagissant ensemble constituent une perte de contrôle systémique.

Quels sont les trois risques identifiés par l'analyse systémique?

Trois risques que les évaluations standard des modèles ne détectent pas. Premièrement, l’écart de vérification de la gouvernance : la responsabilité repose largement sur l’auto-déclaration de conformité par le laboratoire déployant, sans mécanisme de vérification externe indépendant. Deuxièmement, le problème du délai de surveillance : la latence entre une action de l’IA et une alerte humaine est suffisamment longue pour que l’intervention arrive souvent après que la voie du dommage soit déjà établie. Troisièmement, la dérive de variabilité opérationnelle : les calibrages de sauvegarde précis au déploiement s’érodent à mesure que les conditions opérationnelles évoluent sur des mois de déploiement, sans déclencher aucune alerte.

Pourquoi les évaluations de sécurité de l'IA au niveau des modèles manquent-elles les risques systémiques?

Les évaluations au niveau du modèle testent ce qu’un modèle fait en réponse à des entrées : s’il produit des sorties sûres, refuse les demandes nuisibles et reste dans les limites. Elles évaluent le modèle en tant que composant. Les risques systémiques émergent de la structure reliant les composants : comment les responsabilités de supervision sont réparties, quelles informations circulent où et à quelle vitesse, et comment le contexte opérationnel modifie l’efficacité du contrôle au fil du temps. Ces propriétés structurelles ne sont pas testées par l’évaluation des sorties du modèle car elles existent au niveau du système de déploiement. L’article de l’ICML de juin 2026 soutient que l’évaluation au niveau du modèle doit être associée à une analyse des dangers au niveau des systèmes comme composante obligatoire de la gouvernance des modèles de pointe ASI.

Trois méthodes de sécurité industrielle ont été appliquées à l'IA.Ils ont trouvé des risques que les évaluations de modèles ne peuvent pas voir.

Les trois méthodes, en langage clair

Le scénario qu'ils ont utilisé

Trois résultats que les évaluations de modèles manquent

Ce que cela signifie pour la gouvernance

Questions fréquentes.

Aller plus loin

L'évaluation des modèles seulene suffit pas.

Trois méthodes de sécurité industrielle ont été appliquées à l'IA.
Ils ont trouvé des risques que les évaluations de modèles ne peuvent pas voir.

L'évaluation des modèles seule
ne suffit pas.