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

Une partie de vos IA peut déjà entrer dans la catégorie haut risque si l’usage touche la santé, la sécurité ou les droits fondamentaux. Le vrai sujet, ce n’est pas juste la techno. C’est l’intention, la documentation, le déploiement réel et les preuves que vous gardez.

Vos IA sont-elles déjà concernées ?

Oui, certaines IA déjà en production peuvent être concernées par l’EU AI Act, même si personne dans l’entreprise ne les a jamais appelées “IA à haut risque”. C’est souvent là que le sujet devient inconfortable. On pense avoir un outil d’aide, un scoring interne, un modèle de priorisation, un chatbot métier assez classique… et juridiquement, le contexte d’usage change tout.

L’EU AI Act ne regarde pas seulement la puissance technique du système. Il regarde surtout ce que l’IA fait concrètement, où elle est utilisée, par qui, et avec quel impact possible sur les personnes. Une IA très simple peut donc devenir sensible si elle influence une décision liée à l’emploi, à l’accès à un service, à la sécurité, à la santé ou aux droits fondamentaux.

Je le vois souvent sur le terrain. Le vrai problème ne vient pas toujours du modèle au départ. Il vient du décalage entre l’usage prévu et l’usage réel après quelques mois. Au début, l’outil sert à “aider” une équipe. Puis il devient une recommandation suivie automatiquement. Puis il entre dans un processus métier. Puis plus personne ne sait vraiment si l’humain décide encore ou s’il valide juste ce que l’IA propose.

Un exemple simple : un modèle qui classe des candidatures peut sembler banal côté data. Techniquement, c’est parfois juste un score ou une extraction de mots-clés. Mais dès qu’il influence l’accès à un entretien, on touche à l’emploi. Le sujet n’est plus “est-ce que le modèle est sophistiqué ?”. Le sujet devient “est-ce qu’il peut avoir un effet réel sur une personne ?”.

La suite logique, c’est de regarder l’article 6 de l’EU AI Act, parce que c’est lui qui aide à qualifier les systèmes à haut risque. Mais avant ça, je préfère toujours revenir à une question plus simple : quelle était l’intention déclarée au départ, et qu’est-ce que les équipes font vraiment avec l’outil aujourd’hui ? C’est souvent dans cet écart qu’on trouve les risques.

Les signaux faibles à repérer sont assez concrets :

• Une IA utilisée dans un processus métier sensible.
• Une documentation floue sur l’objectif réel du système.
• Un usage élargi sans revue juridique, métier ou conformité.
• Un fournisseur qui promet un usage très large, sans cadrage précis.
• Une absence de propriétaire métier clairement identifié.

Comment l’article 6 classe-t-il le risque ?

L’article 6 classe un système IA comme haut risque par deux grandes voies : soit parce qu’il est intégré à un produit déjà réglementé, soit parce qu’il sert dans un cas d’usage sensible avec un impact significatif possible.

La première voie concerne les systèmes IA qui sont composants de sécurité d’un produit, ou qui sont eux-mêmes utilisés dans un produit soumis à une évaluation de conformité par une réglementation européenne. Dit simplement, si l’IA participe au fonctionnement sûr d’un dispositif médical, d’une machine industrielle, d’un ascenseur, d’un jouet connecté ou d’un équipement critique, on ne la regarde pas comme un simple logiciel. On la regarde comme une partie du produit qui peut créer un risque réel si elle se trompe.

La deuxième voie concerne les systèmes IA déployés dans des domaines sensibles listés par l’EU AI Act. On parle par exemple d’éducation, d’emploi, d’accès à des services essentiels, de maintien de l’ordre, de migration, de justice ou de gestion démocratique. Là, la question n’est pas juste “Est-ce que le modèle est puissant ?”. La vraie question, c’est “Est-ce que son usage peut avoir un effet sérieux sur la santé, la sécurité ou les droits fondamentaux d’une personne ?”.

Ce point est important : la classification ne dépend pas uniquement du modèle. Elle dépend de l’intention et de l’usage. Comment le système est documenté. Comment il est vendu. Comment il est configuré. Comment il est déployé. Comment les équipes l’utilisent vraiment sur le terrain. J’ai déjà vu chez un client un outil présenté comme une simple aide au tri devenir, dans les faits, un filtre automatique de candidats. Le risque change dès que l’usage change.

