Quand la surveillance humaine s'applique et que faire ensuite

La surveillance humaine en vertu de la loi de l'UE sur l'IA s'applique en tant qu'exigence juridique spécifique aux systèmes d'IA à haut risque. Il n'est pas satisfait simplement parce qu'un employé peut voir un résultat ou parce qu'une politique dit qu'une personne reste responsable. Les prestataires doivent concevoir des systèmes à haut risque afin que les personnes physiques puissent les superviser efficacement, tandis que les déployeurs doivent confier la supervision à des personnes possédant les compétences, la formation, l'autorité et le soutien nécessaires.

Pour une équipe SaaS, la séquence pratique est la suivante : classer le système, identifier si l'entreprise agit en tant que fournisseur ou déployeur, définir ce que l'humain peut réellement comprendre et changer, tester le chemin d'intervention et conserver les preuves. Si le système ne présente pas de risque élevé, l'examen humain peut toujours constituer un produit approprié, en matière de sécurité, de confidentialité ou de contrôle contractuel, mais cela est différent de prétendre que l'article 14 s'applique.

Pourquoi la surveillance humaine est importante dans la pratique

La loi sur l’IA considère la surveillance comme un moyen de prévenir ou de minimiser les risques pour la santé, la sécurité et les droits fondamentaux qui subsistent même après l’application d’autres contrôles. L'article 14 précise que les mesures doivent être proportionnées aux risques, à l'autonomie et au contexte d'utilisation du système. On s'attend également à ce que la personne désignée soit capable, le cas échéant, de comprendre les limites, de surveiller le fonctionnement, de reconnaître les biais d'automatisation, d'interpréter les sorties, d'ignorer ou d'inverser une sortie et d'arrêter le système en toute sécurité.

Cela fait de la surveillance une capacité opérationnelle et non une approbation cérémonielle. Un évaluateur qui manque de temps, d’informations sur le système, d’accès ou d’autorité ne peut pas assurer une surveillance significative. Personne ne peut non plus intervenir efficacement si le produit présente une recommandation comme définitive, cache une incertitude ou n'offre aucune dérogation utilisable.

Ceci est étroitement lié aux attentes en matière de gouvernance de l'IA pour les fournisseurs SaaS. Les acheteurs se demandent de plus en plus non seulement si un être humain est « au courant », mais également où l’intervention a lieu et quelles preuves montrent qu’elle fonctionne.

Lorsque l'exigence de la loi sur l'IA s'applique

Commencez par la classification, pas par une liste de contrôle de surveillance. Selon l’article 6, un système peut présenter un risque élevé de deux manières principales :

1. Il s’agit d’un produit, ou d’un composant de sécurité d’un produit, couvert par la législation européenne spécifique en matière de sécurité des produits et soumis à une évaluation de conformité par un tiers.
2. Son objectif prévu relève d'un cas d'utilisation à haut risque de l'annexe III, soumis au filtre de l'article 6, paragraphe 3, et à ses exceptions.

L'annexe III couvre les utilisations définies dans des domaines tels que la biométrie, les infrastructures critiques, l'éducation, l'emploi, l'accès aux services essentiels, l'application de la loi, la migration et l'administration de la justice. Être « alimenté par l’IA », traiter des données personnelles ou influencer un flux de travail commercial ordinaire ne rend pas automatiquement un système à haut risque au sens de l’article 6.

Pour certains systèmes de l’annexe III, l’article 6, paragraphe 3, offre une possibilité de sortir de la classification à haut risque lorsque le système ne présente pas de risque significatif de préjudice et remplit les conditions énumérées – par exemple lorsqu’il exécute une tâche procédurale ou préparatoire étroite. Le profilage de personnes physiques dans un cas d’utilisation de l’annexe III reste à haut risque. Un fournisseur qui s'appuie sur le filtre doit documenter cette évaluation.

La classification dépend fortement de l'objectif visé et du rôle réel. Une entreprise SaaS peut être fournisseur lorsqu'elle développe ou fait développer un système et le commercialise ou le met en service sous son propre nom. Il peut être déployeur lorsqu'il utilise le système d'IA d'un autre fournisseur sous son autorité. Une entreprise peut également créer des obligations de fournisseur en modifiant substantiellement un système à haut risque ou en changeant sa destination d'une manière qui le rend à haut risque. Les équipes doivent confirmer les règles transitoires actuelles avant de traiter une obligation future comme déjà applicable.

Lisez l'aperçu pratique de la loi européenne sur l'IA pour les fournisseurs SaaS ainsi que l'évaluation de la classification.

Lorsque l'article 14 ne s'applique pas

L’article 14 n’est pas une règle universelle pour chaque chatbot, synthétiseur, fonctionnalité de recommandation, signal de fraude ou copilote interne. Si un système ne relève pas du champ d'application de la loi sur l'IA, n'est pas un système d'IA au sens de la loi ou n'est pas classé comme à haut risque, l'exigence de système à haut risque de l'article 14 ne s'applique pas à lui.

