Qu’est-ce qu’une IA à haut risque selon l’EU AI Act ?

Une IA à haut risque, c’est surtout une IA dont l’usage peut toucher la sécurité, la santé ou les droits fondamentaux. Le piège, c’est que la qualification dépend aussi de votre documentation, de votre marketing et de l’usage réel. Je vous montre comment trier ça proprement.

Quand une IA devient-elle à haut risque ?

Une IA devient à haut risque quand elle entre dans l’une des catégories prévues par l’article 6 de l’EU AI Act. Soit elle est intégrée à un produit déjà réglementé au niveau européen, soit elle sert à un cas d’usage sensible listé dans le règlement.

Le point important, c’est que le sujet n’est pas seulement technique. Ce n’est pas parce qu’un modèle est très puissant qu’il est automatiquement à haut risque. Et ce n’est pas parce qu’un outil paraît simple, presque banal, qu’il est forcément sans risque. Ce qui compte vraiment, c’est l’usage prévu et l’impact possible sur les personnes.

L’EU AI Act classe certains systèmes comme à haut risque lorsqu’ils peuvent avoir un effet significatif sur la santé, la sécurité ou les droits fondamentaux. Les droits fondamentaux, c’est par exemple l’accès à l’emploi, à l’éducation, à un service essentiel, ou le fait de ne pas être discriminé par une décision automatisée.

L’article 6 prévoit deux grandes routes pour qualifier une IA de haut risque :

• Première route : L’IA est liée à un produit couvert par une législation européenne d’harmonisation listée à l’annexe I. On parle par exemple de certains dispositifs médicaux, machines, jouets, ascenseurs ou équipements soumis à des règles de sécurité européennes.
• Deuxième route : L’IA est utilisée dans un domaine sensible listé à l’annexe III. On retrouve notamment l’emploi, l’éducation, l’accès aux services essentiels, la biométrie, la justice, la police, la migration ou certaines décisions liées au crédit.

J’ai déjà vu des équipes considérer un outil IA comme un simple assistant interne. Sur le papier, rien d’inquiétant. Dans les faits, l’outil influençait des décisions RH, commerciales ou de conformité. Il ne signait pas la décision finale, mais il orientait fortement les choix. C’est souvent là que le risque réglementaire démarre, dans cette zone grise entre “aide à la décision” et décision quasi automatisée.

La première étape n’est donc pas de paniquer. C’est de cartographier les systèmes IA existants, même les petits outils maison, puis de relier chaque outil à son usage concret. Qui l’utilise ? Pour décider quoi ? Avec quel impact possible sur une personne ? C’est là que l’analyse devient utile.

Pourquoi l’usage prévu compte autant ?

L’usage prévu compte autant parce que l’EU AI Act regarde comment le système est présenté, documenté, vendu, déployé et utilisé dans la réalité. La fiche produit, les supports marketing, les procédures internes et les usages terrain peuvent tous peser dans l’analyse.

Deux systèmes techniquement très proches peuvent donc finir dans deux cases différentes. Un outil qui résume des documents pour faire gagner du temps à une équipe juridique, RH ou support, ce n’est pas la même chose qu’un outil qui influence l’accès à un emploi, à un service essentiel, à une formation ou à une décision administrative. Dans le premier cas, on est souvent sur de l’assistance. Dans le second, le système peut commencer à peser sur les droits ou les opportunités d’une personne.

C’est là que ça devient concret. J’ai déjà vu des outils lancés comme de simples assistants de productivité. Au départ, ils servent à trier, résumer, suggérer. Puis, petit à petit, les équipes s’appuient dessus pour prioriser des candidats, détecter des dossiers “à risque”, recommander une décision ou accélérer un refus. Personne ne met à jour la documentation. Personne ne revoit le contrat. Mais l’usage, lui, a changé. Et c’est souvent là que le vrai risque réglementaire apparaît.

Il faut donc regarder ce que le système est censé faire, mais aussi ce qu’il fait vraiment sur le terrain. Je vérifie en général plusieurs éléments, parce qu’un seul document ne suffit presque jamais.

Documentation fournisseur	Elle indique l’usage officiellement prévu, les limites annoncées et les cas d’usage déconseillés.
Contrats et annexes	Ils peuvent préciser les responsabilités, le contexte de déploiement et les engagements du fournisseur.
Messages commerciaux	Ils montrent comment l’outil est vendu, parfois avec des promesses plus larges que la documentation technique.
Notices internes	Elles révèlent comment l’entreprise demande réellement aux équipes d’utiliser le système.
Prompts métier	Ils montrent les instructions données à l’IA, surtout quand elles orientent une analyse ou une recommandation.
Workflows automatisés	Ils permettent de voir si une sortie de l’IA déclenche une action, une alerte, un score ou une décision.
Logs d’usage	Ils prouvent l’usage réel, pas seulement l’usage théorique décrit dans les documents.
Droits utilisateurs	Ils indiquent qui peut lancer l’outil, modifier ses paramètres ou valider ses recommandations.
Décisions influencées	Elles permettent d’évaluer si le système affecte concrètement une personne, un accès ou une opportunité.

