Quelle documentation des données l’AI Act exige-t-il ?

En bref

• Les exigences les plus détaillées de documentation des données concernent les fournisseurs de systèmes d’IA à haut risque, au titre de l’article 10 et de l’annexe IV de l’AI Act.
• Les organisations qui utilisent un système à haut risque conçu par un tiers doivent aussi veiller aux données d’entrée qu’elles contrôlent et conserver les journaux sous leur contrôle.
• La documentation doit rester à jour. Il s’agit donc d’une pratique continue de suivi des sources et des responsables, pas d’un dossier rédigé une seule fois au lancement.

Quels systèmes d’IA sont concernés par les règles sur les données ?

Les règles détaillées de gouvernance des données de l’AI Act visent les systèmes d’IA à haut risque. Leur qualification dépend notamment de l’article 6 et des annexes I et III. Certains usages de l’IA dans le recrutement, l’évaluation de la solvabilité des personnes physiques ou l’accès à des services essentiels peuvent relever de cette catégorie, selon les conditions et les exceptions prévues par le règlement.

Tous les usages de l’IA en entreprise ne sont donc pas à haut risque. Un chatbot qui résume des politiques internes ou un modèle de prévision des stocks ne relève généralement pas de cette catégorie du seul fait de cette fonction. La finalité et le contexte d’utilisation restent déterminants. La première tâche consiste à établir quels cas d’usage relèvent des règles applicables aux systèmes à haut risque.

Le règlement distingue aussi deux rôles. Un fournisseur développe un système d’IA, ou le fait développer, puis le met sur le marché ou en service sous son propre nom ou sa propre marque. Un déployeur utilise un système d’IA sous sa propre autorité. Une entreprise du Benelux peut être déployeur pour une grande partie de ses outils et fournisseur pour certains systèmes internes.

Ce que l’article 10 demande de démontrer sur les données d’entraînement

L’article 10 encadre les données et leur gouvernance pour les systèmes d’IA à haut risque. Pour ceux qui reposent sur des techniques impliquant l’entraînement de modèles avec des données, il prévoit des pratiques de gouvernance et de gestion adaptées à la destination du système pour les jeux de données d’entraînement, de validation et de test. Ces pratiques couvrent notamment :

1. Les choix de conception pertinents.
2. La collecte des données, leur origine et, pour les données à caractère personnel, la finalité initiale de leur collecte.
3. Les opérations de préparation, comme l’annotation, l’étiquetage, le nettoyage, la mise à jour, l’enrichissement et l’agrégation.
4. Les hypothèses formulées, notamment sur les informations que les données sont censées mesurer et représenter.
5. L’évaluation de la disponibilité, de la quantité et de l’adéquation des données nécessaires.
6. L’examen des biais possibles et les mesures prises pour les détecter, les prévenir et les atténuer.
7. Les lacunes ou insuffisances constatées et la manière d’y remédier.

Selon l’article 10, les jeux de données doivent être pertinents, suffisamment représentatifs et, dans toute la mesure possible, exempts d’erreurs et complets au regard de la destination du système. Pour les systèmes à haut risque qui ne recourent pas à des techniques d’entraînement de modèles, le paragraphe 6 prévoit l’application des exigences pertinentes aux jeux de données de test.

Cette liste ne décrit pas le modèle lui-même. Elle décrit les données : leur origine, les traitements qu’elles ont subis et leurs faiblesses connues. C’est un travail que les équipes de gouvernance des données réalisent déjà, mais qu’il faut ici consigner pour un système précis.

Ce que la documentation technique doit contenir sur les données

L’article 11 impose aux fournisseurs de systèmes à haut risque d’établir une documentation technique avant leur mise sur le marché ou leur mise en service, puis de la tenir à jour. L’annexe IV en précise le contenu.

Concernant les données, le point 2 d) de l’annexe IV prévoit notamment une description des jeux de données d’entraînement utilisés et des informations sur leur provenance, leur portée et leurs principales caractéristiques. Il couvre aussi la manière dont les données ont été obtenues et sélectionnées, ainsi que les procédures d’étiquetage et de nettoyage. L’article 12 ajoute une exigence de traçabilité : les systèmes à haut risque doivent permettre l’enregistrement automatique d’événements dans des journaux tout au long de leur durée de vie.

