Règlement européen sur l’IA : comprendre la classification des systèmes par niveaux de risque

Pourquoi le règlement européen classe-t-il les systèmes d’IA ?

Le règlement européen sur l’intelligence artificielle, établi par le règlement (UE) 2024/1689 du Parlement européen et du Conseil, repose sur une logique fondée sur le risque. Tous les systèmes d’IA ne présentent pas les mêmes conséquences pour les personnes. Un outil qui recommande une musique ne soulève pas les mêmes enjeux qu’un dispositif utilisé pour évaluer la solvabilité, sélectionner des candidats ou assister une décision médicale.

La classification ne sert donc pas à déterminer si une technologie est moderne ou complexe. Elle cherche à évaluer les effets possibles du système sur la santé, la sécurité, les droits fondamentaux et la vie privée. Plus le risque est élevé, plus les exigences applicables au concepteur, au fournisseur, au déployeur ou à l’importateur deviennent nombreuses.

Cette approche demande de regarder plusieurs éléments à la fois : la finalité prévue, le secteur d’utilisation, les personnes concernées, le degré d’autonomie du système et la possibilité qu’une décision automatisée produise un préjudice. Un même modèle technique peut ainsi relever de régimes différents selon la manière dont il est intégré dans un service.

La réglementation distingue principalement quatre ensembles : les pratiques présentant un risque inacceptable et interdites, les systèmes à haut risque, les systèmes soumis à des obligations de transparence et les systèmes à risque minimal ou sans risque particulier. Les modèles d’IA à usage général, souvent appelés GPAI, font l’objet d’un cadre complémentaire qui ne se confond pas avec ces quatre niveaux.

Les quatre niveaux de risque à retenir

NiveauPrincipeConséquence principale
Risque inacceptableLe système porte atteinte à des valeurs ou droits fondamentaux dans les cas visés par le règlement.La pratique est interdite, sauf éventuelles exceptions prévues par le texte.
Risque élevéLe système peut affecter fortement la santé, la sécurité ou les droits fondamentaux.Obligations renforcées avant et pendant la mise à disposition ou l’utilisation.
Risque limité ou encadré par la transparenceLe système présente un risque de confusion ou de tromperie dans certaines interactions.Les personnes doivent être informées de l’intervention ou du contenu généré par une IA dans les cas prévus.
Risque minimal ou nulLe système ne relève pas d’une interdiction ni d’une obligation spécifique majeure au titre du règlement.Les obligations générales restent applicables, avec des bonnes pratiques recommandées.

Ce tableau donne une vue d’ensemble, mais il ne remplace pas l’analyse du cas concret. Le règlement comporte des listes, des définitions et des conditions particulières. Une fonctionnalité présentée comme un outil d’assistance peut entrer dans une catégorie plus contraignante lorsque ses résultats influencent une décision concernant une personne.

Niveau 1 : les pratiques d’IA interdites

Le niveau de risque le plus élevé correspond aux pratiques considérées comme incompatibles avec les exigences européennes de protection des personnes. L’article 5 du règlement (UE) 2024/1689 énumère les pratiques interdites. L’interdiction porte sur des usages précis, et non sur toute technologie utilisant une technique d’apprentissage automatique.

Parmi les cas visés figurent certaines techniques de manipulation ou de tromperie susceptibles d’altérer le comportement d’une personne et de provoquer un préjudice important. Le texte encadre aussi l’exploitation de vulnérabilités liées à l’âge, au handicap ou à une situation sociale ou économique particulière lorsqu’elle conduit à des conséquences dommageables.

Le règlement encadre également certaines formes de notation sociale, l’évaluation prédictive de la criminalité fondée exclusivement sur le profilage ou les caractéristiques de personnalité, ainsi que des usages biométriques et de reconnaissance des émotions dans des contextes déterminés. Les règles concernant l’identification biométrique à distance dans les espaces accessibles au public par les autorités répressives comportent des conditions et des exceptions spécifiques. Elles ne doivent pas être résumées par une interdiction générale de toute biométrie.

Pour analyser un projet, la première question est donc la suivante : la fonctionnalité correspond-elle à une pratique listée par l’article 5, compte tenu de son objectif réel et de son contexte d’utilisation ? Si la réponse est positive, modifier la documentation ou ajouter une validation humaine ne transforme pas automatiquement l’usage en système autorisé.

Points de contrôle avant tout déploiement

  • Décrire la finalité opérationnelle avec des exemples concrets, et non avec une formule commerciale.
  • Identifier les personnes observées, évaluées ou influencées par le système.
  • Vérifier si le dispositif exploite des données biométriques, des caractéristiques sensibles ou des indices de vulnérabilité.
  • Comparer le cas d’usage avec les pratiques mentionnées à l’article 5 du règlement.
  • Conserver l’analyse et les décisions prises dans un dossier de conformité.

