Constituer sa documentation technique AI Act (Annexe IV) : la checklist complète

La documentation technique est l'épine dorsale de la conformité à l'AI Act européen pour les systèmes d'IA à haut risque. L'article 11 du règlement (UE) 2024/1689 exige que tous les fournisseurs l'établissent et la maintiennent. L'annexe IV précise en détail ce qu'elle doit contenir. C'est le document que les autorités nationales de surveillance du marché demanderont en premier lors d'un audit d'un fournisseur, et le document que les organismes notifiés examineront lors d'évaluations de conformité par des tiers.

De nombreux fournisseurs ont une documentation technique — mais une documentation technique satisfaisant à l'AI Act n'est pas la même chose que la documentation produit logicielle standard. Cette checklist identifie chaque élément requis en vertu de l'annexe IV et explique ce que « complet » signifie pour chacun.

Comment utiliser cette checklist

Parcourez chaque section. Pour chaque élément, marquez-le comme : Complet, Partiellement complet ou Manquant. Tout élément « Manquant » est une lacune de conformité qui doit être comblée avant que le système puisse légalement être mis sur le marché de l'UE.

L'annexe IV est organisée en sept sections principales.

Section 1 : Description générale du système d'IA

1.1 Finalité prévue

Déclaration claire de ce que le système est conçu pour faire
Identification du contexte et du cas d'usage spécifiques (ex : « scoring de crédit pour les prêts à la consommation inférieurs à 25 000 € »)
Identification des personnes ou organisations qui utiliseront le système (déployeurs) et des personnes qu'il affecte (sujets)
Déclaration de la portée géographique et temporelle du déploiement prévu

Ce que « complet » signifie : La finalité prévue doit être suffisamment spécifique pour qu'un régulateur puisse déterminer quelle catégorie de l'annexe III s'applique.

1.2 Catégorisation du système

Identification de la catégorie applicable de l'annexe III
Explication des raisons pour lesquelles cette catégorie s'applique
Confirmation que les règles de classification de l'article 6 ont été appliquées

1.3 Description et architecture du système

