Ce que contient un dossier de preuves annexe IV de l’AI Act
L’annexe IV de l’AI Act, le règlement européen sur l’intelligence artificielle, liste la documentation technique qu’un fournisseur de système d’IA à haut risque doit établir avant la mise sur le marché et tenir à jour ensuite (article 11). La plupart des équipes la lisent comme une liste de documents à produire. C’est une erreur. Ce qu’une autorité de surveillance du marché, un organisme notifié ou votre propre audit interne va réellement examiner, c’est si cette documentation constitue une preuve : rattachée au système réellement en production, datée, versionnée et impossible à réécrire discrètement. Ce guide reprend ce que demande l’annexe IV et explique comment l’assembler en un seul dossier de preuves AI Act qui résiste à l’examen.
Qui est concerné, et à quelle échéance
L’obligation pèse sur les fournisseurs de systèmes d’IA à haut risque : les systèmes relevant des cas d’usage de l’annexe III (recrutement, notation de crédit, tarification des contrats vie et santé chez les assureurs, accès aux services essentiels, entre autres) et les composants de sécurité régis par la législation produits de l’annexe I. Les déployeurs n’établissent pas la documentation de l’annexe IV. Mais ils vont l’exiger de plus en plus de leurs prestataires, et les déployeurs du secteur financier ont des obligations parallèles qui leur sont propres (voir notre guide sur l’AI Act pour les banques et les assureurs).
Le texte anglais dit :
The technical documentation of a high-risk AI system shall be drawn up before that system is placed on the market or put into service and shall be kept up-to date. (Article 11(1))
Deux mots comptent dans cette phrase : « avant » et « à jour ». La documentation n’est pas un livrable de lancement. C’est un état du système, qui doit suivre chacune de ses versions.
Sur le calendrier : avec le Digital Omnibus, le règlement (UE) 2026/1744 en vigueur depuis le 27 juillet 2026, les obligations à haut risque des systèmes autonomes de l’annexe III s’appliquent désormais à partir du 2 décembre 2027, et à partir du 2 août 2028 pour l’IA intégrée dans les produits réglementés de l’annexe I. Ce report donne de l’air, pas des vacances. Les pratiques interdites et l’obligation de maîtrise de l’IA s’appliquent depuis le 2 février 2025, les obligations de transparence de l’article 50 depuis le 2 août 2026, et les superviseurs des secteurs réglementés attendent dès aujourd’hui une gouvernance de l’IA documentée. Les équipes qui attendent la mi-2027 pour commencer découvriront que l’essentiel de l’annexe IV ne se reconstitue pas après coup.
Les neuf éléments que demande l’annexe IV
1. Une description générale du système
La destination du système, le nom du fournisseur, la version et son lien avec les versions précédentes, la manière dont le système interagit avec du matériel, des logiciels et d’autres systèmes, les formes sous lesquelles il est mis sur le marché, et la notice d’utilisation.
Le texte anglais dit :
how the AI system interacts with, or can be used to interact with, hardware or software, including with other AI systems, that are not part of the AI system itself, where applicable (Annex IV, point 1(b))
Pour un système agentique, cette interaction inclut la surface d’outils et d’API que l’agent peut atteindre. Gardez cette section courte, mais versionnée : la description doit correspondre au système qui tourne réellement.
2. Les éléments du système et son processus de développement
C’est la section la plus volumineuse : les spécifications de conception et l’architecture, les choix de conception structurants et les arbitrages qui les motivent, ce que le système est optimisé pour faire, les exigences en matière de données, leur provenance, l’étiquetage, le nettoyage, les caractéristiques des jeux d’entraînement, de validation et de test, et les mesures de contrôle humain intégrées dans le système (article 14). Elle couvre aussi les procédures de validation et de test, et c’est là que la notion de preuve apparaît noir sur blanc.
Le texte anglais dit :
the validation and testing procedures used, including information about the validation and testing data used and their main characteristics ... test logs and all test reports dated and signed by the responsible persons (Annex IV, point 2(g))
Des journaux de test, des rapports datés et signés : le règlement ne demande pas une affirmation, il demande une trace. Pour un système construit sur un modèle de fondation tiers, documentez ce que vous contrôlez (les prompts, les sources documentaires interrogées, les outils, les garde-fous) et renvoyez à la documentation du fournisseur du modèle pour ce que vous ne contrôlez pas.
3. Surveillance, fonctionnement et contrôle
Les capacités du système et ses limites connues, les sources de risque prévisibles, les circonstances qui peuvent dégrader ses performances, et les mesures techniques qui permettent à une personne d’interpréter et de contrôler ses sorties. Une déclaration honnête des limites vous protège ici. Un dossier qui n’avoue aucun mode de défaillance connu se lit comme un système non testé, pas comme un système sûr.
4. La pertinence des indicateurs de performance
Pas seulement les indicateurs, mais la raison pour laquelle ce sont les bons au regard de la destination du système et de la population concernée. Si vous évaluez un agent en contact avec la clientèle uniquement sur l’exactitude de ses réponses, jamais sur son comportement de refus ni sur sa manière de se présenter comme une IA, attendez-vous à ce que l’écart soit relevé.
5. Le système de gestion des risques
Une description du système de gestion des risques de l’article 9 : comment les risques ont été identifiés, estimés et évalués, et quelles mesures d’atténuation ont été retenues. La preuve concrète, c’est un registre des risques vivant, avec des dates et des responsables, relié aux tests qui vérifient que chaque mesure fonctionne réellement.
6. Les modifications au cours du cycle de vie
Le texte anglais dit :
A description of relevant changes made by the provider to the system through its lifecycle (Annex IV, point 6)
Un changement de modèle, une révision de prompt, un nouvel outil accordé à un agent, une mise à jour du corpus documentaire : chacun peut invalider des résultats de test antérieurs. Le registre des modifications et le registre des nouveaux tests vont donc ensemble.
7. Les normes harmonisées appliquées
La liste des normes harmonisées appliquées en tout ou partie ou, si aucune norme n’a été appliquée, une description des solutions retenues pour respecter les exigences. À ce jour, aucune norme harmonisée n’a été citée au Journal officiel. C’est donc la description des solutions que vous fournirez, et c’est aussi la raison pour laquelle aucun prestataire ne peut aujourd’hui certifier votre conformité à l’AI Act.
8. La déclaration UE de conformité
Une copie de la déclaration de conformité elle-même (article 47), une fois l’évaluation de la conformité réalisée.
9. Le plan de surveillance après commercialisation
Le texte anglais dit :
A detailed description of the system in place to evaluate the AI system performance in the post-market phase in accordance with Article 72, including the post-market monitoring plan referred to in Article 72(3). (Annex IV, point 9)
Le plan de l’article 72 décrit comment le fournisseur va recueillir et analyser l’expérience de l’usage réel, incidents, dérive, réclamations, et la réinjecter dans le système de gestion des risques. Pour les agents, c’est ici que vivent les nouveaux tests comportementaux, campagne après campagne.
Des documents épars au dossier de preuves AI Act
Quatre propriétés séparent un dossier partagé rempli de fichiers Word d’un dossier de preuves qui résiste à l’examen :
- La traçabilité. Chaque affirmation renvoie à sa source : la déclaration initiale, l’exécution du test, la décision du relecteur, la personne qui valide. « Le contrôle humain est garanti » est une phrase ; un point de validation observé dans une exécution de test journalisée est une preuve.
- L’immuabilité. Les décisions d’approbation et les dossiers délivrés doivent être conservés sous une forme qui ne peut être ni modifiée ni effacée. Si votre documentation peut être corrigée sur place après coup, sa valeur de preuve s’effondre.
- Le versionnage. Le dossier doit dire quelle version du système, quel plan de test et quel modèle d’évaluation ont produit chaque résultat, pour qu’un résultat puisse être reproduit, ou au moins expliqué, des mois plus tard.
- Les références au règlement. Rattacher chaque section à l’obligation à laquelle elle répond épargne au lecteur, et à l’autorité, de faire ce rapprochement eux-mêmes.
Les défaillances les plus fréquentes
Les dossiers qui échouent à la revue échouent presque toujours de la même façon : une documentation écrite une fois pour le lancement et jamais mise à jour après un changement de modèle ; des résultats de test impossibles à rattacher à une version précise du système ; un contrôle humain décrit dans la section conception mais contredit par les journaux ; des registres des risques sans date, sans responsable et sans lien avec la moindre vérification. Ces quatre défauts sont des problèmes de processus, pas des problèmes de rédaction. C’est pourquoi un sprint de rédaction le mois précédant l’échéance ne les corrige pas.
Comment Vidimus assemble ce dossier
Vidimus génère le dossier de preuves à partir des éléments que la plateforme détient déjà : la déclaration initiale structurée (destination, sources de données, outils, dispositif de contrôle humain), la classification du risque, déterministe, avec sa grille de lecture AI Act, les résultats des tests comportementaux issus des tests adverses exécutés contre l’agent en production, avec les appels d’outils observés sur le réseau, les résultats de la liste de contrôle, contrôle par contrôle, avec les corrections du relecteur, la décision d’approbation signée, et la piste d’audit qui ne peut être ni modifiée ni effacée. Chaque test, que nous appelons sonde, porte le passage du règlement qu’il vérifie, et chaque dossier est une version numérotée et figée. Les contrôles propres aux agents sont détaillés dans notre cadre de contrôle pour l’IA agentique.
Si vous voulez savoir où se situe l’un de vos systèmes avant de vous engager dans tout cela, la vérification gratuite de préparation à l’AI Act donne une classe de risque indicative et les obligations qui en découlent, dans le navigateur, sans compte. Et si vous préférez parcourir un vrai dossier de preuves avec nous, contactez-nous : nous intégrons nos clients un par un et nous restons à vos côtés pendant le premier.