◆L'AI Act lui-même n'a pas été reporté. Sa date d'application générale, le 2 août 2026, est inchangée ; le Règlement (UE) 2026/1744 n'a déplacé que les exigences à haut risque du Chapitre III, au 2 décembre 2027 pour les systèmes de l'Annexe III et au 2 août 2028 pour ceux de l'Annexe I.
◆Ceci est une checklist d'ingénierie, pas un conseil juridique : chaque obligation correspond à un changement de code concret, comme quoi journaliser, comment versionner un prompt, et où l'humain doit rester dans la boucle.
◆J'ai livré deux fois de la conformité imposée par le code, les vérifications de transfert on-chain d'ERC-3643 et un RAG en finance régulée qui s'abstient, donc ce mapping vient de la construction, pas de la lecture.
◆L'Article 12 est une spécification de journalisation, l'Article 14 c'est l'humain dans la boucle, et l'Article 15 c'est votre suite d'évaluations. Ils tombent maintenant en 2027 ou 2028, mais l'Article 72 est resté sur la date d'origine et réclame la même machinerie.
22
FOIS OÙ J AI IMPOSÉ LA CONFORMITÉ EN CODE
ERC-3643 on-chain + un RAG régulé
88
ARTICLES DANS CETTE CHECKLIST
AI Act, Ch. III Sect. 2 + Art. 72
Les obligations à haut risque de l'AI Act ne tombent plus le 2 août 2026. Le Règlement (UE) 2026/1744 les a déplacées au 2 décembre 2027 pour les systèmes de l'Annexe III et au 2 août 2028 pour ceux de l'Annexe I. L'Acte lui-même s'applique toujours depuis le 2 août 2026, et la surveillance de l'Article 72 est venue avec. Rien de tout cela ne dit à un ingénieur quoi changer dans le code, alors ce billet le fait.
Les cabinets d'avocats vous donnent l'obligation. Je n'en ai pas trouvé un seul qui vous donne le diff. Voici la traduction : voici l'Article, voici ce que vous construisez.
Je peux l'écrire parce que j'ai livré deux fois de la conformité imposée par le code. Une fois on-chain, où ERC-3643 vérifie l'éligibilité du transfert dans le token. Une fois dans un fonds régulé, où un agent de recherche cite ses sources, s'abstient quand la preuve est mince, et journalise chaque étape. Les Articles ci-dessous correspondent à ce travail presque un pour un.
PAS UN CONSEIL JURIDIQUE
Ceci n'est pas un conseil juridique. C'est une checklist d'ingénierie d'un ingénieur smart-contract et IA, à jour au 5 août 2026. Chaque Article et chaque date ci-dessous provient du texte consolidé de l'AI Act (Règlement (UE) 2024/1689, tel que modifié par le Règlement (UE) 2026/1744) sur EUR-Lex. J'ai publié ceci le 2 juillet 2026, quand le report du volet haut risque n'était encore qu'une proposition de la Commission. Elle a été adoptée le 8 juillet et est entrée en vigueur le 27 juillet : j'ai donc réécrit chaque date d'après l'Article 113 consolidé. Vérifiez sur EUR-Lex avant de vous y fier, et méfiez-vous des trackers non officiels : l'un des plus cités servait encore l'ancien texte quand j'ai vérifié.
LE CALENDRIER
1
Entrée en vigueur
1er août 2024. L'AI Act (Règlement (UE) 2024/1689) devient la loi et lance le compte à rebours de chaque obligation ultérieure.
2
Début d'application de l'Acte
2 août 2026. L'Article 113 le dit toujours, et l'omnibus n'a pas touché à cette phrase. C'est la date à partir de laquelle courent la transparence de l'Article 50 et la surveillance après commercialisation de l'Article 72.
3
Haut risque, Annexe III
2 décembre 2027. Le Chapitre III, Sections 1 à 3, pour les systèmes d'IA classés à haut risque au titre de l'Article 6(2) et de l'Annexe III. Seize mois après l'Acte lui-même.
4
Haut risque, Annexe I
2 août 2028. Les mêmes exigences pour les systèmes à haut risque au titre de l'Article 6(1) et de l'Annexe I, parce qu'ils sont intégrés dans un produit déjà régulé.
Source : Article 113 consolidé du Règlement (UE) 2024/1689 sur EUR-Lex, tel que modifié par le Règlement (UE) 2026/1744 (en vigueur le 27 juillet 2026). La date d'application générale n'a pas bougé. Seul le Chapitre III a bougé.
Deux fois où j'ai imposé la conformité par le code
Avant tout Article, une idée fait l'essentiel du travail : la conformité que vous imposez dans le code bat la conformité que vous promettez dans un document. Je l'ai construite ainsi deux fois, et ces deux chantiers sont le modèle mental de tout ce qui suit.
Un transfert vérifie les attestations d'identité du destinataire dans le token et échoue si elles manquent. La règle ne peut pas être contournée, car elle vit sur le chemin que tout le monde doit emprunter. C'est de la conformité imposée par le code, sans humain dans le chemin critique.
Imposé dans un pipeline : un RAG régulé
Un agent de recherche dans un fonds ne répond qu'avec des preuves citées, s'abstient et escalade quand la preuve est mince, et écrit un enregistrement d'audit à chaque étape. L'AI Act appelle cela journalisation, surveillance humaine et justesse. Moi, je les appelais les raisons pour lesquelles il était autorisé près des comptes.
LA FORME COMMUNE
Les deux précédents, ce sont les trois mêmes gestes. Réussissez-les et personne n'a besoin de se souvenir de la règle : elle est sur le seul chemin qui existe.
La checklist : de l'Article au changement de code
Une chose à régler avant la carte. Ces obligations ne sont plus sur la même horloge. Les Articles 9 à 15 relèvent du Chapitre III et ont bougé. L'Article 72 relève du Chapitre IX et n'a pas bougé.
DEUX HORLOGES, PLUS UNE
Savoir laquelle des deux premières branches couvre un système donné est une classification juridique, pas une décision d'ingénierie : c'est une question pour un avocat. Ce qui ne fait aucun doute, c'est que ces dispositions ne partagent plus la même date. Source : Article 113 consolidé, point (c), sur EUR-Lex.
Voici la carte. La colonne de gauche est l'obligation, tirée des exigences à haut risque de l'AI Act (Règlement (UE) 2024/1689, Chapitre III, Section 2, plus l'Article 72 sur la surveillance). La colonne de droite est ce que cela signifie dans un dépôt de code.
Je ne vous dis pas si votre système est à haut risque. Cette classification dépend de l'Annexe III et c'est une question juridique pour un avocat qualifié. Ce que je peux faire, c'est vous montrer la construction une fois que quelqu'un vous dit que vous êtes dans le périmètre.
Article
Ce qu'il exige
Le changement de code
Art. 9, gestion des risques
Un processus de risque continu sur tout le cycle de vie
Un registre des risques vivant dans le dépôt, revu à chaque release, pas un document ponctuel
Art. 10, gouvernance des données
Des données d'entraînement et de référence gouvernées et documentées
Tracer la provenance et la version des jeux de données et de l'index ; consigner ce que l'agent voit ou non
Art. 11, documentation technique
Docs établis avant la mise sur le marché, tenus à jour (Annexe IV)
Traiter le modèle, le prompt et la config comme des artefacts versionnés ; générer la doc à partir d'eux
Art. 12, tenue de registres
Journalisation automatique des événements sur la durée de vie
Enregistrements d'audit en ajout seul : un par action, version du modèle et du prompt, décision, preuve
Art. 13, transparence envers les déployeurs
Instructions, capacités et limites claires
Livrer une fiche écrite de capacités et de limites avec le système, pas juste un README
Art. 14, surveillance humaine
Une personne peut comprendre, superviser et intervenir
Chemins d'abstention et d'escalade, un contrôle d'arrêt, et une validation humaine sur les actions qui déplacent de l'argent
Art. 15, justesse et robustesse
Métriques de justesse déclarées et résilience
Une suite d'évaluations qui bloque la release, avec l'abstention notée comme métrique de premier plan
Art. 72, surveillance après commercialisation
Surveiller le système en production
De l'observabilité sur les mêmes évaluations ; alerter quand une métrique en production dérive de la référence de release
Source : AI Act consolidé (Règlement (UE) 2024/1689 tel que modifié par le Règlement (UE) 2026/1744), Articles 9 à 15 et 72. Le Chapitre III, Sections 1 à 3, s'applique à partir du 2 décembre 2027 (Annexe III) ou du 2 août 2028 (Annexe I), l'Article 6(5) excepté ; l'Article 72 s'applique depuis le 2 août 2026. Ceci associe des obligations à du travail d'ingénierie ; ce n'est pas une interprétation juridique du périmètre d'un système donné.
HUIT ARTICLES, QUATRE ARTEFACTS
Les mêmes huit lignes, regroupées par ce que vous construisez vraiment. Seule la première bande est de la paperasse ; le reste, c'est du code, des tests et de l'alerting que vous savez déjà écrire. Un cadrage d'ingénierie, pas une taxonomie juridique.
Article 12 : quoi journaliser vraiment
L'Article 12 est celui que les ingénieurs sous-estiment, car il se lit comme de la paperasse et c'est en réalité un schéma. Il exige qu'un système à haut risque enregistre automatiquement les événements sur toute sa durée de vie, pour qu'un incident puisse être reconstitué plus tard.
Le piège, c'est de journaliser la sortie. La sortie est la chose la moins utile à garder. Journalisez la décision : quel était le modèle, quelle version de prompt a tourné, quelle preuve il a vue, ce qu'il a choisi de faire, et si un humain y a touché. Voici l'enregistrement que je garde par action.
UN ENREGISTREMENT, QUATRE ARTICLES
interface AgentAuditRecord
runIdstring
Article 12 journalisation : relie chaque étape d'une action en un seul enregistrement reconstituable.
timestampstring
Article 12 journalisation : ISO-8601, UTC, pour une piste ordonnée et précise sur toute la durée de vie.
modelIdstring
Article 11 documentation technique : le modèle et la version exacts derrière la sortie, générés et non rédigés.
promptVersionstring
Article 11 documentation technique : le prompt est de la config, et la config se versionne.
retrievedDocIdsstring[]
Article 15 justesse : quelles sources ont étayé la réponse, la preuve qu'elle n'a pas été devinée.
decision'answer' | 'abstain' | 'escalate'
Article 14 surveillance humaine : s'abstenir et escalader sont des issues de premier plan, pas des erreurs.
humanReviewer?string
Article 14 surveillance humaine : renseigné quand une personne a confirmé ou corrigé la décision.
outcome'accepted' | 'overridden' | 'pending'
Article 12 journalisation : en ajout seul, l'enregistrement boucle la boucle au lieu de l'écraser.
Le même enregistrement en ajout seul satisfait quatre obligations d'un coup : bien le journaliser et les Articles 11, 14 et 15 viennent avec la journalisation de l'Article 12.
La note sur chaque champ est la clause qu'il satisfait. Une structure de données, quatre Articles.
Article 14 : la surveillance humaine dans un pipeline RAG
La surveillance humaine est l'Article que l'on cite et que l'on lit de travers. L'Article 14 ne veut pas dire qu'une personne regarde un tableau de bord. Il veut dire que le système est conçu pour qu'une personne puisse le comprendre, le corriger et l'arrêter, et pour qu'il n'agisse pas seul là où il ne doit pas.
Dans un pipeline de recherche, c'est un design concret, pas une politique. L'agent ne répond qu'à partir de la preuve récupérée. Quand la preuve est mince, il ne produit pas une supposition assurée, il s'abstient et achemine le cas vers une personne. Une action qui déplace de l'argent ne s'exécute jamais toute seule ; elle attend qu'un humain signe.
Une action qui déplace de l'argent est précisément là où la surveillance doit s'imposer. J'ai écrit sur le versant confinement dans le moindre privilège pour les agents qui paient ; le même contrôle sert aussi de preuve pour l'Article 14.
L'ARTICLE 14 COMME CHEMIN DE CODE
Trois branches, trois chemins de code que vous pouvez montrer à un régulateur. Une surveillance qui ne vit que dans une politique n'a aucune branche ici.
Article 15 : comment prouver la justesse
L'Article 15 demande justesse, robustesse et cybersécurité, et il vous demande de déclarer les métriques de justesse. Les ingénieurs entendent « justesse » et attrapent un pourcentage unique. C'est la mauvaise forme pour un agent autorisé à dire « je ne sais pas ».
Le jeu de métriques honnête a plus d'un axe. À quelle fréquence une réponse assurée est correcte. À quelle fréquence l'agent s'abstient quand il le devrait. Comment il tient face à un red-team qui cherche à le faire mentir. Vous les déclarez, vous les mesurez avant la mise en production, et vous continuez à les mesurer en production.
Cette boucle est votre réponse à « à quel point est-ce juste ? ». Vous remettez la suite et le dernier run, pas un adjectif.
Ce que cela débloque
Faites cela et les échéances cessent d'être une menace pour devenir une checklist que vous savez déjà cocher. La journalisation est un schéma. La surveillance humaine, quelques chemins de code. La justesse, une suite d'évaluations. Rien de tout cela n'est nouveau pour une équipe qui livre avec soin ; l'AI Act ne fait que le nommer et le dater. Deux fois, désormais.
Les équipes qui peinent sont celles qui traitent l'AI Act comme un document juridique à résumer. Les équipes qui le passent le traitent comme une spécification. Je le lis comme une spécification parce que j'avais implémenté les mêmes idées avant que la loi me le demande.
La version d'une page, dans l'ordre de construction. Tout le reste n'est que du processus autour de ces quatre points.
FAQ
Cela dépend de savoir si votre système est classé à haut risque, soit en propre au titre de l'Article 6(2) et de l'Annexe III, soit parce qu'il est intégré dans un produit déjà régulé au titre de l'Article 6(1) et de l'Annexe I. Laquelle des deux, si tant est qu'il y en ait une, est une question juridique pour un avocat qualifié, pas quelque chose que je peux trancher à votre place, et les deux portent désormais des dates différentes. Ce billet vous donne la construction d'ingénierie pour le cas où vous êtes dans le périmètre. Construire dans ce sens est une assurance peu coûteuse, même avant que la classification soit établie.
Non, et le raccourci fait des dégâts. L'Article 113 dit toujours « It shall apply from 2 August 2026 », et cette phrase n'a pas été amendée. Ce qui a changé se trouve dans les exceptions en dessous, et celle qui compte ici vise le Chapitre III, Sections 1 à 3, les exigences à haut risque, qui s'appliquent désormais à partir du 2 décembre 2027 ou du 2 août 2028 selon la classification du système. Tout ce qui n'est pas visé par une exception court depuis le 2 août 2026, y compris la surveillance après commercialisation de l'Article 72, étant entendu que l'Article 72 s'adresse aux fournisseurs de systèmes à haut risque et que les règles qui décident de ce qui est à haut risque figurent elles-mêmes dans le chapitre reporté : ce qu'il exige concrètement de vous avant 2027 est une question pour votre avocat, pas pour moi. Si vous avez lu un titre annonçant le report de l'Acte et arrêté de construire, vous construisiez contre un titre de presse plutôt que contre l'Article 113.
Le Règlement (UE) 2026/1744, le Digital Omnibus on AI, a été adopté le 8 juillet 2026, publié au Journal officiel le 24 juillet 2026, et est entré en vigueur le 27 juillet 2026. Il a modifié le troisième paragraphe de l'Article 113 en trois endroits : il a remplacé le point (a), remplacé le point (c), et ajouté un point (d). Le point (c) est celui sur lequel repose cette checklist : le Chapitre III, Sections 1 à 3, à l'exception de l'Article 6(5), s'applique donc à partir du 2 décembre 2027 pour les systèmes d'IA classés à haut risque au titre de l'Article 6(2) et de l'Annexe III, et à partir du 2 août 2028 pour ceux classés à haut risque au titre de l'Article 6(1) et de l'Annexe I. Les deux autres comptent moins ici mais sont bien réels : le point (a) repousse une partie de l'Article 5 au 2 décembre 2026, et le nouveau point (d) applique les Articles 102 à 110 depuis le 27 juillet 2026. S'y ajoute un nouvel Article 111(4) qui laisse aux fournisseurs de systèmes de contenu de synthèse mis sur le marché avant le 2 août 2026 jusqu'au 2 décembre 2026 pour se conformer à l'Article 50(2). L'Article 72 relève du Chapitre IX, qui n'a pas été visé par une exception : il court donc depuis le 2 août 2026. Lisez l'Article 113 consolidé sur EUR-Lex plutôt qu'un site de suivi : un tracker non officiel très fréquenté servait encore le texte pré-omnibus quand j'ai vérifié, le 5 août 2026.
Non. C'est une checklist d'ingénierie. Elle associe des obligations à du code pour que vous sachiez quoi construire ; elle ne vous dit pas si la loi s'applique à vous ni comment un tribunal la lirait. Obtenez la classification et l'interprétation auprès d'un avocat, puis servez-vous de ceci pour construire.
L'enregistrement d'audit en ajout seul de l'Article 12. Un enregistrement par action de l'agent, capturant la version du modèle et du prompt, la preuve récupérée, la décision, et toute revue humaine. Il satisfait directement l'exigence de journalisation et porte aussi vos preuves pour les Articles 11, 14 et 15 : c'est la structure unique qui fait le plus de travail.
Plus proche que la plupart. Les citations vérifiées sont une preuve de justesse pour l'Article 15, l'abstention fondée sur la preuve est un déclencheur de surveillance pour l'Article 14, et une suite d'évaluations avec des seuils est votre déclaration de justesse. L'écart, ce sont en général deux choses : la journalisation en ajout seul de l'Article 12, et la documentation technique écrite de l'Article 11 que la plupart des équipes ne génèrent jamais.
Ancien CTO d'Integra. Auteur nommé (1 sur 5) d'ERC-3643, premier auteur d'ERC-6960, co-auteur d'ERC-7410 et co-auteur d'ERC-8203, encore à l'état de brouillon. Conçoit des systèmes d'IA en production et des systèmes Web3 régulés.
