Registre des systèmes IA RH : modèle et champs clés

Registre systèmes IA RH : obligatoire ou recommandé ?

Un registre des systèmes IA RH est un inventaire interne qui permet de répondre à des questions très concrètes : quelles intelligences artificielles sont utilisées, pour quelle finalité, par qui, sur quelles données, avec quel fournisseur, quel niveau de risque et quelle décision de maintien ? Au 8 août 2026, le règlement européen sur l’IA ne crée pas une obligation universelle portant exactement ce nom pour toute entreprise et tout outil. Présenter un tableur interne comme « le registre AI Act obligatoire » serait donc trompeur.

Ce registre reste la meilleure porte d’entrée opérationnelle. Sans inventaire, une organisation ne peut pas classer ses usages, retrouver une notice fournisseur, savoir quels collaborateurs exercent la supervision ou suspendre rapidement une fonction après un incident. La CNIL recommande d’ailleurs de faire précéder l’usage d’une IA générative par une analyse des risques et une gouvernance claire, en identifiant les rôles, les transferts et les conditions de réutilisation des données dans ses questions-réponses sur l’IA générative.

L’article 30 du RGPD impose notamment d’indiquer les finalités, catégories de personnes et de données, destinataires, transferts, durées prévues et mesures de sécurité. Il raisonne par activité de traitement, pas par application. À l’inverse, votre inventaire IA peut consacrer une ligne à un système et relier cette ligne à plusieurs traitements : recrutement, mobilité interne ou assistance aux salariés. La méthode de cartographie de la CNIL aide à maintenir ce lien sans confondre les deux documents.

Quels systèmes d’IA RH faut-il recenser ?

Partez des usages, pas de la liste officielle des logiciels achetés. Le « shadow AI » apparaît souvent dans un compte individuel, une extension de navigateur ou une option activée silencieusement dans l’ATS. Interrogez le recrutement, l’administration du personnel, la formation, la paie, les relations sociales, les managers, la DSI, les achats et la sécurité. Demandez ce qui génère, résume, prédit, recommande, classe, extrait ou déclenche une action.

Incluez les systèmes achetés, construits ou adaptés en interne, les modèles accessibles par API, les fonctions IA d’un logiciel existant, les assistants généralistes autorisés, ainsi que les POC et pilotes. Un système abandonné ne disparaît pas immédiatement : passez-le au statut « retiré », indiquez la date de fin, la purge des données et la conservation des preuves utiles. Cette trace évite qu’un ancien connecteur ou compte fournisseur reste actif.

Ne classez pas tout automatiquement « à haut risque ». La qualification dépend de la destination, de la fonction et du contexte. Les systèmes destinés à analyser ou filtrer des candidatures et à évaluer des candidats figurent parmi les usages liés à l’emploi de l’Annexe III, comme le rappelle la Commission européenne. Documentez la justification du classement, puis faites-la valider. Notre article sur les obligations de l’AI Act en recrutement approfondit ce cas sensible.

Modèle de registre IA RH : les champs à documenter

Une fiche utile doit permettre à une personne qui ne connaît pas le projet de comprendre ce que fait le système, qui répond de son usage et où trouver les preuves. Évitez la cellule « conforme : oui/non » : la conformité dépend de plusieurs textes, versions et actions. Préférez des statuts vérifiables — non évalué, action ouverte, validé sous conditions, suspendu ou retiré — assortis d’un responsable et d’une échéance.

Le registre doit contenir des liens vers les documents maîtrisés : notice d’utilisation, contrat et avenant de sous-traitance, analyse de risque, protocole de test, rapport de sécurité, décision du comité, information des salariés et procédure d’incident. Il ne doit pas devenir une copie incontrôlée de ces pièces. Pour un système à haut risque, l’article 26 de l’AI Act prévoit notamment, pour le déployeur, usage conforme à la notice, supervision humaine compétente, suivi du fonctionnement et conservation des journaux sous son contrôle pendant une durée appropriée d’au moins six mois, sous réserve des autres règles applicables. Le registre indique où ces preuves sont gérées ; il ne remplace pas les journaux.

Créer le registre en 7 étapes sans produire un tableur fantôme

1. Nommer le pilote et les contributeurs : désignez la personne qui gère la méthode, puis un propriétaire métier et un propriétaire technique pour chaque système. Associez achats, juridique, DPO et RSSI selon le besoin.
2. Définir le périmètre : précisez les entités, processus RH, pays, filiales, POC et services grand public couverts. Donnez une définition simple des fonctions à déclarer et un canal pour les signaler.
3. Découvrir les usages : combinez entretiens, questionnaires, catalogue applicatif, achats, contrats SaaS, extensions autorisées, appels API et authentification unique. Une seule source ne révèle jamais tout le shadow AI.
4. Créer une fiche par usage cohérent : un même produit peut nécessiter plusieurs fiches si les finalités, populations, données ou conséquences diffèrent. Reliez-les grâce à un identifiant de service commun.
5. Qualifier et prioriser : examinez le rôle de l’organisation, le niveau de risque AI Act, les données personnelles, l’effet sur les personnes, le degré d’automatisation et la réversibilité. Faites valider les cas sensibles.
6. Relier les preuves et ouvrir les actions : attachez la source de chaque affirmation. Un contrat fournisseur manquant devient une action avec propriétaire et échéance, pas une cellule vide.
7. Décider : le propriétaire et le comité compétent autorisent, limitent, suspendent ou retirent l’usage. Inscrivez la décision, ses conditions et la date de réexamen.

