Gouvernance des données selon l'EU AI Act : Ce que les entreprises d'IA doivent documenter en 2026

L'EU AI Act — Regulation (EU) 2024/1689 — est entré en vigueur le 1er août 2024. Pour les équipes développant des produits d'IA en Europe, cette date a marqué le début d'une horloge de conformité, et non une simple actualité politique. Les obligations relatives aux modèles d'IA à usage général s'appliquent à partir d'août 2025. Les exigences pour les systèmes d'IA à haut risque s'appliquent pleinement à partir d'août 2026. La fenêtre pour construire votre infrastructure de documentation est maintenant ouverte.

Cet article se concentre sur les dispositions les plus susceptibles de créer une exposition juridique pour les entreprises d'IA à court terme : les exigences de gouvernance des données de l'Article 10, les obligations de tenue de registres de l'Article 12, et le défi pratique de prouver la provenance des données d'entraînement — un problème que la plupart des équipes n'ont pas encore opérationnalisé.

Ce que l'Article 10 exige réellement

L'Article 10 de l'EU AI Act établit des pratiques obligatoires de gouvernance des données pour les fournisseurs de systèmes d'IA à haut risque. La disposition est intitulée « Données et gouvernance des données » et ne constitue pas un langage aspirationnel — elle impose des obligations spécifiques et vérifiables.

En vertu de l'Article 10(2), les ensembles de données d'entraînement, de validation et de test doivent être soumis à des pratiques appropriées de gouvernance et de gestion des données. Plus précisément, les fournisseurs doivent documenter :

- Les choix de conception pertinents — pourquoi des ensembles de données particuliers ont été sélectionnés, quels critères ont régi leur inclusion ou leur exclusion

- Les processus de collecte de données et l'origine des données — d'où proviennent les données, dans quelles circonstances elles ont été acquises, et qui détenait les droits au moment de l'acquisition

- Les opérations de préparation des données — nettoyage, étiquetage, enrichissement, agrégation, annotation ; chaque transformation ayant modifié l'ensemble de données avant l'entraînement

- Une évaluation statistique des ensembles de données — pour identifier et atténuer les biais potentiels susceptibles d'affecter les droits fondamentaux, notamment dans les domaines d'application à haut risque

- Les limitations connues — lacunes de couverture, biais temporels, déséquilibres géographiques, ou toute caractéristique de l'ensemble de données susceptible d'affecter les performances du système dans les conditions de déploiement

L'Article 10(3) ajoute que les données d'entraînement doivent être pertinentes, suffisamment représentatives et exemptes d'erreurs dans la mesure du possible, compte tenu de la finalité prévue. L'Article 10(5) permet le traitement de catégories particulières de données à caractère personnel pour la détection et la correction des biais — mais uniquement dans le respect des conditions strictes et des garanties définies par le droit européen de la protection des données, et avec des contrôles d'accès limitant l'exposition au minimum nécessaire.

Pour les entreprises qui traitaient jusqu'alors les ensembles de données d'entraînement comme des artefacts d'ingénierie internes plutôt que comme des documents juridiques, l'Article 10 représente un changement fondamental dans la façon dont la gestion des ensembles de données doit être structurée.

Les quatre catégories de documentation exigées par l'Article 10

Lorsque des régulateurs ou une autorité nationale de surveillance auditeront votre conformité à l'Article 10, ils rechercheront des preuves dans quatre catégories de documentation. Chacune nécessite une approche opérationnelle différente.

1. Registres de provenance et d'origine des données

Vous devez être en mesure de démontrer, pour chaque ensemble de données ou composant d'ensemble de données, l'origine des données. Cela comprend : la source (répertoire public, corpus sous licence, fournisseur de données sous contrat, scraping web, génération synthétique), la date d'acquisition, la base juridique en vertu de laquelle vous détenez et utilisez les données, ainsi que toutes les conditions contractuelles restreignant leur traitement. Un registre de provenance créé des semaines ou des mois après l'acquisition — reconstitué à partir de la mémoire des ingénieurs ou de messages Slack informels — ne satisfera pas un auditeur.

