Documentation technique sous le Règlement sur l'IA

Ce que l'obligation de documentation couvre réellement

L'article 11 et l'annexe IV définissent le contenu de la documentation pour les systèmes à haut risque. Le package comprend l'objectif prévu, les choix de conception, l'historique du développement et des tests, les allégations de performance, ainsi que les mesures de gestion des risques que vous avez réellement mises en œuvre. La Commission résume l'Acte comme un cadre fondé sur les risques avec des obligations plus lourdes pour les utilisations à haut risque ; commencez par cette base avant de créer un modèle personnalisé (Commission européenne — Acte IA).

Le texte contraignant est le règlement lui-même sur EUR-Lex (Règlement (UE) 2024/1689). Les blogs et les présentations secondaires sont utiles uniquement après que vous puissiez pointer vers l'article et la ligne de l'annexe qui soutient chaque affirmation. Je traite la documentation comme un ensemble de fichiers vivants sous contrôle de version, et non comme un PDF unique exporté la semaine précédant une démonstration.

Cycle de vie, et non une image figée

Si le modèle change, l'ensemble de formation est rafraîchi, ou un contrôle de sécurité est réaménagé, la documentation doit montrer la différence. Les notes de modification, les propriétaires et les dates sont aussi importants que la première rédaction. Lorsqu'un déployeur demande « quel build était en production mardi? », vous devriez répondre à partir du même enregistrement qui soutient la conformité — et non à partir d'un fil Slack.

Flux de travail étape par étape que nous utilisons avant d'appeler un pack "prêt"

- Confirmez que le système est à haut risque (ou sera traité comme tel) en vertu de l'article 6 / de l'annexe III avant de créer un arbre de documentation. Si ce n'est pas le cas, n'exagérez pas la complétude de l'annexe IV dans les copies de vente. - Ouvrez l'annexe IV et créez un dossier ou un ticket par thème : description générale, spécifications de conception, processus de développement, données, gestion des risques, tests, surveillance et surveillance humaine. - Attribuez un seul propriétaire par thème. La propriété partagée sans nom est la façon dont les sections restent vides. - Rédigez avec le produit et l'ingénierie dans la salle. Les revues juridiques examinent les allégations ; les ingénieurs fournissent des chemins de preuve (configurations, tableaux de bord, rapports de test). - Liez chaque allégation à un artefact : un résumé de jeu de données, un schéma de journalisation, un runbook, une ligne d'enregistrement des risques. La prose non liée est un problème. - Testez le pack contre le système live : la configuration de journalisation correspond-elle aux allégations de l'article 12 ? Le chemin de contournement de l'interface utilisateur correspond-il au texte de l'article 14 ? - Planifiez un déclencheur de rafraîchissement : mise à jour de la version du modèle, changement de jeu de données important, nouvelle classe de déploiement ou incident grave près d'un accident.

VendorVet transforme ces thèmes en une checklist fonctionnelle. Il ne remplace pas le jugement ou les conseils d'un organisme notifié. Utilisez le produit pour détecter les omissions précoces ; utilisez le Journal officiel pour régler les litiges.

Résumés de jeux de données que les équipes skip (Article 10)

L'article 10 exige une gouvernance des données : les données de formation, de validation et de test doivent être pertinentes et représentatives de l'objectif visé, avec un examen des biais et des lacunes qui pourraient nuire aux performances pour les personnes que le système affecte. Les auditeurs recherchent un résumé de quelles données ont été utilisées et de la manière dont elles ont été examinées — et non une carte de modèle marketing avec trois adjectifs.

Une ligne de checklist qui indique « données examinées » sans résumé derrière échoue à la première révision sérieuse. Rédigez le résumé de sorte qu'un nouvel ingénieur puisse répondre : domaines sources, fenêtres de temps, déviations connues, règles d'exclusion et la manière dont les étiquettes ont été produites ou auditées. Si des données personnelles se trouvent dans le pipeline, conservez vos rôles et bases RGPD cohérents avec la manière dont vous décrivez le traitement ailleurs ; la bibliothèque de conseils du CEPD est la référence pratique pour ce langage (directives et bonnes pratiques du CEPD).

Checklist — preuves de données

- Inventaire des ensembles de formation / validation / test avec propriété et date de dernière mise à jour - Notes de représentativité liées à l'objectif visé (qui est dans le périmètre, qui est en dehors) - Méthode d'examen des biais et des erreurs — même si imparfaite — avec risque résiduel indiqué - Processus d'étiquetage ou d'annotation, y compris les contrôles de qualité - Règles de rétention et d'accès pour les ensembles de données eux-mêmes

Conception de la surveillance humaine (Article 14)

L'article 14 demande une surveillance humaine significative : des interfaces et des contrôles qui permettent à une personne de surveiller, d'interpréter et de remplacer les sorties lorsque cela est nécessaire. « Les humains restent dans la boucle » n'est pas un mécanisme. Documentez le chemin de remplacement spécifique, qui peut l'exercer, comment le système signale qu'un humain devrait intervenir et ce qui se passe lorsque l'humain est indisponible.

Dans les produits d'agent, cela signifie souvent un arrêt complet avant une action conséquente (publication de la liste des candidats, envoi de la décision de crédit, mise à jour du dossier), et non un bouton d'approbation décoratif qui se déclenche automatiquement après trois secondes. Associez la description de l'interface utilisateur à la politique d'exécution : quels rôles, quels environnements, quels événements d'audit se déclenchent lorsque le remplacement est utilisé.

Checklist — preuves de surveillance

