K-AI
FREN
Demander une démo
SolutionComment ça marcheImpactActualitésPartenaires
FREN
Demander une démo
← Toutes les actualités
Presse · 6 juillet 2026 · 12 min de lecture

AI Act Article 10 : ce que la gouvernance des données exige de votre corpus documentaire

AI Act Article 10 : ce que la gouvernance des données exige de votre corpus documentaire

Le Conseil UE a adopté le Digital Omnibus le 29 juin. L'Article 10 sur la gouvernance des données reste intact : ce qu'il exige d'un corpus RAG d'entreprise.

Le 29 juin 2026, le Conseil de l’Union européenne a donné son feu vert final et formel au Digital Omnibus sur l’IA, deux semaines après son adoption par le Parlement européen le 16 juin (423 voix pour, 57 contre, 174 abstentions) (NicFab, Licentium). Le texte verrouille désormais le report des obligations liées aux systèmes à haut risque autonomes de l’Annexe III au 2 décembre 2027, et de celles intégrées dans des produits régulés de l’Annexe I au 2 août 2028. Publication au Journal officiel attendue dans les prochaines semaines, avant l’échéance du 2 août 2026.

Ce feu vert clôt trois mois de bras de fer institutionnel. Il ne touche en rien à un article que la couverture médiatique du Digital Omnibus mentionne à peine : l’Article 10 sur la gouvernance des données d’entraînement, de validation et de test. Ni le report de l’Annexe III, ni celui de l’Annexe I ne modifient son contenu. Et contrairement à une idée reçue chez les équipes qui pilotent des systèmes RAG plutôt que des modèles entraînés en interne, cet article ne les laisse pas totalement hors champ.

Ce que le 29 juin change — et ce qu’il ne change pas

Le Digital Omnibus règle une question de calendrier, pas de contenu. Les obligations de la Section 2 du Chapitre III de l’AI Act — gestion des risques (Article 9), gouvernance des données (Article 10), documentation technique (Article 11), tenue de registres (Article 12), transparence envers les déployeurs (Article 13), supervision humaine (Article 14), robustesse et cybersécurité (Article 15) — ne sont pas réécrites. Ce que le texte déplace, c’est la date à laquelle un système classé à haut risque au titre de l’Annexe III doit s’y conformer : du 2 août 2026 au 2 décembre 2027.

K-AI a déjà détaillé, dans une note du 1er juin, ce qui reste exigible dès le 2 août 2026 pour les systèmes haut-risque déjà en service — Annexe IV, Article 12, Article 26 (lire l’article) — et, le 24 juin, ce que l’Article 50 sur la transparence exige spécifiquement des chatbots internes (lire l’article). L’Article 10 est un troisième bloc, distinct des deux premiers : il ne porte pas sur la documentation du système (Annexe IV) ni sur la transparence envers l’utilisateur final (Article 50), mais sur la donnée elle-même — sa collecte, sa préparation, sa représentativité, ses biais. C’est un terrain que ni la couverture juridique généraliste, ni les 26 acteurs du marché DKP et Enterprise Search que nous avons passés en revue cette semaine, ne nomment explicitement.

Ce que l’Article 10 exige réellement de vos jeux de données

Le texte officiel de l’Article 10 impose que les jeux de données d’entraînement, de validation et de test d’un système à haut risque soient soumis à des pratiques de gouvernance couvrant huit points précis (texte officiel — Article 10) : les choix de conception, les processus de collecte et l’origine des données, les opérations de préparation (annotation, étiquetage, nettoyage, mise à jour, enrichissement, agrégation), la formulation des hypothèses sur ce que les données sont censées mesurer, l’évaluation de la disponibilité et de l’adéquation des jeux de données, l’examen des biais susceptibles d’affecter la santé, la sécurité ou les droits fondamentaux, les mesures de correction de ces biais, et l’identification des lacunes ou manques empêchant la conformité.

Traduit en langage de gouvernance documentaire, ce que demande l’Article 10 ressemble beaucoup à un audit de corpus : d’où viennent les documents qui nourrissent le système, sous quelle forme ont-ils été nettoyés ou normalisés avant d’être ingérés, quelles hypothèses ont été faites sur leur fraîcheur et leur exhaustivité, quels segments du corpus sont sur- ou sous-représentés, et quels manques ont été identifiés sans être comblés. L’Article 10(3) ajoute une exigence de fond : les jeux de données doivent être « pertinents, suffisamment représentatifs et, dans la mesure du possible, exempts d’erreurs et complets au regard de la finalité prévue ». Un corpus documentaire d’entreprise truffé de doublons divergents, de politiques obsolètes non marquées comme telles ou de zones métier entières non couvertes ne satisfait pas cette exigence — indépendamment de la performance apparente du système qui s’appuie dessus.

