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

Elle peut l’être si sa finalité, son déploiement ou sa documentation la font entrer dans l’Article 6 de l’AI Act. Je vois souvent des systèmes “internes” sous-estimés. Le vrai sujet, ce n’est pas juste la techno, c’est l’usage réel et les impacts possibles.

Pourquoi la finalité change tout ?

La finalité change tout parce que l’AI Act ne regarde pas seulement ce que votre IA sait faire techniquement. Il regarde surtout pourquoi elle existe, comment elle est présentée, vendue, documentée, déployée et utilisée.

Un même modèle peut résumer un document RH pour gagner du temps, ou aider à décider si un candidat passe à l’étape suivante. Techniquement, ça peut se ressembler. Réglementairement, ce n’est plus du tout la même histoire. Dans le premier cas, on automatise une tâche administrative. Dans le second, on influence une décision qui touche l’emploi d’une personne. Et là, on entre dans une zone beaucoup plus sensible.

C’est pareil avec un système qui classe des demandes clients. S’il trie des tickets SAV pour les envoyer au bon service, le risque reste souvent limité. S’il priorise des demandes d’accès à un logement, à un crédit, à une aide sociale ou à un soin, il peut toucher directement des droits, une sécurité, une santé, une opportunité de vie. Ce n’est pas la techno qui a changé. C’est l’usage.

Sur le terrain, je vois souvent un écart entre la fiche technique et la vraie vie. La fiche dit “assistant interne”. Le marketing dit “optimisez vos décisions RH”. Les prompts internes demandent “note ce candidat de 1 à 10”. Le workflow n8n envoie automatiquement un refus si le score est trop bas. Et les métiers l’utilisent comme un filtre de décision, pas comme une simple aide. C’est souvent là que le risque réglementaire apparaît.

Pour comprendre le niveau de risque réel, je regarde plusieurs éléments très concrets :

• La documentation produit et les fiches fonctionnelles.
• Les messages commerciaux, pages de vente et démonstrations.
• Les cas d’usage déclarés par les équipes.
• Les logs d’utilisation, quand ils existent.
• Le paramétrage réel, pas celui prévu au départ.
• Les équipes qui utilisent le système au quotidien.
• Les données traitées, surtout si elles sont sensibles.
• Les décisions que l’IA influence, même indirectement.

Le point de départ sérieux, c’est d’écrire noir sur blanc l’intended purpose de chaque système d’IA. L’intended purpose, c’est la finalité prévue, l’usage réel pour lequel le système est conçu et mis à disposition. Il faut le formuler sans enjoliver, sans minimiser, sans se cacher derrière “ce n’est qu’un outil”. Parce que si l’outil influence une décision importante, l’AI Act risque de le voir aussi.

Quelles sont les deux voies du haut risque ?

La réponse courte : il y a deux grandes voies pour qu’un système d’IA soit classé à haut risque selon l’Article 6 de l’AI Act. Soit l’IA est intégrée dans un produit déjà fortement réglementé en Europe, soit elle sert dans un usage sensible listé à l’Annexe III.

Première voie : l’IA dans un produit réglementé. C’est le cas quand l’IA fait partie d’un produit couvert par une législation européenne d’harmonisation. Dit simplement, ce sont des règles européennes qui encadrent certains produits avant leur vente ou leur mise en service.

Le point clé, c’est la sécurité. Si l’IA est un composant de sécurité, ou si le produit doit passer une évaluation de conformité par un organisme tiers avant d’être mis sur le marché, on entre vite dans une zone à haut risque. J’ai déjà vu ce sujet être sous-estimé parce que “ce n’est qu’un module logiciel”. Sauf que si ce module influence le comportement d’un produit physique, une erreur peut avoir des conséquences réelles. Là, on ne parle plus juste de performance modèle ou de taux d’erreur.

Deuxième voie : les usages sensibles de l’Annexe III. Ici, on regarde moins le produit lui-même et davantage l’usage. L’Annexe III vise des domaines où une IA peut affecter la santé, la sécurité ou les droits fondamentaux d’une personne.

Ce qui compte, c’est l’impact potentiel. Une IA qui aide à prendre une décision, à faire une recommandation importante, à classer une personne ou à influencer fortement son accès à une opportunité peut devenir haut risque. Même si elle ne décide pas “toute seule”, son rôle peut peser lourd dans la chaîne de décision. C’est souvent là que les équipes se trompent : elles pensent que tant qu’un humain valide à la fin, le risque disparaît. Pas forcément.

