Le dossier technique de l'AI Act, généré et non rédigé
À RETENIR
- L'Article 11 exige une documentation établie avant la mise sur le marché et tenue à jour. C'est la seconde moitié de cette phrase qui tue un dossier rédigé à la main.
- L'Annexe IV, ce sont neuf points, et la plupart posent des questions sur des versions, des données, une architecture et des résultats de tests auxquelles votre dépôt répond déjà. Rendez-les depuis le build qui lance vos tests.
- Trois choses ne se génèrent pas : pourquoi vous avez fait ces choix de conception, pourquoi vos métriques de performance sont les bonnes, et le système de gestion des risques de l'Article 9. Il leur faut une personne, un nom et une date de revue.
- L'Article 19 pose un plancher d'au moins six mois sur les journaux. L'Article 18 demande que la documentation technique reste à la disposition des autorités nationales compétentes pendant dix ans. Objets différents, horloges différentes.
- L'Article 72 s'applique depuis le 2 août 2026 et son troisième paragraphe pointe directement vers l'Annexe IV, alors que l'Article 11 lui-même relève du Chapitre III Section 2, l'une des sections reportées à 2027 ou 2028.
L'Article 11 de l'AI Act européen réclame un document. L'Annexe IV dit ce qu'il doit contenir, en neuf points. Presque personne autour de moi n'en possède un, y compris des équipes qui ont déjà construit chacune des choses que ces neuf points décrivent.
Je comprends pourquoi. Le rédiger à la main est pénible, et le résultat est faux en une semaine.
Alors ne le rédigez pas. Rendez-le. La majeure partie de l'Annexe IV pose des questions sur des versions, des données, une architecture et des résultats de tests, et votre dépôt connaît déjà les réponses, à un tag donné. Le reste relève du jugement, et le jugement exige une personne avec un nom.
PAS UN CONSEIL JURIDIQUE
Ceci n'est pas un conseil juridique. C'est de l'ingénierie documentaire, écrite par un ingénieur IA et smart-contract, à jour au 6 août 2026. Chaque Article, Annexe et 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. Les dispositions modifiées par le Digital Omnibus ont été vérifiées sur le règlement modificatif tel que publié au Journal officiel, car le service d'assistance AI Act de la Commission indique ne pas encore avoir été mis à jour et sert toujours la rédaction antérieure. Rien ici ne vous dit si votre système est à haut risque, et rien ici n'interprète le règlement. Vérifiez sur EUR-Lex avant de vous y fier, et évitez les trackers non officiels : l'un des plus cités servait un texte périmé quand j'ai vérifié.
Le document que j'ai rédigé à la main, et pourquoi il a échoué
J'ai livré les choses que l'Annexe IV vous demande de décrire. Des prompts versionnés, un registre de modèles, un jeu d'évals figé, une abstention fondée sur la preuve, un enregistrement en ajout seul pour chaque action, dans un fonds où un chiffre faux coûte de l'argent réel.
Ce que je n'avais pas, pendant plus longtemps que je ne voudrais l'admettre, c'était un document décrivant tout le système au même endroit.
Alors j'en ai écrit un. Versions de prompts, identifiants de modèles, index de recherche, dernier run d'évals, chemin de revue. Cela m'a pris un après-midi et c'était juste pendant environ une semaine.
Puis un modèle a été remplacé. Puis l'index a été reconstruit. Puis un prompt a changé. Personne n'a touché au document, parce que le mettre à jour ne faisait pas partie de la livraison.
C'est là qu'est l'échec, et il vaut la peine d'être précis. Le problème n'était pas que la documentation était difficile à écrire. Le problème, c'est qu'elle ait été écrite du tout.
Le système avait déjà la bonne forme
Prompts versionnés, registre de modèles, jeu d'évals figé, enregistrement d'audit par action. Chaque fait réclamé par l'Annexe IV se trouvait quelque part dans le dépôt.
J'ai rédigé le document à la main
Un après-midi, une section par sujet. Juste le jour de son enregistrement, qui est le seul jour où une description de système écrite à la main est jamais juste.
Le système a bougé, le document non
Un changement de modèle, un index reconstruit, un prompt modifié. Rien de tout cela n'a touché le document, parce que le mettre à jour n'était le travail de personne sur la checklist de release.
Il décrivait désormais une version que je ne faisais plus tourner
Une description assurée de la mauvaise version est pire qu'un manque assumé, parce qu'elle a l'air terminée. Personne ne relit un document qui a l'air terminé.
L'Annexe IV, lue en ingénieur
L'Annexe IV est le sommaire du document que l'Article 11 vous demande de tenir. Neuf points.
Lisez-les une fois en ingénieur et une évidence saute aux yeux. La plupart posent des questions sur un système que vous faites déjà tourner, et les réponses sont déjà dans votre dépôt, sous un numéro de version.
Si les Articles autour de celui-ci ne vous parlent pas, commencez par le règlement IA européen comme checklist d'ingénierie, qui associe les Articles 9 à 15 et 72 à des changements de code. Ce billet est la seule ligne que ce texte avait laissée ouverte.
Générez le dossier, ne le rédigez pas
Voici toute la méthode. Traitez le dossier technique comme un artefact de build en deux moitiés.
La moitié générée lit le dépôt à un tag : identifiants de modèles, versions de prompts, version de l'index, arbre de dépendances, architecture, dernier run d'évals conditionnant la release. Des faits. Si une personne les retape, ils sont faux au déploiement suivant.
La moitié humaine est courte, et c'est celle qui porte le poids. Pourquoi ces choix de conception. Pourquoi ces métriques sont appropriées. Quel risque vous avez accepté, et qui l'a accepté.
Un générateur qui écrit la seconde moitié écrit de la fiction, et cela se lit comme de la fiction.
Les chiffres d'évals de la moitié générée ne sont pas du travail supplémentaire. C'est le même run que celui décrit dans la suite d'évals qui bloque une release, qui produit le verdict. L'Annexe IV est l'endroit où ce verdict finit enfin par être écrit.
Le manifeste qui décide qui écrit quoi
Il vous faut un seul fichier qui dise quel bloc répond à quel point de l'Annexe IV, et d'où chaque bloc provient. C'est toute la configuration. Le reste n'est qu'un gabarit et une étape de build.
Deux champs font le vrai travail. Voici la forme d'un bloc.
Lequel des neuf points de l'Annexe IV ce bloc traite. Chaque point demande au moins un bloc, et le point 2 en prend deux : le build décrit l'architecture, une personne explique pourquoi elle a cette forme.
Le champ sur lequel toute la conception repose. Il décide qui a le droit d'écrire le bloc, et le générateur refuse de franchir la ligne.
La version que ce dossier décrit. Un dossier technique sans version décrit un système en général, c'est-à-dire aucun système.
Pour un bloc généré, les chemins et registres qu'il a lus. C'est ainsi qu'un lecteur vérifie le dossier au lieu de lui faire confiance.
Pour un bloc humain, la personne responsable des mots. Les points 4 et 5 sont des jugements, et un jugement porte un nom.
Pour un bloc humain, la dernière confirmation par une personne. Expiré veut dire release bloquée, pas dossier livré avec un avertissement.
Quand le build a produit le dossier. L'Article 11 exige une documentation tenue à jour : la date doit être celle du build, pas celle de l'auteur.
# annex-iv.yaml -- the technical file as a build artifact, not a document.
# Each block names the Annex IV point it answers and who is allowed to write it.
# source: generated -> the build reads it from this repo, at this tag
# source: human -> a person owns the words and the build refuses to invent them
#
# Article 11(1) asks for documentation drawn up before the system is placed on
# the market AND kept up to date. The second half is what this file is for.
release_tag: reconciliation-agent@1.4.0
blocks:
- id: system_description
annex_iv_point: 1 # general description, purpose, versions, deployment form
source: generated
inputs: [service.manifest.yaml, git.tag, deploy/targets.yaml]
- id: build_and_architecture
annex_iv_point: 2 # elements and development process, architecture, data, tests
source: generated
inputs: [poetry.lock, models/registry.json, prompts/*.md, index/version.json]
- id: design_rationale
annex_iv_point: 2 # the key design choices, assumptions and trade-offs
source: human # a generator knows what you built, never what you rejected
owner: tech-lead
review_every_days: 90
- id: monitoring_and_control
annex_iv_point: 3 # monitoring, functioning and control in operation
source: generated
inputs: [alerts/rules.yaml, runbooks/kill-switch.md]
- id: metrics_rationale
annex_iv_point: 4 # why THESE performance metrics are the appropriate ones
source: human # the numbers generate; the argument for them does not
owner: risk-owner
review_every_days: 90
- id: risk_management
annex_iv_point: 5 # the Article 9 risk management system
source: human
owner: risk-owner
review_every_days: 90
- id: lifecycle_changes
annex_iv_point: 6 # relevant changes through the lifecycle
source: generated
inputs: [git.log(previous_tag..release_tag)]
- id: standards_applied
annex_iv_point: 7 # harmonised standards applied, or other solutions adopted
source: human
owner: tech-lead
review_every_days: 180
- id: declaration_of_conformity
annex_iv_point: 8 # a copy of the Article 47 EU declaration of conformity
source: human
owner: compliance
- id: post_market_evaluation
annex_iv_point: 9 # includes the Article 72(3) post-market monitoring plan
source: human # the plan is written; the drift alerts under it are code
owner: risk-owner
review_every_days: 90
gate:
block_release_if:
- a human block is past its review_every_days
- a generated block has no input resolvable at release_tag
- release_tag is missing
Lisez la colonne `source` de haut en bas et vous avez le tableau honnête : quatre blocs que le build produit, six qu'une personne assume. Le compte n'est pas l'argument. Les quatre blocs générés sont ceux qui périment entre deux releases, et ceux que personne ne pense à mettre à jour à la main.
Le bloc `gate` en bas est celui que la plupart des équipes sautent, et c'est celui qui permet au dossier de survivre au contact d'une roadmap. Une section humaine périmée est une release en échec, pas une note de bas de page dans un wiki.
Les trois parties qu'un humain doit assumer
Trois choses dans l'Annexe IV ne se génèrent pas, et prétendre le contraire vous donne un beau document qui ne dit rien.
Le point 2 réclame les spécifications de conception : la logique générale, les choix de conception clés avec leur justification et les hypothèses retenues, et les arbitrages. Un générateur sait ce que vous avez construit. Il n'a aucune idée de ce que vous avez écarté, ni pourquoi.
Le point 4 vous demande de décrire pourquoi vos métriques de performance sont les bonnes. Votre suite d'évals produit les chiffres. L'argument selon lequel ce sont les bons chiffres pour ce système est une phrase humaine, et c'est celle sur laquelle un relecteur appuiera le plus fort.
Le point 5 réclame le système de gestion des risques de l'Article 9. C'est un processus avec une personne au bout, pas un tableau que l'on compile.
Tenir le dossier à jour est une étape de build
L'Article 11(1) ne demande pas seulement d'établir la documentation. Il demande de la tenir à jour. C'est cette clause qui tue un dossier rédigé à la main, et c'est aussi celle qu'une étape de build satisfait gratuitement.
Mettez le générateur dans la CI, à côté des tests. Chaque release régénère le dossier et le compare au précédent.
Un bloc généré qui a bougé est normal, c'est simplement le système qui change. Un bloc humain dont la date de revue a expiré bloque la release.
Puis livrez le dossier attaché au tag. La version 1.4 reçoit la documentation de la version 1.4, pas le document du trimestre dernier avec une nouvelle date en couverture.
C'est la même discipline que la barrière de release qui note l'abstention, avec une sortie différente. Un run émet un verdict, l'autre émet un document. Les deux se construisent, et aucun ne se mémorise.
Ce qui se passe quand on vous le demande
Tout ce qui précède existe pour un seul moment : quelqu'un réclame la documentation, et vous pouvez la produire pour la version exacte qui a produit la chose sur laquelle il vous interroge.
Un auditeur, un organisme notifié, l'équipe risque d'un client. La question a la même forme à chaque fois, et ce n'est une simple consultation plutôt qu'une panique que si la sortie porte sa version.
C'est ici que les deux moitiés de la preuve se rejoignent. l'enregistrement d'audit par action que j'écris pour un auditeur nomme la release qui a produit un chiffre. Le dossier technique est ce à quoi cette release renvoie.
Deux horloges de conservation sont constamment confondues : tenez-les séparées.
L'Article 19 vise les journaux, et son plancher est d'au moins six mois. L'Article 18 vise les documents, et il demande aux fournisseurs de tenir la documentation technique, ainsi que la documentation du système de gestion de la qualité, les décisions et documents des organismes notifiés le cas échéant, et la déclaration UE de conformité de l'Article 47, à la disposition des autorités nationales compétentes pendant dix ans après la mise sur le marché ou la mise en service du système.
L'Article 18 porte aussi une ligne à relire si vous travaillez en finance. Les fournisseurs qui sont des établissements financiers soumis au droit de l'Union sur les services financiers conservent la documentation technique dans le cadre de la documentation qu'ils tiennent déjà au titre de ce droit. Elle atterrit dans un dossier de gouvernance que vous gérez déjà, au lieu d'en créer un nouveau.
La raison de construire cela avant toute échéance n'est pas la vertu. C'est que la moitié générée ne coûte presque rien une fois l'étape de build en place, et que la moitié humaine tient en trois sections courtes qui s'affûtent chaque fois que quelqu'un s'y oppose.
Les équipes qui attendent l'écriront dans l'urgence, de mémoire, à propos d'une version qu'elles ne font plus tourner. Je préfère la rendre, mal au début, et améliorer le gabarit.
C'est tout l'échange. Une documentation que vous rédigez est un instantané d'un système. Une documentation que vous générez, c'est le système qui vous dit ce qu'il est.
Ce dossier est un artefact parmi d'autres sur la carte plus large de la façon dont je construis l'IA pour la finance régulée, et c'est celui qui transforme tout le reste en quelque chose que l'on peut remettre.
FAQ
L'Article 11(1) demande au fournisseur d'un système d'IA à haut risque d'établir une documentation technique avant que ce système soit mis sur le marché ou mis en service, et de la tenir à jour. Elle doit démontrer la conformité aux exigences du Chapitre III, Section 2, et donner aux autorités nationales compétentes et aux organismes notifiés les informations nécessaires pour évaluer cette conformité, sous une forme claire et complète. Elle doit contenir au minimum les éléments de l'Annexe IV. Il existe aussi une voie allégée : les PME, y compris les start-ups, et les petites entreprises de taille intermédiaire peuvent fournir ces éléments de manière simplifiée au moyen d'un formulaire établi par la Commission, que les organismes notifiés sont tenus d'accepter.
Neuf points. Une description générale du système, sa destination, ses versions et sa forme de déploiement. Une description détaillée des éléments et du processus de développement, couvrant les méthodes, l'architecture, les données, les mesures de surveillance humaine, la validation et les tests, et la cybersécurité. Des informations sur le suivi, le fonctionnement et le contrôle. Une description de la raison pour laquelle les métriques de performance sont appropriées. Le système de gestion des risques de l'Article 9. Les modifications pertinentes apportées au cours du cycle de vie. Les normes harmonisées appliquées, ou les autres solutions adoptées. Une copie de la déclaration UE de conformité de l'Article 47. Et le système en place pour évaluer la performance après la mise sur le marché, y compris le plan de surveillance après commercialisation visé à l'Article 72(3).
En grande partie, oui. Les versions, l'arbre de dépendances, l'architecture, la provenance des données, le dernier run d'évals qui a conditionné la release et les changements depuis la version précédente sont tous des faits présents dans un dépôt, à un tag donné, et une étape de build les lit plus fidèlement qu'une personne ne les retape. Trois parties ne se génèrent pas : la justification et les arbitrages derrière vos choix de conception, l'argument selon lequel vos métriques de performance sont les bonnes, et le système de gestion des risques. Ce sont des jugements. Donnez à chacun un responsable et une date de revue, et laissez le build refuser de livrer quand une date de revue a expiré.
L'Article 11 relève du Chapitre III, Section 2. Selon l'Article 113 consolidé, le Chapitre III, Sections 1 à 3, à l'exception de l'Article 6(5), s'applique à 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. Savoir quelle branche couvre un système donné, si tant est qu'il y en ait une, est une classification juridique et une question pour un avocat qualifié, pas pour moi. À savoir séparément : l'Article 72 relève du Chapitre IX, qui n'a pas fait l'objet d'une exception, et s'applique donc depuis le 2 août 2026 ; or l'Article 72(3) dispose que le plan de surveillance après commercialisation fait partie de la documentation technique visée à l'Annexe IV.
L'Article 18 demande aux fournisseurs de tenir la documentation technique à la disposition des autorités nationales compétentes pendant dix ans après la mise sur le marché ou la mise en service du système d'IA à haut risque, aux côtés de la documentation du système de gestion de la qualité, des décisions et documents des organismes notifiés le cas échéant, et de la déclaration UE de conformité de l'Article 47. Ne confondez pas cela avec les journaux : l'Article 19 vise les journaux générés automatiquement et son plancher est d'au moins six mois. Une horloge est pour les documents, l'autre pour les enregistrements. L'Article 18 précise aussi que les fournisseurs qui sont des établissements financiers soumis au droit de l'Union sur les services financiers conservent la documentation technique dans le cadre de la documentation qu'ils tiennent déjà au titre de ce droit.
Non. C'est de l'ingénierie documentaire. Cela vous dit comment produire et maintenir un document dont la loi fixe le contenu ; cela ne vous dit pas si la loi s'applique à vous, si votre système est à haut risque, ni comment un régulateur le lirait. Obtenez la classification et l'interprétation auprès d'un avocat, puis servez-vous de ceci pour construire le pipeline.
Cet article vous a plu ?
Recevez les suivants dans votre boîte mail chaque mardi.