Le cas non tranché : votre RAG est-il vraiment concerné ?

C’est ici que se loge la question la plus utile pour un DSI ou un CTO qui déploie un système RAG plutôt qu’un modèle entraîné en interne. L’Article 10(6) prévoit un régime distinct : « pour le développement de systèmes d’IA à haut risque n’utilisant pas de techniques impliquant l’entraînement de modèles d’IA avec des données, les paragraphes 2 à 5 s’appliquent uniquement aux jeux de données de test » (texte officiel — Article 10(6)).

La majorité des déploiements RAG d’entreprise s’appuient sur un modèle de fondation pré-entraîné, non fine-tuné sur le corpus interne. Sur le papier, cela allège la portée de l’Article 10 : les points (a) à (h) ne s’imposent pas à l’ensemble du corpus documentaire mobilisé au moment de la génération, mais spécifiquement au jeu de données utilisé pour tester la performance du système avant sa mise en production, puis à chaque évolution significative. En pratique, la ligne de partage est loin d’être triviale à tracer : si le corpus documentaire sert aussi à évaluer la précision du retrieval, à mesurer le taux de réponses correctement sourcées, ou à qualifier le système avant un changement de version, il devient de facto un jeu de données de test au sens de l’Article 10(6) — et retombe donc sous les exigences de représentativité, d’absence d’erreurs et de détection de biais des paragraphes 2 à 5. Aucun des 26 acteurs du marché DKP, Enterprise Search et gouvernance des données que nous avons passés en revue cette semaine — Glean, Sinequa, Squirro, Unstructured.io, Collibra, Atlan compris — ne formalise cette distinction entre corpus de génération et jeu de données de test au sens de l’Article 10(6).

Ce que révèle une lecture de 26 acteurs du marché

Squirro a publié le 22 juin un article détaillé sur la défendabilité réglementaire d’un déploiement IA face à un régulateur, insistant sur la nécessité de tracer les permissions, les documents récupérés et les décisions humaines à chaque requête (Squirro — AI Audit Trails) — un terrain proche, mais centré sur la traçabilité en production plutôt que sur la gouvernance amont des données qui alimentent le système. Les acteurs de la gouvernance des données structurées — Collibra, Alation, Atlan — publient des guides de conformité IA qui traitent la question au niveau du modèle (registre, fiches modèle, classification du risque) ou du jeu de données structuré (lignage, qualité, provenance), mais aucun ne descend au niveau du document non structuré individuel — PDF, page Confluence, e-mail archivé — qui constitue la matière première d’un RAG d’entreprise.

Cette absence n’est pas un oubli isolé : elle reflète une segmentation persistante du marché entre gouvernance du modèle, gouvernance de la donnée structurée, et outillage RAG en production. L’Article 10, dans son texte, ne fait aucune de ces distinctions — il parle de « jeux de données », un terme suffisamment large pour couvrir un corpus documentaire non structuré dès lors qu’il sert, même partiellement, à entraîner, valider ou tester un système à haut risque.

De la donnée d’entraînement à la preuve de conformité

Un audit de corpus documentaire, pour répondre aux exigences de l’Article 10, doit produire des éléments précis et datés, pas une impression générale de qualité. Concrètement : une cartographie de la provenance des documents (auteur, source de vérité, date de validation), un inventaire des opérations de préparation appliquées (déduplication, normalisation, chunking, annotation), une évaluation de la représentativité par segment métier ou géographique, un registre des biais identifiés — un corpus RH qui surreprésente une entité, une politique interne qui n’existe qu’en version obsolète dans une langue et à jour dans une autre — et un journal des lacunes documentées, même non résolues.

K-AI a publié le détail opérationnel de cette démarche dans deux notes antérieures : la méthode d’audit en six axes du 15 mai (anomalies internes, conflits inter-documents, doublons divergents, obsolescence, traçabilité, fraîcheur — lire l’article) et la grille de diagnostic rapide du 29 juin pour prioriser les efforts (lire l’article). Ces deux méthodes couvrent la matière que l’Article 10 exige de documenter ; ce qui change avec la lecture de l’article cette semaine, c’est le cadrage réglementaire précis qui en fait, pour un système classé à haut risque, une obligation et non plus une bonne pratique.

Pourquoi le report du calendrier ne change rien à l’urgence de commencer

Le report de l’Annexe III à décembre 2027 retire une pression immédiate sur la classification du risque, pas sur la préparation. Un système RAG qui basculera dans le périmètre haut-risque d’ici cette échéance — recrutement, scoring, accès à des services essentiels — devra présenter un historique de gouvernance des données, pas une action ponctuelle réalisée à la veille de l’audit de conformité. L’Article 10(2) demande de documenter des processus, pas un instantané : la manière dont les données ont été collectées, préparées et corrigées dans la durée. Un corpus documentaire mis en ordre en trente jours à l’approche d’une échéance ne produit pas cet historique ; un corpus sous monitoring continu depuis dix-huit mois le produit naturellement.

