Systèmes d’IA à haut risque : comprendre les obligations de documentation et de contrôle humain

Pourquoi les systèmes d’IA à haut risque font l’objet d’exigences renforcées

Les systèmes d’intelligence artificielle ne présentent pas tous le même niveau de danger. Un outil qui propose une reformulation de texte n’a pas les mêmes conséquences qu’un système utilisé pour sélectionner des candidats, évaluer l’accès à un service essentiel ou assister une décision médicale. Le règlement européen 2024/1689, souvent appelé règlement sur l’intelligence artificielle, établit une classification fondée sur les usages et les risques associés.

Les systèmes dits à haut risque peuvent influencer les droits fondamentaux, la sécurité ou l’accès à des possibilités importantes. Cette catégorie comprend notamment certains systèmes intégrés à des produits réglementés ainsi que des systèmes relevant de domaines listés dans le règlement, comme l’éducation, l’emploi, les infrastructures essentielles, l’accès à des services privés ou publics, la police, la migration et la justice.

Le classement ne dépend pas uniquement du nom du logiciel ou de la technologie employée. Il faut examiner la finalité prévue, les personnes concernées, le contexte d’utilisation et le niveau d’autonomie du système. Un même moteur d’IA peut donc relever de contraintes différentes selon qu’il sert à trier des documents internes ou à recommander une décision concernant une personne.

Identifier les rôles avant de répartir les responsabilités

La première étape consiste à déterminer qui intervient dans la chaîne de traitement. Le règlement européen distingue notamment le fournisseur, qui développe un système ou le fait développer sous son nom, et le déployeur, qui utilise ce système dans le cadre de son activité. D’autres acteurs peuvent intervenir, comme l’importateur, le distributeur ou le fabricant d’un produit intégrant une IA.

Cette distinction est essentielle pour la documentation. Le fournisseur assume une grande partie des obligations techniques et réglementaires liées à la conception, à l’évaluation de conformité, au système de gestion des risques et au suivi après mise sur le marché. Le déployeur doit, de son côté, utiliser le système conformément aux instructions, organiser la supervision humaine, surveiller son fonctionnement et conserver certains éléments de traçabilité.

Une organisation qui achète un outil auprès d’un prestataire ne transfère donc pas toutes ses responsabilités. Elle doit vérifier le périmètre d’usage autorisé, former les personnes chargées de la supervision, contrôler la qualité des données fournies au système et prévoir une procédure de signalement des incidents. La répartition peut être précisée dans les contrats, mais elle doit aussi être cohérente avec la réalité opérationnelle.

Le dossier technique : la mémoire vérifiable du système

Le fournisseur d’un système à haut risque doit constituer une documentation technique suffisamment précise pour démontrer la conformité du système. Le règlement européen sur l’intelligence artificielle décrit les éléments attendus dans son annexe IV. Cette documentation doit permettre à une autorité compétente de comprendre la conception, le fonctionnement, les performances et les limites du système.

Un dossier exploitable devrait notamment présenter :

• la finalité prévue et les usages exclus ;
• l’architecture générale du système et les principaux composants logiciels ou matériels ;
• les méthodes utilisées pour le développement, l’entraînement, la validation et les tests ;
• les jeux de données employés, leur provenance, leurs caractéristiques et les mesures prises pour limiter les erreurs ;
• les résultats des essais, les seuils de performance et les conditions dans lesquelles ces résultats sont valables ;
• les risques connus, les mesures de réduction et les limites communiquées aux utilisateurs ;
• les mécanismes de journalisation, de cybersécurité et de surveillance après déploiement.

La documentation ne doit pas être traitée comme une brochure commerciale. Elle doit décrire les choix techniques de manière traçable, avec des versions, des dates, des responsables et des preuves de validation. Une documentation actualisée facilite aussi l’analyse d’un incident ou d’une dérive de performance.

Gestion des risques et gouvernance des données

La conformité d’un système à haut risque repose sur une démarche continue de gestion des risques. Le règlement 2024/1689 prévoit un processus itératif couvrant l’identification des dangers, l’estimation de la gravité et de la probabilité, la mise en place de mesures de réduction et la vérification de leur efficacité.