Le point clé, c’est simple. Une IA ne se classe pas seulement avec son modèle ou sa technologie. Elle se classe aussi avec son contexte d’usage.

Quels sont les deux chemins de l’article 6 ?

L’article 6 prévoit deux chemins principaux vers la qualification d’IA à haut risque. Le premier concerne les systèmes intégrés à certains produits réglementés. Le second concerne les systèmes utilisés dans des domaines sensibles listés à l’annexe III.

Le premier chemin est assez “produit”. Une IA peut être considérée à haut risque si elle est elle-même un produit, ou si elle est un composant de sécurité d’un produit, couvert par certaines réglementations européennes listées à l’annexe I. Et il faut aussi que ce produit soit soumis à une évaluation de conformité par un tiers. Dit simplement : si l’IA entre dans un produit déjà très encadré, avec des exigences fortes de sécurité, elle peut tomber dans le régime haut risque.

Je pense par exemple à des grandes familles comme les machines, les dispositifs médicaux, certains équipements de sécurité, ou plus largement des produits où la conformité ne se résume pas à une auto-déclaration rapide. Là, l’IA n’est pas regardée seule dans son coin. Elle est analysée dans le contexte du produit, de son usage, et du risque qu’elle peut créer pour les personnes.

Le second chemin est souvent plus piégeux pour les entreprises. Il concerne les cas d’usage sensibles listés à l’annexe III. On y retrouve notamment :

• La biométrie, par exemple l’identification ou la catégorisation de personnes.
• Les infrastructures critiques, quand un système peut affecter la sécurité ou l’accès à un service essentiel.
• L’éducation et la formation professionnelle.
• L’emploi, le recrutement et la gestion des travailleurs.
• L’accès à des services essentiels publics ou privés.
• L’application de la loi.
• La migration, l’asile et le contrôle aux frontières.
• La justice et certains processus démocratiques.

C’est cette deuxième voie que je vois le plus sous-estimée. Parce qu’elle ne concerne pas seulement des robots, des caméras ou des systèmes “spectaculaires”. Elle peut toucher un outil SaaS, une automatisation interne, un modèle de scoring, ou un assistant IA connecté à des données métier. Un client m’a déjà dit “On fait juste gagner du temps aux équipes”. Oui, sauf que si l’outil influence une décision RH, un accès à un service, ou une évaluation d’une personne, on n’est plus dans un simple gadget.

Les bonnes questions à poser sont simples :

• Le système influence-t-il une décision importante ?
• Touche-t-il une personne physique ?
• Intervient-il dans un domaine sensible ?
• Remplace-t-il ou oriente-t-il une évaluation humaine ?

L’exemption de l’article 6 peut-elle aider ?

Oui, l’exemption de l’article 6(3) peut aider, mais elle ne doit pas être utilisée comme une sortie facile. Elle permet de considérer certains systèmes listés à l’annexe III comme non haut risque, à condition qu’ils ne présentent pas de risque significatif pour la santé, la sécurité ou les droits fondamentaux. En pratique, ça vise surtout les cas où l’IA n’influence pas matériellement une décision. Elle aide, elle prépare, elle trie, mais elle ne pèse pas vraiment sur le résultat final.

Le piège, c’est de traiter cette exemption comme une case à cocher dans un fichier Excel. Ce n’est pas ça. L’entreprise doit documenter sérieusement pourquoi le système ne crée pas de risque significatif. Il faut pouvoir expliquer le rôle exact de l’IA, son impact réel sur la décision, les garde-fous humains, les données utilisées, et ce qui se passe si le système se trompe.

Dans les faits, l’exemption peut être envisagée dans quelques cas assez précis :

• Une tâche procédurale étroite, par exemple classer un document dans le bon dossier sans évaluer la personne concernée.
• Une amélioration d’un résultat déjà produit par un humain, comme reformuler une note ou détecter une incohérence évidente.
• Une détection de schémas ou d’écarts, tant que l’IA ne remplace pas l’appréciation humaine.
• Une tâche préparatoire, avant une vraie évaluation faite par une personne compétente.

Le point à ne pas oublier, c’est le profilage. Le profilage, c’est quand un système analyse des données personnelles pour évaluer ou prédire des aspects liés à une personne, comme sa performance, son comportement, sa fiabilité ou son risque. Si le système fait ça sur des personnes physiques, l’exemption devient beaucoup plus difficile à défendre. Le règlement met clairement ce type d’usage sous surveillance, parce qu’il peut vite toucher aux droits fondamentaux.

Dans mes missions data et IA, je préfère demander aux équipes de prouver l’exemption comme si elles devaient l’expliquer à un auditeur demain matin. Si la preuve est floue, la gouvernance n’est pas prête. Et franchement, c’est souvent là que les vrais problèmes apparaissent.

Comment auditer vos IA maintenant ?

Pour auditer vos IA maintenant, je pars d’un inventaire complet, puis je relie chaque système à son usage réel, à ses utilisateurs, aux décisions influencées et aux domaines de l’EU AI Act potentiellement concernés.