Les sanctions applicables restent, elles, inchangées par le Digital Omnibus : le non-respect des obligations des fournisseurs au titre de l’Article 16 — qui inclut la conformité à l’Article 10 — expose à une amende administrative pouvant atteindre 15 millions d’euros ou 3 % du chiffre d’affaires mondial annuel, le montant le plus élevé étant retenu (texte officiel — Article 99§4). Les PME et jeunes pousses bénéficient d’un plafond réduit au montant le plus bas des deux seuils.

Foire aux questions

Que doit contenir la documentation exigée par l’Article 10 de l’AI Act pour un système IA à haut risque ?

L’Article 10(2) exige de documenter huit éléments pour chaque jeu de données d’entraînement, de validation et de test : les choix de conception, les processus de collecte et l’origine des données, les opérations de préparation (annotation, nettoyage, mise à jour, enrichissement), les hypothèses formulées sur ce que les données représentent, l’évaluation de leur disponibilité et adéquation, l’examen des biais possibles, les mesures de correction de ces biais, et l’identification des lacunes empêchant la conformité. L’Article 10(3) ajoute une exigence de fond : les données doivent être pertinentes, représentatives, autant que possible exemptes d’erreurs, et complètes au regard de l’usage prévu.

Un corpus documentaire RAG (SharePoint, Confluence, GED) est-il concerné par l’Article 10 s’il n’entraîne pas de modèle ?

Partiellement, selon l’Article 10(6). Si le système à haut risque n’entraîne pas de modèle sur ce corpus, les exigences de gouvernance des paragraphes 2 à 5 ne s’appliquent qu’au jeu de données utilisé pour tester le système. En pratique, dès que le corpus sert aussi à évaluer la précision du retrieval ou à qualifier une nouvelle version avant mise en production, il entre dans le périmètre de cette obligation de test — ce qui couvre une large partie des usages réels d’un RAG d’entreprise.

Quelle différence entre les obligations de l’Article 10 et celles de l’Annexe IV ?

L’Article 10 porte sur la gouvernance de la donnée elle-même : collecte, préparation, représentativité, biais. L’Annexe IV, référencée par l’Article 11, porte sur la documentation technique du système dans son ensemble — description générale, spécifications de conception, gestion des risques, surveillance post-commercialisation. Un système peut avoir une documentation Annexe IV complète sans que la gouvernance des données sous-jacente au sens de l’Article 10 soit démontrée : ce sont deux obligations complémentaires, pas interchangeables.

Le Digital Omnibus adopté le 29 juin 2026 repousse-t-il aussi l’Article 10 ?

Non. Le Digital Omnibus reporte l’échéance de mise en conformité des systèmes classés à haut risque au titre de l’Annexe III (2 décembre 2027) et de l’Annexe I (2 août 2028). Il ne modifie ni le texte ni le contenu de l’Article 10 : une fois qu’un système entre dans le périmètre haut-risque, à quelque date que ce soit, les obligations de gouvernance des données s’appliquent dans leur intégralité.

Quelles sanctions en cas de non-conformité à l’Article 10 ?

Le non-respect des obligations des fournisseurs au titre de l’Article 16 de l’AI Act — qui couvre la conformité à l’Article 10 sur la gouvernance des données — est sanctionné, selon l’Article 99§4, d’une amende administrative pouvant atteindre 15 millions d’euros ou 3 % du chiffre d’affaires mondial annuel de l’exercice précédent, le montant le plus élevé étant retenu. Les PME et jeunes pousses se voient appliquer le montant le plus bas des deux seuils.

Pour aller plus loin

L’Article 10 déplace la question de la conformité documentaire d’un exercice de bonne volonté vers une obligation de gouvernance datée et vérifiable. Pour évaluer où se situe votre corpus documentaire au regard de ces huit points — collecte, préparation, représentativité, biais, lacunes — l’équipe K-AI peut échanger avec vous sur un premier diagnostic. Contact : contact@k-ai.ai.

K-AI accompagne déjà CMA CGM, Veolia, PwC, BNP Paribas, TotalEnergies et CEVA Logistics. Partenaires : AWS, Snowflake, Microsoft, Wavestone, Devoteam.

Sur le même sujet

Sources citées

Et chez vous, quel est votre patrimoine documentaire ?

30 minutes avec un fondateur. On audite gratuitement un échantillon de vos documents et on vous montre exactement ce que K-AI détecte.

Demander une démo → Lire d’autres articles