Conformité au règlement européen sur l'IA : documentation technique, journalisation, contrôle humain et gouvernance des données

Presque tout ce qui a été écrit sur l'AI Act porte sur le champ d'application : dans quelle catégorie de risque vous tombez, si vous êtes fournisseur ou déployeur, si votre système est visé par l'annexe III. Vos conseils juridiques répondent à cela.

Ce que presque personne n'aborde, c'est ce qui commence une fois la réponse connue. Si votre système est à haut risque, le règlement attend un système de gestion des risques qui vit tout au long du cycle de vie, une gouvernance des données que vous pouvez prouver, une journalisation automatique avec une durée de conservation définie, une documentation technique au format prescrit, un contrôle humain conçu et non affirmé, et une surveillance après commercialisation qui recueille effectivement quelque chose. Ce sont des livrables d'ingénierie. C'est cette partie-là que nous construisons.

Où en sont les échéances

Le règlement sur l'intelligence artificielle (AI Act, règlement (UE) 2024/1689) est entré en vigueur en août 2024 et s'applique par étapes. Le calendrier a changé en 2026, et il vaut la peine d'être précis, parce que ce changement a déplacé de l'argent et de l'attention.

• 2 février 2025 : application des pratiques interdites et des obligations de maîtrise de l'IA.
• 2 août 2025 : application des obligations relatives aux modèles d'IA à usage général.
• 2 août 2026 : application des obligations de transparence de l'article 50 : information de l'utilisateur qu'il interagit avec un système d'IA, marquage des contenus synthétiques, information en cas de reconnaissance des émotions et de catégorisation biométrique, et étiquetage des hypertrucages.
• 2 décembre 2027 : obligations relatives aux systèmes à haut risque autonomes, à la suite du Digital Omnibus. Le Conseil et le Parlement se sont accordés sur ce report en mai 2026, validé définitivement en juin 2026.
• 2 août 2028 : obligations relatives aux systèmes d'IA intégrés dans des produits réglementés.

Si vous êtes fournisseur d'un système à haut risque, le report vous a fait gagner environ seize mois. Il n'a pas réduit la charge de travail, et il n'a pas déplacé les deux obligations déjà en vigueur : la transparence au titre de l'article 50 et la maîtrise de l'IA pour les personnes qui exploitent ces systèmes.

Ce que nous construisons

La documentation technique, produite par la chaîne de build

L'annexe IV énumère ce que doit contenir la documentation technique : description du système, choix de conception, architecture, exigences relatives aux données, méthode d'entraînement le cas échéant, procédures de validation et de test, métriques, mesures de gestion des risques et modifications intervenues au fil du cycle de vie.

Rédigé à la main, ce document est périmé la semaine qui suit sa signature. Nous en faisons un artefact que votre pipeline produit : fiches de modèle et fiches de données générées à partir des exécutions d'entraînement et d'évaluation, descriptions d'architecture et de flux de données maintenues à côté du code, résultats d'évaluation rattachés à la version qu'ils décrivent, et historique des modifications issu de votre gestion de versions plutôt que de la mémoire de quelqu'un. Le document devient une sortie de build.

Une journalisation automatique conforme à l'article 12

Les systèmes à haut risque doivent enregistrer automatiquement des journaux tout au long de leur durée de vie, à un niveau permettant la traçabilité du fonctionnement et la surveillance après commercialisation, avec une conservation adaptée à la finalité, et dans certains cas d'au moins six mois.

En pratique, il faut décider ce qu'est un « événement » pour votre système, capter les entrées, les sorties, la version du modèle, le chemin de décision et l'identité de l'humain impliqué, stocker le tout sous une forme interrogeable des années plus tard, et le faire sans accumuler des données personnelles que rien ne vous autorise à conserver. Cette tension (journaliser assez pour l'AI Act, conserver assez peu pour le RGPD) est le véritable problème de conception, et nous le traitons explicitement avec vos responsables de la protection des données.

La gouvernance des données au titre de l'article 10

Les jeux de données d'entraînement, de validation et de test doivent être pertinents, suffisamment représentatifs et, dans toute la mesure du possible, exempts d'erreurs et complets, avec un examen des biais. Le respecter suppose une traçabilité des données démontrable, une provenance documentée, une méthodologie d'évaluation des biais assortie de résultats, et la capacité de reproduire quelles données ont produit quelle version du modèle.

