Qualification des risques AI Act : décider sur des faits.

Décrire le système avant de lui attribuer une catégorie

Une qualification solide commence par une fiche factuelle. Elle décrit la finalité prévue, les entrées, les sorties, le processus influencé, les utilisateurs, les personnes affectées et la manière dont une décision est prise. Le nom commercial du produit et la présentation du fournisseur ne suffisent pas. Deux organisations peuvent utiliser la même solution dans des contextes qui conduisent à des analyses différentes.

Il faut ensuite identifier les rôles. Une entreprise peut être déployeur pour un service acheté et fournisseur pour une application proposée sous sa marque. Une modification substantielle, un changement de finalité ou certaines interventions dans la chaîne de valeur peuvent faire évoluer cette répartition. La qualification doit donc représenter les faits techniques, contractuels et métiers au jour de l’analyse.

Appliquer un ordre de contrôle qui évite les angles morts

Commencez par rechercher les signaux d’une pratique interdite. Une alerte appelle une revue immédiate des conditions et des exceptions prévues par le texte. Examinez ensuite si le système relève d’un produit de l’annexe I soumis à une évaluation de conformité par un tiers, puis s’il correspond à un cas d’usage de l’annexe III. Les deux voies vers le haut risque répondent à des critères distincts.

Pour un cas de l’annexe III, l’analyse de l’article 6, paragraphe 3, peut être pertinente lorsque le système n’entraîne pas de risque significatif de préjudice pour la santé, la sécurité ou les droits fondamentaux. Cette possibilité est encadrée et ne doit pas être transformée en exemption automatique. Les obligations de transparence sont enfin examinées séparément, car elles peuvent s’appliquer en dehors du haut risque.

Documenter une conclusion qui résiste à la contradiction

La fiche de qualification sépare les faits, le texte applicable et l’interprétation retenue. Elle cite la version du règlement consultée, conserve les documents du fournisseur et indique les hypothèses non confirmées. Une conclusion comme « faible risque » est trop vague. Il faut préciser ce qui a été vérifié, ce qui ne s’applique pas et quelles obligations demeurent malgré l’absence de haut risque.

Le décideur accepte ou refuse la conclusion avec des réserves explicites. Lorsque l’analyse d’impact sur les droits fondamentaux est requise, elle complète la qualification sans la remplacer. Les données manquantes deviennent des demandes adressées au fournisseur ou au métier, avec une date de réponse et une mesure provisoire lorsque l’usage ne peut pas attendre.

Comparer des usages qui se ressemblent en apparence

Un assistant qui reformule une offre d’emploi n’appelle pas la même analyse qu’un système qui classe les candidatures. Le premier agit sur un contenu préparatoire. Le second peut influencer l’accès à l’emploi et doit être rapproché du cas d’usage exact de l’annexe III, de sa configuration et du rôle de l’organisation.

Un chatbot interne qui répond à des questions documentaires et un agent conversationnel ouvert au public n’exposent pas les mêmes personnes et ne produisent pas les mêmes attentes de transparence. La nature de l’interaction, le risque de confusion et l’information donnée à l’utilisateur doivent être décrits au lieu de qualifier globalement la technologie conversationnelle.

Un modèle qui signale un défaut visuel à un opérateur et un composant qui commande une fonction de sécurité peuvent partager une architecture technique. Leur intégration dans le produit, leur finalité et les règles sectorielles applicables changent pourtant l’analyse. C’est pourquoi la qualification appartient au cas d’usage, pas au catalogue des technologies.

Organiser les requalifications dans le cycle de vie

Une qualification n’est fiable que pour une version et un contexte donnés. Le changement de fournisseur, de modèle, de finalité, de population, de données ou de niveau d’autonomie peut modifier la conclusion. Les incidents et les écarts observés en production constituent eux aussi des déclencheurs de revue.

Le registre doit donc porter une date de prochaine revue et des événements déclencheurs. Les équipes achats et techniques signalent les mises à jour qui affectent le comportement ou les garanties contractuelles. Le métier signale les changements de processus. Cette mécanique évite qu’une fiche exacte lors du lancement devienne une preuve trompeuse quelques mois plus tard.

Parcours de lecture recommandé

Commencez par le guide qui correspond à votre décision immédiate, puis utilisez les autres contenus pour relier qualification, contrôles, compétences et preuves. Le maillage suit l’ordre du travail réel plutôt qu’un classement purement juridique. Chaque article précise la source, les rôles concernés et les livrables qui permettent de passer de la lecture à l’action.

Décider et démontrer

Pour chaque sujet, conservez les faits, le texte applicable, le raisonnement, le décideur, les réserves, les actions et la date de prochaine revue. Cette structure rend la décision compréhensible et facilite sa mise à jour. Elle distingue ce qui relève d’une obligation juridique, d’un engagement contractuel et d’un choix de maîtrise interne.

Passer à l’action sur un premier système

Choisissez un périmètre représentatif et appliquez la méthode sur un système réel. Commencez par les faits disponibles, puis transformez chaque question non résolue en action avec un responsable et une date. Une première boucle complète apporte davantage qu’un catalogue de procédures sans propriétaire.

Les modèles téléchargeables permettent ensuite d’harmoniser le travail à l’échelle de l’organisation. Ils restent des supports à adapter. La validation finale doit tenir compte du rôle de l’organisation, du système, de son contexte d’utilisation et des autres droits applicables.