Guide de l'enregistrement au titre du règlement européen sur l'IA : article 49, article 71 et annexe VIII

Calendrier : l'enregistrement s'applique à partir du 2 décembre 2027¶

Le Digital Omnibus sur l'IA est adopté. Le Parlement européen a approuvé le texte convenu le 16 juin 2026 et le Conseil l'a adopté le 29 juin 2026 ; le règlement modificatif, le règlement (UE) 2026/1744, a été publié au Journal officiel le 24 juillet 2026 et entre en vigueur le 27 juillet 2026. Il reporte les règles applicables aux systèmes d'IA à haut risque autonomes de l'annexe III au 2 décembre 2027 et celles applicables à l'IA à haut risque intégrée dans des produits au 2 août 2028. L'enregistrement prévu à l'article 49 et la base de données de l'article 71 suivent la date de l'annexe III.

La Commission avait proposé de supprimer l'obligation, prévue à l'article 49, paragraphe 2, d'enregistrer les systèmes de l'annexe III qu'un fournisseur auto-évalue comme n'étant pas à haut risque au titre de l'article 6, paragraphe 3. Le Parlement et le Conseil ont rejeté cette suppression et maintenu l'obligation, avec un contenu allégé : les points 7 et 9 de la section B de l'annexe VIII sont supprimés, ce qui retire le bref résumé des motifs de la détermination au titre de l'article 6, paragraphe 3, et la liste des États membres dans lesquels le système a été mis à disposition. Le point 6 demeure, de sorte que le fournisseur continue d'indiquer la condition de l'article 6, paragraphe 3, sur laquelle il s'appuie. Les équipes conformité doivent vérifier le texte du Journal officiel avant de s'appuyer sur une date.

La conclusion pratique est simple : n'attendez ni le portail ni l'échéance finale. Les données exigées par l'annexe VIII dépendent de travaux de gouvernance en amont qui prennent des mois à rassembler.

À quoi sert l'enregistrement prévu à l'article 49¶

L'article 49 porte sur l'enregistrement de certains systèmes d'IA avant leur mise sur le marché, leur mise en service ou leur utilisation. Il s'applique principalement aux systèmes d'IA énumérés à l'annexe III, c'est-à-dire les cas d'usage à haut risque autonomes : biométrie, infrastructures critiques, éducation, emploi, services essentiels, activités répressives, migration et contrôle aux frontières, administration de la justice et processus démocratiques.

Le régime d'enregistrement est lié à la classification à haut risque prévue à l'article 6. Un système peut être à haut risque parce qu'il constitue un produit ou un composant de sécurité couvert par la législation de l'annexe I et soumis à une évaluation de la conformité par un tiers, ou parce qu'il relève d'un cas d'usage de l'annexe III. L'article 6, paragraphe 3, ouvre aussi une voie étroite permettant de considérer certains systèmes de l'annexe III comme n'étant pas à haut risque, mais le profilage de personnes physiques reste à haut risque.

L'enregistrement n'est donc pas un simple exercice de divulgation. Il constitue l'aboutissement, public ou à destination du régulateur, d'une décision de classification.

Ce que prévoit l'article 71¶

L'article 71 établit la base de données de l'UE pour les systèmes d'IA à haut risque énumérés à l'annexe III. La Commission, en collaboration avec les États membres, doit la mettre en place et la tenir à jour. La base contient les systèmes à haut risque enregistrés au titre des articles 49 et 60, ainsi que les systèmes que les fournisseurs considèrent comme n'étant pas à haut risque au titre de l'article 6, paragraphe 3, mais qui doivent tout de même être enregistrés au titre de l'article 49.

L'article 71 répartit la responsabilité de la saisie entre les fournisseurs et certains déployeurs. Les fournisseurs ou leurs mandataires renseignent les sections A et B de l'annexe VIII. Les déployeurs qui sont des autorités publiques, des institutions, organes ou organismes de l'UE, ou des personnes agissant pour leur compte, renseignent la section C.

Par défaut, l'article 71 prévoit que les informations de la base de données visées à l'article 49 doivent être accessibles au public, conviviales, faciles à consulter et lisibles par machine, à l'exception des sections restreintes, telles que les cas d'usage sensibles liés aux activités répressives et à la migration.

L'enregistrement ne se confond pas avec la documentation technique¶