Les lignes directrices de la Commission européenne cherchent justement à clarifier cette lecture pratique. Elles aident à passer du texte juridique à la réalité opérationnelle. Et là, il faut que les équipes se parlent. Juridique, data, produit, conformité et métiers. Sinon chacun voit seulement un bout du problème, et personne ne voit le risque complet.

Voie de classification	Ce qu’il faut vérifier
IA intégrée à un produit réglementé	Le système est-il un composant de sécurité ou utilisé dans un produit soumis à une évaluation de conformité européenne ?
IA utilisée dans un domaine sensible	L’usage peut-il avoir un impact significatif sur la santé, la sécurité ou les droits fondamentaux ?

Que faut-il vérifier en interne ?

Il faut vérifier le périmètre réel des systèmes IA, leur documentation, leur usage métier et les preuves disponibles. Pas l’intention de départ. Pas la slide comité. Ce qui compte, c’est ce que l’outil fait vraiment aujourd’hui, avec qui, sur quelles données, et avec quel impact sur une personne.

Je n’attaquerais pas ça par un grand chantier abstrait de gouvernance IA. J’ai vu trop d’équipes passer trois mois à écrire une politique IA sans savoir combien d’outils étaient déjà utilisés dans les RH, le crédit, la conformité ou le support client. Je commencerais par un inventaire court, utile, relié aux usages sensibles.

Les bonnes questions à poser sont très concrètes.

• Quels systèmes entrent potentiellement dans le périmètre de l’article 6, c’est-à-dire les systèmes qui touchent à des domaines listés comme l’emploi, l’éducation, l’accès à certains services essentiels ou l’application de la loi ?
• La documentation décrit-elle l’usage réel ou seulement l’usage imaginé au lancement ?
• Les supports commerciaux, les démos internes ou les fiches produit promettent-ils une capacité qui élargit le risque, par exemple “sélection automatique”, “score de fiabilité” ou “recommandation de décision” ?
• Qui utilise l’outil, dans quel workflow, avec quel niveau d’autonomie ?
• Y a-t-il une validation humaine réelle, traçable, avec un pouvoir de correction, ou juste une case “humain dans la boucle” quelque part dans un document ?

Je collecterais au minimum ces informations.

Nom du système	Nom commercial et nom interne si différent.
Responsable	Propriétaire métier, équipe technique, fournisseur.
Finalité	Ce que le système est censé faire, et ce qu’il fait vraiment.
Utilisateurs	Équipes concernées, profils, niveau de formation.
Données traitées	Données personnelles, sensibles, historiques, sources externes.
Décisions influencées	Recrutement, accès à un service, scoring, priorisation, contrôle.
Preuves disponibles	Documentation, logs, tickets, audits, tests, validations humaines.
Exemptions envisagées	Arguments possibles pour sortir du haut risque, à vérifier sérieusement.

Côté juridique, je qualifierais les cas d’usage et je vérifierais les promesses contractuelles ou marketing. Côté gouvernance, je fixerais un propriétaire clair et une règle simple de revue avant changement d’usage. Côté technique, je sécuriserais les logs, les versions de modèles, les données d’entrée et les traces de validation humaine.

La question suivante vient vite, et elle est légitime : Est-ce qu’on peut bénéficier de l’exemption de l’article 6(3) pour éviter le classement haut risque ?

L’exemption de l’article 6(3) suffit-elle ?

L’exemption de l’article 6(3) peut aider, mais elle ne suffit pas sans justification solide et preuves cohérentes. Je la vois comme une soupape utile, pas comme une sortie de secours automatique. Si votre système d’IA est utilisé dans un domaine sensible listé par l’EU AI Act, par exemple recrutement, éducation, accès à des services essentiels ou gestion des travailleurs, il peut parfois ne pas être classé haut risque si son rôle reste vraiment limité.

Le point clé, c’est le risque significatif. Si l’IA ne prend pas de décision importante, ne remplace pas une appréciation humaine, ne classe pas une personne d’une manière qui produit un effet réel, et ne crée pas de risque sérieux pour la santé, la sécurité ou les droits fondamentaux, l’exemption peut se défendre. Mais il faut le prouver. Pas juste l’affirmer dans une slide.

