Anthropic prouve l'origine d'une réponse d'IA sans dévoiler les poids du modèle

Lorsque vous appelez un modèle coûteux via l'API d'un tiers, vous devez croire le fournisseur sur parole. L'interface affiche un nom, mais il est généralement impossible de vérifier quel modèle a réellement produit la réponse. Pour une requête isolée, c'est désagréable. Pour l'audit de code, un service médical ou l'évaluation de risques métier, cette incertitude devient un problème de confiance.

Anthropic étudie FlashProve, un système ouvert de preuve cryptographique de l'origine des résultats d'IA. L'idée est simple : le laboratoire publie l'empreinte du modèle qu'il a lancé, et chaque résultat peut être accompagné d'une preuve mathématique. L'utilisateur compare la preuve à l'empreinte et s'assure que la réponse provient bien du modèle annoncé.

À quoi cela ressemble en pratique

Imaginons un service qui vend la vérification d'un dépôt de code avant une mise en production. Il affirme envoyer le code à un modèle de pointe pour détecter des vulnérabilités. Aujourd'hui, le client ne voit qu'un rapport et une facture, et aucun des deux ne prouve quel système a réalisé l'analyse.

Avec FlashProve, le service pourrait fournir une preuve cryptographique avec le rapport. Le client la vérifierait sur son appareil et confirmerait que ce résultat est lié à l'empreinte du bon modèle. Si un intermédiaire a discrètement remplacé le modèle coûteux par un modèle moins cher, la vérification ne devrait pas aboutir.

Le même mécanisme fonctionne dans l'autre sens. Le développeur d'un modèle ne pourrait pas substituer une version plus puissante pendant une démonstration pour améliorer artificiellement les résultats d'un test. La preuve relie la sortie non pas au nom affiché dans l'interface, mais à une empreinte publiée précise.

Détail important : la vérification n'exige pas de dévoiler les poids, c'est-à-dire les paramètres numériques internes du modèle. Le schéma convient donc en principe non seulement aux systèmes ouverts, mais aussi aux systèmes commerciaux d'Anthropic, d'OpenAI et d'autres laboratoires. Les auteurs conçoivent en outre une vérification assez légère pour s'exécuter en local, sans serveur puissant dédié.

Ce que cela change pour les développeurs et les produits

Si l'approche devient un standard opérationnel, les API disposeront d'une nouvelle couche vérifiable. Aujourd'hui, un contrat confirme généralement le format de la requête, le prix et le nom du modèle. À l'avenir, on pourra joindre à la réponse une preuve de son origine et la conserver dans un journal d'audit.

Pour un développeur, cela signifie pouvoir vérifier le fournisseur du modèle plutôt que de se fier à sa seule documentation. Pour un produit, cela permet de confirmer aux clients quel système a traité leurs données. Pour un fondateur, c'est un moyen de mieux contrôler les prestataires qui vendent une « analyse par un modèle de pointe » sans montrer ce qui se passe en coulisses.

Le scénario pratique est particulièrement parlant dans les chaînes à plusieurs intermédiaires : l'application appelle une plateforme d'automatisation, qui s'adresse à un agrégateur, lequel interroge le laboratoire. Plus la chaîne est longue, plus il est facile de perdre la certitude de savoir quel modèle a fait le travail. La preuve cryptographique peut parcourir toute la chaîne avec le résultat.

Pourquoi il est encore trop tôt pour l'adopter

FlashProve reste un travail de recherche. Anthropic indique clairement que le programme n'est pas terminé et qu'aucun déploiement n'est pour l'instant prévu, ni en interne ni dans d'autres laboratoires. La spécification technique et le code fonctionnel de certains composants sont publiés, mais il ne s'agit ni d'une fonctionnalité Claude aboutie ni d'un protocole communément admis.

Par ailleurs, le schéma suppose la participation des laboratoires eux-mêmes : ils doivent publier les empreintes des modèles et prendre en charge l'émission des preuves. Sans cela, un développeur indépendant ne pourra pas ajouter une vérification complète au-dessus d'une API fermée existante. La preuve cryptographique ne répond d'ailleurs qu'à la question de l'origine du résultat. Elle ne démontre pas que la réponse est correcte, sûre ou adaptée à la tâche posée.

L'étape pratique aujourd'hui n'est donc pas de rebâtir la production autour de FlashProve, mais d'étudier la spécification et de suivre les expérimentations. Les équipes qui achètent l'accès aux modèles via des intermédiaires devraient dès maintenant consigner séparément les versions des modèles, les paramètres des requêtes et les journaux d'appels. Si l'inférence prouvable devient un standard, ces processus offriront une place toute trouvée à la nouvelle preuve : à côté de chaque résultat critique qu'il faut aujourd'hui accepter sur parole.