Le calcul n'est pas le vôtre. La réponse, elle, l'est.
Parmi les équipes d'IA réglementée avec qui nous discutons en Pologne et dans l'ensemble de l'UE lors de cette vague de démarchage, un schéma revient sans cesse : presque aucune n'exécute sa propre inférence. Elle repose chez un hyperscaler, une plateforme d'inférence spécialisée, un point de terminaison infogéré. Exploiter sa propre flotte est la rare exception.
Ce n'est pas un scandale. Louer du calcul est le choix par défaut rationnel ; personne ne bâtit une flotte de GPU pour desservir un seul outil d'aide à la décision clinique. Mais cela crée une scission que la plupart des équipes n'examinent pas avant que quelque chose ne tourne mal : la machine qui a exécuté la tâche appartient à un fournisseur. La sortie qu'elle a produite, et la conséquence qui a suivi, vous appartiennent.
Regardez ce que font réellement les systèmes de ces équipes. Le geste conséquent le plus courant sur le terrain en ce moment n'est pas une réponse de robot conversationnel, c'est une instruction clinique ou de sécurité : un signalement de dosage, une recommandation de triage, un verdict de panne sur un équipement. Et la partie la plus susceptible d'attendre une réponse au sujet de cette instruction n'est pas un auditeur interne. C'est un régulateur.
Voici donc la position réelle de l'exploitant : vous possédez le résultat d'une décision prise sur du matériel que vous ne contrôlez pas, et vous devez une explication à quelqu'un qui a le pouvoir de vous mettre à l'arrêt.
Ce qui casse en premier
Demandez à n'importe quelle équipe dans cette position ce qu'elle remettrait à un régulateur, ou à un client d'entreprise, qui demande quel modèle a produit une sortie donnée et si elle s'est exécutée correctement. La plupart produisent un journal d'API, une ligne de facture de fournisseur, une capture d'écran de tableau de bord. Les trois décrivent ce que le système du fournisseur a rapporté sur lui-même. Aucun n'est quelque chose que la personne qui pose la question peut vérifier de façon indépendante. Si le récit du fournisseur est contesté, ou si le modèle a été discrètement remplacé derrière un point de terminaison versionné, il n'y a rien en dessous.
Cet écart n'apparaît pas lors d'un trimestre tranquille. Il apparaît en plein incident : une mauvaise recommandation clinique, un signalement de sécurité déclenché trop tard, un assureur ou un régulateur réclamant l'inférence exacte qui a produit la sortie exacte au moment exact. Reconstruire cela à partir de la télémétrie du fournisseur, contre la montre, avec la coopération du fournisseur requise mais non garantie, c'est là que les équipes découvrent que le contrat qu'elles ont signé couvre la disponibilité et la résidence des données, pas la preuve de ce qui a réellement tourné.
Ce qu'il faut plutôt demander à un fournisseur de calcul
- Pouvez-vous me donner une preuve, et pas seulement une entrée de journal, qu'une sortie précise provient d'un modèle déclaré précis — une preuve qu'un tiers peut vérifier sans croire votre parole ni refaire la tâche ?
- Si votre infrastructure change, se met à niveau ou se réachemine silencieusement, quelque chose voyage-t-il avec ma sortie qui permettrait de le détecter ?
- Quand je devrai une réponse à un régulateur ou à un client dans six mois, qu'ai-je qui ne dépende pas de vos systèmes conservant encore le dossier, ni de votre coopération ?
La plupart des fournisseurs répondent aux deux premières par des chiffres de disponibilité, et à la troisième par un haussement d'épaules. C'est là l'écart.
La solution est structurelle, pas procédurale
Le mécanisme qui le comble est celui au cœur de notre travail : séparer la partie qui exécute l'inférence de la partie qui prouve ce qui a tourné. Un reçu cryptographique lié à une inférence précise et vérifiée mathématiquement vous donne une preuve vérifiable de façon indépendante, reproductible et inviolable, vérifiable par un régulateur ou un client sans qu'il ait à faire confiance au fournisseur, ni à vous, sur parole. C'est en service aujourd'hui pour les charges de travail de plongement (embedding) et pour les modèles exportables en ONNX apportés directement.