Voie de classification	Ce qu’il faut regarder	Question à se poser
Produit réglementé	IA intégrée à un produit soumis à des règles européennes, surtout si elle joue un rôle de sécurité ou si une évaluation par un tiers est nécessaire.	Est-ce qu’une erreur de l’IA peut toucher la sécurité du produit ou de ses utilisateurs ?
Usage sensible de l’Annexe III	IA utilisée dans un domaine où elle peut affecter la santé, la sécurité ou les droits fondamentaux.	Est-ce que l’IA influence fortement une décision ou une recommandation concernant une personne ?

Une fois ces deux voies identifiées, le vrai travail commence. Il faut vérifier si l’exemption prévue par l’Article 6(3) peut vraiment s’appliquer, ou si on est bel et bien face à une IA à haut risque.

L’exemption Article 6(3) suffit-elle ?

L’exemption peut aider, mais je ne l’utiliserais jamais comme un raccourci confortable. L’Article 6(3) de l’AI Act dit, en gros, qu’un système qui tombe en apparence dans un cas sensible peut ne pas être considéré comme “haut risque” s’il ne crée pas de risque significatif pour la santé, la sécurité ou les droits fondamentaux.

C’est surtout vrai quand l’IA n’influence pas matériellement une décision. “Matériellement”, ça veut dire qu’elle ne pèse pas vraiment sur le résultat final. Elle ne décide pas qui obtient un service, qui est refusé, qui est contrôlé, qui passe en priorité, qui perd une opportunité.

Dans certains cas, l’analyse peut donc être différente. Si l’IA fait une tâche procédurale très étroite, comme classer des documents sans impact direct sur une personne. Si elle prépare un travail humain, sans orienter fortement la conclusion. Si elle améliore un résultat déjà décidé par un humain, sans se substituer à lui. Ou si elle détecte des écarts, mais ne produit pas l’effet final sur la personne concernée.

Mais il y a une limite importante. Il faut documenter l’évaluation. Il faut pouvoir expliquer pourquoi le risque n’est pas significatif. Il faut montrer ce que fait vraiment le système, où il intervient dans le processus, et quelle marge de manœuvre reste à l’humain.

Et là, je vais être honnête. J’ai déjà vu des équipes me dire “l’humain décide toujours”, alors qu’en pratique l’humain clique sur valider parce que le score IA fait autorité. Personne ne veut contredire l’outil. Personne n’a le temps de refaire l’analyse. Ce détail change tout. Ce n’est plus une supervision humaine réelle, c’est une validation automatique avec une couche humaine par-dessus.

Les signaux d’alerte que je regarde en priorité sont assez simples :

• Profiling de personnes, surtout si le système évalue un comportement, une fiabilité, une performance ou une vulnérabilité.
• Score utilisé pour prioriser ou exclure, même si la décision finale est officiellement humaine.
• Recommandation suivie presque automatiquement, sans remise en question réelle par l’utilisateur.
• Absence de documentation sur l’usage, les risques, les limites et la place exacte de l’humain.
• Usage réel différent de l’usage déclaré, ce qui arrive plus souvent qu’on ne le pense.

Comment auditer vos systèmes maintenant ?

Il faut construire un inventaire vivant des systèmes d’IA, et le croiser avec cinq choses simples : l’usage, la finalité, les données, l’impact et les responsabilités. Pas un fichier Excel oublié dans un dossier conformité. Un vrai référentiel qui bouge avec vos produits, vos automatisations, vos API, vos tests internes.

L’audit ne doit surtout pas rester dans les mains du juridique seul. Le juridique lit le texte. Les équipes data voient les données. Les équipes IA comprennent les modèles. Les équipes automatisation savent ce qui tourne vraiment dans n8n, Make, Zapier ou via API. Le produit connaît l’usage client. La sécurité voit les accès. Les métiers savent l’effet réel sur une personne. C’est souvent là que les écarts apparaissent.

Je commence toujours par recenser les outils IA internes et externes. Les modèles maison, les briques SaaS, les assistants, les connecteurs dans n8n, les API IA branchées sur un CRM, les systèmes d’enrichissement de données, l’analyse de documents, la génération d’avis, le scoring, le classement, l’assistance à la décision. Aucun de ces cas n’est automatiquement à haut risque. Tout dépend de la finalité et de l’effet réel. Un scoring marketing n’a pas le même poids qu’un scoring qui influence un accès à l’emploi, au crédit ou à un service essentiel.