Le piège, c’est de regarder seulement les outils officiellement achetés. Ça ne suffit pas. Dans les entreprises que j’accompagne, les usages les plus sensibles sont parfois cachés dans un prototype, une automatisation no-code, un connecteur IA dans le CRM, un outil RH enrichi avec du scoring, un tableau d’analyse qui classe des dossiers, ou un agent IA interne bricolé pour accélérer une tâche métier.

Il faut aussi inclure les usages directs de modèles génératifs par les équipes. Un collaborateur qui utilise une IA pour présélectionner des CV, résumer des dossiers clients ou prioriser des demandes peut créer un vrai sujet réglementaire, même si l’outil n’a jamais été présenté comme une “IA critique”.

Ma méthode reste simple. Pour chaque système, je documente les points qui permettent de comprendre le risque réel, pas seulement la fiche produit du fournisseur.

• Le système : Nom de l’outil, version, fournisseur, intégration interne.
• Le propriétaire métier : La personne qui sait vraiment pourquoi l’outil est utilisé.
• Les données utilisées : Données RH, clients, santé, comportement, performance, documents internes.
• Les personnes concernées : Salariés, candidats, clients, usagers, partenaires.
• La décision assistée : Recrutement, accès à un service, notation, contrôle, recommandation, priorisation.
• Le niveau d’automatisation : Simple aide, recommandation forte, décision quasi automatique.
• Le contrôle humain : Qui valide, avec quelles informations, et peut-il vraiment contester la sortie de l’IA ?
• La documentation : Notice, logs, évaluation, tests, politique interne, contrat fournisseur.
• Le lien EU AI Act : Annexe I pour certaines techniques IA, Annexe III pour les domaines à haut risque comme emploi, éducation, services essentiels, police ou justice.

Ce travail doit être fait à plusieurs. Le juridique ne voit pas toujours les usages réels. La data et l’IT ne voient pas toujours l’impact réglementaire. Les métiers, eux, savent souvent où l’outil pèse vraiment dans la décision. C’est là que les vrais risques apparaissent.

Système IA	Usage réel	Domaine sensible	Impact potentiel	Documentation	Action prioritaire
Assistant RH	Tri de candidatures	Emploi	Accès à un entretien	Faible	Audit complet
Scoring client	Priorisation commerciale	Services essentiels possible	Traitement différencié	Moyenne	Vérifier critères et biais
Agent interne	Résumé de dossiers	Données sensibles possible	Erreur de synthèse	Faible	Encadrer l’usage

Votre gouvernance IA tient-elle vraiment la route ?

Une IA à haut risque ne se repère pas juste en regardant son modèle ou sa fiche technique. Il faut regarder l’usage prévu, l’usage réel, les décisions influencées et les personnes concernées. L’EU AI Act impose surtout une discipline : savoir quels systèmes IA existent, où ils sont utilisés, avec quelles données, et dans quels cas ils peuvent toucher la santé, la sécurité ou les droits fondamentaux. Mon conseil est simple : commencez par l’inventaire, documentez les arbitrages, puis traitez les zones grises avant qu’elles deviennent des urgences. Le bénéfice pour vous, c’est une IA exploitable, défendable et beaucoup moins risquée.

FAQ

• Qu’est-ce qu’une IA à haut risque dans l’EU AI Act ?
  C’est un système d’IA dont l’usage peut avoir un impact significatif sur la santé, la sécurité ou les droits fondamentaux. La qualification dépend surtout de l’usage prévu, du contexte de déploiement et du domaine concerné par l’article 6, pas seulement de la puissance technique du modèle.
• Quels systèmes IA sont concernés par l’article 6 ?
  Deux grandes familles sont concernées : les IA intégrées à certains produits réglementés soumis à conformité, et les IA utilisées dans des domaines sensibles comme l’emploi, l’éducation, les services essentiels, la biométrie, la justice, les infrastructures critiques ou la migration.
• Un outil IA interne peut-il être à haut risque ?
  Oui, s’il influence une décision importante dans un domaine sensible. Un outil interne utilisé pour aider à filtrer des candidats, orienter une décision RH ou prioriser l’accès à un service essentiel peut entrer dans une zone à risque, même s’il n’est pas vendu comme un produit réglementaire.
• L’exemption de l’article 6(3) suffit-elle à éviter le classement haut risque ?
  Pas automatiquement. L’exemption doit être justifiée et documentée. Elle peut s’appliquer si le système ne présente pas de risque significatif et n’influence pas matériellement une décision. Mais si l’outil fait du profilage ou pèse réellement sur une décision humaine, l’analyse devient beaucoup plus stricte.
• Par quoi commencer pour vérifier mes systèmes IA ?
  Je commencerais par un inventaire complet : outils achetés, prototypes, automatisations low-code, agents IA, connecteurs dans les logiciels métier. Ensuite, pour chaque système, il faut documenter l’usage réel, les données utilisées, les décisions influencées, les personnes concernées et le lien éventuel avec l’annexe I ou l’annexe III.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, analytics engineering, automatisation no/low code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent industrialiser leurs usages data et IA sans perdre le contrôle sur la conformité, la mesure et la gouvernance. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous avez besoin de cadrer vos usages IA ou vos automatisations, contactez-moi.