Mécanismes de vérification
Comment vérifier qu'un État ou un Frontier Lab respecte ses engagements sur le développement de modèles d'IA ? Sans mécanisme technique, tout accord reste déclaratif. Ce programme structure la recherche sur les briques qui rendent cette vérification possible, de la preuve cryptographique d'un entraînement au matériel de confiance en datacenter.
Lorsque plusieurs États ou entreprises s'engagent mutuellement à respecter des règles sur le développement de modèles d'IA, par exemple un plafond de puissance de calcul pour un entraînement, il faut pouvoir vérifier que chaque partie tient ses engagements. Sans mécanisme de vérification technique, tout accord reste déclaratif. Ce programme de recherche porte sur les problèmes ouverts qui conditionnent la faisabilité d'une telle vérification au niveau de l'infrastructure de calcul : prouver cryptographiquement qu'un entraînement s'est déroulé conformément à ce qui a été déclaré, garantir l'exécution déterministe des calculs sur GPU, et concevoir des dispositifs matériels de confiance capables de surveiller les opérations d'un datacenter sans en révéler le contenu. Les problèmes listés ci-dessous couvrent l'ensemble de cette chaîne technique. Initié en France par le GPAI Policy Lab, ce programme a vocation à structurer ce champ de recherche et à le faire croître jusqu'à la résolution de ces problèmes.
Les définitions
Garanties de contrôle : garanties que le comportement d'un système d'IA est contrôlable en toute circonstance et qu'il ne pose pas de problème grave de sécurité.
Exemple : preuve formelle de fonctionnement du modèle selon les spécifications des développeurs, dans toutes les situations que le système pourrait rencontrer.
Engagements de conformité : engagement de la part des développeurs de modèles de ne pas mettre en œuvre de processus de développement et de déploiement non conforme aux règles établies en commun.
Exemple : engagement à ne pas entraîner utiliser une puissance de calcul supérieure à 10^28 FLOPs pour entraîner un modèle d'IA à usage général.
Mécanisme de vérification : moyen technique permettant de vérifier la mise en application des engagements de conformité pris par un acteur.
Exemple : mécanisme de surveillance des opérations au niveau des serveurs permettant de monitorer le nombre de FLOPs utilisés durant un entraînement.
Le problème
Le comportement des modèles d'IA fondés sur l'apprentissage profond est actuellement impossible à prédire avec certitude. Leurs mécanismes de prise de décision sont encodés dans des combinaisons de matrices de très haute dimension que l'on ne sait pas interpréter, et par conséquent pas superviser de manière fiable. C'est pour cette raison que ces systèmes sont qualifiés de « boîtes noires ».
Les méthodes de développement de ces systèmes s'appuient exclusivement sur des approximations des objectifs souhaités par les développeurs. Deux sources d'erreur sont irréductibles dans le paradigme actuel. D'une part, les développeurs ne peuvent pas entièrement spécifier en lignes de code les objectifs à poursuivre et les contraintes à respecter ; l'utilisation d'objectifs simplifiés induit une misspecification. D'autre part, la distribution des données d'entraînement ne peut jamais être totalement représentative de l'ensemble des situations que le système rencontrera en déploiement, ce qui produit des problèmes de généralisation. Sous forte pression d'optimisation, ces méthodes produisent par défaut des divergences systématiques entre les objectifs attendus et ceux internalisés par le système (Goodhart failure modes). Il n'existe donc actuellement aucune méthode permettant d'encoder des règles strictes au sein des modèles d'IA fondés sur l'apprentissage profond.
Il en découle qu'il n'est pas possible, en l'état, de fournir de garantie de contrôle sur le comportement de ces systèmes : on ne peut pas démontrer formellement qu'un modèle donné se comportera conformément aux spécifications de ses développeurs dans toutes les situations qu'il pourrait rencontrer. Les approches alternatives visant explicitement à fournir de telles garanties (safe-by-design) existent, mais leur niveau de performance reste très inférieur à celui de l'apprentissage profond, et les ressources investies dans leur développement sont marginales en comparaison.
Ce problème de contrôle a une conséquence directe sur la gouvernance internationale de l'IA. Tout accord entre acteurs (États, entreprises) portant sur le développement de systèmes d'IA, par exemple un seuil de puissance de calcul autorisé pour un entraînement, ou l'interdiction de certaines méthodes, n'est crédible que si les parties disposent de mécanismes de vérification permettant de s'assurer que chaque acteur respecte effectivement ses engagements. Ce problème est analogue à celui de la vérification dans le domaine nucléaire (rôle de l'AIEA) ou chimique (rôle de l'OIAC), mais présente des contraintes techniques spécifiques au domaine de l'IA.
L'accès à de grands centres de calcul étant une condition nécessaire au développement des modèles d'IA de frontière, l'approche la plus directe consiste à mettre en place des mécanismes de vérification au niveau de l'infrastructure de calcul elle-même : centres de données, nœuds de calcul, contrôleurs d'interface réseau, et GPU. Chaque niveau d'observation offre un compromis différent entre la finesse des métriques observables, la robustesse face aux tentatives de contournement, et la complexité de déploiement.
Ces mécanismes doivent satisfaire simultanément trois contraintes :
- Détection des défections : Les dispositifs doivent être en mesure de rendre toute violation des engagements soit impossible, soit manifeste. Par analogie, l'AIEA s'appuie sur des systèmes de scellés et de caméras dont la désactivation est elle-même un signal détectable. Dans le contexte des centres de calcul, cela implique de concevoir des systèmes dont le contournement est soit techniquement infaisable, soit détectable avec un niveau de confiance quantifiable.
- Préservation de la confidentialité : Le monitorage des activités au sein des centres de calcul implique un accès potentiel à des informations relevant du secret industriel : architecture et hyperparamètres des modèles, données d'entraînement, procédures d'entraînement, poids des modèles. Les dispositifs de vérification doivent être conçus de sorte à ne produire que des informations agrégées (métriques d'intérêt, signatures cryptographiques) sans moyen d'exfiltrer les données brutes.
- Transparence et auditabilité : Les dispositifs de vérification déployés dans les centres de calcul d'un acteur pourraient eux-mêmes contenir des vulnérabilités exploitables, pour de l'espionnage industriel, du sabotage, ou pour faire passer un acteur conforme pour un tricheur. Par conséquent, les dispositifs doivent être librement auditables par tous les acteurs impliqués. La méthode la plus robuste consiste à co-construire des solutions open source (logiciel et composants matériels) via des projets de collaboration internationale, ce qui aligne les incitations de chaque acteur vers la fiabilisation du dispositif.
Ce programme de recherche porte sur l'ensemble des problèmes techniques nécessaires pour concevoir, implémenter et déployer de tels mécanismes de vérification. Depuis les preuves cryptographiques jusqu'à la conception de composants matériels dédiés.
Les problèmes ouverts
Fondements des Preuves
Problème ouvert 1
Réductions Algébriques pour la Vérification de GEMM en Virgule Flottante
En raison de la complexité inhérente en O(n³) de la vérification naïve de matrices, et étant donné que les approches de Freivalds et du sumcheck échouent en raison de l'arrondissement non associatif en virgule flottante, l'échantillonnage par élément (k = 4 605 entrées par matrice) est la stratégie de vérification actuellement retenue pour les GEMM en BF16/FP32. L'échantillonnage par élément est-il optimalement prouvable pour la vérification du matmul en virgule flottante, ou existe-t-il un raccourci algébrique exploitant la structure (par exemple, la topologie de l'arbre d'accumulation déclarée dans le precompile) ? Une borne inférieure serrée clôturerait cette question ; une réduction algébrique réduirait le coût de preuve dominant.
Problème ouvert 2
Minimisation des Contraintes pour les Precompiles MAC en BF16/FP32
Le precompile MAC (Multiply Accumulate) coûte environ 90 contraintes par opération sur le corps de Baby Bear. Il constitue le goulot d'étranglement pour environ 99 % du budget de génération de preuve. Des custom gates, des arguments de lookup ou des représentations de corps alternatifs permettraient-ils de ramener ce coût à 30–50 contraintes ? Même une amélioration d'un facteur 2 réduirait de moitié le coût de preuve à l'échelle frontière.
Problème ouvert 3
Preuve ZK de la Rétropropagation (Affirmation Centrale Non Démontrée)
Aucun travail antérieur n'a produit de preuve à divulgation nulle (zero-knowledge) de la rétropropagation (back propagation) d'un réseau de LLM complet (une telle preuve existe pour du LoRA fine-tuning, sur des modèles sans virgule flottante). La rétropropagation repose sur les mêmes primitives que la passe avant (forward pass), mais le circuit complet avant+arrière n'a jamais été démontré dans une zkVM. Nous cherchons soit : (a) une preuve fonctionnelle pour un transformer d'au moins 1M de paramètres avec correspondance bit-exacte des gradients, soit (b) l'identification d'un obstacle fondamental. Il s'agit du jalon le plus risqué de notre feuille de route de recherche.
Exécution Déterministe sur le Matériel
Problème ouvert 4
Kernels Déterministes pour la Rétropropagation d'Attention avec moins de 5 % de Surcoût
La rétropropagation (back propagation) de FlashAttention-2/3 engendre un surcoût de 23–82 % en mode déterministe (croissant avec la longueur de séquence). DASH atteint une accélération de 1,28×. Peut-on concevoir des kernels pour la rétropropagation des opérations d'attention par construction (par exemple via des arbres de réduction fixes au niveau des warps du GPU) avec moins de 5 % de surcoût pour des longueurs de séquence ≥ 8K ? Il s'agit de la principale source du determinism tax et du levier le plus important pour réduire le coût de vérification à l'échelle frontière.
Problème ouvert 5
Spécification de Precompiles Multi-Architectures
Chaque GPU (H100, MI300X, Gaudi3) possède une topologie d'arbre d'accumulation, un mode d'arrondi et un comportement FTZ (Flush To Zero) distincts, nécessitant un precompile séparé par cible. Peut-on définir une famille de precompiles paramétrée (instanciée automatiquement à partir d'un descripteur matériel compact) et la valider sur silicium ?
- Langage de spécification formelle pour les numériques constructeurs.
- Génération automatique de contraintes à partir de la spécification.
- Méthodologie de validation empirique (combien de vecteurs de test suffisent à confirmer que la spécification correspond au matériel ?).
Ancres de Confiance Matérielles
Problème ouvert 6
TAP Réseau Open-Hardware à 400+ Gbps
Le protocole requiert un dispositif passif et auditable hachant l'intégralité du trafic inter-nœuds à débit nominal.
- Hachage Poseidon en streaming à 400 Gbps dans le fabric FPGA.
- Packaging physique inviolable.
- Vérification formelle du RTL par rapport à la spécification de référence.
Une conception de TAP open-source et formellement vérifiée constituerait une nouvelle primitive de confiance pour la communauté de gouvernance de l'IA.
Problème ouvert 7
Distinguer les SDC des Déviations Adversariales
Les corruptions silencieuses matérielles (~120 événements par entraînement à l'échelle de GPT-3) produisent des inversions de bits indiscernables d'une modification intentionnelle au niveau de l'événement individuel. Un adversaire sophistiqué pourrait dissimuler des déviations en les faisant passer pour des SDC. Peut-on concevoir des tests statistiques distinguant les schémas de SDC matériels (aléatoires, sans mémoire, corrélés avec des modes de défaillance connus) d'une injection adversariale structurée ? Cela pourrait nécessiter une caractérisation empirique des distributions de SDC sur le matériel actuel.
Extensions du Protocole
Problème ouvert 8
Vérification du Fine-Tuning et du RLHF
Le protocole actuel couvre le pré-entraînement. Son extension au post-entraînement introduit des défis spécifiques :
- Le RLHF intègre un modèle de récompense dans la boucle de vérification, qui devra vraisemblablement être lui aussi vérifié.
- Le DPO implique des comparaisons par paires.
Quel est le protocole de vérification minimal pour chaque méthode de post-entraînement qui préserve la chaîne de confiance établie lors du pré-entraînement ?
Problème ouvert 9
Vérification de l'Entraînement Multi-Site
L'entraînement frontière s'étend de plus en plus sur plusieurs datacenters reliés par des liens WAN. Le modèle TAP suppose un point d'observation contrôlé par le vérificateur sur chaque lien inter-nœuds. Comment le protocole s'adapte-t-il lorsque certains liens franchissent des frontières administratives ? Quelles hypothèses de confiance changent lorsque des segments réseau sont contrôlés par des parties distinctes ?
Nos travaux
Prépublication : La vérification par preuve à divulgation nulle de connaissance de l'entraînement des IA de frontière est possible
Juin 2026
Garanties de contrôle de l'IA et mécanismes de vérification : Implications et options pour la France
Mai 2026
Puissance de calcul : Chaîne d'approvisionnement et dépendances stratégiques pour le développement de l'IA
Juillet 2026
Les contributeurs
Tom David
Pilotage de la stratégie · CEO, GPAI Policy Lab
Pierre Peigné
Pilotage de la roadmap technique · Chercheur en Sécurité de l'IA, GPAI Policy Lab
Dr. Ky Nguyen
Maître de Conférence, Sorbonne Université – LIP6
Dr. Paul Wang
Post-Doc, Sorbonne Université – LIP6
Dr. Emeric Bergmann
STMicroelectronics
Dr. Dimitris Kolonelos
Post-Doc, UC Berkeley
Bibliographie
Systèmes de preuve zero-knowledge
- Groth, Jens. "On the Size of Pairing-Based Non-interactive Arguments." IACR Cryptol. ePrint Arch. 2016 (2016): 260.
- Ben-Sasson, Eli et al. "Scalable, transparent, and post-quantum secure computational integrity." IACR Cryptol. ePrint Arch. 2018 (2018): 46.
- RISC Zero. Scalable, Transparent Arguments of RISC-V Integrity (Proof System in Detail). RISC Zero, 2025, https://dev.risczero.com/proof-system-in-detail.pdf.
- Bünz, Benedikt et al. "Recursive Proof Composition from Accumulation Schemes." Theory of Cryptography Conference (2020).
Vérification des GEMM
- Freivalds, Rusins. "Fast Probabilistic Algorithms." International Symposium on Mathematical Foundations of Computer Science (1979).
- Sun, Haochen et al. "zkLLM: Zero Knowledge Proofs for Large Language Models." Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security (2024).
Entraînement déterministe
- Shah, Jay et al. "FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision." ArXiv abs/2407.08608 (2024).
- Qiang, Xinwei et al. "DASH: Deterministic Attention Scheduling for High-throughput Reproducible LLM Training." ArXiv abs/2601.21824 (2026).
Preuves de concept existantes
- Abbaszadeh, Kasra et al. "Zero-Knowledge Proofs of Training for Deep Neural Networks." Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security (2024).
- Qu, Wenjie et al. "zkGPT: An Efficient Non-interactive Zero-knowledge Proof Framework for LLM Inference." IACR Cryptology ePrint Archive (2025).
- Liao, Guofu et al. "zkLoRA: Fine-Tuning Large Language Models with Verifiable Security via Zero-Knowledge Proofs." ArXiv abs/2508.21393 (2025).
Hardware / SDC
- Hochschild, Peter H. et al. "Cores that don't count." Proceedings of the Workshop on Hot Topics in Operating Systems (HotOS '21). ACM, 2021, pp. 9–16. https://doi.org/10.1145/3458336.3465297.
- Dixit, Harish Dattatraya et al. Silent Data Corruptions at Scale. arXiv, 2021. https://arxiv.org/abs/2102.11245.
Pour participer
Ce programme est ouvert aux chercheurs et ingénieurs travaillant en cryptographie, sécurité hardware, méthodes formelles, systèmes distribués ou gouvernance technique de l'IA (en poste académique, en entreprise ou indépendants).
Nous organisons régulièrement, sur invitation, des workshop de travail au Campus Cyber (La Défense).
Si vous travaillez sur un des problèmes ouverts listés sur cette page, sur un problème connexe que nous n'avons pas identifié, ou que vous souhaitez contribuer à rejoindre la communauté de recherche, écrivez-nous à contact@gpaipolicylab.org avec quelques lignes sur ce que vous envisagez.
Nous cherchons avant tout des contributions durables mais sommes ouverts aux contributions ponctuelles (formalisation d'un problème, relecture, etc.).
Pour toute question : contact@gpaipolicylab.org.
Vous souhaitez contribuer aux travaux de recherche du GPAI Policy Lab ?
Découvrir la Résidence de recherche