Cela ne signifie pas qu’« aucun examen humain n’est nécessaire ». D'autres obligations peuvent découler de règles de protection des données, de consommation, d'emploi, spécifiques au secteur, de sécurité ou contractuelles. Une évaluation des risques peut également montrer que l’approbation humaine constitue le contrôle le plus proportionné, même sans mandat légal spécifique.

Utilisez un langage précis dans les enregistrements et les réponses des clients :

• Exigence légale : "Le système présente un risque élevé et ces mesures mettent en œuvre les articles 14 et 26."
• Contrôle des risques : "Le système n'est actuellement pas classé comme à haut risque, mais un examen humain est requis par notre politique de risque interne."
• Question ouverte : "La classification dépend de l'objectif final prévu et du contexte de déploiement ; le lancement est bloqué jusqu'à ce que cette évaluation soit approuvée."

Cette distinction empêche les équipes d’exagérer la conformité et facilite la gestion des modifications ultérieures.

Responsabilités du fournisseur et du déployeur

Les fournisseurs et les déployeurs ont un travail connecté mais différent.

Fournisseurs : conception d'une surveillance dans le système

Un prestataire doit traduire l’évaluation des risques en mesures techniques et procédurales utilisables. Selon le cas d'utilisation, cela peut inclure :

• démontrant une confiance, des limites et un contexte de saisie pertinents ;
• rendre visibles les anomalies et les performances inattendues ;
• empêcher l'interface d'encourager l'acceptation aveugle ;
• permettre aux personnes autorisées d'ignorer, d'ignorer, d'inverser ou d'interrompre les sorties ;
• définir les mesures de surveillance que le déployeur doit mettre en œuvre ; et
• expliquer clairement ces mesures dans la notice d'utilisation.

La conception doit correspondre aux conditions de travail prévisibles. Une dérogation cachée derrière un flux de travail d'administrateur peut s'avérer inutile lorsqu'un réviseur de première ligne doit agir immédiatement.

Déployeurs : rendre la supervision opérationnelle

L’article 26 exige que les déployeurs de systèmes à haut risque confient la surveillance à des personnes physiques possédant les compétences, la formation, l’autorité et le soutien nécessaires. Les déployeurs doivent utiliser le système conformément à ses instructions, surveiller son fonctionnement, agir en cas de risques identifiés ou d'incidents graves et conserver sous leur contrôle les journaux générés automatiquement pendant une période appropriée d'au moins six mois, sauf disposition contraire d'une autre loi applicable.

Sur le plan opérationnel, cela signifie choisir des rôles nommés, protéger le temps de révision, contrôler l'accès, définir l'escalade et vérifier si les instructions du fournisseur correspondent au déploiement réel. Un employé ne peut être tenu responsable d’un dépassement qu’il n’est pas autorisé à effectuer.

Un workflow de surveillance humaine pratique

1. Rédigez un enregistrement de classification délimité

Enregistrez le système, l’objectif prévu, les utilisateurs, les personnes concernées, les entrées, les sorties, l’impact de la décision, les rôles du fournisseur/déployeur et la voie envisagée au titre de l’article 6. Liez la conclusion à la version du produit et au contexte de déploiement. Réévaluez-le lorsque l’un ou l’autre change.

2. Cartographier les décisions et les modes de défaillance

Identifiez où les résultats de l’IA peuvent affecter une personne, la sécurité, l’accès, la priorisation ou un processus réglementé. Pour chaque point, décrivez des erreurs réalistes : une fausse correspondance, une exception manquée, un classement biaisé, un résumé trompeur, une recommandation peu sûre ou une dérive des performances.

3. Définir l'action de l'humain, pas seulement sa présence

Pour chaque décision importante, précisez :

• quelles informations l'évaluateur voit ;
• ce qu'ils doivent vérifier de manière indépendante ;
• quand ils doivent rejeter ou faire remonter ;
• s'ils peuvent mettre en pause, annuler ou annuler le résultat ;
• la rapidité avec laquelle ils doivent agir ; et
• qui a l'autorité finale.

Évitez les contrôles vagues tels que « un responsable examine si nécessaire ». Un déclencheur et une règle de décision rendent le contrôle testable.

4. Entraînez-vous pour la tâche réelle

La formation doit couvrir l'objectif prévu du système, les limites connues, les signaux pertinents, les biais d'automatisation, les utilisations interdites, les outils d'intervention, la tenue des dossiers et la remontée des informations. Confirmez la compétence à travers des scénarios, pas seulement la présence. Cela complète les questions plus larges que les équipes devraient poser avant d'adopter de nouveaux outils d'IA en interne.

5. Testez le chemin complet

Exécutez des exercices réalistes. Le réviseur peut-il repérer un mauvais résultat ? Ont-ils suffisamment de contexte ? La dérogation fonctionne-t-elle ? L’arrêt du système le laisse-t-il dans un état sûr ? L'événement est-il enregistré ? L’escalade atteint-elle quelqu’un qui peut agir ?

Enregistrez les défauts et retestez après les correctifs. Une capture d'écran d'un écran d'approbation prouve bien moins qu'un scénario terminé avec les résultats attendus et observés.

