On ne peut pas gérer un modèle qu'on ne peut pas nommer
Le 19 août, Stripe a acquis OpenRouter dans une transaction rapportée à plus de sept milliards de dollars. La logique est solide, et le prix vous dit à quel point : OpenRouter était devenu la passerelle neutre par défaut vers des centaines de modèles, et acheminer une requête vers le modèle le moins cher capable de la traiter est une entreprise réelle et vaste.
Autre chose en découle, et cela a reçu bien moins d'attention. Si une couche choisit le modèle à votre place, par requête, selon des critères qui changent, alors l'identité du modèle qui a servi un appel donné n'est plus une décision que vous avez prise. C'est un résultat que vous avez reçu.
Un analyste de l'industrie l'a dit plus crûment qu'aucun fournisseur ne le ferait : les entreprises ne font plus un choix clair et délibéré du modèle d'IA qu'elles adoptent.
L'identité est devenue dynamique. Les obligations, non.
Beaucoup de devoirs tiennent encore à l'identité précise d'un modèle, et plusieurs d'entre eux tiennent à son origine plutôt qu'à sa performance.
- Marchés publics fédéraux. La NDAA pour l'exercice 2026 oblige le département de la Défense à exclure certains développeurs d'IA nommés de ses systèmes, et interdit aux contractants et sous-traitants de les utiliser dans l'exécution des contrats. Cette obligation descend toute une chaîne d'approvisionnement.
- Contrôle des exportations. Interroger un modèle hébergé dans une autre juridiction avec des données techniques contrôlées s'analyse au mieux comme une exportation, exigeant une autorisation. L'endroit où le modèle s'exécute détermine si une exportation a eu lieu.
- Listes d'entités. Certains développeurs de modèles figurent sur des listes de parties visées, assorties d'une présomption de refus.
- Règles sectorielles. Les directives sur le risque de modèle dans les services financiers, et la classification à haut risque au titre du règlement européen sur l'IA, rattachent toutes deux des devoirs à des modèles particuliers plutôt qu'à une capacité abstraite.
Remarquez ce que ces éléments ont en commun. Aucun ne demande si un modèle est bon. Ils demandent lequel c'était. C'est une question d'identité, et l'identité est précisément ce qu'une couche de routage abstrait en échange d'efficacité.
Le problème, c'est de prouver une négation
Prenez une entreprise dont le contrat fédéral interdit une famille de modèles nommée partout dans l'exécution du contrat. La question de conformité n'est pas « quels modèles approuvons-nous ». C'est « pouvons-nous démontrer qu'aucun de ces modèles n'a touché ce travail ».
Essayez d'y répondre avec ce que la plupart des organisations ont. Un catalogue de modèles énumère ce qui a été approuvé, pas ce qui s'est exécuté. Une attestation de fournisseur dit ce que le fournisseur a l'intention de servir, rédigée par le fournisseur. Une configuration de routage décrit la politique au moment où quelqu'un l'a lue, pas le comportement au moment où une requête a été servie. Une facture agrège. La surveillance observe les sorties, et un modèle substitué de qualité comparable produit des sorties qui paraissent tout à fait normales.
Aucun de ces éléments n'est une preuve au sujet d'une inférence précise. Ce sont des descriptions d'un système, offertes à la place d'un dossier de ce que le système a fait.
Et la négation est la direction difficile. Prouver que quelque chose s'est produit est affaire de production du dossier. Prouver que quelque chose ne s'est pas produit, sur des millions d'appels pendant dix-huit mois, exige un dossier complet et digne de confiance de tout ce qui s'est produit.
Ce qu'une attestation ne peut pas porter
La réponse raisonnable est de renvoyer la question aux fournisseurs : ajouter une clause, exiger une déclaration, imposer un avis en cas de changement de modèle. Cela vaut la peine d'être fait. Mais cela a un plafond, et c'est le même plafond chaque fois.
Une attestation de fournisseur est le récit que le fournisseur fait de son propre comportement. Elle peut être entièrement sincère et échouer quand même, parce que la chose attestée n'est pas observable par la partie qui s'y fie. Si le fournisseur route lui-même vers des sous-fournisseurs, l'attestation est une affirmation à propos d'une affirmation. Chaque saut ajoute une promesse et retire un fait.
L'identité est un fait d'exécution, alors consignez-la à l'exécution
L'alternative est peu spectaculaire. Capter l'identité du modèle au moment de l'exécution, la lier à l'entrée et à la sortie de cet appel précis, et faire signer le dossier par une partie qui n'a pas exécuté la tâche. Alors la réponse à « quel modèle a servi cette requête » cesse d'être une reconstruction et devient une consultation, et la réponse à « un modèle interdit en a-t-il jamais servi une » devient une requête sur des dossiers que vous détenez plutôt qu'une demande à un fournisseur.
La raison pour laquelle cela doit venir de l'extérieur du chemin d'exécution est structurelle plutôt que technique. Un routeur qui choisit le modèle, ou un fournisseur qui le sert, ne peut pas être le témoin indépendant de son propre choix. Ce n'est pas un commentaire sur l'intégrité de qui que ce soit. C'est la même raison pour laquelle les auditeurs ne travaillent pas pour le service qu'ils auditent.
Ce qu'un reçu ne fait pas
Il ne vous dit pas qu'un modèle est sûr, approprié, bien aligné ou permis. Il ne porte aucun jugement sur un fournisseur ou une juridiction, et ne prend aucune position sur les modèles qu'une organisation devrait autoriser. Ce sont des questions de politique, et elles restent aux mains de ceux dont c'est le travail.
Ce qu'il fournit, c'est le fait dont ces politiques dépendent. Une règle sur les modèles qui peuvent être utilisés est inapplicable si personne ne peut établir quel modèle a été utilisé.
La couche bon marché et celle qui manque
Le routage est désormais une couche de la pile qui vaut sept milliards de dollars, et elle le mérite. Il a rendu l'inférence moins chère et plus accessible, ce qui est bon pour presque tout le monde.
Il a aussi fait de l'identité du modèle un résultat d'exécution plutôt qu'une décision d'approvisionnement, au moment précis où plus d'obligations que jamais se rattachent à cette identité. Ces deux faits vont ensemble, et pour l'instant un seul des deux a été financé.
Cyberian Systems est la couche de vérification pour l'inférence d'IA, qui émet des reçus cryptographiques indépendants liant le modèle, l'entrée et la sortie exacts de chaque inférence — en service en production aujourd'hui. Écrivez à philippe@cyberiansystems.ai.