AI Act votre IA est-elle déjà à haut risque ?

Votre IA peut déjà entrer dans la catégorie high-risk si sa finalité touche un produit réglementé, un usage sensible ou les droits des personnes. Le vrai sujet, c’est moins le modèle que son usage réel, sa documentation, son déploiement et les preuves que vous gardez.

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

Une IA devient high-risk au sens de l’AI Act quand elle entre dans l’une des deux voies de l’article 6. Soit elle est intégrée dans un produit déjà réglementé par des règles européennes de sécurité. Soit elle est utilisée dans un cas sensible, avec un impact possible sur la santé, la sécurité ou les droits fondamentaux des personnes.

Le point central, c’est l’intended purpose. En français, la finalité prévue du système. Dit simplement : À quoi sert officiellement l’IA, pour qui, dans quel contexte, et avec quel effet attendu.

Et là, il faut être très concret. Ce n’est pas seulement ce que l’équipe dit en interne qui compte. Ce qui compte aussi, c’est ce qui est écrit dans la documentation, ce qui est vendu au client, ce qui apparaît dans les écrans, ce qui est paramétré par défaut, et ce que les utilisateurs font réellement avec l’outil. Si votre plaquette commerciale dit “optimise la sélection des candidats”, mais que vous dites en réunion “non non, c’est juste une aide”, le régulateur va regarder l’ensemble, pas seulement votre intention orale.

La première voie concerne les IA intégrées à certains produits soumis à une réglementation européenne de sécurité. Par exemple des dispositifs médicaux, des machines, des jouets connectés, des ascenseurs, des équipements radio, ou d’autres produits couverts par des textes européens spécifiques. Dans ce cas, l’IA hérite du niveau d’exigence du produit, parce qu’une mauvaise décision peut avoir un effet physique réel.

La deuxième voie concerne les usages sensibles listés par l’AI Act. Là, on parle de domaines comme l’emploi, l’éducation, l’accès à certains services essentiels, le crédit, la justice, la police, la migration ou la gestion de travailleurs. Le sujet n’est pas juste “est-ce que le modèle est puissant ?”. Le sujet, c’est “est-ce que cette IA influence une décision importante sur une personne ?”.

J’ai déjà vu des équipes penser qu’elles faisaient juste un outil d’aide interne, alors que la fiche produit, les écrans et les usages métiers racontaient autre chose. C’est souvent là que le risque réglementaire apparaît. Pas dans le modèle lui-même, mais dans le décalage entre le discours, le produit et l’usage réel.

Voie de classification	Question à se poser	Signal d’alerte
IA intégrée à un produit réglementé	Est-ce que l’IA fait partie d’un produit soumis à une réglementation européenne de sécurité ?	Le produit peut affecter la santé, la sécurité physique ou le bon fonctionnement d’un équipement.
IA utilisée dans un domaine sensible	Est-ce que l’IA influence une décision importante sur une personne ?	L’outil sert au recrutement, au crédit, à l’éducation, à l’accès à un service, ou à une décision administrative.

Où regarder dans vos systèmes ?

Il faut regarder l’inventaire réel des systèmes d’IA, pas seulement les projets qui s’appellent officiellement “IA”. Dans beaucoup d’entreprises, les vrais sujets sont cachés dans des moteurs de scoring, des assistants de décision, des modèles de tri, des outils de recommandation ou des automatisations qui utilisent un modèle IA sans que personne ne l’ait vraiment étiqueté comme tel.

Je commence toujours par deux zones. D’abord, les systèmes intégrés dans des produits déjà réglementés. Par exemple un logiciel médical, un équipement industriel critique, un système embarqué dans un produit soumis à certification. Là, l’IA peut hériter d’un niveau d’exigence élevé parce qu’elle influence le fonctionnement du produit.