Ne confondez pas les données d'enregistrement de l'annexe VIII avec la documentation technique de l'annexe IV. L'annexe VIII correspond à l'entrée dans la base de données publique ou réglementaire. Elle contient des informations concises d'identification, de statut, de finalité, de conformité et d'utilisation par le déployeur. L'annexe IV est le dossier de documentation technique approfondi : description du système, processus de développement, architecture, exigences en matière de données, contrôle humain, validation et tests, cybersécurité, gestion des risques, modifications au cours du cycle de vie, normes, déclaration de conformité et plan de surveillance après commercialisation.

Les deux doivent être reliés, mais ce n'est pas le même artefact. L'annexe IV est le dossier de conformité détaillé. L'annexe VIII est le contenu de l'enregistrement. L'article 49 est le déclencheur juridique. L'article 71 est le mécanisme de base de données. Votre registre interne des systèmes d'IA est le système de référence qui doit produire et étayer l'ensemble de ces éléments.

Qui doit s'enregistrer ?¶

La réponse dépend du rôle, de la classification, du point de l'annexe III concerné et du contexte de déploiement. L'enregistrement par le seul éditeur peut ne pas suffire si une organisation du secteur public déploie le système. Une conclusion d'absence de haut risque au titre de l'article 6, paragraphe 3, peut aussi créer sa propre trace d'enregistrement.

Ce que l'annexe VIII exige des fournisseurs et des déployeurs¶

L'annexe VIII n'est pas une liste interminable, mais ses champs sont lourds de conséquences. La finalité prévue, la logique de fonctionnement, le statut, le certificat, la déclaration UE de conformité, la notice d'utilisation et la disponibilité dans les États membres dépendent tous de travaux de gouvernance en amont.

Si votre finalité prévue est vague, votre enregistrement sera vague. Si la gestion des versions du produit est faible, la traçabilité sera faible. Si la documentation de conformité n'est pas rattachée à chaque version livrée, l'équipe peut ne pas savoir quelle déclaration correspond à quelle version du système.

L'arbre de décision pratique de l'article 49¶

Partez du système, pas de l'éditeur. L'enregistrement dépend de la classification et de l'utilisation, et non de la manière dont le produit est commercialisé : plateforme, assistant, surcouche de modèle, copilote ou agent.

Une revue d'aiguillage pratique doit répondre à huit questions : le système entre-t-il dans le champ d'application ; l'article 6, paragraphe 1, s'applique-t-il ; l'annexe III s'applique-t-elle ; l'article 6, paragraphe 3, est-il invoqué ; le point 2 de l'annexe III renvoie-t-il vers un enregistrement national ; les sections restreintes s'appliquent-elles ; le déployeur est-il une autorité publique ou agit-il pour le compte d'une telle autorité ; et l'équipe peut-elle tenir l'enregistrement à jour.

• Si le système est hors du champ du règlement, consignez la justification et arrêtez-vous là.
• Si l'article 6, paragraphe 1, s'applique, confirmez les implications au titre de la législation sectorielle sur les produits et en matière d'enregistrement.
• Si l'annexe III ne s'applique pas, l'enregistrement dans la base de données de l'UE au titre de l'article 49 peut ne pas s'appliquer ; conservez la fiche de classification.
• Si l'annexe III s'applique et que le système est à haut risque, préparez l'enregistrement du fournisseur au titre de l'article 49, paragraphe 1.
• Si l'annexe III s'applique et que le fournisseur s'appuie sur l'article 6, paragraphe 3, préparez l'enregistrement au titre de l'article 49, paragraphe 2, et conservez la justification documentée dans vos dossiers, même si la section B de l'annexe VIII ne vous demande plus de la soumettre.
• Si le point 2 de l'annexe III s'applique, vérifiez la voie d'enregistrement nationale.
• Si les points 1, 6 ou 7 de l'annexe III s'appliquent dans des contextes sensibles d'activités répressives ou de contrôle aux frontières, vérifiez la section sécurisée non publique.
• Si le déployeur est une autorité publique ou agit pour le compte d'une telle autorité, préparez la fiche d'utilisation du déployeur de la section C.

Ce qu'il faut préparer avant l'enregistrement¶

Un processus d'enregistrement solide commence bien avant la soumission dans la base de données. Constituez d'abord le dossier interne, puis générez le contenu de l'enregistrement à partir de la fiche gouvernée.

Utilisez un modèle de données interne versionné¶

Une fiche de système d'IA prête pour l'enregistrement doit être versionnée, attribuée à un propriétaire, revue et reliée à l'utilisation réelle à l'exécution. Le schéma exact peut varier, mais il doit relier l'identité, la classification, la finalité prévue, les fonctions prises en charge, les entrées, la logique de fonctionnement, le statut sur le marché, les preuves de conformité et la voie d'enregistrement.

