L'inférence n'a pas de contrôleur
Quiconque a passé du temps réel à l'intérieur de Kubernetes en garde une intuition difficile à désapprendre une fois qu'on la possède.
Un contrôleur existe parce que deux choses ne sont jamais tout à fait identiques : l'état qu'un système déclare, et l'état dans lequel le système se trouve réellement. Vous rédigez un manifeste qui annonce trois répliques. Le registre du cluster lui-même indique trois répliques. Aucun de ces faits ne fait exister trois répliques. Le contrôleur se tient à l'extérieur de l'objet, observe le monde, observe la déclaration, et réconcilie l'écart. Retirez le contrôleur et le manifeste devient un vœu.
L'essentiel n'est pas la réconciliation. C'est l'emplacement.
Le contrôleur n'est pas la chose qu'il réconcilie. Si on pouvait faire confiance à un objet pour rapporter son propre état avec exactitude, il n'y aurait aucun besoin de contrôleur. Tout le patron est un aveu permanent que l'état autodéclaré n'est pas une preuve.
Regardez maintenant comment l'industrie exécute l'inférence IA.
L'opérateur exécute le modèle. L'opérateur rédige le journal. Le journal est la preuve. Il n'y a de contrôleur nulle part dans cette boucle, et personne ne semble trouver cela étrange.
Les quatre mots sur chaque page d'accueil
Lisez le texte de n'importe quelle plateforme d'agents qui se lance en ce moment. Vous y trouverez une variante des mêmes quatre promesses : utile, déboguable, contrôlable, digne de confiance. On les présente comme quatre cadrans sur une même console, quatre instances d'une seule et même chose sous-jacente.
Elles ne le sont pas.
Les trois premières sont des propriétés que vous pouvez concevoir dans un système. Vous le rendez plus utile en l'améliorant. Vous le rendez déboguable en l'instrumentant. Vous le rendez contrôlable en ajoutant des politiques, des points d'approbation et des plafonds de dépense. Chacune de ces choses est un travail que vous faites à l'intérieur de votre propre frontière, et une fois le travail achevé, il est achevé.
La confiance n'est pas ce genre de propriété. La confiance est une affirmation que vous adressez à quelqu'un d'autre. Vous ne pouvez pas la fabriquer depuis l'intérieur du système qui demande à être cru, pour la même raison qu'un accusé ne peut pas servir de son propre alibi.
Et remarquez quels outils on saisit lorsqu'une équipe décide de prendre la confiance au sérieux : l'observabilité et l'évaluation. Les deux sont des artefacts qu'un système produit à propos de lui-même. Cela fonctionne jusqu'au moment précis où la partie qui pose la question n'est pas vous.
Ce que les réponses habituelles attestent vraiment
Trois choses sont proposées pour combler cet écart. Il vaut la peine d'être précis sur chacune, car elles ne sont pas interchangeables et aucune ne termine le travail.
Les journaux d'audit. Un journal d'audit vous dit ce que l'opérateur a consigné. Il est rédigé par l'opérateur, stocké par l'opérateur et produit par l'opérateur sur demande. C'est un excellent outil opérationnel. Ce n'est pas une preuve pour quiconque ne fait pas déjà confiance à l'opérateur. Ce n'est pas une accusation visant l'intégrité de qui que ce soit ; c'est un fait structurel. Un journal est une affirmation, pas une preuve.
Les certifications. SOC 2, ISO 27001, ISO 42001. Elles sont réelles, elles sont coûteuses, et elles valent la peine d'être obtenues. Elles attestent qu'une organisation dispose de contrôles, de politiques et de systèmes de gestion, et qu'un auditeur les a échantillonnés à un moment donné. Elles ne disent absolument rien sur le fait qu'une sortie précise provienne d'un modèle précis à partir d'une entrée précise. Ce sont des énoncés sur un processus, pas sur un calcul. Nécessaires, et d'une nature catégoriquement différente.
L'informatique confidentielle. C'est la réponse la plus sérieuse sur le plan technique et celle qu'on interprète le plus souvent de travers. Un environnement d'exécution de confiance, qu'il s'agisse d'un GPU en mode confidentiel, d'AMD SEV-SNP ou d'Intel TDX, vous donne une attestation à distance : une preuve cryptographique qu'une enclave authentique et non modifiée, avec un état d'amorçage mesuré et connu, est en cours d'exécution, et que les données sont restées chiffrées pendant leur utilisation. C'est de la vraie sécurité qui résout de vrais problèmes.
Elle atteste la boîte. Elle n'atteste pas le calcul.
Un TEE vous dira qu'un environnement de confiance a exécuté quelque chose. Il ne vous dira pas que cette sortie précise est bien ce que ce modèle précis produit à partir de cette entrée précise, sous une forme qu'un tiers peut vérifier plus tard, sans votre matériel et sans vous. L'attestation se lie à l'identité du matériel. Elle ne laisse pas derrière elle un artefact portable qui survit à la question « et pourquoi devrais-je croire votre matériel ? »
L'invariant
Il y a une seule ligne qui court sous tout cela, et une fois que vous la voyez, vous ne pouvez plus ne pas la voir.
Non pas « ne devrait pas ». Ne peut pas. Si la partie qui a exécuté le calcul est aussi la partie qui s'en porte garante, cette garantie ne transporte aucune information. C'est la même signature écrite deux fois. Tout dispositif d'autoattestation, quelle que soit la quantité de cryptographie empilée par-dessus, se termine par l'opérateur qui l'affirme.
Ce n'est pas une critique d'un fournisseur en particulier. C'est une propriété de l'arrangement lui-même. Et cela signifie que la solution ne peut pas être un meilleur journal, une politique plus stricte ou une enclave plus robuste. Il faut une séparation structurelle. La chose qui exécute la tâche et la chose qui prouve la tâche doivent être des choses différentes, et la preuve doit être vérifiable par quelqu'un qui ne fait confiance ni à l'une ni à l'autre.
Le cas qui devrait le plus inquiéter
Voici celui que je ne cesse de retourner dans ma tête.
Le domaine de la sécurité de l'IA est devenu plutôt bon pour démontrer que les évaluateurs automatisés ne sont pas fiables. Il existe des travaux publiés solides montrant que lorsqu'un modèle de langage sert de juge de la sécurité, le juge est incohérent, sensible à des artefacts de surface, et peut être fortement influencé par des caractéristiques de la formulation qui n'ont rien à voir avec le contenu. L'évaluateur, il s'avère, ne peut pas être cru sur le fond.
Soit. Mais regardez ce que toute cette ligne de recherche présuppose discrètement.
Elle présuppose que l'évaluation s'est déroulée de la façon dont le rapport le dit.
Une évaluation de sécurité est une tâche d'inférence. C'est un lot d'invites poussées à travers un modèle, notées, puis résumées. Et les résultats de cette tâche ne restent pas à l'intérieur du laboratoire. Ils deviennent des fiches de modèle. Ils deviennent la documentation technique qu'un fournisseur de modèle à usage général dépose auprès d'un régulateur. Ils deviennent la preuve sur laquelle s'appuie une banque, un hôpital ou un ministère de la défense au moment de décider s'il faut déployer.
La partie qui exécute l'évaluation est la partie qui rapporte l'évaluation. Rien dans cette chaîne ne permet à une partie extérieure de confirmer que l'évaluation a bien été menée sur le modèle qui a réellement été livré, sur les entrées annoncées, produisant les sorties annoncées. L'équipe de sécurité est l'exécutant et le prouveur de ses propres affirmations de sécurité.
Nous dépensons une énergie considérable à débattre de la justesse de ces résultats. Presque aucune à demander s'ils sont vérifiés.
Personne n'évalue l'évaluateur.
Ce que nous construisons, et où cela s'arrête
Cyberian émet un reçu cryptographique pour chaque tâche d'inférence. Le reçu lie le modèle, l'entrée et la sortie en une seule structure, et le composant qui exécute la tâche est architecturalement séparé du composant qui la prouve. Un tiers peut prendre ce reçu et confirmer de façon indépendante qu'une sortie donnée provient bien d'un modèle donné à partir d'une entrée donnée, sans faire confiance à notre matériel et sans nous faire confiance.
Deux limites honnêtes, parce que des limites énoncées valent plus que des limites revendiquées.
C'est en service aujourd'hui pour les charges de travail déterministes et de type plongement (embedding). Notre première charge de travail en production est la génération de plongements, vérifiée par rapport à une tolérance calibrée plutôt qu'à une égalité au bit près, parce que le déterminisme au bit près sur du matériel hétérogène est un fantasme, et prétendre le contraire disqualifie la moitié de la puissance de calcul du monde sans vous acheter la moindre assurance supplémentaire.
La vérification des sorties génératives est un problème plus difficile et nous n'allons pas prétendre qu'il est résolu. C'est la question ouverte, et nous préférons le dire clairement plutôt que de la contourner par le discours.
Mais la primitive sous-jacente est la même dans les deux cas, et la primitive n'est pas compliquée.
Quelque chose à l'extérieur du système doit vérifier le système.
Kubernetes a réglé cela il y a une décennie. L'inférence n'a pas encore rattrapé son retard.