Registre des systèmes d'IA : que doit-il contenir ?
Qu'est-ce qu'un registre des systèmes d'IA ?
Un registre des systèmes d'IA — parfois appelé inventaire d'IA ou cartographie des usages d'intelligence artificielle — est le document interne qui recense l'ensemble des systèmes d'intelligence artificielle qu'une organisation développe, achète ou utilise. Pour chaque système, il consigne son fournisseur, sa finalité, les personnes concernées, le rôle joué par l'organisation au sens du Règlement (UE) 2024/1689, le niveau de risque retenu et les mesures prises pour respecter les obligations correspondantes.
C'est l'équivalent, pour l'IA, de ce que le registre des activités de traitement de l'article 30 du RGPD est pour les données personnelles : un document de gouvernance qui ne se contente pas d'exister, mais qui prouve, à la date d'un contrôle, que l'organisation sait ce qu'elle utilise et pourquoi.
La différence pratique est de taille. Le registre RGPD se construit à partir des traitements que l'on connaît, généralement documentés par la direction juridique. Le registre des systèmes d'IA, lui, se heurte à une réalité désordonnée : les outils d'IA entrent dans l'entreprise par le bas. Un développeur essaie un assistant de code, une équipe marketing génère des visuels, un recruteur teste un outil de tri de CV. Personne n'informe le DPO. C'est le « shadow AI », et c'est exactement ce que le registre est censé faire remonter.
Le point de départ n'est pas juridique, il est factuel. Tant que vous n'avez pas la liste des outils d'IA réellement ouverts dans les navigateurs de vos équipes, votre registre est une déclaration d'intention. AI Act Register Pilot part de cette réalité : l'extension reconnaît, par nom de domaine et en local, les outils d'IA visités, et pré-remplit une ligne de registre pour chacun.
Est-il obligatoire ?
Le Règlement 2024/1689 n'impose pas, en toutes lettres, « un registre » à toutes les organisations sous ce nom. Il impose une série d'obligations documentaires dont le registre est le moyen le plus économique de s'acquitter. Trois textes le rendent en pratique incontournable :
- Article 4 (maîtrise de l'IA) : les fournisseurs et déployeurs prennent des mesures pour garantir un niveau suffisant de maîtrise de l'IA de leur personnel, en tenant compte des systèmes utilisés. On ne peut pas former des équipes sur des systèmes que l'on n'a pas recensés.
- Article 26 (obligations des déployeurs de systèmes à haut risque) : conservation des journaux, information des travailleurs, désignation d'une supervision humaine compétente. Ces obligations supposent l'identification préalable des systèmes à haut risque en service.
- Article 50 (transparence) : les déployeurs doivent informer les personnes exposées à certains systèmes. Savoir quels systèmes déclenchent cette obligation exige un inventaire.
Une précision que beaucoup d'éditeurs omettent : l'article 49 crée un enregistrement dans la base de données de l'Union, et il ne vous concerne probablement pas. Ne s'y enregistrent que les fournisseurs de systèmes à haut risque de l'annexe III et les déployeurs qui sont des autorités publiques, des institutions, organes ou organismes de l'Union. Une entreprise privée qui se contente d'utiliser un système à haut risque n'a aucune obligation d'enregistrement à la base européenne. Son registre est un inventaire de gouvernance interne : la base de preuve des articles 4, 5, 26 et 50, et le socle d'un système de management de l'IA (ISO/IEC 42001) ou d'une AIPD au titre du RGPD. C'est exactement ce que produit AI Act Register Pilot — nous ne vous vendons pas une obligation qui n'existe pas.
Transversalement, l'article 21 impose de coopérer avec les autorités et de leur fournir, sur demande motivée, toute l'information nécessaire à la démonstration de la conformité. Sans registre, cette demande est ingérable.
En clair : le registre n'est pas une case à cocher, c'est l'instrument de preuve. Une autorité de surveillance du marché qui vous interroge ne vous demandera pas « avez-vous un registre ? », elle vous demandera « quels systèmes d'IA utilisez-vous, avec quelle finalité, et comment avez-vous conclu qu'ils ne relèvent pas du haut risque ? ».
Qui est concerné : déployeur ou fournisseur ?
Le Règlement distingue plusieurs rôles ; deux concernent la quasi-totalité des entreprises.
Le fournisseur (article 3, point 3) développe un système d'IA — ou le fait développer — et le met sur le marché ou en service sous son propre nom ou sa propre marque. Il porte le gros des obligations : système de gestion des risques, gouvernance des données, documentation technique, marquage CE pour le haut risque.
Le déployeur (article 3, point 4) utilise un système d'IA sous sa propre autorité, dans le cadre d'une activité professionnelle. C'est le cas de l'immense majorité des organisations : elles achètent ou utilisent gratuitement des systèmes conçus par d'autres. Leurs obligations sont plus légères mais bien réelles, et détaillées aux articles 26 et 50.
La frontière n'est pas figée. L'article 25 prévoit qu'un déployeur devient fournisseur s'il appose son nom ou sa marque sur un système à haut risque, s'il en modifie substantiellement la finalité, ou s'il apporte une modification substantielle à un système déjà mis sur le marché. Concrètement : « fine-tuner » un modèle et l'exposer à vos clients sous votre marque peut faire basculer votre organisation dans le régime fournisseur, avec ses obligations de documentation technique. Le registre doit donc tracer, pour chaque système, le rôle retenu et la raison de ce choix.
Les champs que doit contenir le registre
Il n'existe pas de gabarit officiel publié par la Commission. Le tableau ci-dessous rassemble les champs qui découlent directement des obligations du Règlement et de ce qu'une autorité demandera en contrôle.
| Champ | Pourquoi |
|---|---|
| Nom du système et fournisseur | Identifier l'éditeur responsable, retrouver sa documentation et sa déclaration de conformité. |
| Finalité d'utilisation dans l'organisation | Le risque dépend de l'usage, pas seulement de l'outil. Un même LLM est minimal en aide à la rédaction, haut risque en tri de candidatures. |
| Rôle de l'organisation (déployeur / fournisseur) | Détermine le bloc d'obligations applicable (art. 26 ou chapitre III section 2). |
| Niveau de risque retenu | Inacceptable, haut, limité, minimal. Avec la justification. |
| Base annexe III le cas échéant | Point précis de l'annexe III qui rend le système à haut risque (emploi, crédit, éducation…). |
| Modèle d'IA à usage général (GPAI) ? | Déclenche le régime du chapitre V et des obligations d'information amont. |
| Obligations de transparence applicables | Interaction avec une IA, contenu de synthèse, deepfake, reconnaissance des émotions (art. 50). |
| Mesures de supervision humaine | Qui contrôle, comment, avec quelle compétence (art. 26 §2). |
| Données traitées et base légale RGPD | Articulation avec le registre de l'article 30 du RGPD ; AIPD si nécessaire. |
| Hébergement / transferts hors UE | Point de vigilance RGPD et souveraineté ; à documenter, pas à ignorer. |
| Date de dernière revue et prochaine échéance | Un registre non revu est un registre faux. Trimestriel, semestriel ou annuel selon le risque. |
| Responsable interne | Une ligne sans propriétaire ne sera jamais mise à jour. |
Deux champs sont systématiquement oubliés et systématiquement demandés : la justification du niveau de risque (une phrase suffit, mais elle doit exister) et la date de revue. Un registre daté d'il y a dix-huit mois, dans un domaine où le parc d'outils change tous les trimestres, dessert son auteur davantage qu'il ne le protège.
Classer chaque système par niveau de risque
Le Règlement organise les systèmes en quatre catégories, décrites en détail dans notre guide des niveaux de risque de l'AI Act. Retenez la logique : le risque se déduit de l'usage, pas de la technologie.
- Risque inacceptable (article 5) : notation sociale, exploitation des vulnérabilités, reconnaissance des émotions sur le lieu de travail et dans l'éducation, moissonnage non ciblé d'images faciales. Interdit depuis le 2 février 2025.
- Haut risque (article 6, annexes I et III) : recrutement, gestion des travailleurs, accès à l'éducation, évaluation de solvabilité, services essentiels, biométrie, infrastructures critiques, application de la loi.
- Risque limité (article 50) : chatbots, IA générative, deepfakes. Obligation d'information, pas de certification.
- Risque minimal : tout le reste. Aucune obligation spécifique, bonnes pratiques recommandées.
Un piège classique : un outil du quotidien classé « minimal » sur son site marketing devient à haut risque dès que vous le branchez sur un processus de l'annexe III. Le registre doit donc consigner la finalité chez vous, pas la description commerciale de l'éditeur.
Sanctions encourues
L'article 99 fixe trois plafonds, retenus au montant le plus élevé entre la somme fixe et le pourcentage du chiffre d'affaires annuel mondial (le plus faible des deux pour les PME et les jeunes pousses) :
- 35 M€ ou 7 % pour le recours à une pratique d'IA interdite (article 5) ;
- 15 M€ ou 3 % pour la violation des autres obligations, dont celles des déployeurs (article 26) et les obligations de transparence (article 50) ;
- 7,5 M€ ou 1 % pour la fourniture d'informations inexactes, incomplètes ou trompeuses aux autorités.
Cette troisième catégorie mérite attention : répondre à une autorité de surveillance avec un inventaire approximatif expose spécifiquement à une sanction. Un registre incomplet est un risque distinct de celui de l'usage non conforme.
Checklist actionnable
- Cartographier le réel avant de rédiger. Recensez les domaines d'outils d'IA effectivement ouverts par vos équipes pendant deux à quatre semaines.
- Une ligne par couple outil × finalité. Le même assistant utilisé en rédaction et en présélection de CV occupe deux lignes, avec deux niveaux de risque.
- Trancher le rôle pour chaque ligne : déployeur par défaut, fournisseur si l'article 25 s'applique.
- Justifier le niveau de risque en une phrase, en citant le point d'annexe III lorsqu'il s'applique.
- Lister les obligations de transparence déclenchées et préparer les mentions correspondantes avant le 2 août 2026.
- Nommer un responsable et fixer une date de revue par ligne : trimestrielle pour le haut risque, annuelle pour le minimal.
- Archiver une version horodatée à chaque revue : c'est cet historique, et non le fichier courant, qui prouve la tenue à jour.
- Croiser avec le registre RGPD de l'article 30 pour les systèmes traitant des données personnelles.
Le raccourci. AI Act Register Pilot exécute les étapes 1, 2, 4 et 5 automatiquement : détection locale par domaine, pré-remplissage du registre, suggestion de niveau de risque et de rôle, génération des mentions de transparence. Vous gardez la décision ; l'outil supprime la saisie.
Le modèle gratuit
Récupérez le modèle de registre des systèmes d'IA au format XLSX et CSV, avec toutes les colonnes du tableau ci-dessus, une feuille d'exemples et un onglet de rappel des échéances.
Recevoir le modèle par email
Gratuit, sans engagement. Un seul email : celui qui contient vos fichiers.
Pour aller plus loin
Ce contenu est fourni à titre informatif. Il reflète l'état du Règlement (UE) 2024/1689 à la date de mise à jour et ne constitue pas un conseil juridique. La qualification définitive de vos systèmes relève de votre analyse et, le cas échéant, de votre conseil.