Les seuils de risque ont besoin d'un mécanisme de mesure, pas d'un cutoff

Un livre blanc du Center for Long-Term Cybersecurity d'UC Berkeley soutient que les seuils de cyberrisque par IA tirés des cadres de sécurité des laboratoires de frontière (OpenAI, Anthropic, DeepMind, Meta) échouent parce qu'ils sont fondés sur les capacités, vagues et déconnectés du dommage réel. Les auteurs proposent des réseaux bayésiens qui transforment « ce modèle franchit-il une ligne ? » en « quelle est la probabilité qu'il cause un dommage dans des conditions réelles ? » — et ce passage, d'un cutoff statique à un mécanisme mesuré en continu, est exactement ce qu'un seuil défendable exige.

Le seuil n'est pas une ligne qu'on franchit ; c'est une mesure qu'on maintient

Les cadres de sécurité des laboratoires d'IA de frontière convergent sur une poignée d'« éléments de seuil » — automatisation d'attaques multi-étapes, découverte de zero-days, habilitation d'attaquants peu qualifiés — puis attachent des benchmarks de capacité à chacun. La critique centrale du livre blanc de Berkeley est que ces cutoffs sont déterministes dans un système fondamentalement probabiliste. Un modèle qui « peut » découvrir un zero-day dans un benchmark ne cause pas de dommage par ce fait ; la même capacité est bénigne ou catastrophique selon l'accès, la posture du défenseur et l'économie de l'attaquant. Un seuil formulé comme une ligne de capacité ignore chacune de ces variables médiatrices.

C'est le même mode de défaillance que nous nommons avec Theorem 3 dans les 21 papers : une propriété est garantie exactement quand son mécanisme est implémenté et mesure. [ORIGINAL DATA] Theorem 3 (a property is guaranteed exactly when its mechanism is implemented and measuring) est déterminant ici parce que « cyberrisque inacceptable » est une propriété d'un système socio-technique, pas d'un modèle. Déclarer un cutoff de capacité n'implémente pas la propriété ; il l'affirme. La propriété — que le dommage reste sous un niveau accepté — n'existe que quand quelque chose produit continûment la mesure qui vous dirait qu'elle a été franchie. Une ligne que personne ne mesure n'est pas un seuil ; c'est un espoir.

Le livre blanc reformule la question de « ce modèle franchit-il un seuil ? » à « quelle est la probabilité qu'il cause un dommage dans des conditions réelles ? ». C'est le recadrage correct, et il a une conséquence structurelle : le seuil devient un état maintenu, non un jalon franchi. Vous instrumentez le déploiement, alimentez l'évidence dans un modèle probabiliste et maintenez le posterior sous le niveau accepté — ou vous restreignez le déploiement. Le cutoff est la sortie d'un mécanisme en marche, jamais son substitut.

Les capacités ne sont pas le risque ; le contexte l'est

Le livre blanc énonce la critique directement : capacités ≠ risque. La même capacité peut être bénigne ou catastrophique selon le contexte, l'accès et les défenses. Une capacité de génération de phishing derrière un périmètre d'authentification d'entreprise avec un filtre de courrier mature est un risque différent de la même capacité exposée à quiconque avec un numéro de téléphone et un grief. Les cadres de frontière esquivent cela en indexant sur la capacité et en laissant le contexte implicite.

Deux défauts supplémentaires aggravent le problème. D'abord, le langage est vague — « augmentation significative » apparaît dans les cadres sans une ligne de base, une unité ou une méthode. « Significative » par rapport à quoi, mesurée comment, par qui, mise à jour quand ? Un terme de seuil qui ne peut pas être peuplé est un artefact de conformité, pas un contrôle. Ensuite, les cadres se concentrent sur des scénarios extrêmes et peu probables — exploitation autonome de bout en bout d'une cible durcie — tout en omettant les décalages incrémentaux qui reconfigurent réellement l'équilibre attaque–défense. La dérive lente dans l'économie de l'attaquant, pas le scénario cinématographique, est là où l'équilibre bascule.

[UNIQUE INSIGHT] La raison pour laquelle les seuils de capacité manquent la dérive incrémentale est qu'ils sont des déclarations d'un instant sur un modèle, pas des mesures longitudinales sur un système. Un benchmark de capacité est une photographie ; le risque est une vidéo. La proposition de Berkeley — décomposer le risque en variables, les lier par des dépendances probabilistes, alimenter avec benchmark et red teaming et évidence du monde réel, et mettre à jour au fil du temps — est, en effet, une demande de commencer à filmer. Le seuil vit alors dans la tendance du posterior, pas dans un seul score de benchmark.

