Annexe IV de l’AI Act : quels points exigent une personne ?
L’Annexe IV liste neuf points pour votre dossier technique. Lesquels vos traces de livraison couvrent-elles, et lesquels demandent un nom ?
EN 30 SECONDES
L’Annexe IV est la liste des neuf points que le dossier technique de l’AI Act doit couvrir au minimum. Les traces de livraison peuvent répondre en partie à plusieurs points, mais trois sont des jugements qu’une personne nommée doit écrire.
À RETENIR · 3
- L’Annexe IV compte neuf points principaux. Votre dépôt ne contient peut-être qu’une partie des réponses.
- Le point 9 inclut le plan de surveillance de l’Article 72(3) : des personnes l’écrivent, les alertes de dérive sont du code.
- La justification de conception (point 2), l’argumentaire des métriques (point 4) et le système de gestion des risques de l’Article 9 (point 5) demandent un responsable nommé et une date de revue.
Sur cette page
L’Annexe IV en neuf points, lue par un ingénieur
EN BREF L’essentiel de l’Annexe IV porte sur des versions, des données, une architecture et des tests, que vos traces de livraison contiennent déjà en partie.
LES MOTS À CONNAÎTRE
- Documentation technique
- Le dossier que l’Article 11 demande au fournisseur d’établir avant la mise sur le marché ou la mise en service, puis de tenir à jour.
- Annexe IV
- La partie du règlement qui fixe, en neuf points, le contenu minimal de la documentation technique.
- Plan de surveillance après commercialisation
- Le plan écrit du fournisseur pour suivre les performances du système une fois sur le marché. L’Article 72(3) l’intègre à la documentation technique.
Source : Annexe IV de l’AI Act
L’Article 11(1) précise que la Documentation technique Le dossier que l’Article 11 demande au fournisseur d’établir avant la mise sur le marché ou la mise en service, puis de tenir à jour. Voir le glossaire contient au minimum ces neuf éléments, énumérés à l’Annexe IV La partie du règlement qui fixe, en neuf points, le contenu minimal de la documentation technique. Voir le glossaire. Votre dépôt ne contient peut-être qu’une partie des réponses. La provenance des données, les procédures et d’autres preuves peuvent se trouver ailleurs.
Le point 9 inclut le Plan de surveillance après commercialisation Le plan écrit du fournisseur pour suivre les performances du système une fois sur le marché. L’Article 72(3) l’intègre à la documentation technique. Voir le glossaire. Ce plan s’écrit à la main ; les alertes de dérive qui l’accompagnent sont du code.
Les petites structures ont une voie plus simple. Les PME, start-ups comprises, et les petites entreprises de taille intermédiaire peuvent remplir un formulaire simplifié prévu par la Commission. Les organismes notifiés doivent l’accepter.
Dans la section suivante : Alors, lesquels des neuf points échappent à tout générateur ?
Trois parties de l’Annexe IV qu’une personne doit assumer
EN BREF Trois parties de l’Annexe IV sont des jugements : la justification de conception, l’argumentaire des métriques et le système de gestion des risques.
Le point 2 demande comment le système est conçu : sa logique, ses choix clés avec leurs raisons et hypothèses, et ses arbitrages.
Un générateur sait ce que vous avez construit, pas ce que vous avez écarté, ni pourquoi.
Le point 4 demande pourquoi vos métriques de performance sont les bonnes. Votre suite d’évals produit les chiffres. Montrer que ce sont les bons chiffres pour ce système relève d’un argument humain, et c’est là-dessus que les relecteurs insisteront le plus.
ÉTAPE PAR ÉTAPE
Étape 1. Demander. Pour chaque point, le build demande : un fait consigné, ou un jugement ?
- Demander Pour chaque point, le build demande : un fait consigné, ou un jugement ?
- Un fait Versions, dépendances, architecture, provenance des données, résultats de tests, écart depuis le dernier tag : générés à chaque version, puis contrôlés sur la source.
- Une raison Point 2 : les choix clés, les hypothèses et les arbitrages, y compris ce que vous avez refusé. Une personne les écrit et les signe.
- Un jugement de risque Points 4 et 5 : la pertinence des métriques et le risque accepté. Le build refuse de les écrire ; le responsable du risque s’en charge.
Le point 5 demande le système de gestion des risques prévu à l’Article 9. C’est un processus avec une personne au bout, pas un tableau qu’on compile.
EN CLAIR
Le build peut dire ce qu’est le système. Seule une personne peut dire pourquoi il est construit ainsi, et pourquoi ses métriques et les risques acceptés sont les bons.
OBJET OBTENU
Chaque jugement a son responsable
NIVEAU TERMINÉ
Ce que vous savez maintenant
- L’Annexe IV est une liste minimale de neuf points, et un dépôt n’en couvre peut-être qu’une partie.
- Les points 2, 4 et 5 reposent sur des jugements : un dossier généré peut décrire le système sans rien expliquer.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Votre suite d’évals affiche la justesse à chaque version. Cela répond-il au point 4 de l’Annexe IV ?
Pas à lui seul. Les chiffres se génèrent ; pourquoi ces métriques conviennent à ce système, c’est un argument qu’une personne écrit.
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.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.