Votre IA est-elle à haut risque selon l’EU AI Act ?

Elle peut l’être si son usage prévu touche un produit réglementé ou un cas sensible pour la santé, la sécurité ou les droits fondamentaux. Le vrai sujet, c’est moins la techno que ce que vous documentez, vendez, déployez et laissez faire à votre IA.

Qu’est-ce qui rend une IA à haut risque ?

Une IA devient à haut risque quand son usage prévu entre dans l’une des deux voies prévues par l’article 6 de l’EU AI Act.

Le point central, c’est l’usage prévu du système. Pas juste le modèle utilisé, pas juste le fait que ce soit du machine learning, un LLM ou une automatisation un peu avancée. Ce qui compte, c’est ce que l’IA est censée faire, dans quel contexte, avec quelles conséquences possibles.

Quand je parle d’usage prévu, je parle de ce qui ressort de la documentation, des instructions d’utilisation, des supports commerciaux, du déploiement réel et des conditions d’usage annoncées. C’est souvent là que les choses se compliquent. Une entreprise peut dire “c’est juste un outil interne”, alors qu’en pratique l’outil aide à trier des candidats, prioriser des dossiers médicaux ou orienter une décision de crédit. Là, on n’est plus dans le gadget.

L’EU AI Act, le règlement européen 2024/1689, est entré en vigueur le 1er août 2024, avec une application progressive. La logique est assez simple sur le papier. Deux voies peuvent faire basculer un système dans la catégorie haut risque.

• Première voie. L’IA est intégrée à certains produits réglementés listés à l’annexe I. C’est le cas surtout quand elle agit comme composant de sécurité, ou quand le produit lui-même doit passer par une évaluation de conformité par un tiers.
• Deuxième voie. L’IA est utilisée dans un domaine sensible listé à l’annexe III, et elle peut affecter de façon significative la santé, la sécurité ou les droits fondamentaux des personnes.

Voie de classification	Ce qu’il faut regarder	Point d’attention
Annexe I	Le produit dans lequel l’IA est intégrée, son rôle de sécurité, et l’existence d’une évaluation de conformité par un tiers.	Une IA embarquée dans un dispositif réglementé peut devenir haut risque même si le modèle semble banal.
Annexe III	Le domaine d’usage réel, comme l’emploi, l’éducation, le crédit, la justice, la santé ou les services essentiels.	Le vrai risque vient souvent de l’influence sur une décision sensible, même si l’humain garde le dernier mot.

Le piège classique, je le vois souvent chez les clients, c’est de raisonner par technologie. “C’est juste un scoring”, “c’est juste une recommandation”, “c’est juste un chatbot”. Mauvais réflexe. La bonne question, c’est plutôt : Est-ce que cette IA influence une décision qui peut changer concrètement la vie d’une personne ? Si oui, il faut regarder l’article 6 de très près.

Pourquoi l’usage prévu change tout ?

L’usage prévu, c’est souvent le vrai point de départ. Pas le modèle, pas l’algorithme, pas le niveau de sophistication technique. Ce que le régulateur va regarder en premier, c’est à quoi sert le système, dans quel contexte il est utilisé, et quel effet il peut avoir sur une personne.

Deux IA très proches techniquement peuvent donc tomber dans des niveaux de risque différents. Un outil de scoring, de recommandation ou de priorisation peut être assez banal s’il aide à classer des tickets support. Le même type d’outil devient beaucoup plus sensible s’il influence l’accès à un emploi, à une formation, à un service essentiel ou à une prestation.

Usage	Lecture du risque
Prioriser des demandes internes sans impact direct sur des droits ou opportunités	Risque souvent plus faible, à confirmer selon le contexte réel
Classer des candidats, des apprenants, des bénéficiaires ou des demandes sensibles	Risque potentiellement élevé, surtout si le résultat influence une décision importante