Cela compte parce que la régulation converge vers le même cadrage. Le livre blanc note l'alignement avec le EU AI Act et le NIST Risk Management Framework, qui demandent tous deux un traitement du risque continu et fondé sur l'évidence plutôt qu'une déclaration unique. Un laboratoire avec seulement un cutoff de capacité ne peut pas répondre à la question que ces cadres posent réellement : « Quel est votre risque mesuré, et quel est votre mécanisme pour le maintenir sous le niveau accepté ? »

Le réseau bayésien est le mécanisme de mesure

La proposition constructive du livre blanc est les réseaux bayésiens (BN) : des graphes probabilistes qui représentent les relations entre variables — capacité d'IA, comportement de l'attaquant, détection de la défense, impact économique — et qui intègrent une évidence diverse et se mettent à jour continûment à mesure que les conditions changent. Contrairement à un seuil statique, un BN permet de suivre à quel point un système est proche de franchir une frontière de risque, parce que la frontière est une région dans une distribution jointe, pas un seul nombre sur un axe.

C'est la partie du livre blanc qui se relie le plus directement à notre façon de penser le mécanisme. Un BN n'est pas une prédiction au sens colloquial ; c'est un instrument de mesure. Il dit, étant donné ce que nous avons observé, voici le posterior sur les variables de dommage, et voici comment il bouge quand nous introduisons un nouveau résultat de red team ou un nouveau rapport d'incident. Le seuil est alors une politique sur ce posterior — « le déploiement est restreint quand P(dompage significatif) dépasse 0.X » — et la politique est applicable parce que le posterior est reproductible à partir de l'évidence et du graphe.

Trois propriétés font d'un BN la bonne forme pour ce travail, et chacune mappe à une propriété que nous cherchons dans tout mécanisme de mesure :