Pour les déployeurs qui sont des autorités publiques, ajoutez une fiche d'utilisation du déployeur comprenant l'URL de l'entrée du fournisseur dans la base de données, le contexte d'utilisation, le résumé de la FRIA, le résumé de l'AIPD le cas échéant et le statut de la soumission. Le fournisseur peut être propriétaire de l'entrée du système, mais le déployeur est propriétaire du contexte d'utilisation.

Enregistrement et gestion des changements¶

L'annexe VIII exige que les informations soumises soient tenues à jour. Cela soulève une question opérationnelle : quels changements nécessitent une revue ou une mise à jour ? L'équipe conformité ne doit pas découvrir un changement pertinent pour l'enregistrement après le déploiement en production.

Intégrez la revue de l'enregistrement à la gestion des mises en production, aux changements de modèle, aux lancements dans de nouveaux pays, aux changements de nom du produit, aux mises à jour de certificats, aux modifications de la notice d'utilisation et aux extensions de Process.

• La finalité prévue change ou le système commence à traiter de nouvelles catégories d'entrées.
• Le système est lancé dans un nouvel État membre ou passe de la phase de test à la mise en service.
• Le système est retiré, rappelé ou n'est plus proposé.
• Le nom commercial, le fournisseur ou le mandataire change.
• La logique de fonctionnement change de manière substantielle ou le système devient un Process agentique.
• Le système commence à profiler des personnes physiques ou la justification au titre de l'article 6, paragraphe 3, change.
• Un certificat est délivré, mis à jour, suspendu ou arrive à expiration.
• Un déploiement par une autorité publique commence, s'arrête ou change de contexte.
• Une FRIA, une AIPD ou la notice d'utilisation est mise à jour.

L'enregistrement des agents IA et des copilotes¶

L'article 49 n'a pas été rédigé uniquement pour des produits d'apprentissage automatique statiques. Il s'applique en fonction de la classification juridique, de la finalité prévue et du contexte d'utilisation. Un copilote de productivité interne peut ne pas être à haut risque, mais la même architecture utilisée pour présélectionner des candidats, noter des étudiants, trier des appels d'urgence, évaluer l'éligibilité à des prestations ou appuyer des activités répressives peut relever de l'annexe III.

Un agent ajoute une couche supplémentaire. Il peut appeler des outils, récupérer des données, mettre à jour des enregistrements, aiguiller des dossiers, recommander des actions ou déclencher des Process. Cela peut modifier la finalité prévue et l'influence substantielle du système.

• Tenez un inventaire des outils et un inventaire des actions.
• Consignez les points d'approbation humaine et l'analyse de l'influence sur les décisions.
• Cartographiez les personnes concernées, la traçabilité des entrées et des sorties, les contrôles de politique à l'exécution et les voies d'escalade.
• Versionnez la notice d'utilisation et surveillez la dérive par rapport à la finalité prévue enregistrée.
• Évitez les formulations génériques de finalité prévue telles que « assistant IA pour la gestion de dossiers » lorsque le système trie en réalité des réclamations, rédige des conclusions juridiques ou aiguille des dossiers à haut risque.

Ce que les régulateurs et le public peuvent apprendre de la base de données¶

L'article 71 prévoit que les informations de la base de données visées à l'article 49 doivent en général être accessibles au public, conviviales, faciles à consulter et lisibles par machine, à l'exception des sections restreintes. L'enregistrement devient donc une composante de la confiance du public.

Les fournisseurs peuvent ainsi rendre visibles qui fournit le système, son nom, sa finalité prévue, les fonctions prises en charge, une description générale des données et des entrées, les lieux où il est disponible, s'il est sur le marché ou rappelé, si des documents de conformité existent et comment les déployeurs peuvent accéder à la notice d'utilisation. Les déployeurs qui sont des autorités publiques peuvent rendre visibles quelle autorité utilise le système, quel système de fournisseur est utilisé et les résumés des conclusions de la FRIA et de l'AIPD.

Les résumés de l'annexe VIII doivent être exacts, clairs et défendables. Ils ne doivent pas divulguer inutilement des secrets d'affaires, mais ils ne doivent pas non plus être vagues au point de nuire à la confiance.

Erreurs courantes¶

Les erreurs récurrentes ne viennent pas d'une annexe VIII trop longue. Elles surviennent lorsque les équipes traitent l'enregistrement comme une formalité juridique plutôt que comme un produit du travail des équipes produit, ingénierie, protection des données, sécurité et conformité, du contexte de déploiement et des preuves d'exécution.