Niveau 2 : reconnaître un système d’IA à haut risque

Les systèmes à haut risque ne sont pas interdits. Ils sont autorisés sous réserve du respect d’exigences importantes destinées à réduire les erreurs, les discriminations, les atteintes à la sécurité et les décisions impossibles à expliquer. Le règlement organise cette catégorie autour de deux grandes situations.

La première concerne les systèmes d’IA qui sont des composants de sécurité ou qui sont eux-mêmes intégrés à certains produits couverts par la législation européenne d’harmonisation. Ils peuvent devoir faire l’objet d’une évaluation de conformité avant leur mise sur le marché.

La seconde s’appuie sur l’annexe III du règlement. Elle vise plusieurs domaines sensibles, notamment la biométrie dans les conditions prévues par le texte, les infrastructures critiques, l’éducation et la formation professionnelle, l’emploi et la gestion des travailleurs, l’accès à des services essentiels, la répression, la migration et le contrôle aux frontières, la justice ainsi que les processus démocratiques.

La présence d’un système dans l’un de ces secteurs ne suffit toutefois pas toujours à le qualifier automatiquement de haut risque. Les conditions de l’annexe III et les éventuelles exclusions doivent être examinées. Par exemple, un outil de gestion administrative sans influence notable sur une décision concernant une personne ne présente pas nécessairement le même statut qu’un système qui classe ou sélectionne des candidats.

Le fournisseur doit aussi déterminer la fonction réelle du système. Un logiciel qui trie des curriculum vitae, établit une liste de candidats ou recommande une promotion peut entrer dans le champ des systèmes à haut risque lorsqu’il est utilisé dans le domaine de l’emploi et qu’il produit un effet significatif sur une personne.

Quelles obligations s’appliquent aux systèmes à haut risque ?

Le règlement (UE) 2024/1689 impose aux fournisseurs de systèmes à haut risque un ensemble d’exigences portant sur la conception, la qualité des données, la documentation et le suivi. Ces exigences doivent être anticipées dès le projet, car elles concernent la chaîne complète allant du développement jusqu’à l’utilisation.

  • Gestion des risques : les risques prévisibles doivent être identifiés, évalués et réduits pendant tout le cycle de vie du système.
  • Données et gouvernance : les jeux de données utilisés pour l’entraînement, la validation et les tests doivent répondre à des exigences de qualité adaptées à la finalité, avec une attention portée aux biais et aux erreurs.
  • Documentation technique : le fonctionnement, les choix de conception, les performances, les limites et les procédures de contrôle doivent être décrits.
  • Traçabilité : le système doit, dans les conditions prévues par le règlement, générer des journaux permettant de comprendre son fonctionnement et d’analyser les incidents.
  • Transparence et instructions : les utilisateurs professionnels doivent disposer d’informations utiles sur les capacités, les limites et les conditions d’utilisation.
  • Surveillance humaine : des personnes compétentes doivent pouvoir interpréter les sorties, détecter les anomalies, ignorer une recommandation ou interrompre le système lorsque cela est nécessaire.
  • Exactitude, robustesse et cybersécurité : le système doit atteindre des niveaux de performance adaptés à son usage et résister aux erreurs, aux manipulations et à certaines attaques.

Une erreur fréquente consiste à considérer la validation humaine comme une formalité. Elle ne remplace pas une analyse technique et organisationnelle. La personne chargée de la supervision doit disposer d’un accès réel aux informations nécessaires, d’une formation appropriée et d’une autorité suffisante pour contester le résultat du système.

Le rôle du déployeur : les obligations côté utilisateur

Le déployeur est l’entité qui utilise un système d’IA sous sa responsabilité, notamment dans un cadre professionnel. Ses obligations diffèrent de celles du fournisseur, mais elles peuvent être substantielles pour un système à haut risque. Acheter ou intégrer un outil conforme ne dispense pas de contrôler la manière dont il est utilisé.

Avant la mise en service, il est utile de formaliser une fiche d’usage comprenant la finalité, les catégories de personnes concernées, les données exploitées, les décisions influencées et les personnes responsables. Cette fiche doit préciser ce que l’outil peut faire et ce qu’il ne doit pas faire.

  1. Vérifier la notice d’utilisation et les conditions prévues par le fournisseur.
  2. Définir les rôles des utilisateurs autorisés et les règles d’accès.
  3. Organiser la surveillance humaine et la procédure d’escalade en cas d’anomalie.
  4. Conserver les journaux et les éléments nécessaires à l’analyse des incidents, dans le respect des règles applicables aux données personnelles.
  5. Contrôler régulièrement la qualité des résultats sur des situations représentatives.
  6. Informer les personnes concernées lorsque le règlement ou une autre règle applicable l’exige.
  7. Réexaminer la classification si la finalité, les données, le public ou le niveau d’autonomie évolue.