Le piège, c’est de croire que la qualification se joue uniquement dans la fiche technique du modèle. En réalité, il faut aligner tout ce qui raconte l’usage réel du système. La documentation produit, les fiches internes, le discours commercial, les contrats, les logs d’usage, le paramétrage, les workflows métiers et les consignes données aux utilisateurs doivent raconter la même histoire.

J’ai déjà vu des équipes data penser que le risque était faible parce que le modèle ne décidait pas seul. Sur le papier, l’humain gardait la main. Dans les faits, l’interface mettait un score très visible, poussait une recommandation par défaut, et rendait l’option contraire beaucoup moins naturelle. Là, on n’est plus dans une simple aide neutre. On touche à ce que j’appelle l’influence matérielle sur le résultat, c’est-à-dire la capacité réelle du système à orienter fortement la décision finale.

Les signaux suivants doivent déclencher une revue juridique et gouvernance :

• Le système influence l’accès à un emploi, une formation, un service essentiel ou une prestation.
• Le score ou la recommandation est présenté comme prioritaire dans l’interface.
• Les utilisateurs suivent presque toujours la sortie de l’IA.
• Le discours commercial promet une sélection, un classement ou une optimisation de décisions sensibles.
• Les logs montrent que l’IA modifie réellement les décisions métier.

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

L’article 6(3) peut aider, oui. Mais je le vois souvent mal compris. Ce n’est pas une sortie magique du statut “haut risque”. C’est plutôt une porte étroite, à condition de pouvoir montrer que votre système d’IA ne crée pas de risque significatif pour la santé, la sécurité ou les droits fondamentaux.

En clair, même si votre IA tombe dans une catégorie sensible listée par l’EU AI Act, elle peut ne pas être considérée comme haut risque dans certains cas précis.

• Si elle n’influence pas matériellement le résultat d’une décision.
• Si elle réalise une tâche procédurale très limitée, par exemple classer un dossier dans une file de traitement.
• Si elle améliore le résultat d’une activité humaine déjà réalisée, sans remplacer le jugement humain.
• Si elle détecte des schémas, anomalies ou écarts, mais laisse un humain examiner et décider réellement.
• Si elle prépare une évaluation, sans produire elle-même la décision finale ou une recommandation déterminante.

Le point dur, c’est celui-ci : si le système fait du profilage de personnes physiques, il reste considéré comme haut risque. Le profilage, c’est quand l’IA analyse ou prédit des aspects liés à une personne, comme son comportement, sa performance, sa fiabilité, sa santé, sa situation économique ou ses préférences. Là, l’exemption ne sauve pas le projet.

Situation où l’exemption peut être envisagée	Preuves attendues	Limites
L’IA trie, classe ou prépare des dossiers sans orienter la décision.	Une description claire du rôle exact du système, avec exemples de sorties et logs d’usage.	Si le tri change réellement les chances d’une personne, le risque revient.
L’IA détecte des anomalies pour aider un humain à vérifier.	Une preuve que l’humain garde un examen réel, pas juste une validation automatique.	Si les équipes suivent presque toujours l’IA, l’influence devient matérielle.
L’IA améliore une analyse déjà faite par un professionnel.	Une comparaison entre le processus sans IA et avec IA, avec contrôle des impacts.	Si l’IA devient la source principale de jugement, l’exemption devient fragile.

Je le dis franchement, une auto-évaluation bâclée peut devenir un risque en soi. J’ai déjà vu un client écrire “pas haut risque” dans un fichier interne, sans test, sans justification métier, sans validation juridique. Le problème n’était pas seulement l’IA. Le problème, c’était l’absence de preuve.

Une bonne justification doit être documentée, testable et compréhensible par les équipes juridiques, gouvernance, data et métier. Si personne ne peut expliquer pourquoi l’IA n’influence pas vraiment la décision, alors l’exemption repose sur du sable.

Que doivent faire les équipes maintenant ?

Le bon réflexe, maintenant, c’est de sortir du débat théorique et de regarder ce qui tourne vraiment dans l’entreprise. Beaucoup d’équipes pensent “modèles IA”, alors qu’il faut penser “systèmes IA en usage”. C’est là que le risque réglementaire apparaît.