2. Évaluations des biais et journaux des limitations

L'Article 10(2)(f) exige explicitement des fournisseurs qu'ils identifient et documentent tout biais connu ou toute lacune potentielle dans les ensembles de données susceptibles de générer des risques pour la santé, la sécurité ou les droits fondamentaux. Il ne s'agit pas d'un exercice ponctuel. Au fil de l'évolution des ensembles de données au cours des cycles d'entraînement, les évaluations des biais doivent être mises à jour et l'historique de ces évaluations doit être conservé. La documentation doit enregistrer ce qui a été constaté, les mesures d'atténuation appliquées, et les limitations qui subsistent dans la configuration d'entraînement finale.

3. Journaux de traitement et de transformation des données

Chaque opération de pré-traitement — déduplication, normalisation, filtrage, augmentation synthétique, révision des annotations — doit être consignée avec suffisamment de détails pour reconstituer l'état de l'ensemble de données à tout moment dans le pipeline. L'objectif est la traçabilité : si une autorité réglementaire identifie une défaillance du système ou une sortie discriminatoire, elle doit pouvoir remonter la chaîne causale à travers les données d'entraînement. Une description vague de « nettoyage standard des données » ne satisfera pas à cette exigence.

4. Documentation des consentements et des droits

Lorsque les données d'entraînement incluent des données à caractère personnel, les registres de consentement et les bases juridiques du traitement doivent être documentés sous une forme récupérable et horodatée. Lorsque des données sont obtenues sous licence auprès de tiers, les conditions de licence, les éventuelles restrictions d'utilisation et la version de l'ensemble de données couverte par ces conditions doivent être conservées pendant toute la durée de vie opérationnelle du système — et au-delà, les obligations de surveillance post-commercialisation en vertu de l'Article 72 prolongeant la fenêtre de documentation pertinente.

Article 12 : Documentation technique et obligations d'archivage

L'Article 12 de l'EU AI Act établit des obligations d'archivage qui s'ajoutent aux exigences de gouvernance des données de l'Article 10. En vertu de l'Article 12, les fournisseurs de systèmes d'IA à haut risque doivent s'assurer que leurs systèmes sont capables de consigner automatiquement les événements pertinents pour l'identification des risques pesant sur la santé, la sécurité ou les droits fondamentaux tout au long du cycle de vie du système.

Plus largement, l'Annexe IV du Règlement (référencée à l'Article 11) précise la documentation technique devant être préparée avant qu'un système d'IA à haut risque soit mis sur le marché ou mis en service. La Section 2 de l'Annexe IV se rapporte directement aux exigences de l'Article 10 : elle exige une description générale des méthodologies et techniques d'entraînement utilisées, ainsi que des ensembles de données d'entraînement, de validation et de test utilisés, en précisant leur provenance, leur portée et leurs caractéristiques essentielles.

La documentation produite en vertu des Articles 10 et 12 n'est pas destinée principalement à un usage interne. Elle doit être mise à la disposition des autorités nationales compétentes sur demande. Elle doit être conservée pendant au moins dix ans après la mise sur le marché ou la mise en service du système. Et elle doit être mise à jour chaque fois que le système subit une modification substantielle.

Article 53 : Obligations pour les fournisseurs de modèles d'IA à usage général

Pour les entreprises développant des modèles d'IA à usage général — grands modèles de langage, modèles fondamentaux multimodaux et systèmes similaires — l'Article 53 de l'EU AI Act introduit un ensemble parallèle d'obligations applicables à partir d'août 2025. Les fournisseurs de modèles GPAI doivent maintenir une documentation technique couvrant les données d'entraînement et les méthodologies utilisées pour l'entraînement, les tests et l'évaluation. Lorsqu'un modèle GPAI est classé comme modèle présentant un risque systémique en vertu de l'Article 51, des obligations supplémentaires en matière de tests adversariaux et de signalement d'incidents s'appliquent.