Cette analyse doit dépasser les erreurs techniques visibles. Elle doit examiner les biais, les résultats discriminatoires, les défaillances de sécurité, les usages détournés, les erreurs d’interprétation et les conséquences d’une dépendance excessive aux recommandations du système. Les risques doivent être étudiés dans le contexte réel, car une performance acceptable en laboratoire peut devenir insuffisante lorsque les données, les utilisateurs ou les contraintes changent.

La qualité des données constitue un autre volet central. Les données d’entraînement, de validation et de test doivent être pertinentes pour la finalité prévue, suffisamment représentatives et soumises à des contrôles adaptés. Les anomalies, les doublons, les valeurs manquantes et les changements de distribution doivent être documentés. La gouvernance doit aussi préciser qui peut modifier les jeux de données, approuver une nouvelle version ou interrompre l’usage du système.

Une fiche de contrôle utile associe chaque risque à une mesure, un responsable, un indicateur et une fréquence de réévaluation. Cette structure transforme une analyse théorique en dispositif opérationnel.

Journalisation, traçabilité et conservation des preuves

Un système à haut risque doit produire des journaux adaptés à sa finalité. La journalisation permet de reconstituer ce qui s’est passé : version du modèle, données d’entrée pertinentes, résultat généré, intervention humaine, erreur éventuelle et action effectuée ensuite. Le niveau de détail doit respecter les règles de protection des données et le principe de minimisation.

Pour un déployeur, les journaux peuvent être nécessaires afin d’examiner une contestation, de détecter une dérive ou de comprendre un incident. Une politique de conservation doit préciser les catégories d’informations enregistrées, la durée retenue, les accès autorisés et les mesures de protection contre l’altération. La durée applicable peut dépendre du rôle de l’acteur, de la réglementation sectorielle et des obligations contractuelles. Il faut donc la documenter au lieu d’adopter une durée uniforme sans justification.

Une procédure de traçabilité peut suivre ce parcours :

1. attribuer un identifiant à chaque version du système et à chaque configuration importante ;
2. enregistrer les événements nécessaires à la compréhension d’une décision ou d’une recommandation ;
3. protéger les journaux contre la modification non autorisée ;
4. prévoir une recherche par dossier, utilisateur, date ou version ;
5. tester régulièrement la capacité à restaurer et analyser ces informations.

Les journaux ne remplacent pas une documentation de conception. Ils apportent la preuve du comportement réel en production.

Le contrôle humain : une intervention organisée, pas une présence symbolique

Le contrôle humain est souvent mal compris. La présence d’un opérateur devant un écran ne garantit pas une supervision effective. Le règlement européen exige que les systèmes à haut risque soient conçus de manière à permettre une supervision humaine appropriée pendant leur utilisation. La personne chargée de cette mission doit disposer des compétences, de l’autorité et des informations nécessaires.

Une supervision robuste doit permettre de comprendre les capacités et les limites du système, de repérer les anomalies, d’interpréter correctement une sortie et de décider de ne pas la suivre. Dans certains cas, l’opérateur doit pouvoir interrompre le système, ignorer une recommandation ou revenir à une procédure non automatisée. Ces possibilités doivent être techniquement accessibles et intégrées aux procédures de travail.

Pour organiser ce contrôle, il est utile de définir :

• qui examine les résultats et à quel moment ;
• quels signaux imposent une vérification renforcée ;
• quels cas doivent être transmis à un responsable compétent ;
• dans quelles situations la décision automatisée est interdite ou suspendue ;
• comment l’intervention humaine est enregistrée ;
• quelle formation est requise avant l’accès au système.

Le contrôle doit tenir compte du risque d’automatisation excessive. Un opérateur qui valide mécaniquement toutes les sorties n’exerce pas une supervision réelle, même si une validation est prévue dans l’interface.

Instructions d’utilisation, formation et limites à communiquer

Les instructions fournies avec un système à haut risque doivent être suffisamment détaillées pour guider un usage sûr. Elles doivent décrire la finalité prévue, les caractéristiques des données d’entrée, les performances attendues, les situations connues de défaillance, les mesures de supervision et les conditions de maintenance.

Un déployeur doit transformer ces informations en consignes adaptées à son environnement. Une documentation technique destinée à des spécialistes ne répond pas toujours aux besoins d’un agent qui utilise l’outil au quotidien. Les procédures internes doivent expliquer les termes importants, les erreurs fréquentes, les éléments à vérifier avant de prendre une décision et le canal de remontée d’un incident.