Je commencerais par créer un inventaire vivant des systèmes IA. Pas seulement les outils développés en interne. Il faut aussi inclure les outils achetés, les fonctionnalités IA déjà intégrées dans les logiciels métiers, les automatisations branchées via API, c’est-à-dire une interface qui permet à deux systèmes de communiquer, et les usages un peu cachés dans les équipes.

Pour chaque système, je documenterais les éléments qui permettent de classifier proprement l’usage :

• L’usage prévu, pas seulement la technologie utilisée.
• Les utilisateurs internes ou externes.
• Les personnes affectées par le résultat du système.
• Les décisions influencées ou automatisées.
• Les données utilisées, surtout si elles sont sensibles ou personnelles.
• Le degré d’automatisation, de simple aide à la décision jusqu’à décision quasi automatique.
• La présence réelle d’un contrôle humain, pas juste une case “validation humaine” dans un process.

Ensuite, je vérifierais si le système tombe dans l’article 6(1), qui vise certains systèmes liés à des produits réglementés, ou dans l’article 6(2), qui renvoie aux usages listés dans l’annexe III. Ça couvre par exemple l’emploi, l’éducation, l’accès à certains services essentiels, la justice ou la biométrie. Si le système semble dans l’annexe III, il faut regarder si une exemption de l’article 6(3) peut être justifiée. Mais là, il faut être solide. Une exemption se documente, elle ne se décide pas à l’instinct.

J’ai vu des clients perdre des semaines parce que le juridique attendait la data, la data attendait l’IT, et les métiers pensaient que “l’IA” était un sujet central. Il faut répartir les rôles clairement. Juridique pour l’interprétation du texte, gouvernance pour la méthode, data pour les modèles, IT pour l’intégration, sécurité pour les risques techniques, métiers pour l’usage réel.

Les échéances à garder en tête restent à manier avec prudence. Les obligations générales pour les systèmes à haut risque de l’annexe III s’appliquent à partir du 2 août 2026. Certains systèmes liés à des produits réglementés ont une échéance au 2 août 2027.

Je préfère largement un inventaire imparfait mais vivant à un grand fichier parfait abandonné après trois semaines.

Action	Responsable	Livrable
Recenser les systèmes IA utilisés	Gouvernance, IT, métiers	Inventaire vivant des systèmes IA
Décrire l’usage réel et les impacts	Métiers, data, juridique	Fiche d’usage par système
Classifier selon l’article 6(1), 6(2) ou 6(3)	Juridique, gouvernance, data	Décision de classification documentée
Valider les contrôles et responsabilités	Sécurité, IT, métiers	Plan d’actions et propriétaires nommés

Comment éviter une mauvaise classification ?

Je vois souvent la même erreur : on classe une IA au lancement, on range le document dans un dossier, puis le produit vit sa vie. Mauvaise idée. Avec l’EU AI Act, la qualification du risque doit rester vivante, parce que l’usage réel compte autant que l’intention de départ.

Un système peut changer de statut sans changer de nom. Il suffit que le produit évolue, que le discours commercial promette autre chose, qu’un nouveau département l’utilise, ou que les données traitées deviennent plus sensibles. Même chose si le workflow métier transforme une simple recommandation en quasi-décision. Sur le papier, l’IA “aide”. Sur le terrain, tout le monde suit son score sans discuter. Là, le risque n’est plus le même.

Les erreurs les plus fréquentes sont assez classiques, et franchement je les ai vues chez des clients très structurés :

• Une documentation trop vague, avec des phrases comme “outil d’aide à la décision”, sans expliquer quelle décision, qui l’utilise, et avec quel impact.
• Un usage réel jamais vérifié, alors que les équipes ont adapté l’outil à leur manière.
• Une dépendance excessive au fournisseur, sans preuve concrète sur les données, les limites du modèle, ou les changements de version.
• Une absence de preuve sur le contrôle humain, alors que c’est souvent le point clé.
• Une confusion entre assistance et influence réelle, parce qu’un outil qui “suggère” peut quand même orienter fortement une décision.