Une idée mérite d’être corrigée : la documentation liée à l’AI Act n’est pas simplement un dossier de conformité rédigé au lancement par l’équipe qui a construit le modèle. Le règlement demande une documentation actualisée. Lorsqu’une source pertinente change de responsable, qu’une étape d’extraction est ajoutée ou qu’une source est remplacée, il faut examiner les conséquences de ce changement et adapter les éléments concernés.

Prenons un exemple : un modèle d’évaluation de la solvabilité a été entraîné à partir d’une table clients gérée par le service Finance. Six mois plus tard, la personne responsable de cette table quitte l’entreprise et un collègue ajoute un filtre. Si personne ne consigne ces changements, la documentation peut ne plus refléter les données utilisées lors d’un nouvel entraînement ou dans le fonctionnement actuel du système. Il faut conserver la description des données historiques tout en documentant les évolutions pertinentes.

Ce que les déployeurs doivent documenter

Si vous utilisez un système à haut risque conçu par un fournisseur externe, les obligations des articles 10 et 11 et de l’annexe IV incombent principalement à ce fournisseur, tant que votre rôle reste celui de déployeur. Vos obligations sont plus ciblées, mais elles concernent aussi les données.

L’article 26 prévoit que, dans la mesure où vous contrôlez les données d’entrée, vous devez veiller à ce qu’elles soient pertinentes et suffisamment représentatives au regard de la destination du système. Des obligations concernent aussi les journaux générés automatiquement sous votre contrôle. Faites confirmer les exigences de conservation applicables par votre conseil juridique, en tenant compte des règles de protection des données.

En pratique, vous devez donc savoir quels jeux de données alimentent quels systèmes d’IA, qui en est responsable et ce qui a changé. C’est une question de traçabilité des données et de responsabilité, qui concerne l’équipe data, pas uniquement le service des achats.

Ce que documentent les fournisseurs de modèles d’IA à usage général

Les fournisseurs de modèles d’IA à usage général, notamment les grands modèles sur lesquels reposent de nombreux outils, ont des obligations propres au titre de l’article 53. Celui-ci prévoit notamment une documentation technique ainsi qu’un résumé suffisamment détaillé, accessible au public, du contenu utilisé pour l’entraînement, conformément au modèle fourni par le Bureau de l’IA. Certaines exceptions à des obligations documentaires sont prévues pour des modèles diffusés sous licence libre et ouverte, sous les conditions fixées par le règlement.

La plupart des entreprises utilisent ces modèles plutôt qu’elles ne les fournissent. Pour elles, les questions pratiques portent généralement sur les informations publiées par le fournisseur et sur la manière dont leurs propres données sont utilisées : dans des prompts, pour un ajustement fin du modèle ou dans un mécanisme de recherche documentaire. Ces usages ne signifient pas tous que les données servent à entraîner le modèle.

Qui documente quoi au titre de l’AI Act ?

Un cadre pratique : inventorier, identifier les sources, attribuer, consigner, réviser

• Inventorier : listez vos cas d’usage de l’IA et indiquez, pour chacun, s’il est à haut risque et si vous êtes fournisseur ou déployeur.
• Identifier les sources : pour chaque cas d’usage à haut risque, répertoriez les jeux de données utilisés et l’origine de chacun.
• Attribuer les responsabilités : désignez, pour chaque jeu de données, une personne qui répond de son contenu et peut approuver les modifications.
• Consigner : conservez un historique daté des changements apportés à chaque jeu de données et de leurs auteurs.
• Réviser : vérifiez que la documentation correspond à la réalité à intervalles réguliers et chaque fois qu’une source, un responsable ou une étape de préparation change.

Faire vivre la documentation

Pour les données, une part importante du travail demandé par l’AI Act consiste à connaître leur origine, les traitements qu’elles ont subis et les responsabilités associées, puis à tenir ces informations à jour. Les équipes qui consignent déjà les sources et les responsables des données utilisées dans leurs rapports disposent d’une base utile, sans que cela suffise à satisfaire toutes les obligations du règlement. Commencez par l’inventaire, puis faites vivre la documentation.