Nous construisons la chaîne qui rend ces affirmations vérifiables plutôt que déclaratives : jeux de données versionnés, découpages reproductibles, contrôles automatisés de qualité des données et évaluation des biais sur les caractéristiques protégées pertinentes pour votre cas d'usage.

Un contrôle humain construit, et non déclaré

L'article 14 exige que les systèmes à haut risque soient conçus de façon qu'un humain puisse comprendre la sortie, rester conscient du biais d'automatisation, interpréter correctement le résultat, décider de ne pas l'utiliser, et intervenir ou arrêter le système.

C'est une spécification d'interface. Nous intégrons le contrôle dans le produit : confiance et incertitude affichées honnêtement, facteurs à l'origine d'une sortie rendus visibles, dérogation aussi simple d'usage que l'acceptation, commande d'arrêt qui fonctionne, et journalisation de chaque dérogation pour que la surveillance après commercialisation ait matière à apprendre.

Surveillance après commercialisation et signalement d'incidents

Un plan de surveillance est requis, tout comme le signalement des incidents graves à l'autorité compétente. Nous construisons la télémétrie qui l'alimente : performance suivie au regard des métriques figurant dans votre documentation, détection de dérive sur les entrées et les sorties, canal de remontée des problèmes signalés par les utilisateurs qui atteint réellement l'ingénierie, et processus d'incident dont les délais réglementaires sont intégrés d'avance plutôt que découverts pendant.

Les obligations de transparence de l'article 50

