Résumé

  • Daté du 5 septembre 2026, draft-das-eu-ai-act-execution-enforcement-00 est un Internet-Draft individuel actif visant un statut informatif. Ce n’est ni une norme, ni un texte de groupe de travail, ni une validation réglementaire.
  • Le schéma proposé retient une opération conséquente comme Candidate Act, valide des contraintes déjà déterminées, délivre une autorité limitée à cet acte, puis vérifie cette autorité au Finality Sink juste avant le premier effet externe protégé.
  • La section 35 restreint explicitement la propriété aux effets médiés par la frontière. Son schéma avec une API externe directe à côté du sink ne protège pas cette API.
  • L’implémentation Python v0.1.0 démontre un cas local où le sink possède l’unique API d’enregistrement de l’effet. Elle n’est présentée ni comme produit de sécurité en production ni comme moteur de conformité juridique.
  • La preuve utile serait un reçu de fermeture de la surface d’effet : chemins exhaustifs, versions de routage, privilèges de contournement, exceptions déclarées et tests négatifs pour chaque voie.

La topologie décide de la promesse

Le projet sépare calcul et autorité. Le système d’IA peut préparer une opération, mais celle-ci reste sans effet. Un domaine d’exécution protégé évalue des conditions lisibles par machine ; une validation réussie produit une autorité liée au contenu exact de l’acte, à sa destination, à son époque de politique et au sink prévu. Le sink vérifie de nouveau l’empreinte, la signature, l’expiration, la révocation, l’usage unique et l’état courant avant de laisser passer la conséquence.

Cette discipline répond à un vrai problème : l’authentification d’une charge de travail ne donne pas carte blanche à toutes ses actions. Une approbation antérieure ne couvre pas une somme, un destinataire ou une politique modifiés. Et un journal écrit après l’envoi ne l’empêche pas.

La limite arrive avant même la cryptographie. Dans la figure 75, l’agent possède deux branches. L’une va au Finality Sink, l’autre à une API externe directe. Le texte dit que la propriété de finalité ne vaut pas pour cette dernière. Le sink peut donc refuser parfaitement tout ce qu’il voit sans empêcher ce qui ne lui est jamais présenté.

Imaginons une passerelle qui protège les paiements alors qu’un compte de service peut appeler directement l’interface de règlement. La vérification de la passerelle ne couvre que sa route. Même chose pour une publication contrôlée devant laquelle subsiste une écriture directe dans un stockage rendu public, ou pour un proxy de base de données doublé d’une chaîne de connexion d’urgence. Ce ne sont pas des incidents rapportés. Ce sont des exemples qui montrent pourquoi l’unité d’assurance est la surface de l’effet, et non la présence d’un composant.

Protéger une transition sélectionnée

Le texte ne propose pas de faire passer chaque jeton, lecture de base ou paquet par un sink. Il vise des transitions conséquentes sélectionnées. Cette retenue correspond à une spécification minimale raisonnable : inutile de centraliser tout le calcul pour empêcher un paiement, un message, une publication ou une commande industrielle non autorisés.

Mais la sélection porte sur la conséquence, pas sur l’API la plus commode. Dès qu’un opérateur affirme protéger une conséquence, il doit recenser toutes les routes qui peuvent la produire ou publier leurs exclusions. Un chemin de secours, un SDK fournisseur, un compte d’administration, une file secondaire ou un accès côté destinataire ne disparaissent pas parce qu’ils ne figurent pas dans le schéma principal.

Le projet reconnaît aussi la difficulté des effets distants. Une transaction locale peut unir vérification, consommation de l’autorité et écriture. Une requête Internet arbitraire ne devient pas atomique pour autant. Un effet distant peut exiger un sink chez le destinataire, une clé d’idempotence, une boîte transactionnelle ou une machine d’état coordonnée. C’est encore une question de lieu où l’effet devient réellement utilisable.

Ce que montre la version 0.1.0

Le dépôt de référence apporte du code exécutable : représentation canonique, empreinte SHA-256, signatures Ed25519, preuve de possession, contrôles d’époque et de nonce, puis consommation locale dans SQLite. Son scénario synthétique de support client refuse une substitution d’objectif avant l’inscription de l’effet.

La phrase la plus importante du README précise que l’état sans effet repose sur l’existence d’une seule API d’enregistrement, située dans le sink. En production, ajoute-t-il, l’égress réseau, le commit de base, le paiement, l’export de fichier, l’appel d’outil et toute autre voie conséquente doivent être médiés de façon équivalente.

Cette démonstration valide un mécanisme borné, non une architecture d’entreprise invisible. Le projet énumère ses absences : gestion HSM et attestation TEE de production, consensus distribué, cycle PKI complet, vérification formelle, haute disponibilité, protection contre les canaux auxiliaires, atomicité distante intégrale et évaluation de conformité. La séparation logique dans un processus Python ne résiste pas à un administrateur qui contrôle librement ce processus.

Le reçu de fermeture

Un reçu de fermeture de la surface d’effet commencerait par nommer la conséquence et son premier état utilisable. Il dresserait ensuite la liste de chaque passerelle, courtier, connexion, interface de fichier, chemin réseau, SDK, compte privilégié et service destinataire susceptible de la produire.

Pour chaque voie, il associerait le point d’exécution protégé, l’identité du sink, la version du routage et de la politique, les identifiants autorisés et les mécanismes d’urgence. Puis il conserverait des essais négatifs : autorité absente, périmée, révoquée, rejouée, liée au mauvais sink ou à la mauvaise charge. Le résultat attendu serait l’absence d’effet au point où celui-ci devient utilisable, pas seulement un refus local.

Les exceptions doivent être visibles. Une opération en lecture seule peut rester hors champ. Une route d’urgence peut relever d’une autre autorité. Une voie inconnue doit recevoir l’état inconnu, non fermé.

Ce reçu est ma recommandation. Il ne vient ni de l’IETF, ni de l’Union européenne, ni de l’auteur du projet. Il ne dit pas non plus si la contrainte fournie est juste ou légale. Le texte laisse expressément aux autorités compétentes la qualification du risque, l’interdiction d’une pratique, l’adéquation de la supervision humaine et la conformité globale. Le reçu prouve seulement qu’une règle déclarée était incontournable pour un effet déclaré dans une topologie testée.

Une normalisation volontairement étroite

Le projet dit que l’interprétation juridique des lois sur l’IA n’est pas une cible appropriée pour l’IETF. Les objets techniques possibles sont plus modestes : représentation d’un acte, canonisation, preuves de validation, autorisation liée à l’acte, preuve de possession, liaison au sink, fraîcheur, révocation et erreurs.

La doctrine de Heng Lu conduit à la même retenue. Le code en fonctionnement doit discipliner la promesse ; la spécification commune doit rester minimale ; l’observation doit primer sur la promotion. Une norme peut décrire comment un sink se lie à un acte. Elle ne peut pas déduire de la présence de ce sink que toutes les autres routes ont disparu.

La formule finale est simple : un Finality Sink peut bloquer tout acte invalide qui le traverse. Il ne peut pas bloquer l’acte envoyé ailleurs.

Sources