Registre des systèmes IA : obligation et modèle

L’AI Act prévoit un enregistrement de certains systèmes dans une base de données de l’Union européenne. Cet enregistrement juridique ne se confond pas avec l’inventaire interne des outils d’IA de l’entreprise, qui sert à suivre les usages, les responsabilités et les risques. Un troisième document, le registre des activités de traitement du RGPD, porte sur les traitements de données personnelles.

Un seul outil peut organiser ces informations, mais chaque obligation doit rester identifiable. L’objectif pratique est de savoir qui utilise quel système, pour quelle décision, avec quelles données et sous quelle responsabilité.

Ce qu’il faut retenir

• L’article 49 ne prévoit pas un enregistrement européen de toute IA utilisée en entreprise.
• Les fournisseurs des systèmes concernés de l’annexe III sont visés, y compris ceux qui invoquent l’exception de l’article 6(3).
• L’enregistrement par les déployeurs concerne les acteurs publics et les personnes agissant pour leur compte visés par le texte ; une entreprise privée n’y est pas soumise du seul fait d’utiliser une IA à haut risque.
• Un inventaire interne reste utile pour tous les usages, même sans obligation d’enregistrement public.

Qui doit enregistrer quoi dans la base européenne ?

Ce tableau résume les articles 49(1) à (5) de l’AI Act. Il faut d’abord vérifier la destination et la qualification du système à haut risque, ainsi que votre rôle exact.

La réforme de juillet 2026 a supprimé deux champs de la section B de l’annexe VIII, destinée aux systèmes déclarés non à haut risque au titre de l’article 6(3). Elle n’a pas supprimé leur enregistrement ni l’obligation de documenter l’analyse de classification. Règlement 2026/1744, art. 1(42), et AI Act, art. 6(4).

Le calendrier doit être apprécié avec la classification et le régime transitoire : les sections 1 à 3 du chapitre III sont reportées au 2 décembre 2027 pour l’annexe III et au 2 août 2028 pour l’annexe I. Ce report ciblé ne signifie pas que tous les articles de l’AI Act ou toute utilisation de sa base seraient suspendus jusqu’en 2027. Pour une mise sur le marché précise, examinez également l’article 111(2) et les modalités opérationnelles applicables. Règlement 2026/1744, art. 1(39) et 1(40).

Quelles informations sont publiques ?

La base de l’Union contient les informations prévues par l’annexe VIII : identification et coordonnées, identification du système, destination, statut et, selon le cas, documents de conformité ou notice. Les champs diffèrent pour un fournisseur de système à haut risque, un fournisseur invoquant l’article 6(3) et un déployeur public. Il ne faut pas transposer à tous les cas la liste la plus complète. AI Act, annexe VIII, sections A, B et C.

L’accès public comporte des exceptions : certains systèmes dans les domaines répressif, de la migration, de l’asile et des frontières relèvent de sections sécurisées ; les informations sur les essais en conditions réelles suivent également un régime spécifique. La base n’est donc pas un espace dans lequel publier indistinctement contrats, données d’entraînement ou dossiers nominatifs. AI Act, art. 49(4) et 71(4)–(6).

Le registre interne : pourquoi le tenir ?

En matière de gouvernance, le registre fournit une vision du patrimoine IA de l’organisation. Il permet d’identifier les systèmes nécessitant une conformité renforcée, de suivre leur cycle de vie, de coordonner les actions et de prioriser les efforts d’audit algorithmique.

Il facilite aussi les analyses d’impact en rapprochant les usages des données et des personnes concernées. Il ne remplace ni l’analyse juridique ni les documents requis : une ligne « conforme » ne prouve pas à elle seule qu’un système respecte le RGPD ou l’AI Act.

Le registre RGPD recense les traitements de données personnelles ; l’inventaire IA recense les systèmes et usages, y compris ceux qui n’utilisent aucune donnée personnelle. Les références croisées évitent les incohérences : un même outil peut servir à plusieurs traitements, et un traitement peut mobiliser plusieurs composants techniques. Les mentions obligatoires du registre RGPD et son champ propre restent ceux de l’article 30. RGPD, art. 30(1)–(5).