Ensuite, je regarde les usages sensibles. C’est souvent là que le risque AI Act apparaît. On parle de biométrie, comme l’identification ou la vérification d’identité. D’éducation et de formation professionnelle, par exemple un outil qui note, classe ou oriente des candidats. De recrutement et gestion des travailleurs, avec du matching CV, du scoring de performance, de la planification automatique. D’accès à des services essentiels, comme crédit, assurance, aides sociales, logement ou santé. Il y a aussi le maintien de l’ordre, la migration et le contrôle aux frontières, la justice, et certains usages liés aux processus démocratiques.

Il faut rester précis. Le même modèle peut être banal dans un contexte et high-risk dans un autre. Un outil de résumé de texte, par exemple, n’a pas le même poids s’il résume des notes internes ou s’il influence une décision RH. J’ai déjà vu ce cas chez un client : l’équipe pensait avoir un simple “assistant de productivité”, mais les managers s’en servaient pour préparer des évaluations individuelles. Ce n’est plus la même histoire.

La documentation doit aider à trancher. Je compare toujours trois versions : l’usage prévu, l’usage vendu ou présenté, et l’usage constaté. Si ces trois versions ne racontent pas la même chose, ce n’est pas juste un détail. C’est un problème de gouvernance.

• Quels systèmes prennent, recommandent ou influencent une décision sur une personne ?
• Quels outils sont utilisés en RH, formation, crédit, assurance, santé, justice ou accès à un service essentiel ?
• Quels modèles sont intégrés dans un produit déjà réglementé ?
• Quel usage est écrit dans la documentation interne ?
• Quel usage est promis dans les supports commerciaux ou les démos ?
• Quel usage les métiers en font réellement au quotidien ?
• Qui valide les résultats du système, et cette validation est-elle réelle ou juste théorique ?
• Quelles données personnelles ou sensibles sont utilisées pour produire le résultat ?

L’exemption de l’article 6 3 tient-elle ?

L’exemption de l’article 6(3) peut s’appliquer, mais seulement si le système ne présente pas de risque significatif pour la santé, la sécurité ou les droits fondamentaux, et si cette position est sérieusement documentée.

Ce n’est pas une sortie automatique. Ce n’est pas un bouton magique qui permet de dire “mon IA est dans l’annexe III, mais finalement non”. L’entreprise doit être capable de montrer pourquoi son système ne détermine pas matériellement le résultat d’une décision sensible.

Dit simplement, il faut prouver que l’IA reste limitée dans son rôle. Elle aide, elle prépare, elle signale, elle classe peut-être une information, mais elle ne remplace pas l’évaluation humaine sur un sujet qui touche vraiment une personne.

Cas possible d’exemption	Ce que ça veut dire concrètement
Tâche procédurale étroite	Le système automatise une étape administrative limitée, sans décider du fond.
Amélioration d’un résultat humain	L’IA corrige, reformule ou enrichit un résultat déjà produit par une personne.
Détection de schémas ou d’écarts	Le système repère des anomalies, mais l’humain garde l’analyse et la décision.
Tâche préparatoire	L’IA prépare des éléments avant une vraie évaluation humaine.

Le point que je vois souvent sous-estimé, c’est le profilage. Si le système réalise du profilage de personnes physiques dans ces contextes, il est en principe considéré comme high-risk. Le profilage, c’est le fait d’analyser ou prédire des aspects liés à une personne, comme sa performance au travail, sa solvabilité, son comportement, sa santé, ses préférences ou ses risques. Là, on n’est plus dans un petit outil neutre.

En pratique, je documente l’analyse comme si je devais l’expliquer à un régulateur dans six mois. Je garde les preuves, les tests, les validations, les comptes rendus de décision, les limites fonctionnelles du système, et surtout la preuve du rôle réel de l’humain. Pas juste “human in the loop” écrit dans une slide. Il faut montrer ce que l’humain voit, ce qu’il peut modifier, ce qu’il peut refuser, et comment ses décisions sont tracées.

L’exemption est utile, oui. Mais je ne la traiterais jamais comme une case à cocher. Si l’impact humain est réel, il faut être très solide.

Quelles preuves faut-il préparer ?

