AI en cryptographie : un modèle sans le droit d'avoir raison

Lorsque l'IA est intégrée dans un système cryptographique, la question surgit souvent : le modèle peut-il trouver la bonne réponse ? Mais dans le contexte des systèmes hautement fiables, c'est la mauvaise question. La bonne question est différente : est-il possible d'intégrer l'IA de manière à ce que, même en cas d'erreur, elle ne puisse pas prendre une décision dangereuse ?

Governed

Solver Orchestration : Une Architecture de Confiance

Dans nonce-observatory, une architecture a été implémentée où l'IA joue un rôle clairement défini de planificateur, mais n'agit jamais comme source de vérité. Le modèle n'analyse que les données publiquement disponibles et sûres (contrat public-safe feature), propose des itinéraires d'exécution pour les solvers et aide au triage et à l'explication des solutions choisies. Mais il existe une limite stricte — un ensemble de champs interdits — que le modèle ne peut physiquement pas voir.

Voici ce qui est disponible pour l'IA :

• Analyse du contrat public-safe feature
• Proposition d'itinéraires de solver et optimisation des itinéraires
• Construction des files d'attente d'exécution dans le bon ordre
• Assistance à la classification des tâches et explication du choix
• Recommandations sans assumer la prise de décision finale

Et voici ce qui se trouve au-delà de la limite non-escalation :

• Champs nonce privés (données secrètes critiques)
• Valeurs de candidate_d et k des algorithmes cryptographiques
• Formation de recovery claims
• Conversion de son score ou métrique en preuve cryptographique

Limite Non-escalation et Vérification Déterministe

La limite se situe entre deux couches : le planificateur IA et le vérificateur déterministe. L'IA peut se tromper dans les recommandations d'itinéraire — ce n'est pas critique. Pourquoi ? Parce que la décision finale est toujours prise par un vérificateur exact qui fonctionne selon des règles cryptographiquement vérifiables et déterministes, sans jugement du modèle. Cette approche change complètement le paradigme de développement.

Généralement, les systèmes hautement fiables nécessitent une IA très intelligente qui ne doit simplement pas faire d'erreurs — sinon tout s'effondre. Ici, la stratégie est différente : l'IA peut être intellectuellement moyenne. La contrainte clé est que son erreur ne doit jamais devenir automatiquement un fait du système.

« L'IA suggère.

Le vérificateur exact décide. » — non seulement un motif architectural, mais une philosophie du développement de l'IA en cryptographie.

Pourquoi

Ceci Est Critique pour les Systèmes Hautement Fiables

Les systèmes critiques sont souvent construits sur l'hypothèse de solutions univoques. Si l'IA dit « c'est correct » et que le système l'accepte comme un axiome — et le modèle s'est trompé — tout le protocole et ses garanties sont compromis. Il n'y a pas un tel risque ici.

La logique de fonctionnement :

• Le modèle n'analyse que les données publiées
• Propose des itinéraires candidats pour lancer les solvers
• Le vérificateur vérifie de manière déterministe chaque étape
• La preuve cryptographique est formée sans implication de l'IA

L'article est particulièrement utile pour tous ceux qui conçoivent de l'IA dans des systèmes critiques — pas seulement cryptographiques. Si l'erreur d'un modèle ne doit pas devenir automatiquement une décision du système, c'est exactement ce type de limite architecturale qui est nécessaire.

Ce Que Cela Signifie

L'IA dans les systèmes critiques ne consiste pas à ce que le modèle soit parfait et ne fasse jamais d'erreurs. Il s'agit de la bonne répartition des responsabilités entre les composants. Il y a des tâches pour l'IA : analyse des données, recommandations d'itinéraires, optimisation des files d'attente. Il y a des tâches uniquement pour les vérificateurs déterministes : décision finale, inférence cryptographique, garanties de sécurité. Lorsque cette limite est claire et strictement appliquée, le système reste sûr même avec des capacités modestes du modèle.