Le déployeur doit aussi éviter le glissement d’usage. Un outil prévu pour aider à rechercher des dossiers peut être détourné vers une sélection automatisée. Dans ce cas, l’analyse de risque doit être reprise à partir de la nouvelle finalité, même si le logiciel n’a pas changé.

Niveau 3 : les obligations de transparence

Certains systèmes ne sont pas classés à haut risque, mais peuvent tromper une personne sur la nature de l’interaction ou sur l’origine d’un contenu. Le règlement prévoit alors des obligations de transparence. Elles concernent notamment les systèmes qui dialoguent directement avec des personnes, les contenus générés ou manipulés et certains systèmes de reconnaissance des émotions ou de catégorisation biométrique dans les conditions prévues par le texte.

La transparence doit être compréhensible et intervenir au moment pertinent. Une personne qui échange avec un agent conversationnel doit savoir qu’elle interagit avec une IA lorsque cette information n’est pas évidente. De même, certains contenus générés ou modifiés artificiellement doivent être marqués ou signalés de manière adaptée, selon les modalités prévues par le règlement.

Cette obligation ne signifie pas que chaque élément produit par un logiciel doit afficher une mention identique. Le format dépend de la technologie, du contexte et du type de contenu. Une information noyée dans des conditions générales peut être insuffisante si l’utilisateur doit comprendre immédiatement la nature de l’interaction.

Il faut aussi distinguer la transparence envers le public de la documentation technique destinée aux professionnels. Une notice complète pour un administrateur ne remplace pas une information claire affichée à la personne qui échange avec le système ou qui consulte un contenu généré.

Niveau 4 : les systèmes à risque minimal ou sans risque particulier

Une grande partie des usages courants relève d’un risque minimal ou ne déclenche pas d’obligation spécifique importante au titre du règlement sur l’IA. Cela peut concerner des fonctions de recommandation, des filtres anti-spam, des jeux vidéo ou des outils d’optimisation qui ne prennent pas de décision sensible concernant une personne.

Cette catégorie ne constitue pas une dispense générale de prudence. D’autres textes peuvent s’appliquer, notamment le règlement général sur la protection des données, le droit de la consommation, le droit du travail, les règles de cybersécurité ou les obligations sectorielles. Une fonctionnalité peut également changer de catégorie après une modification de son objectif ou de son intégration.

Le règlement encourage par ailleurs l’adoption volontaire de codes de conduite pour les systèmes ne présentant pas un risque élevé. Une organisation peut donc mettre en place des mesures de test, de documentation, de contrôle des biais et d’information des utilisateurs même lorsque le texte n’impose pas le même niveau de formalité que pour un système à haut risque.

Les modèles d’IA à usage général : une catégorie à part

Les modèles d’IA à usage général, désignés comme GPAI dans le règlement, peuvent réaliser ou soutenir des tâches variées, comme la génération de texte, l’analyse d’informations ou la production de code. Leur encadrement ne correspond pas exactement à un niveau de risque appliqué à un cas d’usage final.

Le règlement prévoit des obligations pour les fournisseurs de ces modèles, notamment en matière de documentation, de politique relative au respect du droit d’auteur et de publication d’un résumé suffisamment détaillé des contenus utilisés pour l’entraînement, selon les exigences applicables. Des règles supplémentaires concernent les modèles présentant un risque systémique, en fonction des critères prévus par le texte et des désignations de l’autorité compétente.

Le fournisseur d’un modèle général et l’organisation qui l’intègre dans un outil métier n’ont pas nécessairement les mêmes responsabilités. Le niveau de risque doit être réévalué au niveau du système déployé, de sa finalité et de son impact. Un modèle polyvalent utilisé pour rédiger des idées n’est pas analysé de la même manière lorsqu’il est intégré à un processus de sélection ou d’accès à un service essentiel.

Méthode pratique pour classer un système d’IA