Il faut préparer des preuves avant d’avoir un contrôle, pas après. Une classification high-risk, donc “à haut risque”, ou une exemption doit se défendre avec des documents, des logs, des décisions et une gouvernance claire. Sinon, on est vite dans le “faites-nous confiance”, et ça ne tient pas longtemps.

Pour un système à haut risque, l’AI Act attend surtout qu’on puisse montrer que l’IA est maîtrisée. Pas juste qu’elle marche en démo. Il faut garder des traces sur la gestion des risques, la qualité des données, la documentation technique, la traçabilité, les logs, la transparence donnée aux utilisateurs, la supervision humaine, la précision, la robustesse et la cybersécurité.

Dit simplement, une équipe data ou automatisation doit pouvoir répondre à des questions très concrètes. Quelles données ont servi ? Quels biais ont été testés ? Qui valide les sorties ? Quels incidents sont remontés ? Quels seuils déclenchent une alerte ? Qui peut désactiver le système ? J’ai déjà vu chez un client un outil décrit comme “aide à la décision”, alors que dans les faits personne ne relisait les recommandations. Sur le papier, l’humain gardait la main. Dans l’interface, tout poussait à accepter. Là, la preuve ne colle plus à la réalité.

La documentation doit donc raconter ce qui se passe vraiment. Si l’outil est vendu comme assistant mais utilisé comme filtre final, c’est un autre niveau de risque. Si l’humain est censé superviser mais n’a ni temps, ni information, ni bouton clair pour reprendre la main, la supervision humaine est théorique.

Cartographier	Lister les systèmes IA, leurs usages, les équipes concernées, les fournisseurs et les données utilisées.
Qualifier	Produire une note courte qui explique si le cas est high-risk, interdit, limité, ou hors champ, avec le raisonnement.
Tester	Conserver les résultats de tests sur biais, erreurs, robustesse, sécurité, dérives et cas limites.
Documenter	Tenir à jour la fiche système, les versions de modèle, les sources de données, les choix métier et les limites connues.
Arbitrer	Tracer les décisions importantes, les validations humaines, les refus de mise en production et les plans de correction.
Surveiller	Garder les logs, les incidents, les alertes, les revues périodiques et les changements de comportement du système.

Le règlement est entré en vigueur en 2024. Les obligations applicables aux systèmes high-risk arrivent progressivement, avec un jalon majeur en 2026. Pas besoin de paniquer, mais attendre la dernière minute serait une erreur. Le vrai sujet, c’est d’installer maintenant les bons réflexes de preuve.

Qui doit décider dans l’entreprise ?

La décision ne doit pas rester uniquement chez les juristes, ni uniquement chez les équipes techniques. La classification AI Act doit être un travail commun entre juridique, data, produit, sécurité, conformité et métiers. Sinon, chacun regarde un morceau du problème, et personne ne voit vraiment le risque réel.

Le juridique interprète le cadre, qualifie les obligations et sécurise la position de l’entreprise. Les équipes data et IA décrivent le fonctionnement réel du système, les modèles utilisés, les données d’entrée, les sorties, les limites connues. Le produit explique la finalité, les écrans, les parcours utilisateurs, et surtout ce que l’outil permet de faire concrètement. Les métiers confirment les usages terrain. La sécurité regarde les risques techniques, les accès, les dépendances, les logs, les vulnérabilités. La conformité s’assure que tout ça tient dans le temps. La gouvernance arbitre, tranche les zones grises et garde les preuves.

Dans les projets IA que je vois, le plus gros risque vient souvent des zones grises. Un outil est lancé comme support, puis il devient peu à peu une brique de décision. Personne n’a changé officiellement sa finalité, mais dans les faits, son impact a changé. C’est exactement là que l’AI Act peut vous rattraper.

Je préfère une gouvernance légère mais réelle. Pas un comité de 15 personnes qui se réunit trois heures pour valider une ligne Excel. Plutôt un point court, régulier, avec les bonnes personnes et des décisions tracées.