L'intersection entre l'Article 53 et l'Article 10 est importante pour les entreprises dont les modèles à usage général sont ensuite intégrés par des déployeurs en aval dans des applications d'IA à haut risque. Le déployeur en aval est responsable de la conformité à l'Article 10, mais dépend d'informations de provenance exactes de la part du fournisseur du modèle fondamental. Les lacunes dans la documentation du fournisseur GPAI compromettent directement la capacité du déployeur à se conformer — et dans la pratique, la responsabilité contractuelle s'ensuivra.

Le problème de la provenance : pourquoi la documentation des données d'entraînement est difficile

En théorie, les exigences documentaires de l'Article 10 sont simples. En pratique, les équipes d'IA font face à un défi structurel : la façon dont les ensembles de données d'entraînement sont assemblés, itérés et réutilisés dans le développement ML moderne n'a jamais été conçue en pensant à la traçabilité juridique.

Les corpus d'entraînement sont généralement assemblés sur des mois ou des années, en puisant dans des dizaines de sources — ensembles de données publics, corpus sous licence, crawls web, fournisseurs d'annotation sous contrat et pipelines internes de génération synthétique. Le contrôle de version pour le code est mature ; pour les ensembles de données à grande échelle, il ne l'est pas. Un ensemble de données « collecté au T3 2024 » est souvent un composite d'acquisitions couvrant plusieurs trimestres, traité par plusieurs équipes, avec un suivi informel de ce qui a changé entre les exécutions.

Lorsque l'Article 10 vous demande de documenter l'« origine des données » et les « processus de collecte de données », il exige un niveau de précision rétrospective que de nombreuses équipes ne peuvent tout simplement pas fournir actuellement. L'écart entre ce que vous savez de vos données d'entraînement et ce que vous pouvez prouver — à un régulateur, à un tribunal, à une contrepartie dans un litige de propriété intellectuelle — est là où se concentre l'exposition à l'Article 10.

Il existe une dimension temporelle supplémentaire. La documentation créée aujourd'hui, décrivant des données acquises aujourd'hui, est relativement simple à produire. La documentation qui restera crédible et juridiquement fiable dans cinq ou dix ans — après que les systèmes auront été mis à jour, que les membres de l'équipe auront changé et que les licences sources auront évolué — nécessite des enregistrements durables et infalsifiables plutôt que des wikis internes ou des feuilles de calcul.

Comment les horodatages cryptographiques comblent le déficit de provenance

La réponse technique au problème de documentation de la provenance est l'horodatage cryptographique appliqué au moment de l'acquisition des données et à chaque étape de traitement ultérieure.

En vertu de l'Article 41 du eIDAS Regulation, un horodatage électronique qualifié bénéficie d'une présomption légale d'exactitude de la date et de l'heure indiquées et de l'intégrité des données auxquelles il est lié. Il ne s'agit pas d'une affirmation commerciale — c'est une norme probatoire légale applicable dans tous les États membres de l'UE. Lorsque vous apposez un horodatage qualifié sur un ensemble de données au moment de son acquisition, vous créez un enregistrement légalement présumé authentique attestant que l'ensemble de données existait dans cet état exact à ce moment précis, indépendamment de toute réclamation ou contestation ultérieure.

Cela répond simultanément à trois des quatre catégories de documentation de l'Article 10 :

- Provenance et origine — l'horodatage établit quand l'ensemble de données a été acquis et, si le sceau inclut des métadonnées, à partir de quelle source

- Journaux de traitement — le scellement de l'ensemble de données après chaque étape de transformation crée un enregistrement horodaté de l'état de l'ensemble de données à chaque point du pipeline

- Intégrité des versions — toute modification ultérieure de l'ensemble de données invalide le hash cryptographique, rendant toute falsification détectable

De manière cruciale, l'ensemble de données lui-même n'a pas besoin d'être divulgué pour vérifier le sceau. La vérification est effectuée par rapport au hash cryptographique, et non aux données sous-jacentes — ce qui signifie que les enregistrements de provenance peuvent être partagés avec les régulateurs sans exposer les corpus d'entraînement commercialement sensibles ou les données à caractère personnel qu'ils peuvent contenir.