Je regarde aussi la documentation fournisseur, les supports de vente, les promesses produit, puis les vrais workflows de déploiement. Parce qu’entre “simple aide à la rédaction” et “outil utilisé pour pré-filtrer des candidats”, il y a parfois juste une règle d’automatisation low code ajoutée un vendredi soir. Il faut ensuite vérifier si l’Article 6 de l’AI Act est concerné. C’est l’article qui aide à qualifier certains systèmes comme “haut risque”. L’Article 6(3) peut parfois sortir un système de cette catégorie si son rôle reste limité et sans impact significatif, mais ça se documente, ça ne se devine pas.

Question d’audit	Équipe concernée	Preuve à collecter	Risque si oublié
À quoi sert vraiment le système IA ?	Produit, métiers, data	Cas d’usage, workflow, captures, règles métier	Mauvaise qualification du risque
Quelles données sont utilisées ?	Data, sécurité, conformité	Schéma de données, sources, logs, contrats	Traitement sensible non maîtrisé
Le système influence-t-il une décision sur une personne ?	Métiers, juridique, IA	Parcours utilisateur, seuils, critères de décision	Impact individuel sous-estimé
L’Article 6 ou 6(3) s’applique-t-il ?	Juridique, conformité, IA	Analyse documentée, justification, limites d’usage	Système haut risque non identifié

Ma recommandation est simple : faites cet audit maintenant. C’est beaucoup moins pénible de cadrer vos systèmes IA avant un lancement que de découvrir le sujet pendant un contrôle, un incident ou une mise en production déjà engagée.

Votre gouvernance IA tient-elle face à l’usage réel ?

Je retiens surtout une chose : avec l’AI Act, un système d’IA ne se juge pas seulement à sa technologie. Il se juge à sa finalité, à sa documentation, à son déploiement et à l’impact possible sur les personnes. L’Article 6 crée deux grandes portes d’entrée vers le haut risque, et l’exemption Article 6(3) demande une vraie analyse, pas une phrase rassurante dans un fichier conformité. Le bon réflexe, c’est d’inventorier vos IA, de qualifier les usages et de documenter vos arbitrages. Vous gagnez en clarté, vous réduisez le risque réglementaire et vous pilotez mieux vos projets IA.

FAQ

• Qu’est-ce qu’une IA à haut risque dans l’AI Act ?
  Une IA à haut risque est un système dont l’usage peut avoir un impact important sur la santé, la sécurité ou les droits fondamentaux. L’Article 6 prévoit notamment deux voies : l’intégration dans certains produits réglementés et l’utilisation dans des cas sensibles. Le point clé reste la finalité d’utilisation.
• Un outil IA interne peut-il être concerné ?
  Oui, un outil interne peut être concerné si son usage réel entre dans un cas sensible ou influence des décisions importantes. Le fait qu’il ne soit pas vendu publiquement ne suffit pas à écarter le sujet. Il faut regarder ce qu’il fait, pour qui, avec quelles données et avec quel effet.
• La documentation peut-elle changer la classification ?
  Elle ne change pas la technologie, mais elle peut révéler la finalité du système. Une fiche produit, une page commerciale, un guide utilisateur ou un workflow interne peuvent montrer que l’IA est destinée à influencer une décision sensible. C’est pour ça que la documentation doit être cohérente avec l’usage réel.
• À quoi sert l’exemption de l’Article 6(3) ?
  Elle permet, dans certains cas, de considérer qu’un système lié à un usage sensible n’est pas haut risque s’il ne présente pas de risque significatif et n’influence pas matériellement une décision. Mais cette analyse doit être documentée sérieusement. Ce n’est pas une case à cocher pour éviter la conformité.
• Que faut-il faire en premier pour se préparer ?
  Je commencerais par un inventaire des systèmes IA. Pour chaque système, il faut noter la finalité, les utilisateurs, les données, les décisions influencées, la documentation disponible et les impacts possibles. Ensuite seulement, on peut qualifier le risque et décider des actions juridiques, techniques et de gouvernance.

 

 

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, produit et conformité sur des sujets très opérationnels : gouvernance, mesure, automatisation, qualité des données et déploiement IA. 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.