Quand les systemes d'IA a haut risque s'appliquent et quoi faire ensuite

Les systemes d'IA a haut risque s'appliquent lorsqu'une equipe SaaS construit, vend, integre, configure ou utilise un systeme d'IA qui entre dans l'une des routes high-risk de l'EU AI Act. La question n'est pas si l'entreprise utilise de l'IA. Elle est de savoir si un systeme precis, pour une finalite precise, releve d'un produit reglemente ou d'un cas sensible d'Annex III.

Pour SaaS, la reponse depend souvent de la finalite produit, de la configuration client, des personnes affectees, des donnees, du role vendor, de la revue humaine, du marche et de l'utilisation de l'output.

Les deux routes principales

La premiere route concerne les produits reglementes. Un systeme d'IA peut etre high-risk s'il est destine a etre composant de securite d'un produit, ou est lui-meme un produit, couvert par la legislation d'Annex I et soumis a third-party conformity assessment. Cela compte pour SaaS lie aux medical devices, machinery, transport, aviation, radio equipment, toys, industrie ou robotics.

La seconde route est Annex III: biometrics, critical infrastructure, education, employment, worker management, essential services, law enforcement, migration, justice et democratic processes. Pour SaaS, c'est souvent la route la plus visible. Hiring, ranking de candidats, evaluation de travailleurs, student assessment, credit eligibility ou access decisions peuvent exiger une revue plus profonde.

Quand declencher une revue

Declenchez une revue quand un systeme d'IA peut affecter des personnes dans un contexte consequent. Les triggers courants sont nouveau AI feature, nouveau modele ou vendor, nouvelle finalite, nouvelle configuration client, usage HR, education, healthcare, essential services, credit ou insurance, biometrics, automated ranking, reduction de human review, entree sur le marche UE ou question client.

La configuration client est critique. Une plateforme horizontale peut etre non high-risk par defaut, mais devenir sensible si un client l'utilise pour evaluer des travailleurs, classer des candidats, scorer une eligibility ou soutenir des decisions publiques.

Quand cela peut ne pas s'appliquer

Toute fonctionnalite SaaS avec IA n'est pas high-risk. Un assistant interne de redaction, code helper, analytics assistant, resume de tickets ou knowledge search peut etre hors route high-risk s'il ne releve pas d'Annex III, n'est pas un composant de securite d'un produit reglemente et ne soutient pas de decisions consequentes sur des personnes.

Il peut quand meme necessiter AI inventory, privacy review, security review, vendor assessment, prohibited-practice screening, customer disclosure ou controles AI governance ordinaires.

Que faire d'abord

Commencez par un intake court: nom du systeme, owner, business purpose, user journey, personnes affectees, geographie, donnees, modele ou vendor, hypothese de role AI Act, output, human review, configuration client et lien avec produits reglementes ou Annex III.

Ensuite routez le cas. Les cas clairement no-high-risk vont vers la governance ordinaire. Les candidats high-risk passent en revue legal et compliance. Les cas incertains vont a un reviewer nomme avec deadline et preuve minimale.

Preuves a garder

Conservez AI inventory, intake, description produit ou vendor, data flow, analyse des personnes affectees, intended purpose, screening Annex I ou Annex III, role analysis, conclusion, reviewer, date, rationale, decision launch, controles actives et trigger de re-review.

Pour un systeme interne, gardez architecture notes, model documentation, tests, logging design, human oversight et monitoring plan. Avec un vendor, gardez AI documentation, instructions for use, engagements contractuels, security answers et elements audit ou certification.

Scenarios SaaS

Un assistant support qui resume des tickets internes peut etre hors high-risk si les agents verifient l'output et si le systeme ne classe, note ou refuse pas l'acces a des personnes.

Une fonctionnalite HR qui filtre des candidatures, classe des candidats ou evalue la performance est differente. Employment et worker management sont des domaines Annex III.

Un workflow healthcare pour triage, diagnostics ou medical-device functionality peut soulever a la fois Annex III et des questions de produit reglemente.

FAQ

Quel est l'objectif pratique?

Identifier les systemes qui demandent une governance plus stricte, des preuves plus fortes, des lifecycle controls et une ownership claire.

Quand cela s'applique-t-il aux equipes SaaS?

Quand elles construisent, vendent, integrent, configurent ou utilisent l'IA comme composant de securite d'un produit reglemente, comme produit reglemente ou pour un cas Annex III.

Que documenter d'abord?

AI inventory, high-risk intake, role analysis, intended purpose, analyse des personnes affectees, decision de classification, owner, emplacement des preuves, launch gate et trigger de re-review.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidance for providers and deployers of high-risk AI systems.
• European Commission AI Act FAQ.
• AI Act Service Desk guidance on Annex III high-risk AI systems.