Modèle de fiche interne à adapter

Le tableau suivant est un modèle de gestion interne, pas une liste de mentions universellement imposées par l’AI Act. Ajustez le détail aux usages et aux informations accessibles.

Ne recopiez pas toutes les données dans le registre. Une référence vers la documentation technique, le contrat ou une analyse protégée suffit souvent ; les droits d’accès peuvent différer selon la sensibilité du document.

Les obligations propres des déployeurs

Pour les systèmes à haut risque concernés, l’article 26 prévoit notamment l’utilisation selon les instructions, la supervision humaine, la surveillance et la réaction aux risques ou incidents. La vérification expresse de l’enregistrement et l’interdiction d’utiliser un système non enregistré prévues au paragraphe 8 concernent les déployeurs publics qu’il vise : elles ne doivent pas être présentées comme une obligation identique de tous les utilisateurs privés. AI Act, art. 26(1)–(9).

L’analyse d’impact sur les droits fondamentaux concerne les organismes de droit public, les entités privées fournissant des services publics et les déployeurs des systèmes des points 5(b) et 5(c) de l’annexe III, dans les conditions de l’article 27(1), hors point 2. Une entreprise n’a donc pas systématiquement à produire cette analyse pour chaque outil. L’AIPD en matière d’IA relève, elle, des critères du RGPD et peut fournir des éléments communs sans confondre les deux analyses. AI Act, art. 27(1), complété par le règlement 2026/1744, art. 1(13).

Le registre peut contenir une rubrique incidents : date, système, conséquences connues, interlocuteurs informés, mesure de suspension éventuelle et suivi. Les signalements exigés dépendent du rôle de fournisseur ou de déployeur et des faits ; inscrire un incident en interne ne remplace pas une notification requise. AI Act, art. 26(5) et 73.

Mettre l’inventaire en place sans le figer

La constitution initiale passe par un recensement couvrant les directions et services, y compris les outils intégrant des fonctionnalités d’IA : assistants, recommandations, classement, transcription ou analyse prédictive. Croisez les déclarations métier avec les achats, abonnements et fonctionnalités activées par les administrateurs.

Attribuez la tenue de chaque fiche à un responsable métier, avec un pilote chargé de la cohérence générale. Le DPO conseille sur les traitements et analyses qui relèvent de ses missions ; il ne devient pas automatiquement responsable de toutes les décisions IA. Notre guide de gouvernance IA en entreprise aide à répartir ces rôles.

Intégrez les mises à jour aux événements réels : acquisition, activation d’une fonction, changement de destination, modification substantielle ou retrait. Une revue périodique complète ce suivi ; sa fréquence est un choix de gouvernance, pas un minimum annuel fixé pour tout inventaire interne par l’AI Act.

Pour quelques systèmes, un tableur structuré peut suffire. À plus grande échelle, un outil commun peut gérer les droits d’accès, les versions et les pièces liées. Le choix du logiciel compte moins que l’identification des responsables et des décisions encore ouvertes.

FAQ

Faut-il un registre IA interne sans système à haut risque ?

Il n’existe pas d’obligation générale, dans l’AI Act, d’utiliser un registre interne type pour chaque entreprise. Un inventaire reste utile pour connaître les outils, appliquer les règles internes et détecter les usages qui nécessitent une analyse particulière.

Peut-on réunir le registre IA et le registre RGPD ?

Oui, dans un même outil, si les périmètres restent lisibles et les mentions requises par l’article 30 du RGPD sont couvertes. Des fiches liées sont souvent plus pratiques qu’une ligne unique regroupant toutes les fonctions d’un logiciel.

Une IA exclue du haut risque doit-elle être enregistrée ?

Si le fournisseur invoque l’exception de l’article 6(3) pour un système relevant de l’annexe III, l’article 49(2) prévoit précisément un enregistrement. Cette situation se distingue d’un outil qui n’entre pas du tout dans les cas visés par cette annexe.

Recevez nos analyses pratiques de conformité dans la newsletter.

À propos de l’auteur. Thiébaut Devergranne est docteur en droit privé, titulaire du CAPA et fondateur de Legiscope. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.