• Un registre des systèmes IA, même simple au départ.
• Un propriétaire métier, responsable de l’usage.
• Un propriétaire technique, responsable du fonctionnement.
• Une revue des usages, pour vérifier ce qui se passe vraiment.
• Une revue des changements, surtout quand la finalité, les données ou les utilisateurs évoluent.
• Une validation claire des exemptions, quand vous estimez que le système n’est pas à haut risque.
• Un suivi des incidents, même les petits signaux faibles.

L’objectif n’est pas de créer une usine à gaz. L’objectif, c’est de pouvoir répondre calmement à une question simple : pourquoi avez-vous classé cette IA comme ça, et sur quelles preuves ?

Acteur	Responsabilité	Preuve à conserver
Juridique	Interpréter l’AI Act et sécuriser la qualification	Note d’analyse, critères retenus, avis formel
Data / IA	Décrire le modèle, les données, les limites et le fonctionnement réel	Documentation technique, tests, version du modèle
Produit	Expliquer la finalité, les écrans et les parcours utilisateurs	Spécifications, maquettes, description des fonctionnalités
Métiers	Confirmer les usages réels et l’impact opérationnel	Compte rendu d’atelier, validation métier
Sécurité	Évaluer les risques techniques, accès, logs et dépendances	Analyse de risques, contrôles, incidents suivis
Gouvernance	Arbitrer, valider, suivre les changements et garder la trace	Registre IA, décisions, dates de revue

Votre IA mérite-t-elle un vrai audit maintenant ?

Le sujet high-risk de l’AI Act n’est pas théorique. Une IA peut basculer dans cette catégorie à cause de sa finalité, de son contexte d’usage, de sa documentation ou de la façon dont elle influence une décision. Je retiens surtout une chose : il faut comparer ce que l’outil est censé faire, ce qu’il fait vraiment, et ce que l’entreprise peut prouver. L’exemption de l’article 6(3) existe, mais elle demande une analyse solide. Le bon réflexe, c’est d’inventorier, qualifier, documenter et gouverner. Le bénéfice pour vous : moins d’incertitude, moins de risque, et des projets IA plus faciles à défendre.

FAQ

• Qu’est-ce qu’un système high-risk dans l’AI Act ?
  C’est un système d’IA qui entre dans les critères de l’article 6. Il peut être high-risk parce qu’il est intégré dans un produit réglementé, ou parce qu’il est utilisé dans un domaine sensible avec un impact possible sur la santé, la sécurité ou les droits fondamentaux des personnes.
• La finalité d’une IA peut-elle changer sa classification ?
  Oui, c’est même un point central. La classification dépend beaucoup de l’usage prévu, documenté, commercialisé et réel. Un même modèle peut être peu risqué dans un contexte simple et devenir high-risk s’il influence une décision RH, éducative, financière ou liée à un service essentiel.
• L’article 6(3) permet-il d’éviter la classification high-risk ?
  Il peut permettre de sortir du régime high-risk dans certains cas, si le système ne présente pas de risque significatif et ne détermine pas matériellement le résultat d’une décision sensible. Mais il faut le prouver. Ce n’est pas une simple déclaration interne.
• Quels documents faut-il garder pour se protéger ?
  Il faut garder l’analyse de classification, la finalité du système, les usages réels, les tests, les décisions de gouvernance, les preuves de supervision humaine, les logs utiles, les limites fonctionnelles et les éléments qui justifient une éventuelle exemption.
• Qui doit piloter l’analyse AI Act dans l’entreprise ?
  Le pilotage doit être partagé. Le juridique sécurise l’interprétation, les équipes data expliquent le fonctionnement réel, le produit décrit les parcours, les métiers valident les usages, et la gouvernance conserve les décisions. Si chacun travaille dans son coin, la classification devient fragile.

 

 

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, mesure, automatisation, fiabilisation des flux et adoption de l’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 voulez cadrer vos systèmes IA et automatisations sans bullshit, contactez-moi.