Concrètement, je regarderais plusieurs éléments avant de dormir tranquille :

• L’usage réel : Ce que fait le système en production, pas ce qu’il était censé faire au départ.
• La décision influencée : Est-ce que l’IA aide, recommande, filtre, priorise, exclut ou déclenche une action.
• Les limites fonctionnelles : Ce que l’outil ne peut pas faire, et comment ces limites sont verrouillées.
• Le contrôle humain : Qui vérifie, qui peut contredire l’IA, et dans quelles conditions.
• Les preuves : Tests, documentation fournisseur, analyse interne, logs d’usage, procédures, revue de gouvernance.

Ce n’est pas une case à cocher pour échapper au règlement. C’est une position à documenter. Et cette position doit rester vivante. Si demain le même modèle passe d’un simple résumé de CV à un score de présélection, la classification peut changer. Même outil, autre usage, autre niveau de risque.

Dans les missions data et automatisation, ce qui manque le plus souvent, ce n’est pas l’outil. C’est la trace propre de la décision. Qui a décidé que l’usage était limité. Sur quelles preuves. Avec quelle validation. Et quand ça a été revu pour la dernière fois.

Situation	Risque	Preuve attendue
IA qui reformule un document RH sans noter le salarié.	Risque plutôt limité si aucune décision n’en découle automatiquement.	Description d’usage, limites de l’outil, validation humaine, traces d’utilisation.
IA qui classe des candidats selon un score.	Risque élevé car elle influence l’accès à l’emploi.	Analyse d’impact, tests de biais, documentation modèle, procédure de recours.
IA utilisée initialement comme assistant puis intégrée dans un workflow de décision.	Risque qui augmente avec le changement d’usage.	Revue de gouvernance, journal des changements, nouvelle analyse de classification.

Alors on vérifie quoi maintenant ?

Je retiens surtout une chose : avec l’EU AI Act, il ne suffit plus de dire qu’un système IA est technique, expérimental ou interne. Ce qui compte, c’est son usage réel, son intention déclarée, sa documentation et son impact possible. L’article 6 donne deux grandes portes d’entrée vers le haut risque, et l’article 6(3) peut parfois limiter ce classement, mais seulement avec des preuves sérieuses. Le bon réflexe, c’est d’inventorier vos IA, de rapprocher juridique, data et métiers, puis de documenter proprement. Le bénéfice pour vous : moins d’incertitude, moins de risque réglementaire, et une gouvernance IA beaucoup plus solide.

FAQ

• Qu’est-ce qu’une IA à haut risque selon l’EU AI Act ?
  C’est un système IA qui peut avoir un impact significatif sur la santé, la sécurité ou les droits fondamentaux, ou qui est intégré à certains produits réglementés. Le classement dépend du contexte d’usage, pas seulement du modèle ou de sa performance technique.
• Pourquoi l’intention compte autant dans la classification ?
  Parce que l’EU AI Act regarde comment le système est conçu, documenté, commercialisé, déployé et utilisé. Une même technologie peut avoir un niveau de risque différent selon sa finalité réelle et les décisions qu’elle influence.
• Quels systèmes faut-il auditer en priorité ?
  Je commencerais par les IA utilisées dans les processus sensibles : recrutement, évaluation de personnes, accès à des services, santé, sécurité, décisions automatisées ou aide à la décision importante. Ce sont souvent les cas où le risque réglementaire apparaît le plus vite.
• L’article 6(3) permet-il d’éviter le classement haut risque ?
  Parfois, oui, si le système a un rôle limité et ne crée pas de risque significatif. Mais il faut pouvoir le prouver. Une simple déclaration ne suffit pas. Il faut une analyse documentée, cohérente avec l’usage réel et mise à jour si le système évolue.
• Quelle est la première action concrète à lancer ?
  Faire un inventaire court des systèmes IA, avec leur finalité, leurs utilisateurs, les décisions influencées, la documentation disponible et le propriétaire métier. Ensuite seulement, on peut qualifier le risque et décider quoi renforcer côté 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 concrets : gouvernance des données, industrialisation des automatisations, choix d’outils IA, documentation et mesure fiable. Je dirige l’agence webAnalyste et l’organisme 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 sans partir dans une usine à gaz, contactez-moi.