Dossier de preuves minimal pour l'enregistrement au titre de l'article 49¶

Avant de soumettre ou d'approuver un enregistrement, constituez un dossier de preuves exportable. La personne qui soumet l'entrée dans la base de données de l'UE ne devrait pas avoir à solliciter cinq équipes pour renseigner un seul champ de l'annexe VIII.

• Fiche d'inventaire du système d'IA, analyse des rôles de fournisseur et de déployeur, évaluation de classification au titre de l'article 6 et correspondance avec l'annexe III.
• Évaluation concluant à l'absence de haut risque au titre de l'article 6, paragraphe 3, le cas échéant.
• Déclaration de finalité prévue, version du système, fiche de version, fiche de statut, liste de disponibilité par État membre, description générale des données et des entrées, résumé de la logique de fonctionnement et fonctions prises en charge.
• Déclaration UE de conformité, détails du certificat de l'organisme notifié le cas échéant, notice d'utilisation électronique et URL d'information publique si utilisée.
• Résumé de la FRIA et résumé de l'AIPD lorsque la section C relative aux déployeurs s'applique.
• Fiche d'approbation, liste des déclencheurs de gestion des changements et responsable nommé pour tenir l'enregistrement à jour.

Comment KLA opérationnaliserait cela¶

Le problème central n'est pas que l'annexe VIII comporte trop de champs. Ce n'est pas le cas. Le problème est que chaque champ renvoie à un contrôle qui doit rester vrai dans le temps.

KLA devrait faire de l'enregistrement un produit gouverné du plan de contrôle de l'IA : tenir un inventaire canonique, relier chaque système à l'article 6, à l'annexe III, à l'article 49 et à l'annexe VIII, stocker la finalité prévue et le contexte de déploiement, soumettre à approbation les classifications à haut risque et les exceptions au titre de l'article 6, paragraphe 3, joindre les documents de conformité et les analyses d'impact, détecter la dérive à l'exécution, consigner les actions et approbations des agents, et exporter les preuves pour l'audit, les achats, les régulateurs ou la soumission dans la base de données.

C'est la différence entre « nous avons rempli la base de données de l'UE une fois » et « nous pouvons prouver que le système enregistré est toujours celui qui tourne en production ».

Checklist de préparation à l'enregistrement¶

Avant le lancement d'un système d'IA à haut risque, posez ces questions. Si une réponse n'est pas claire, le système n'est pas prêt pour l'enregistrement.

• Avons-nous déterminé si l'article 6, paragraphe 1, l'article 6, paragraphe 2, ou l'article 6, paragraphe 3, s'applique ?
• Avons-nous rattaché le système au bon point de l'annexe III et vérifié si le point 2 exige un enregistrement national ?
• Avons-nous vérifié si le système relève d'une section sécurisée non publique ?
• Avons-nous déterminé si nous sommes fournisseur, mandataire, déployeur, ou si nous agissons pour le compte d'une autorité publique ?
• Avons-nous préparé les sections A, B ou C de l'annexe VIII selon le cas ?
• Disposons-nous d'une finalité prévue stable, d'un résumé de la logique de fonctionnement, d'une description des données d'entrée, d'une notice d'utilisation, de preuves de conformité et d'une liste des États membres ?
• Disposons-nous d'un processus pour tenir l'enregistrement à jour et reconstituer les preuves derrière chaque champ soumis ?
• Les journaux d'exécution peuvent-ils prouver que le système fonctionne dans les limites de sa finalité prévue enregistrée ?

Sanctions et risque en matière de contrôle¶

L'article 99 impose aux États membres de prévoir des sanctions effectives, proportionnées et dissuasives. Plusieurs infractions aux obligations des opérateurs peuvent entraîner des amendes administratives pouvant atteindre 15 millions d'EUR ou 3 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. La fourniture d'informations inexactes, incomplètes ou trompeuses aux organismes notifiés ou aux autorités nationales compétentes en réponse à une demande peut entraîner des amendes pouvant atteindre 7,5 millions d'EUR ou 1 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu.

L'enregistrement est aussi un signal pour les autorités de contrôle. L'article 80 prévoit que les autorités de surveillance du marché peuvent effectuer des contrôles en tenant compte des informations stockées dans la base de données de l'UE. Le risque ne se limite pas au défaut d'enregistrement. Le risque le plus important est l'incohérence : l'entrée publique dans la base de données dit une chose, la documentation technique en dit une autre, et le système en production fait encore autre chose.