6. Surveiller et améliorer

Suivez les remplacements, les annulations, les escalades, les plaintes, les détections manquées, les désaccords des évaluateurs et les performances anormales. Les tendances peuvent révéler une formation faible, une interface inutilisable, des entrées modifiées ou un système fonctionnant en dehors de son objectif approuvé. Définissez les seuils qui déclenchent une enquête, une suspension ou une réévaluation.

Erreurs courantes

• Classification par étiquette de produit. Un nom de fonctionnalité ne détermine pas si l'utilisation prévue est à haut risque.
• Utiliser « l'humain dans la boucle » comme contrôle global. La présence sans information, sans temps ou sans autorité ne constitue pas une surveillance efficace.
• La révision après la conséquence est irréversible. Le point d'intervention doit avoir lieu pendant que la personne peut encore changer le résultat.
• Laisser le même résultat se valider. Une vérification indépendante nécessite des preuves supplémentaires, pas une seconde lecture de l'explication de l'IA.
• Ignorer les biais d'automatisation. Des résultats précis à plusieurs reprises peuvent rendre les évaluateurs moins susceptibles de contester l'échec exceptionnel.
• Laisser la propriété à « l'entreprise ». Nommer un rôle responsable et un remplaçant opérationnel.
• Ne conserver aucune preuve. Les politiques à elles seules ne montrent pas que les évaluateurs ont été formés, que les remplacements ont fonctionné ou que les problèmes ont été signalés.

Exemple : sélection de candidats assistée par l'IA

Supposons qu'un fournisseur SaaS propose un logiciel qui classe les candidats pour un employeur. Les utilisations de l’IA liées à l’emploi répertoriées à l’annexe III peuvent présenter un risque élevé. Le fournisseur doit donc compléter et documenter l’évaluation au titre de l’article 6 plutôt que de supposer qu’un recruteur cliquant sur « approuver » résout le problème.

Une surveillance significative pourrait obliger le recruteur à examiner les facteurs pertinents pour la recommandation, à vérifier les informations sources, à identifier les données manquantes ou trompeuses, à ignorer le classement, à rétablir un candidat et à faire remonter les soupçons de biais systématiques. L'employeur, en tant que déployeur, affecterait des personnes formées avec autorité et surveillerait le système conformément aux instructions.

En revanche, un outil interne qui reformate un e-mail rédigé par un recruteur sans classer les candidats ni influencer une décision d'emploi peut ne pas relever de ce cas d'utilisation à haut risque. L'équipe peut toujours interdire les entrées sensibles et exiger l'approbation humaine avant l'envoi, mais elle doit documenter cela comme un contrôle interne plutôt que de le décrire automatiquement comme une conformité à l'article 14.

FAQ

Quel est le but pratique de la surveillance humaine ?

Son objectif est de permettre aux personnes compétentes de comprendre, de surveiller et d'intervenir afin de prévenir ou de réduire les risques résiduels pour la santé, la sécurité ou les droits fondamentaux. Le flux de travail doit leur fournir des informations, du temps, des outils et une autorité réels.

Quand la surveillance humaine s'applique-t-elle aux équipes SaaS ?

Les obligations spécifiques de l’AI Act s’appliquent lorsque l’équipe fournit ou déploie un système d’IA à haut risque. D’autres systèmes d’IA peuvent encore nécessiter un examen humain en raison d’une autre loi, d’un autre contrat, d’une autre évaluation des risques ou d’une autre politique interne.

Une approbation humaine finale est-elle suffisante ?

Pas automatiquement. L'approbation n'a de sens que si l'examinateur peut comprendre les limites pertinentes, détecter les problèmes, contester le résultat et modifier ou arrêter le résultat avant qu'un préjudice ne survienne.

Que doivent documenter les équipes en premier ?

Commencez par le dossier de classification et le but recherché. Documentez ensuite les personnes responsables, examinez les déclencheurs, les informations affichées, les interventions autorisées, le chemin d'escalade, la formation, les résultats des tests et les preuves de fonctionnement.

Chaque décision de l'IA doit-elle être vérifiée par deux personnes ?

L'article 14 comprend une règle spécifique de vérification par deux personnes pour certains systèmes d'identification biométrique à distance, avec des exceptions définies. Ce n’est pas une règle générale pour tous les systèmes d’IA à haut risque.

Que faire maintenant

Classez le cas d’utilisation avant de promettre que la « surveillance humaine » le résoudra. Si le système présente un risque élevé, connectez les mesures techniques du fournisseur aux personnes, autorisations et procédures réelles du déployeur. Testez ensuite le chemin et conservez la preuve qu'un humain peut reconnaître les problèmes et agir à temps.

C’est la différence entre une personne proche du système et une surveillance humaine efficace.

Sources

• Règlement (UE) 2024/1689 (Loi sur l'intelligence artificielle)
• Article 6 : Règles de classification des systèmes d'IA à haut risque
• Article 14 : Contrôle humain
• Article 26 : Obligations des déployeurs de systèmes d'IA à haut risque