Vue d'ensemble des composants du système d'IA (données d'entrée, modèle, sorties, interfaces)
Description des exigences matérielles
Description des dépendances logicielles et des versions
Description des interfaces avec d'autres systèmes
Diagramme de blocs ou vue d'ensemble de l'architecture

Section 2 : Description détaillée des éléments et du processus de développement

2.1 Méthodologie d'entraînement

Description de la méthode d'apprentissage utilisée (supervisé, non supervisé, par renforcement, etc.)
Description des algorithmes d'entraînement, des paramètres et de l'approche d'optimisation
Description de la façon dont le modèle a été entraîné (ressources de calcul, environnement d'entraînement)

2.2 Données d'entraînement

C'est l'une des sections les plus scrutées. Les exigences de l'article 10 en matière de qualité des données d'entraînement s'intègrent dans l'obligation de documentation technique.

Description des jeux de données d'entraînement utilisés (source, taille, format, catégories de contenu)
Description de la méthodologie de collecte des données et de leur provenance
Description des étapes de prétraitement des données (nettoyage, normalisation, augmentation)
Description de la méthodologie d'étiquetage des données et des contrôles qualité
Déclaration sur la représentativité des données : le jeu de données représente-t-il la population sur laquelle le système opérera ?
Description des limites connues et des biais dans les données d'entraînement
Description des mesures prises pour identifier et corriger les biais
Description de la répartition entre jeux d'entraînement, de validation et de test
Si utilisation de jeux de données tiers : noms des jeux de données, fournisseurs et base de licence

2.3 Validation et tests

Description de la méthodologie de validation
Description des jeux de données de test (séparés des données d'entraînement)
Métriques de performance utilisées et leur justification (précision, rappel, F1, AUC-ROC, selon le cas)
Résultats de performance sur les jeux de données de test, ventilés par sous-groupes pertinents
Description des modes de défaillance identifiés
Description des tests de robustesse (performances sous changement de distribution, entrées adversariales, cas limites)

2.4 Modifications du système au cours du cycle de développement

Description des changements significatifs apportés au système pendant le développement et leur impact sur les performances

Section 3 : Informations sur la surveillance, le fonctionnement et le contrôle

3.1 Capacités et limites du système

Déclaration explicite de ce que le système peut et ne peut pas faire
Seuils de performance identifiés en dessous desquels le système ne devrait pas être utilisé
Cas limites connus où le système peut sous-performer
Description des scénarios d'utilisation abusive prévisibles et de la façon dont ils ont été traités dans la conception

3.2 Mesures de gestion des risques (article 9)

Description du processus de gestion des risques utilisé tout au long du cycle de développement
Identification de tous les risques prévisibles pour la santé, la sécurité et les droits fondamentaux
Description de la méthodologie d'estimation et d'évaluation des risques
Description des mesures de contrôle des risques mises en œuvre
Risques résiduels après les mesures de contrôle

3.3 Fonctionnalités de supervision humaine (article 14)

Description des fonctionnalités techniques permettant la supervision humaine
Description des contrôles d'arrêt/pause/invalidation disponibles pour les déployeurs
Description de la façon dont le système signale les sorties à faible confiance

3.4 Robustesse, précision et cybersécurité (article 15)

Niveaux de précision atteints sur des jeux de test représentatifs
Description des mesures de robustesse contre les erreurs et incohérences dans les données d'entrée
Description des mesures techniques contre les attaques adversariales
Évaluation de la cybersécurité et mesures mises en œuvre

Section 4 : Surveillance, fonctionnement et contrôle du système d'IA à haut risque

4.1 Plan de surveillance post-commercialisation

Description de la façon dont les performances réelles du système seront surveillées après déploiement
Indicateurs de performance clés suivis en production
Fréquence des examens de performance
Processus de détection et de réponse à la dégradation des performances

4.2 Capacités de journalisation (article 12)

Description des fonctionnalités de journalisation intégrées au système
Événements automatiquement journalisés
Durée de conservation et format des journaux

Section 5 : Description de la procédure d'évaluation de la conformité

Identification de la procédure d'évaluation applicable (autoévaluation annexe VI ou organisme notifié annexe VII)
Si annexe VII : nom et numéro d'identification de l'organisme notifié, numéro et date du certificat

Section 6 : Déclaration de Conformité UE

Copie de la Déclaration de Conformité UE signée (annexe V) incluse dans le dossier de documentation

Section 7 : Instructions d'utilisation (article 13)

Finalité prévue et contexte d'utilisation
Niveaux de précision, de robustesse et de cybersécurité
Limites connues et caractéristiques de performance
Exigences de supervision humaine
Spécifications matérielles et logicielles
Coordonnées du support technique du fournisseur

Lacunes courantes dans la documentation technique AI Act

Descriptions trop génériques. « Nous utilisons un réseau de neurones entraîné sur de grands jeux de données » n'est pas conforme.

Données de performance non ventilées. Rapporter la précision globale sans la ventiler par sous-groupes démographiques pertinents est insuffisant.

Aucun traitement des modes de défaillance. La documentation qui ne décrit que le système fonctionnant correctement échouera aux examens.

Provenance des données incomplète. Lister les noms des jeux de données sans décrire leur provenance est insuffisant.

Documentation obsolète. La documentation doit refléter la version déployée actuelle.

Comment Dilaig vous aide

L'audit en 50 questions de Dilaig génère automatiquement votre Documentation Technique de l'annexe IV — structurée pour satisfaire chaque élément de cette checklist.

Lancez votre audit gratuit sur dilaig.com et générez votre Documentation Technique en moins d'une heure.

FAQ : Documentation technique AI Act

Q : Les déployeurs doivent-ils créer une documentation technique, ou seulement les fournisseurs ? La documentation technique au titre de l'article 11 est une obligation du fournisseur. Les déployeurs ne sont pas tenus de créer une documentation annexe IV. Cependant, les déployeurs sont tenus en vertu de l'article 26(1) de vérifier que le fournisseur a rempli ses obligations documentaires.

Q : Quelle doit être la longueur de la documentation technique ? L'AI Act ne fixe pas de nombre de pages. La documentation doit être complète mais peut être aussi concise ou détaillée que nécessaire.

Q : La documentation technique peut-elle référencer d'autres documents ? Oui. Elle peut référencer d'autres documents (rapports de tests, évaluations tierces) plutôt que reproduire tout le contenu.

Points clés à retenir

L'annexe IV de l'AI Act spécifie sept sections de contenu requis pour la documentation technique.
Les lacunes les plus courantes sont les descriptions génériques, les données de performance non ventilées, l'absence d'analyse des modes de défaillance et la documentation obsolète.
Elle doit être maintenue tout au long du cycle de vie du système et conservée 10 ans.