La formation peut comprendre des exercices sur des résultats ambigus, des données incomplètes et des alertes de sécurité. Elle doit aussi rappeler qu’une sortie produite par une IA constitue une information à évaluer, non une preuve automatique. Les personnes responsables d’une décision doivent savoir quand demander un examen complémentaire et quand suspendre le processus.

Les limites doivent être communiquées sans formulation vague. Une consigne comme vérifier les résultats n’indique ni quoi vérifier, ni avec quelle source, ni dans quel délai. Une consigne opérationnelle précise les critères d’alerte, la personne à contacter et la trace à conserver. Cette précision réduit le risque que la supervision repose sur l’interprétation individuelle de chaque utilisateur.

Évaluation de conformité, déclaration et surveillance après mise sur le marché

Avant la mise à disposition ou la mise en service d’un système à haut risque, le fournisseur doit suivre une procédure d’évaluation de conformité adaptée à la catégorie du système. Selon le cas, cette évaluation peut relever d’un contrôle interne ou nécessiter l’intervention d’un organisme notifié. Le fournisseur doit également établir la documentation requise, apposer le marquage de conformité lorsqu’il est applicable et enregistrer le système dans la base européenne prévue par le règlement, lorsque cette obligation s’applique.

La conformité ne s’arrête pas au lancement. Le fournisseur doit organiser une surveillance après mise sur le marché afin de recueillir et d’analyser les informations relatives aux performances, aux incidents et aux changements de contexte. Les incidents graves doivent être signalés selon les modalités et les délais prévus par le règlement européen. Les mesures correctives peuvent inclure une mise à jour, une limitation d’usage, une suspension ou un retrait.

Le déployeur doit également surveiller le fonctionnement dans son environnement. Il doit signaler les problèmes identifiés, conserver les journaux pertinents et respecter les instructions. Lorsqu’une modification importante affecte la finalité ou le comportement du système, il faut réexaminer la répartition des responsabilités et déterminer si le changement entraîne de nouvelles obligations réglementaires.

Protection des données, cybersécurité et droits des personnes

Les obligations liées à l’IA ne remplacent pas celles qui concernent la protection des données. Lorsqu’un système traite des données personnelles, il faut déterminer la base juridique, limiter les données utilisées, encadrer les accès et informer les personnes concernées selon le cadre applicable. Une analyse d’impact relative à la protection des données peut être nécessaire lorsque le traitement présente un risque élevé pour les droits et libertés.

La cybersécurité doit couvrir le modèle, les données, les interfaces et les journaux. Les menaces peuvent prendre la forme d’une modification des données d’entraînement, d’une extraction d’informations, d’une injection de contenu malveillant, d’un contournement des contrôles ou d’un accès non autorisé aux résultats. Les mesures de protection doivent être testées dans des scénarios réalistes et réévaluées après chaque évolution importante.

Les personnes affectées par une décision utilisant un système à haut risque peuvent avoir besoin d’informations sur le rôle de l’IA dans le processus. Le règlement européen prévoit aussi des dispositions concernant la transparence et, dans certains cas, le droit à une explication sur le rôle du système dans une décision. Les modalités dépendent du contexte juridique et de la nature du traitement. Une organisation doit donc articuler son dispositif IA avec ses procédures de réclamation, d’accès aux données, de rectification et de recours.

Méthode pratique pour construire un dispositif de contrôle

Une démarche progressive permet de passer des principes à des actions vérifiables. Elle peut être organisée en huit étapes :

1. Cartographier les usages. Recenser les systèmes, leurs finalités, les utilisateurs, les données traitées et les décisions influencées.
2. Qualifier le risque. Vérifier si le système relève d’une catégorie à haut risque au regard du règlement 2024/1689 et des textes sectoriels applicables.
3. Identifier les acteurs. Documenter le fournisseur, le déployeur, les sous-traitants, les responsables de validation et les personnes chargées de la supervision.
4. Exiger les preuves. Demander la documentation technique pertinente, les résultats de tests, les informations sur les versions, les limites et les incidents connus.
5. Définir les contrôles humains. Fixer les points de validation, les critères d’escalade, le pouvoir d’arrêt et la procédure de remplacement.
6. Organiser la traçabilité. Déterminer les événements journalisés, les droits d’accès, les durées de conservation et les contrôles d’intégrité.
7. Tester en conditions réelles. Utiliser des cas normaux, des données incomplètes, des situations atypiques et des scénarios de cybersécurité.
8. Réviser régulièrement. Revoir le dispositif après un incident, une modification du modèle, une évolution réglementaire ou un changement de finalité.