Pour la validité à long terme — essentielle compte tenu de l'obligation de conservation de la documentation pendant dix ans en vertu de l'Article 12 — les sceaux émis avec encodage Long-Term Validation (LTV) restent vérifiables de manière indépendante longtemps après l'expiration du certificat émetteur, la chaîne de validation complète étant intégrée dans le document scellé au moment de la signature.

Flux de travail pratique : Documenter l'acquisition d'ensembles de données avec Swiss Trust Layer

Swiss Trust Layer accompagne les entreprises d'IA dans le respect des exigences documentaires des Articles 10 et 12 grâce à des sceaux cryptographiques qualifiés émis via Swisscom Trust Services, un Qualified Trust Service Provider (QTSP) dans le cadre à la fois de ZertES (Suisse) et d'eIDAS (UE). Les sceaux bénéficient des présomptions légales de l'Article 41 d'eIDAS et sont recevables devant les tribunaux de toutes les juridictions européennes.

Un flux de travail pratique de documentation selon l'Article 10 utilisant Swiss Trust Layer fonctionne comme suit :

- Lors de l'acquisition — quand un ensemble de données ou un composant d'ensemble de données est ingéré, générez un hash cryptographique de l'ensemble de données et du fichier de métadonnées accompagnateur (qui enregistre la source, la date d'acquisition, la base juridique et les limitations connues). Scellez les deux via le flux de travail de scellement d'ensembles de données IA de Swiss Trust Layer. Le certificat résultant constitue le registre de provenance de ce composant d'ensemble de données.

- Après chaque étape de traitement — après déduplication, nettoyage, annotation ou augmentation synthétique, scellez l'ensemble de données transformé. La chaîne de versions scellées documente l'historique complet du traitement requis en vertu de l'Article 10(2)(c).

- Avant les cycles d'entraînement — scellez la configuration d'entraînement finale (manifeste de l'ensemble de données, hash des versions, sortie de l'évaluation des biais). Cela crée un enregistrement instantané de l'état exact des données utilisé pour chaque cycle d'entraînement, permettant la traçabilité au niveau du système requise en vertu de l'Article 12.

- Pour la divulgation réglementaire — partagez les certificats de sceau avec les autorités nationales compétentes sur demande. La vérification ne nécessite pas d'accès aux données sous-jacentes — seulement le certificat et le point de vérification public du service de vérification de Swiss Trust Layer.

Pour les entreprises ayant déjà publié du contenu généré par IA ou déployé des systèmes d'IA et devant établir rétrospectivement la provenance d'ensembles de données existants, le même flux de travail s'applique — avec la compréhension que les sceaux créés aujourd'hui établissent la provenance à partir d'aujourd'hui, non rétroactivement. Une mise en œuvre précoce est donc le choix opérationnellement judicieux.

Ce flux de travail intersecte également les exigences documentaires de propriété intellectuelle plus larges abordées dans notre article sur le contenu généré par IA et la protection de la propriété intellectuelle en droit européen — notamment pour les entreprises dont les corpus d'entraînement comprennent des données synthétiques qu'elles ont générées et souhaitent protéger en tant qu'actifs propriétaires.

Calendrier de mise en œuvre : quand les exigences s'appliquent

Le calendrier de mise en œuvre progressive de l'EU AI Act est fréquemment mal interprété. Les dates clés pour les entreprises d'IA sont :

- 1er août 2024 — Le Règlement est entré en vigueur. Les dispositions relatives aux pratiques interdites ont commencé à s'appliquer six mois plus tard (février 2025).

- 2 août 2025 — Les obligations relatives aux modèles GPAI en vertu de l'Article 53 s'appliquent. Les entreprises développant ou déployant des modèles d'IA à usage général doivent disposer d'une documentation technique en place à cette date.

- 2 août 2026 — Les obligations relatives aux systèmes d'IA à haut risque en vertu des Articles 10, 11 et 12 s'appliquent pleinement. Les fournisseurs et déployeurs de systèmes relevant des catégories de l'Annexe III doivent être en conformité.

- 2 août 2027 — Certains systèmes d'IA intégrés (systèmes à haut risque selon l'Article 6(1) déjà mis sur le marché dans le cadre d'autres législations européennes sur la sécurité des produits) bénéficient d'une période de transition supplémentaire.

