Blogue
Secteur
Réglementation, structure du marché et ce que les acheteurs des secteurs réglementés devraient exiger.
S'abonner par RSS-
Quand le laboratoire détient l'attestation, qui répond de ce qui a tourné ?
Opaque Systems, l'acteur indépendant le plus visible de l'IA confidentielle, a mis fin à ses activités le 13 octobre en rejoignant Anthropic. Trois commentateurs qui ne se citent pas les uns les autres arrivent à la même observation : la partie contrôlée détient désormais une part du contrôle. Voici ce que cela change pour quiconque doit démontrer à un validateur, à un auditeur ou à un examinateur ce que son IA a réellement fait.
Lire l'article → -
Vérifiable de quoi ?
« Vérifiable » est sur toutes les pages d'accueil de confiance en IA, mais le mot cache trois propriétés distinctes : caché (personne n'a vu les données), inaltéré (personne n'a réécrit le dossier) et vrai (le calcul a bien été ce que dit le dossier). N'importe laquelle peut tenir pendant que les autres échouent. Un dossier peut être parfaitement caché et inaltéré et pourtant faux dès sa rédaction. Seul le rejeu indépendant établit la vérité sans faire confiance au matériel de l'exploitant.
Lire l'article → -
La couche que personne n'a achetée
En neuf mois, environ 40 G$ ont changé de mains pour les couches autour de l'inférence, NVIDIA prenant le silicium de Groq et la distribution de Hugging Face, Stripe achetant le routage d'OpenRouter. Chaque acquéreur a désormais un intérêt commercial dans ce qui a tourné. La preuve indépendante de l'exécution est la seule couche que personne n'a achetée, et ne pouvait acheter : un vérificateur détenu par la partie qui exécute le calcul ne vérifie pas, il rapporte. L'indépendance est une position que l'acquisition détruit.
Lire l'article → -
On ne peut pas gérer un modèle qu'on ne peut pas nommer
L'acquisition d'OpenRouter par Stripe (~7 G$) a confirmé le routage comme couche centrale : une requête va au modèle le moins cher, si bien que l'identité du modèle qui a servi un appel donné est un résultat que vous recevez, pas un choix que vous faites. Mais le contrôle des exportations, les exclusions de contrats fédéraux, les listes d'entités et les règles sectorielles tiennent toutes à quel modèle a tourné. Prouver qu'un modèle interdit n'a jamais touché le travail exige un dossier de ce qui s'est exécuté, pas un catalogue, une attestation ou une configuration de routage.
Lire l'article → -
Le modèle de votre fournisseur est maintenant dans votre inventaire
La ligne directrice E-23 du BSIF entre en vigueur le 1er mai 2027 et couvre chaque modèle, quelle qu'en soit la source, y compris ceux que vous avez achetés. Vous êtes responsable d'un modèle que vous n'avez pas construit, que vous ne pouvez pas inspecter ni réexécuter. L'outillage actuel pour ce risque, c'est le récit que le fournisseur fait de lui-même. Un inventaire consigne quel modèle un fournisseur dit exécuter ; il n'établit pas lequel a réellement tourné sur une décision donnée. Des reçus cryptographiques captés, oui.
Lire l'article → -
Sept milliards pour le routeur
Le 19 août, Stripe a acquis OpenRouter pour un prix rapporté de plus de 7 G$. Acheter le routeur, c'est acheter une position dans la façon dont circulent les dépenses d'IA, mais un routeur gagne sa vie en choisissant le modèle par requête, si bien qu'après coup le client ne peut souvent pas dire lequel l'a servi. Pour une décision contestée (une réclamation, un refus de crédit, une clause de juridiction), ce déficit de preuve est toute la question. Le routage moins cher et l'exécution prouvable sont deux moitiés du même problème.
Lire l'article → -
Quel modèle a décidé : ce que les superviseurs d'Amérique latine peuvent déjà exiger
Partout en Amérique latine, les décisions automatisées (pointage de crédit, signalements de LBA, triage des réclamations) sont la voie de production, et chacune atterrit sur une personne qui peut la contester. L'article 20 de la LGPD du Brésil permet déjà d'en exiger la révision tout en protégeant les secrets commerciaux : expliquer la décision sans ouvrir le modèle. Les journaux autoattestés échouent précisément quand un superviseur demande. La vérification indépendante est la façon de répondre aux deux.
Lire l'article → -
Le watt le moins cher est celui qu'on ne dépense pas deux fois
L'histoire énergétique de l'IA parle surtout d'échelle. En dessous se cache un gaspillage plus discret : pour faire confiance à un résultat, on le réexécute, ce qui double l'énergie. La vérification probabiliste procure la confiance sans la seconde exécution complète, et dès qu'un résultat porte une preuve que quiconque peut vérifier, le travail peut migrer vers des téléphones inactifs, déjà branchés, à faible consommation. Ni l'une ni l'autre de ces avancées n'exige un nouveau centre de données.
Lire l'article → -
Deux preuves, une décision
Quand une décision d'IA est remise en question, on pose trois questions différentes : y avait-il un programme (gouvernance), l'action était-elle permise (autorisation), et le calcul s'est-il déroulé comme prétendu (exécution). La documentation répond à la première ; presque personne ne peut répondre aux deux autres autrement que par ses propres journaux. Deux preuves distinctes, la vérification de politique d'IronProof et les reçus d'exécution de Cyberian, comblent cet écart, et elles ne sont pas interchangeables.
Lire l'article → -
Ce qu'un DER peut réexécuter : un moyen de conformité candidat pour l'apprentissage automatique en certification aéronautique
Toute discipline d'assurance de conception en aéronautique repose sur une preuve qu'un tiers peut vérifier de façon indépendante, pas sur l'attestation d'une première partie. Un DER peut réexécuter un rapport de couverture ; il ne peut pas réexécuter un modèle entraîné. Pendant qu'EUROCAE WG-114, SAE G-34 et le projet MLEAP de l'EASA écrivent les règles, un reçu cryptographique par inférence vérifiée est un moyen de conformité candidat qu'un DER peut re-dériver sans croire le fournisseur sur parole.
Lire l'article → -
Le problème de l'heure d'or : les chaînes d'escalade ne peuvent pas vérifier ce qu'un agent d'IA a fait
Deux heures du matin : un modèle de fraude bloque une transaction, l'horloge de l'ombudsman démarre, et l'ingénieur de garde ouvre les journaux. Chaque palier d'escalade relit le même journal et ajoute un nom au fil : une délégation du doute, pas une vérification. Un reçu cryptographique permet au responsable de la conformité, à l'ombudsman ou à un auditeur de vérifier directement ce que l'agent a fait, sans gravir la chaîne.
Lire l'article → -
Le calcul n'est pas le vôtre. La réponse, elle, l'est.
Presque aucune équipe d'IA réglementée n'exécute sa propre inférence. Elle repose chez un hyperscaler ou un point de terminaison infogéré. La machine appartient à un fournisseur ; la sortie, la conséquence et la question du régulateur vous appartiennent. Un journal d'API, une ligne de facture, une capture d'écran de tableau de bord décrivent tous ce que le système du fournisseur a rapporté sur lui-même. Aucun n'est vérifiable par celui qui pose la question. Un reçu cryptographique, oui.
Lire l'article → -
Quand un agent pose le geste, ses propres journaux ne sont pas la preuve
Un agent conversationnel qui ne produit que du texte suscite peu de douleur ressentie. Elle se concentre là où un agent pose un geste conséquent, déplacer de l'argent, refuser une réclamation, déposer un document auprès d'un régulateur. La question cesse alors d'être « qu'a produit le modèle » pour devenir « qu'a réellement fait cet agent, et sur quelle base ». L'observabilité, c'est la parole du système sur lui-même ; un reçu indépendant, c'est quelque chose qu'un tiers peut vérifier.
Lire l'article → -
Vous avez des journaux. Les journaux peuvent être modifiés.
Dans l'affaire Mobley v. Workday, un tribunal a laissé des plaintes pour discrimination viser le fournisseur d'IA lui-même, sur ce que le modèle a réellement fait. Tout fournisseur d'IA dans un secteur réglementé doit désormais prouver quel modèle a tourné, sur quelle entrée, produisant quelle sortie. Les journaux tenus par soi-même, la SOC 2 et les contrats s'effondrent dès que la situation devient contradictoire. La solution : un reçu inviolable, vérifié par une partie qui n'a jamais exécuté la tâche.
Lire l'article → -
La marque de confiance de l'informatique indépendante
Des milliards affluent vers l'informatique d'IA, mais presque rien de cet argent n'achète une garantie sur le travail effectué. Les fournisseurs indépendants sont moins chers, mais les acheteurs sérieux se rabattent sur les acteurs établis parce qu'ils ne peuvent pas vérifier le travail, alors ils achètent la réputation. Un reçu vérifiable, produit par un prouveur distinct de l'exécutant, permet aux indépendants de vendre une preuve plutôt qu'un nom.
Lire l'article → -
Quand l'approbation cesse d'être la dernière ligne de défense
Un responsable de la conformité ou un évaluateur ISO 42001 approuve les sorties d'un système d'IA après avoir lu une fiche de modèle et un échantillon de prédictions. Cette signature porte la confiance depuis des années, mais un réviseur qui atteste de l'exactitude sans pouvoir vérifier le calcul de façon indépendante porte une responsabilité qu'il ne peut pas décharger. Séparer l'exécutant du prouveur transforme l'approbation en quelque chose que tout le monde en aval peut vérifier.
Lire l'article → -
L'exécutant fait tourner le modèle. Le prouveur en répond.
Partout dans le secteur de l'IA réglementée, l'inférence en production tourne sur du cloud infogéré que l'entreprise n'exploite pas, mais l'obligation de conformité reste au titulaire de la licence. Le palier de revue humaine qui comblait cet écart atteste, mais ne reproduit jamais. Un reçu cryptographique produit par un prouveur distinct de l'exécutant, lui, le fait.
Lire l'article → -
L'inférence n'a pas de contrôleur
Kubernetes a compris il y a dix ans qu'un système ne peut pas être cru sur parole quant à son propre état, alors le contrôleur se tient à l'extérieur de l'objet. L'inférence IA ne l'a jamais compris : l'opérateur exécute le modèle, rédige le journal et se porte garant de lui-même. L'exécutant ne peut pas être le prouveur.
Lire l'article → -
Le réviseur et le révisé ne peuvent pas être le même agent
La séparation des tâches (la partie qui fait le travail ne peut pas être la seule à le vérifier) est un pilier de tout cadre de GRC. Quand un agent d'IA agit et qu'une autre IA révise, cette indépendance est cosmétique. Ce que les systèmes agentiques font à l'un des plus vieux contrôles qui soient.
Lire l'article → -
Ce que la norme ISO 42001 exige, et ce qu'elle ne peut pas vous donner
ISO 42001 demande de mesurer, de surveiller et de conserver des registres du comportement de votre IA. Aucune de ces clauses, à elle seule, ne prouve ce que le modèle a fait sur une décision précise. C'est la différence entre un registre et une preuve, et le moment où elle compte.
Lire l'article → -
Calcul moins cher, confiance empruntée
Déplacer l'inférence hors des hyperscalers coûte moins cher, mais le modèle de confiance change. Quand le matériel n'est pas le vôtre, c'est un reçu cryptographique (pas la parole du fournisseur) qui rend le résultat utilisable en contexte réglementé.
Lire l'article → -
Les quatre questions que je pose à chaque fournisseur d'IA avant de signer
Je signe le contrat du fournisseur et c'est moi qui en réponds plus tard. Quatre questions, aucune technique, qui décident si je peux prouver ce qu'un modèle d'IA a fait, ou seulement répéter ce que le fournisseur m'a dit.
Lire l'article → -
Le régulateur est déjà dans la place
Pendant que la majorité de l'industrie de l'IA regarde les échéances du règlement européen glisser vers 2027, les examinateurs en assurance de douze États demandent déjà aux assureurs de rendre compte de leur IA. L'instrument existe, il est utilisé, et votre fournisseur ne peut pas y répondre à votre place.
Lire l'article → -
Je ne suis pas l'ingénieure. Je suis celle qui doit le défendre.
Les personnes qui décident réellement de l'achat d'un outil d'IA me ressemblent davantage qu'à celles qui le présentent. Le point de vue d'une opératrice sur l'écart entre une démo de fournisseur et ce qu'une équipe de conformité peut défendre.
Lire l'article → -
L'UE a cligné des yeux. La trajectoire n'a pas changé.
Un report n'est pas un répit. C'est du temps de plus pour bâtir ce vers quoi convergent toutes les versions de ces règles : prouver quel modèle a pris une décision, sur quelles données, et comment vous le savez.
Lire l'article → -
100 milliards de dollars d'inférence IA reposent sur la confiance aveugle
Chaque modèle d'IA qui tarifie une assurance, détecte une fraude ou prend une décision clinique produit aujourd'hui des résultats qu'aucun tiers ne peut vérifier de manière indépendante. Cette époque touche à sa fin.
Lire l'article →
Ingénierie
Comment la vérification fonctionne réellement : mécanismes, mesures et limites de chaque affirmation.
Les articles d'ingénierie sont publiés en anglais seulement.
S'abonner par RSS-
Merkle commitments for batch inference receipts
A batch of a million embeddings should not need a million signatures, and an auditor who asks about one item should not need the other 999,999. A Merkle root is one 32-byte fingerprint of the whole batch, and an inclusion proof of about 640 bytes lets anyone check a single item offline, years later, without the producer's cooperation. What the root proves is membership and integrity. What it does not prove is correctness or completeness, and keeping those three apart removes most of the confusion about verification records.
Lire l'article → -
Committed computation traces, explained for engineers
Re-running a sample of the work catches a cheat one time in five. Proving every operation cryptographically still costs a large multiple of the inference on production-scale models. There is a middle path: make the executor commit to its intermediate activations before it knows what will be checked, then verify a handful of inter-layer constraints instead of re-running end to end. For a 24-layer transformer with five sampled constraints that is 86.8 percent detection at the same sampling budget, and the honest boundary is that it only beats replay against an adversary who cheats to save work.
Lire l'article → -
Sampling as deterrence: the economics of unpredictable re-execution
Re-running every job to verify it doubles the compute bill, and full cryptographic proofs still cost a large multiple of the inference itself. Sampling sits between them: re-run an unpredictable fraction and let the economics do the rest. Cheating stops paying as soon as the penalty on detection exceeds the saving divided by the sampling rate, and across a relationship of any length there is no cheating policy that survives. The whole argument rests on one property, which is that the executor cannot predict which jobs get checked.
Lire l'article → -
Why bit-exact determinism fails on GPUs, and why a tolerance-based comparison is the right check
If you verify AI inference by re-running it on independent hardware, the two results will not match bit for bit, even when both parties are honest. Floating-point addition is not associative, and batch composition, kernel selection and GPU generation all change the reduction order. Demanding bit-exact agreement would mean surrendering the independence that made the second run worth anything. A calibrated tolerance separates honest drift from model substitution by orders of magnitude.
Lire l'article → -
Three Properties of an AI Evidence Record
An AI evidence record can have three distinct properties, each established by a different mechanism and each failing its own way: integrity since checkpoint (what witnessed transparency logs deliver), completeness (a process property, established from outside), and truth at the time of writing (which the log cannot give you). A log faithfully pins whatever it was handed, so the source of truth is a separate question from the log that holds the record.
Lire l'article → -
Hardware Attestation Versus Independent Re-execution: Two Threat Models
Attestation reports and independent re-execution both get sold as verification, but they assume different adversaries. Hardware attestation is strong when the machine is intact and the adversary is software; it excludes physical attacks, and TEE.fail showed that a party with physical access can forge a report for work that never ran in an enclave. Re-execution assumes nothing about the executor's hardware, but costs compute and offers no confidentiality. Which one you need depends on whether your adversary is the operator.
Lire l'article → -
What a Receipt Proves, and What It Does Not
A walk through the artifact Cyberian issues for each inference: its fields, the three checks a third party can run offline (output digest, Merkle inclusion, attestor signature), what passing them establishes (integrity and attribution), what re-execution adds (truth, to the assurance level), and the exact boundary of what a receipt does not prove.
Lire l'article →