Cette méthode permet de distinguer les documents indispensables des supports secondaires et de vérifier que le contrôle humain fonctionne réellement.

Les erreurs qui fragilisent le dispositif

Certaines pratiques donnent une impression de conformité sans apporter de garanties suffisantes. La première consiste à copier une documentation générique fournie pour un autre contexte. Un document ne décrit pas les risques propres aux données, aux utilisateurs et aux décisions de l’organisation. Il faut vérifier l’adéquation entre la documentation et l’usage réel.

Une autre erreur est de mesurer uniquement la précision moyenne. Une moyenne peut masquer des performances très différentes selon les groupes, les langues, les types de dossiers ou les conditions de collecte. Les tests doivent inclure des indicateurs pertinents pour les conséquences de l’erreur, ainsi que des seuils qui déclenchent une revue.

La validation humaine peut aussi devenir une formalité. Lorsque le volume de recommandations est trop important, lorsque les délais sont incompatibles avec une vérification sérieuse ou lorsque l’interface présente la sortie comme certaine, la supervision perd sa portée. Il faut alors revoir le flux de travail, les seuils d’alerte ou le périmètre d’automatisation.

Enfin, l’absence de gestion des versions rend les analyses difficiles. Une organisation doit pouvoir savoir quelle version a produit un résultat, quelles données ont servi à la tester et quelles modifications ont été approuvées. Sans cette traçabilité, l’enquête après incident repose sur des reconstitutions incertaines.

Tableau récapitulatif des obligations et des preuves attendues

Domaine	Objectif	Éléments à conserver
Gestion des risques	Identifier et réduire les dangers liés au système et à son contexte	Analyse des risques, mesures de réduction, résultats de réévaluation
Données	Garantir la qualité, la pertinence et la gouvernance des jeux de données	Origine, critères de sélection, contrôles, versions et anomalies
Documentation technique	Décrire la conception, le fonctionnement et les limites	Architecture, méthodes, tests, performances et conditions d’usage
Journalisation	Reconstituer les événements et analyser les incidents	Versions, entrées utiles, sorties, alertes et interventions humaines
Contrôle humain	Permettre une intervention compétente et effective	Procédures, habilitations, formations, validations et décisions d’arrêt
Cybersécurité	Prévenir les manipulations, fuites et accès non autorisés	Tests, mesures de protection, alertes et actions correctives
Surveillance après déploiement	Détecter les dérives et les incidents dans la durée	Indicateurs, rapports, signalements, mises à jour et retraits

FAQ sur les systèmes d’IA à haut risque

Un outil d’IA utilisé en interne est-il automatiquement exempt d’obligations ?

Non. Le caractère interne de l’usage ne suffit pas à écarter les règles. La qualification dépend de la finalité, du domaine d’utilisation, des personnes concernées et des fonctions du système. Un outil utilisé pour évaluer des candidats ou influencer l’accès à un service peut présenter des risques élevés même s’il n’est pas accessible au public.

Le fournisseur doit-il transmettre tout son code source ?

La documentation exigée doit permettre d’évaluer la conformité et le fonctionnement du système, mais elle ne signifie pas automatiquement que le code source doit être remis à chaque utilisateur. Les autorités compétentes peuvent disposer de pouvoirs d’accès spécifiques. Le déployeur doit surtout obtenir les informations nécessaires à un usage sûr, à la supervision et à la traçabilité.

Une validation par un salarié suffit-elle pour assurer le contrôle humain ?

Non. La personne doit avoir le temps, les compétences, les informations et l’autorité nécessaires pour remettre en cause la sortie du système. Elle doit aussi pouvoir interrompre le processus ou demander un examen complémentaire lorsque les critères prévus sont réunis.

Que faire lorsqu’une nouvelle version du modèle est installée ?

Il faut identifier les changements, vérifier leur incidence sur les performances et les risques, refaire les tests pertinents, mettre à jour la documentation et informer les utilisateurs concernés. Une nouvelle version peut modifier les limites du système ou la manière dont les résultats doivent être interprétés.