La date limite d'août 2026 se situe à environ quatorze mois au moment de la rédaction de cet article. Pour les entreprises qui n'ont pas encore commencé à construire leur infrastructure de documentation selon l'Article 10, ce délai n'est pas confortable. Les processus de gouvernance des données ne s'implémentent pas en un sprint — ils nécessitent des modifications de pipeline, l'acquisition d'outils, un examen juridique des licences d'ensembles de données existants et, dans de nombreux cas, un audit rétrospectif de ce qui a été collecté et quand.

Les autorités nationales compétentes désignées en vertu de l'Article 70 n'ont pas encore développé de pratique d'application uniforme, mais le texte du Règlement est clair : la non-conformité aux exigences de documentation de l'Article 10 expose les fournisseurs à des amendes administratives pouvant atteindre EUR 15 millions ou 3 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu, en vertu de l'Article 99(3).

L'argument stratégique pour construire une infrastructure de provenance maintenant

Au-delà de la conformité réglementaire, il existe une dimension concurrentielle à la documentation de la provenance des ensembles de données que les entreprises d'IA tournées vers l'avenir commencent à reconnaître. À mesure que le contenu généré par IA et les modèles entraînés par IA deviennent des sujets de litiges de propriété intellectuelle — notamment dans les juridictions où les conflits de droits d'auteur sur les données d'entraînement sont activement plaidés — la capacité à prouver exactement sur quelles données vous avez entraîné, quand vous les avez acquises et sous quelle base juridique, devient un atout stratégique.

Les entreprises capables de produire des registres de provenance qualifiés et infalsifiables en réponse à une réclamation sur des données ou à une demande d'information d'un régulateur se trouveront dans une position fondamentalement plus solide que celles présentant des journaux reconstitués et des feuilles de calcul. Le coût de la construction de cette infrastructure avant qu'un litige survienne est une fraction du coût de défense d'une réclamation sans elle.

Les exigences de gouvernance des données de l'EU AI Act et le besoin commercial pratique de protection de la propriété intellectuelle des ensembles de données sont, à cet égard, parfaitement alignés. La conformité à l'Article 10 n'est pas un frais généraux — c'est le fondement d'un développement d'IA défendable.

Prochaines étapes pour votre entreprise d'IA

Si votre organisation développe, entraîne ou déploie des systèmes d'IA relevant des catégories à haut risque de l'EU AI Act — ou si vous fournissez des modèles d'IA à usage général soumis à l'Article 53 — les actions suivantes sont urgentes :

- Classez vos systèmes d'IA par rapport à l'Annexe III pour déterminer quels produits sont dans le périmètre d'août 2026

- Auditez votre documentation existante d'ensembles de données d'entraînement par rapport aux exigences de l'Article 10(2) — identifiez les lacunes en matière de provenance, de registres de biais et de journaux de traitement

- Établissez un protocole de scellement des ensembles de données pour toutes les nouvelles acquisitions et étapes de traitement à venir

- Faites appel à des conseils juridiques qualifiés pour examiner votre portefeuille de licences d'ensembles de données au regard des exigences de documentation des droits de l'Article 10(2)(b)

- Examinez les exigences de documentation technique de l'Annexe IV par rapport à vos pratiques documentaires actuelles

Le service de scellement de provenance des ensembles de données IA de Swiss Trust Layer soutient les étapes trois et cinq — en fournissant l'infrastructure cryptographique qualifiée pour la documentation horodatée et infalsifiable que les Articles 10 et 12 exigent. Les sceaux sont émis via Swisscom Trust Services sous eIDAS et ZertES, avec vérification indépendante disponible sur /compliance. La tarification commence à CHF 5 par document.

L'EU AI Act est une loi. L'horloge de documentation tourne. La question n'est pas de savoir si votre entreprise d'IA aura besoin de registres de provenance conformes à l'Article 10 — c'est de savoir si vous aurez construit l'infrastructure pour les produire avant l'arrivée de votre première demande réglementaire.