Une classification fiable repose sur une description précise du système. Les termes comme assistant intelligent, automatisation ou analyse prédictive ne suffisent pas à déterminer le régime applicable.

  1. Décrire la fonction : indiquez les entrées, les traitements, les sorties et les actions déclenchées par le système.
  2. Définir la finalité : expliquez la décision ou le processus auquel la sortie contribue.
  3. Identifier les personnes touchées : distinguez les utilisateurs du logiciel des personnes évaluées, classées ou influencées.
  4. Examiner les données : repérez les données personnelles, biométriques, sensibles, comportementales ou inférées.
  5. Comparer avec les interdictions : recherchez les correspondances avec l’article 5 du règlement.
  6. Comparer avec le haut risque : vérifiez les produits concernés et les domaines de l’annexe III, puis examinez les conditions particulières.
  7. Rechercher une obligation de transparence : analysez le risque de confusion, la génération de contenu et l’interaction directe avec des personnes.
  8. Documenter le résultat : indiquez les textes examinés, les hypothèses retenues, les exclusions éventuelles et la date de révision.

Cette méthode doit être répétée lorsque le modèle, les données, le public, le pays d’utilisation ou la finalité change. Une classification datée peut devenir inexacte après une mise à jour fonctionnelle.

Les erreurs de qualification les plus fréquentes

  • Classer selon la technologie au lieu de l’usage : un modèle de langage n’est pas automatiquement à haut risque, tout comme un outil traditionnel n’est pas automatiquement sans risque.
  • Confondre secteur et catégorie : travailler dans les ressources humaines ou la santé ne suffit pas à établir la classification sans examiner la fonction précise.
  • Oublier les décisions indirectes : une recommandation peut avoir un effet important même si un humain valide ensuite le résultat.
  • Se fier à l’étiquette commerciale : les termes assistant, copilot ou support ne décrivent pas toujours les capacités réelles.
  • Ignorer les données dérivées : une donnée estimée ou déduite peut produire un effet comparable à celui d’une donnée directement collectée.
  • Négliger les mises à jour : l’ajout d’un module de classement, de profilage ou d’action automatique peut modifier l’analyse.

La documentation doit rendre visibles ces points de vigilance. Elle permet aussi de distinguer les obligations du fournisseur, du déployeur et des autres acteurs de la chaîne de valeur, au lieu de regrouper toutes les responsabilités sous le mot utilisateur.

Calendrier et sources à consulter

Le règlement (UE) 2024/1689 est entré en vigueur après sa publication au Journal officiel de l’Union européenne. Son application est progressive : certaines dispositions, notamment celles relatives aux pratiques interdites et à la culture de l’IA, s’appliquent avant les règles générales concernant les systèmes à haut risque et les obligations de transparence. Le calendrier exact dépend de la disposition concernée et des évolutions prévues par le texte.

Pour vérifier une date, une définition ou une obligation, les références prioritaires sont le texte officiel du règlement, ses articles, ses annexes et les communications publiées par la Commission européenne. Les recommandations et guides peuvent aider à interpréter les notions, mais ils ne remplacent pas le règlement ni les règles sectorielles applicables.

Une veille doit porter sur plusieurs éléments :

  • les actes d’exécution et actes délégués adoptés pour préciser certaines exigences ;
  • les orientations de la Commission européenne et du Bureau européen de l’IA ;
  • les normes harmonisées et les procédures d’évaluation de conformité pertinentes ;
  • les décisions ou informations publiées par les autorités nationales compétentes ;
  • les évolutions du système, de ses fournisseurs et de son contexte d’utilisation.

Cette veille est particulièrement importante pour les projets dont la mise sur le marché ou l’utilisation s’étend sur plusieurs États membres.

FAQ : classification des systèmes d’IA

Un chatbot est-il automatiquement un système à haut risque ?

Non. Un chatbot relève souvent d’obligations de transparence lorsque la personne doit savoir qu’elle échange avec une IA. Il peut toutefois entrer dans un régime plus contraignant s’il est intégré à un processus sensible et exerce une influence significative sur une décision concernant une personne.

La présence d’un humain exclut-elle le haut risque ?

Non. La supervision humaine est une exigence importante pour de nombreux systèmes à haut risque, mais elle ne supprime pas la classification. L’analyse porte sur la fonction et les effets du système, pas uniquement sur l’existence d’une validation finale.

Un outil utilisé uniquement en interne échappe-t-il au règlement ?

Non. Le règlement peut s’appliquer à l’utilisation de systèmes d’IA dans l’Union européenne, y compris dans un cadre interne ou professionnel. Les obligations dépendent du rôle de l’acteur et du type de système concerné.

Que faire si la classification est incertaine ?

Il faut documenter l’incertitude, décrire la finalité réelle, examiner les articles et annexes pertinents du règlement, puis solliciter une analyse juridique ou technique compétente lorsque l’impact potentiel est important. Le déploiement ne devrait pas précéder cette vérification.