- Rôles de surveillance nommés et chemin d'escalade - Contrôles d'interface utilisateur ou d'API qui mettent réellement en pause ou inversent l'action de l'IA - Signaux / seuils qui appellent à un examen humain - Formation ou carnet de bord pour les personnes qui supervisent - Preuves que les événements de remplacement sont consignés

Surveillance et journalisation post-marché (Articles 12 et 72)

L'article 12 exige une journalisation automatique suffisante pour la traçabilité, avec une durée de rétention minimale de six mois pour les systèmes à haut risque. L'article 72 ajoute des devoirs de déclaration d'incidents graves. Les équipes documentent le modèle et oublient le plan de preuve de l'exécution. Associez la documentation à la configuration de journalisation réelle afin que les deux soient en accord.

Si vous exécutez déjà l'observabilité GenAI, mappez les spans et les événements aux questions que posera une revue post-marché : quelle classe d'entrée, quelle version de modèle, quelle décision de politique, quelle action humaine. Les conventions GenAI d'OpenTelemetry sont une référence pratique d'ingénierie pour nommer ces champs de manière cohérente entre les services (OpenTelemetry — Observabilité GenAI). L'Acte ne mandate pas OTel ; des traces cohérentes rendent simplement les revendications de l'article 12 plus faciles à défendre.

Thème | Article / crochet d'annexe | Erreur courante | Preuve qui convainc Description générale et objectif | Art. 11 / Annexe IV | Présentation marketing au lieu de l'objectif prévu | Déclaration d'objectif + utilisations hors champ Gouvernance des données | Art. 10 | "Dataset examiné" sans résumé | Inventaire de datasets + notes d'examen des biais Gestion des risques | Art. 9 | PDF de risque statique de l'année dernière | Registre vivant avec propriétaires et risque résiduel Journalisation | Art. 12 | Journaux revendiqués mais rétention < 6 mois | Schéma + capture d'écran/export de configuration de rétention Supervision humaine | Art. 14 | Slogan sans chemin de contournement | UI/runbook + matrice de rôles Post-marché / incidents | Art. 72 | Pas de livre de jeu d'incidents graves | Définitions de déclenchement + contacts de déclaration

Erreurs courantes que nous constatons dans les packs de documentation

- Écrire pour la brochure, et non pour l'annexe. Les diagrammes jolis qui ne citent jamais les thèmes de l'annexe IV gaspillent le temps d'examen. - Copier une feuille de travail US RMF et la renommer « pack AI Act ». Le cadre de gestion des risques liés à l'IA de la NIST (NIST AI RMF) est utile pour le vocabulaire des processus, mais il ne remplace pas le contenu de l'article 11 / annexe IV. - Documenter le modèle d'hier. La production a déjà évolué ; le pack n'a pas suivi. - Laisser les instructions de déploiement vides. La transparence de l'article 13 pour les déploiements est facile à omettre lorsque l'équipe du fournisseur ne parle qu'à elle-même. - Appeler une liste de contrôle « certifiée ». Ce langage surestime. Les listes de contrôle réduisent le risque d'omission ; elles ne garantissent pas la conformité.

Critères de décision : expédier le pack ou continuer à rédiger

Considérez le pack comme bloquant la publication pour un lancement à haut risque lorsque l'une des conditions suivantes est vraie :

- Aucun résumé de jeu de données que un tiers peut suivre - Aucun mécanisme de surveillance humaine décrit lié à un contrôle réel - Conservation des journaux de moins de six mois, ou des journaux qui ne peuvent pas reconstruire une décision - Registre des risques sans propriétaires de risques résiduels - Objectif prévu si vague que le mappage d'Annexe III est impossible

Vous pouvez toujours expédier des prototypes internes qui ne touchent jamais l'utilisation à haut risque de l'UE. Soyez honnête sur la portée par écrit. Le langage ambigu « nous sommes conformes dans l'esprit » est pire qu'un statut clair « pas encore à haut risque / pas encore sur le marché de l'UE ».

Ce que cela n'est pas

Cette page ne constitue pas un conseil juridique, ni une évaluation d'un organisme notifié, et ne garantit pas que votre système est conforme au Règlement (UE) 2024/1689. VendorVet ne prétend pas avoir une couverture de 100 %, n'invente pas les taux de victoire des clients et ne remplace pas les conseils ou une évaluation de conformité lorsque celle-ci est requise. Une liste de contrôle vous aide à assembler et à vérifier les thèmes ; l'obligation contraignante reste la documentation décrite à l'article11 et à l'annexe IV, détenue par des personnes qualifiées au sein de votre organisation.

Clôture

Commencez par le texte du Journal officiel, mappez les thèmes de l'Annexe IV aux propriétaires, puis remplissez les trois lacunes que les auditeurs ouvrent en premier : données, surveillance et journalisation. Gardez le pack versionné avec le système. Lorsque le modèle ou le jeu de données est déplacé, déplacez la documentation dans le même train de version. Pour la décision de niveau de risque qui se situe en amont de tout cela, lisez notre guide sœur sur les niveaux de risque de l'Acte IA de l'UE.

Références

- Règlement (UE) 2024/1689 (EUR-Lex) - Commission européenne — Loi sur l'IA - Loi sur l'IA de l'UE — Calendrier de mise en œuvre - Cadre de gestion des risques liés à l'IA de la NIST - EDPB — Lignes directrices et bonnes pratiques du RGPD - OpenTelemetry — Observabilité du GenAI

Articles liés

- Niveaux de risque de l'Acte IA de l'UE : un guide pour les praticiens (2026) - Explorez la matrice complète des sujets de micro-SaaS IA →