Déjà en vigueur. Information de l'utilisateur qu'il a affaire à un système d'IA, marquage lisible par machine des contenus synthétiques audio, image, vidéo et texte, étiquetage des hypertrucages, et information en cas de reconnaissance des émotions. Nous mettons en place les surfaces d'information et le marquage de provenance des contenus (les identifiants de contenu C2PA lorsque c'est le bon mécanisme), et faisons en sorte qu'ils survivent aux chaînes d'export et de réencodage qui, d'ordinaire, les effacent.

Appui à l'enregistrement et à l'évaluation de la conformité

Les systèmes à haut risque relevant des domaines de l'annexe III doivent être enregistrés dans la base de données de l'UE avant leur mise sur le marché, et les fournisseurs doivent conduire une évaluation de la conformité. Nous préparons les éléments techniques (documentation, dossier de preuves, artefacts du système de management de la qualité côté ingénierie), et travaillons aux côtés de votre organisme notifié ou de votre processus d'évaluation interne.

Ce que nous ne faisons pas

Nous ne fournissons pas de conseil juridique et nous ne vous dirons pas dans quelle catégorie de risque se situe votre système. Cette qualification est juridique, ses conséquences sont réelles, et elle appartient à un avocat ou à un conseil en conformité qualifié.

Nous ne vendons pas non plus de plateforme de gouvernance de l'IA. Il en existe beaucoup, et si votre besoin est un registre des systèmes d'IA assorti d'un circuit de validation des politiques, l'une d'elles vous servira mieux que nous. Notre métier, c'est l'ingénierie à l'intérieur des systèmes eux-mêmes.

À qui cela s'adresse

Aux fournisseurs de systèmes d'IA à haut risque au sens de l'annexe III (recrutement et gestion des travailleurs, scoring de crédit, tarification en assurance, évaluation en éducation, accès aux services essentiels, systèmes biométriques), qui disposent désormais de décembre 2027 et d'un programme chargé.

Aux fabricants qui intègrent de l'IA dans des produits réglementés (dispositifs médicaux, machines, véhicules), où l'AI Act se superpose à un régime de conformité existant et où les deux corpus documentaires doivent concorder.

Aux entreprises qui déploient des systèmes à haut risque achetés à un tiers, porteuses de leurs propres obligations : contrôle humain, pertinence des données d'entrée, surveillance et conservation des journaux.

À toute organisation qui livre des fonctionnalités génératives à des utilisateurs européens, la transparence de l'article 50 s'appliquant déjà aujourd'hui, quelle que soit la catégorie de risque.

Déroulement des missions

Évaluation technique des écarts, deux à quatre semaines. Nous partons de la qualification retenue par votre équipe juridique et confrontons vos systèmes aux obligations d'ingénierie qui en découlent. Le livrable est un registre d'écarts (obligation, état actuel, ce qu'il faut construire, charge) exploitable aussi bien par vos responsables conformité que par vos responsables techniques.

Réalisation, par phases, en commençant généralement par la journalisation et la génération de documentation, puisque tout le reste produit des preuves qui doivent bien atterrir quelque part.

Revue de préparation en amont de l'évaluation de la conformité, avec le dossier de preuves constitué et les écarts restants nommés sans complaisance.

Normes et référentiels

Règlement (UE) 2024/1689 et ses annexes III et IV ; les normes harmonisées issues du CEN/CENELEC JTC 21 ; ISO/IEC 42001 pour les systèmes de management de l'IA et ISO/IEC 23894 pour la gestion des risques liés à l'IA ; le NIST AI Risk Management Framework lorsqu'une maison mère américaine réclame un alignement ; et le RGPD, qui ne disparaît pas et qui contraint la plupart des décisions de journalisation.

Questions fréquentes

L'AI Act a-t-il été reporté ?

En partie. Le Digital Omnibus a reporté les obligations relatives aux systèmes à haut risque au 2 décembre 2027 pour les systèmes autonomes et au 2 août 2028 pour l'IA intégrée dans des produits réglementés. Les pratiques interdites, la maîtrise de l'IA, les obligations relatives aux modèles d'IA à usage général et les règles de transparence de l'article 50 n'ont pas été reportées et sont en vigueur aujourd'hui.

Nous utilisons uniquement des systèmes d'IA construits par d'autres. Avons-nous des obligations ?

Oui, en tant que déployeur. Elles couvrent l'exploitation du système conformément à sa notice, l'attribution du contrôle humain à des personnes ayant la compétence et l'autorité de l'exercer, la vérification que les données d'entrée sont pertinentes au regard de la destination, la surveillance du fonctionnement et la conservation des journaux. Plus légères que celles d'un fournisseur, mais bien réelles, et notez que modifier substantiellement un système ou y apposer votre nom peut faire de vous un fournisseur.

Notre système n'est pas à haut risque. Y a-t-il tout de même quelque chose à faire ?

Probablement deux choses. La transparence de l'article 50 s'applique à certains systèmes indépendamment de la catégorie de risque, notamment aux agents conversationnels et à la génération de contenus synthétiques. Et la maîtrise de l'IA au titre de l'article 4 s'applique aux fournisseurs comme aux déployeurs, de façon générale. Au-delà, pouvoir justifier la décision de qualification est utile si un régulateur pose un jour la question.

La documentation technique peut-elle réellement être générée ?

Pour l'essentiel, oui. L'architecture, la description des jeux de données, les résultats d'évaluation, les métriques, les versions de modèle et l'historique des modifications existent déjà dans vos systèmes ; le travail consiste à les capter dans une structure stable au moment du build. Les sections véritablement rédactionnelles (destination, analyse de risques, justification des choix de conception) sont écrites par des humains, puis conservées dans le même dépôt afin d'être versionnées avec le reste.

Comment l'AI Act s'articule-t-il avec le RGPD ?

Ils se recouvrent et tirent parfois en sens inverse, en particulier sur la journalisation. L'AI Act veut de la traçabilité ; le RGPD veut de la minimisation et de l'effacement. La résolution passe habituellement par la pseudonymisation, un cadrage soigneux de ce qui est journalisé et une durée de conservation définie, rattachée à une finalité documentée. C'est une décision de conception, prise une fois, délibérément.

Utiliser le modèle d'un tiers fait-il de nous le fournisseur de ce modèle ?

Non, mais construire un système d'IA au-dessus peut faire de vous le fournisseur de ce système, avec les obligations attachées. Où passe exactement la ligne dépend de ce que vous construisez et de la manière dont vous le présentez, ce qui est une question juridique : la conséquence technique, elle, est que vous devez partir du principe qu'il vous faudra une documentation de votre propre système dans tous les cas.

Commencer

Dites-nous ce que font vos systèmes et où vos conseils juridiques ont abouti sur la qualification. Nous évaluerons ce que les obligations signifient dans le code et vous remettrons un registre d'écarts avec une charge en face de chaque ligne.

Contactez-nous pour convenir d'une évaluation technique des écarts AI Act.

Services associés

• Développement d'agents IA et intégration MCP : la construction des systèmes que ce régime encadre
• Développement Entrée Marché UE : la pile plus large de conformité numérique européenne
• Remédiation de l'accessibilité web : l'autre obligation européenne qui se révèle être un projet d'ingénierie