• Décomposition. Un risque de haut niveau (« l'IA permet le phishing à grande échelle ») est décomposé en variables mesurables — maîtrise linguistique de l'IA, crédibilité de l'appât, taux de détection de la défense, susceptibilité de la cible. On ne peut pas mesurer « le risque de phishing » directement ; on peut mesurer ses composants. La décomposition est ce qui rend le risque lisible pour l'évidence.
• Dépendance. Les variables sont liées par des probabilités conditionnelles, pas sommées indépendamment. Le succès de l'attaque dépend conjointement de la capacité et de la défense, pas de chacune séparément. C'est pourquoi un seuil purement de capacité échoue : il suppose que la jointe se lit à partir d'une marginale.
• Mise à jour. Le posterior est une fonction de l'évidence, et l'évidence s'accumule. Un BN est un instrument longitudinal par construction ; le posterior d'hier est l'a priori d'aujourd'hui. C'est ce que « surveillance dynamique » signifie opérationnellement, pas comme slogan.

La limite honnête que le livre blanc lui-même nomme est que ces modèles sont à un stade précoce : il n'y a pas de BN validés dans le monde réel à grande échelle, pas de jeux de données standardisés pour peupler les probabilités, et pas d'intégration de gouvernance claire — qui fixe les seuils, comment ils sont appliqués. Je cite la propre section « What's Missing » du livre blanc parce qu'une lecture honnête ne la recouvre pas. Un mécanisme de mesure jamais calibré contre des résultats est une hypothèse sur une mesure, pas encore une mesure. Le mécanisme a la bonne forme ; la base d'évidence n'est pas construite.

Comment l'étude de cas du phishing transforme « augmentation significative » en un nombre

L'étude de cas du phishing du livre blanc (pages 31–32) est là où l'abstraction devient concrète. Un réseau bayésien décompose le risque d'ingénierie sociale en nœuds — « maîtrise linguistique de l'IA », « crédibilité de l'appât », « taux de détection de la défense », « susceptibilité de la cible » — qui déterminent conjointement des résultats comme le fait qu'un employé ouvre un courriel malveillant. Des concepts vagues deviennent des signaux quantifiables parce que chaque nœud est quelque chose pour lequel vous pouvez produire de l'évidence : un score de maîtrise linguistique d'un benchmark, un taux de détection d'un test de filtre de courrier, une estimation de susceptibilité d'une campagne de simulation de phishing.

L'étude de cas fait deux choses à la fois, et il vaut la peine de les séparer. D'abord, elle montre qu'un terme de risque comme « augmentation significative de l'efficacité du phishing » peut être décomposé en variables avec des unités. Ensuite, elle montre que l'augmentation elle-même est un changement dans une distribution jointe, pas dans un seul score. Une amélioration de 10 % de la maîtrise linguistique ne se traduit pas linéairement en 10 % de courriels ouverts en plus ; elle se traduit à travers le taux de détection et le nœud de susceptibilité, et la traduction est différente dans une entreprise défendue que dans une petite entreprise non défendue.

C'est la différence entre un benchmark de capacité et un seuil de risque énoncé avec précision. Un benchmark dit que le modèle s'est amélioré sur une tâche. Un BN dit combien cette amélioration a déplacé le posterior de dommage dans les conditions où vous déployez réellement. Le premier est nécessaire ; le second est ce qu'un seuil exige. La contribution du livre blanc est de montrer que le second est constructible, pas seulement souhaitable — et de montrer, honnêtement, que le travail de le peupler à grande échelle a à peine commencé.

Ce que cela mappe chez Everythink

Nous lisons ce livre blanc à travers une lentille spécifique, et il vaut la peine d'être explicite pour que le lecteur puisse vérifier notre raisonnement plutôt que de l'accepter sur foi.

[PERSONAL EXPERIENCE] Le HAI Engine tourne en production depuis 2016, et la leçon de neuf ans d'exploitation d'un système de prévision multi-agent est qu'une prévision que vous ne pouvez pas mettre à jour est une prévision que vous ne devriez pas publier. Nos Sisters produisent des brouillons de scénarios ; l'Oracle les fusionne en un ensemble calibré dont les probabilités somment à un et dont l'entropie est suivie en nats. Cet ensemble est un instrument de mesure, pas une prédiction au sens colloquial : reproductible à partir de ses entrées, mis à jour à mesure que l'évidence s'accumule, faux de façon traçable quand il se trompe. La proposition de BN de Berkeley a la même forme appliquée à un domaine différent — variables de dommage au lieu de probabilités de scénario, évidence de red team au lieu de flux de signaux — mais la même insistance sur le fait que le nombre n'est fiable que si le mécanisme qui l'a produit est inspectable.

Le principe structurel que nous partageons est celui que nous appelons « the space is the router » : la topologie network→community→room route une requête avant que quoi que ce soit réponde. Le routage est un mécanisme qui produit un résultat mesurable — quel contexte a vu quel signal — et c'est ce qui rend la prévision aval auditable. Un seuil sans topologie de routage est un nombre attaché à un modèle ; un seuil à l'intérieur d'une topologie de routage est un nombre attaché à un chemin à travers un système, qui est le seul endroit où le dommage vit réellement. Le dommage est contextuel, et le contexte est une topologie.

Nos étiquettes d'honnêteté existent pour la même raison pour laquelle le livre blanc insiste sur l'évidence plutôt que l'affirmation. Là où nous avons un mécanisme en production, nous disons Production ✅ — le HAI Engine, Social, Campaigns, Whitelabel Network, World Monitor, les Sisters, l'Oracle. Là où le mécanisme est partiel, nous disons Partial ⚠️ — Matchmaking, Marketplace, Calendar. Là où c'est une feuille de route, nous disons Roadmap 🔵 — Wallet & Token, Super App, Community Credit — et nous ne promettons pas de résultats pour ceux-ci parce qu'ils sont pré-revenu et, pour les composants de token, soumis à la révision Howey. Le point n'est pas le glyphe ; le point est qu'un lecteur peut mapper chaque affirmation à un état de maturité et nous y tenir. C'est la même discipline que le livre blanc demande aux laboratoires de frontière : arrêter d'affirmer des seuils, commencer à produire les mesures qui les justifieraient.

Nous sommes explicites sur la limite de portée parce que le livre blanc l'est aussi. Everythink opère uniquement dans des contextes civils et défensifs. Un mécanisme de seuil de risque honnête sur la capacité offensive n'est pas une licence pour construire des outils offensifs ; c'est une raison de savoir où est la ligne défensive et de l'instrumenter. Le cadre de Berkeley nous est utile précisément parce qu'il rend la posture défensive mesurable plutôt que rhétorique.

La lacune de gouvernance que le livre blanc nomme honnêtement

La section la plus utile du livre blanc est peut-être sa propre liste « What's Missing », parce que c'est la partie qui empêche la proposition de devenir une autre affirmation de capacité. Il manque au cadre des modèles bayésiens validés dans le monde réel à grande échelle, des jeux de données standardisés pour peupler les probabilités, des orientations claires d'intégration de gouvernance, et des benchmarks empiriques liant la capacité du modèle à l'impact cyber réel. Des domaines plus complexes — exploitation autonome, attaques sur la chaîne d'approvisionnement — ne sont pas profondément opérationnalisés.

Nous ajouterions une lacune que le livre blanc effleure mais ne détaille pas : un mécanisme de seuil n'est fiable que par l'indépendance de l'évidence qui l'alimente. Un laboratoire qui peuple son propre BN avec ses propres résultats de red team, contre ses propres lignes de base, sans contrôle externe, a construit un instrument qui rapporte ce dont le laboratoire a besoin qu'il rapporte. La demande de jeux de données standardisés est en partie une demande d'évidence qui ne provienne pas toute de la partie mesurée. C'est la question de gouvernance que le cadre laisse ouverte, et c'est la bonne à laisser ouverte — la réponse est institutionnelle, pas technique.

La conséquence pragmatique est qu'un mécanisme de seuil digne de gouverner est un qu'un tiers peut reproduire : graphe publié, évidence nommée, a priori déclarés, posterior recalculable. Un BN qui remplit ces conditions est auditable de la façon dont un régulateur peut réellement l'utiliser ; un qui ne le fait pas est une affirmation propriétaire déguisée en mesure.

Points clés

• Un cutoff de capacité n'est pas un seuil de risque ; c'est une affirmation d'un instant sur un modèle qui ignore le contexte où le dommage vit.
• Le livre blanc de Berkeley reformule la question de « ce modèle franchit-il une ligne ? » à « quelle est la probabilité qu'il cause un dommage dans des conditions réelles ? » — un passage d'un jalon statique à une mesure maintenue.
• Les réseaux bayésiens sont le mécanisme de mesure proposé : décomposer le risque en variables, les lier par des probabilités conditionnelles, alimenter avec benchmark et red teaming et évidence du monde réel, et mettre à jour continûment.
• L'étude de cas du phishing montre que des termes vagues comme « augmentation significative » peuvent être décomposés en nœuds avec des unités — mais le travail de peupler ces modèles à grande échelle a à peine commencé, et le livre blanc le dit.
• Theorem 3 généralise le principe : une propriété (risque acceptable) est garantie exactement quand son mécanisme (un posterior continûment mis à jour et inspectable) est implémenté et mesure.
• Un mécanisme de seuil n'est gouvernable que si un tiers peut le reproduire — graphe publié, évidence nommée, a priori déclarés, posterior recalculable.

Questions fréquentes

Pourquoi un benchmark de capacité n'est-il pas un seuil de risque ? Un benchmark mesure ce qu'un modèle peut faire dans un test ; le risque est ce qui arrive quand cette capacité rencontre un défenseur, un attaquant et une cible dans le monde réel. Le benchmark est un input d'une estimation de risque ; ce n'est pas l'estimation. Le point du livre blanc est que traiter la marginale comme si elle était la jointe est l'erreur centrale des seuils des cadres de frontière.

Qu'apporte un réseau bayésien qu'une checklist n'apporte pas ? Une checklist enregistre qu'un contrôle existe ; un BN enregistre combien le contrôle a déplacé le posterior de dommage. La première est binaire et statique ; le second est continu et actualisable. Un BN rend aussi les dépendances explicites — le succès de l'attaque dépend conjointement de la capacité et de la défense — ce qu'une checklist ne peut pas représenter sans devenir le BN en forme de prose.

Le cadre de Berkeley est-il prêt à gouverner aujourd'hui ? Non, et le livre blanc le dit directement. Il lui manque des modèles validés à grande échelle, des jeux de données standardisés et une intégration de gouvernance claire. C'est une méthodologie — une façon reproductible d'opérationnaliser le risque — pas un instrument fini. Le traiter comme fini répéterait l'erreur qu'il critique : affirmer une propriété au lieu de la mesurer.

Comment cela se relie-t-il à Theorem 3 ? Theorem 3 dit qu'une propriété est garantie exactement quand son mécanisme est implémenté et mesure. « Cyberrisque acceptable » est une propriété d'un déploiement, pas d'un modèle. La garantie n'existe que quand un BN (ou un instrument équivalent) tourne, est alimenté et est inspectable. Déclarer un cutoff n'implémente aucun mécanisme et ne garantit donc rien.

À quoi Everythink utilise-t-il cela ? Nous utilisons le même principe structurel — un posterior reproductible et actualisable produit par un mécanisme inspectable — dans le HAI Engine et l'Oracle, pour la prévision plutôt que pour des seuils de cyberrisque. La topologie de routage (network→community→room) est ce qui rend nos prévisions contextuelles et auditables. Nous ne construisons pas d'outils offensifs ; la valeur d'une ligne défensive mesurable est de savoir où elle est.

Si ce cadrage est utile, le travail qui suit est opérationnel : choisissez un risque, décomposez-le, liez les variables, nommez l'évidence et commencez à mettre à jour. Créez votre réseau, ou lisez les papers.

Sources

• 2026 — UC Berkeley Center for Long-Term Cybersecurity, « Toward Risk Thresholds for AI-Enabled Cyber Threats » (livre blanc, janvier 2026 ; résumé publié par AIGL, mars 2026) — https://www.aigl.blog/toward-risk-thresholds-for-ai-enabled-cyber-threats-2/