Le plus simple, c’est d’installer une revue périodique. Pas un comité énorme. Juste un rendez-vous régulier, avec les bonnes questions et des traces propres.

Question	Pourquoi ça compte
Est-ce que l’IA touche une décision sensible ?	Parce que l’emploi, le crédit, l’éducation, la santé ou l’accès à un service changent vite le niveau de risque.
Est-ce qu’une personne peut être affectée ?	Parce que l’impact humain est au cœur de la classification.
Est-ce que l’humain garde une vraie marge de manœuvre ?	Parce qu’un bouton “valider” ne suffit pas si personne n’ose contredire l’IA.
Est-ce que la documentation correspond encore au terrain ?	Parce que les usages dérivent plus vite que les documents.
Est-ce que les logs permettent de comprendre l’usage ?	Parce qu’il faut pouvoir prouver ce qui s’est passé, pas seulement l’affirmer.

Pour moi, la bonne approche tient en une phrase : classer, surveiller, prouver. C’est moins sexy qu’une démo IA, mais c’est ce qui protège vraiment l’entreprise. Une classification propre réduit le risque réglementaire, mais aussi le risque business : moins de mauvaises surprises, plus de confiance côté utilisateurs, et une IA qu’on peut défendre si quelqu’un demande des comptes.

Alors, votre IA mérite-t-elle une vraie revue maintenant ?

Je retiens une chose simple, avec l’EU AI Act, le risque ne se juge pas juste sur le modèle. Il se juge sur l’usage prévu, la manière dont le système est présenté, déployé et utilisé. Si votre IA touche un produit réglementé ou une décision sensible, il faut la regarder sérieusement. L’exemption de l’article 6(3) peut aider, mais elle doit être prouvée, pas supposée. Le bon réflexe, c’est l’inventaire, la documentation, la revue métier et juridique, puis un suivi dans le temps. Le bénéfice pour vous, c’est clair, moins d’incertitude et des systèmes IA plus solides.

FAQ

• Qu’est-ce qu’un système d’IA à haut risque selon l’EU AI Act ?
  C’est un système qui entre dans les critères de l’article 6. Il peut être lié à un produit réglementé ou utilisé dans un domaine sensible susceptible d’affecter la santé, la sécurité ou les droits fondamentaux des personnes.
• Pourquoi l’usage prévu est-il aussi important ?
  Parce que la classification dépend de ce que le système est censé faire, de la façon dont il est documenté, vendu, configuré et utilisé. Une IA techniquement simple peut devenir sensible si elle influence une décision importante pour une personne.
• L’article 6(3) permet-il d’éviter la catégorie haut risque ?
  Il peut permettre une exemption si le système ne présente pas de risque significatif et n’influence pas matériellement le résultat d’une décision. Mais il faut le démontrer avec une documentation solide. Et si le système fait du profilage de personnes physiques, il reste considéré comme haut risque.
• Qui doit s’occuper de cette classification dans l’entreprise ?
  Ce n’est pas seulement un sujet juridique ou data. Les équipes juridiques, gouvernance, IT, sécurité, métiers et parfois achats doivent travailler ensemble. Le métier connaît l’usage réel, la data connaît le système, le juridique cadre le risque.
• Quelle est la première action à lancer ?
  Je commencerais par un inventaire simple des systèmes IA. Pour chaque outil, notez l’usage prévu, les utilisateurs, les personnes affectées, les décisions influencées, les données utilisées et le niveau de contrôle humain. C’est la base pour savoir si l’article 6 s’applique.

 

 

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 data, marketing, juridiques et métiers sur des sujets très concrets, de la gouvernance des données à l’industrialisation de workflows IA. Avec webAnalyste et Formations Analytics, 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. Si vous voulez cadrer vos usages IA et avancer sans usine à gaz, contactez-moi.