Commencez dans un support que l’organisation sait maintenir : tableur avec droits d’accès, outil GRC, CMDB enrichie ou catalogue de données. Le choix technique est secondaire par rapport aux identifiants stables, à l’historique des changements, aux champs obligatoires et aux notifications de revue. Restreignez l’accès : le registre peut révéler une architecture, des fournisseurs, des incidents et des mesures de sécurité. Une vue expurgée peut être partagée plus largement sans exposer les détails sensibles.

Évitez aussi de demander au DPO de certifier seul tous les usages. Le métier sait pourquoi le système est utilisé, la DSI sait comment il fonctionne, les achats maîtrisent le contrat, le RSSI évalue les contrôles et le DPO conseille sur les traitements de données personnelles. Cette répartition transforme le registre en mécanisme de responsabilité. Pour analyser la dimension données candidats, reliez les fiches concernées à notre guide du RGPD appliqué au tri de CV.

Versions, KPI, incidents et revues : maintenir le registre vivant

Un inventaire photographié une fois devient faux dès qu’un fournisseur change de modèle, active une fonctionnalité, déplace un traitement ou modifie sa politique de conservation. Prévoyez donc des événements déclencheurs : nouvelle finalité, nouvelle population, ajout d’une source, nouveau connecteur, changement de version majeure, hausse du niveau d’autonomie, incident, dérive d’un KPI ou évolution réglementaire.

Choisissez des KPI reliés à la finalité et au risque : exactitude sur un jeu de référence, taux d’abstention, corrections humaines, faux positifs et faux négatifs, écarts entre groupes lorsque l’analyse est licite et pertinente, incidents de sécurité, plaintes, temps de traitement et disponibilité. Un gain de temps ne compense pas une hausse d’erreurs défavorables. Indiquez pour chaque métrique sa définition, sa source, sa fréquence, son propriétaire et le seuil qui déclenche une action.

Ne stockez pas les prompts, CV ou conversations directement dans le registre pour « avoir une preuve ». Les systèmes à haut risque doivent permettre une journalisation adaptée, selon l’article 12 de l’AI Act, mais les traces restent soumises à la sécurité, à la minimisation et aux durées applicables. Notre guide sur la sécurité d’un assistant RH IA détaille une journalisation proportionnée et la réponse aux incidents.

Checklist de mise en œuvre et décision de mise en service

Avant d’autoriser un système, vérifiez que la ligne de registre permet de répondre « oui » ou « non applicable, justification validée » aux points suivants. Une réponse « en cours » doit comporter un responsable, une échéance et, si nécessaire, une restriction temporaire d’usage.

• -- La finalité, les utilisateurs, les personnes concernées et les actions interdites sont formulés sans ambiguïté.
• -- Le propriétaire métier, le propriétaire technique, le fournisseur et les rôles juridiques sont identifiés.
• -- La version, l’offre, les connecteurs, l’hébergement, les transferts, les sous-traitants et la réutilisation des données sont connus.
• -- La qualification AI Act et RGPD est justifiée et renvoie aux analyses d’impact applicables.
• -- Les personnes qui supervisent disposent de la compétence, de l’autorité, du temps et des informations nécessaires pour contester la sortie.
• -- Les tests, mesures de sécurité, journaux, durées de conservation et procédures d’incident sont définis.
• -- L’information des candidats, salariés et représentants est organisée lorsque les textes ou le contexte l’exigent.
• -- Les KPI, seuils d’arrêt, conditions de réversibilité, décision et prochaine date de revue sont inscrits.

Pour la base européenne, ne cochez pas « fait » par défaut. L’article 49 du règlement (UE) 2024/1689 organise l’enregistrement de certains systèmes à haut risque par leurs fournisseurs et prévoit une obligation spécifique pour les déployeurs qui sont des autorités publiques, des institutions ou organismes de l’Union, ou des personnes agissant en leur nom. Un employeur privé ordinaire ne doit donc pas se déclarer soumis à cette formalité uniquement parce qu’il tient un inventaire interne. Il doit néanmoins vérifier son rôle exact et le système concerné.

Cet article fournit une méthode de gouvernance générale, pas un avis juridique. La qualification dépend de la destination du système, du rôle de l’organisation, des données et du contexte d’usage. Faites valider les cas sensibles par votre DPO et votre conseil juridique.