Systemes dIA a haut risque: guide pratique pour equipes SaaS

Les systemes dIA a haut risque sont des systemes qui entrent dans le parcours de conformite le plus strict de lEU AI Act en raison de leur finalite, de leur contexte produit ou de leur impact potentiel sur la sante, la securite ou les droits fondamentaux. Pour une equipe SaaS, la question pratique nest pas seulement de savoir si le produit utilise lIA. Il faut savoir si le cas dusage est un composant de securite dun produit reglemente, un produit reglemente lui-meme, ou un usage liste dans lAnnex III.

Si la reponse peut etre oui, lequipe a besoin dun workflow structure. Il doit identifier le systeme, le role, la finalite, les personnes affectees, les donnees, la configuration client, le fournisseur, les preuves, les controles, lowner et le launch gate. La decision ne doit pas rester dans une note juridique; elle doit guider product, engineering, security, privacy, compliance et les equipes client.

Les draft guidelines de la European Commission de mai 2026 sont utiles parce quelles expliquent linterpretation actuelle de lArticle 6 et donnent des exemples pratiques. Elles restent draft guidance; lAI Act demeure la source de lobligation juridique.

Pourquoi cela compte

La classification haut risque peut declencher risk management, data governance, documentation technique, logging, transparence, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, enregistrement, monitoring et incident handling.

Le principal risque operationnel est lambiguite. Une equipe peut lancer ranking, scoring, filtering, recommandations, HR, education, healthcare ou access decisions sans decider si le cas suit le parcours haut risque. Quand procurement, security client ou audit pose la question, le feature peut deja etre dans les contrats.

La classification accelere le travail parce quelle route les cas. Un assistant de redaction na pas besoin du meme processus quun systeme qui filtre des candidats. Un outil de resume interne nest pas le meme quun scoring pour credit, emploi, education ou services essentiels.

Deux routes principales

La premiere route concerne les produits reglementes. Un systeme dIA peut etre haut risque sil est composant de securite dun produit, ou produit lui-meme, couvert par la legislation dharmonisation dAnnex I et soumis a une third-party conformity assessment. Cest pertinent pour SaaS dans medical devices, machinery, transport, aviation, robotics, industrie ou infrastructure.

La seconde route concerne Annex III: biometrics, critical infrastructure, education, employment, worker management, essential services, law enforcement, migration, justice et democratic processes. Lanalyse depend de la finalite et de lusage concret, pas du nom du modele.

Pour SaaS, Annex III est souvent le declencheur le plus frequent: hiring, candidate filtering, worker evaluation, student assessment, creditworthiness, insurance risk, biometric identification ou legal decision support meritent une revue approfondie.

Quand declencher la revue

Declenchez une revue lors dun nouveau AI feature, modele ou fournisseur, dune nouvelle finalite, configuration client, utilisation HR, education, healthcare, essential services, credit ou insurance, traitement biometrique, ranking automatise, reduction du human review, entree sur le marche UE ou question client sur lAI Act.

Les vendors IA exigent la meme discipline. Les mots insight, intelligence, automation, recommendation, screening, identity ou safety ne resolvent pas la classification. Lequipe doit savoir ce que fait le systeme, quelles donnees il utilise, qui est affecte, comment loutput est utilise, quelles configurations sensibles existent et quel role incombe au client.

Workflow pratique

Commencez par un intake court: systeme, owner, finalite, user journey, personnes affectees, geographie, donnees, modele ou vendor, role AI Act, output, human review, configuration client et lien avec Annex I ou Annex III.

Ensuite, routez. Les cas sans red flag passent en classification ordinaire, privacy, security et vendor review. Les candidats haut risque passent en assessment legal et compliance avant lancement. Les cas ambigus vont a un reviewer nomme avec delai.

Pour les systemes probablement high-risk, completez le dossier: risk management, data governance, technical documentation, logging, instructions dutilisation, human oversight, testing, cybersecurity, post-market monitoring, incident escalation, preuves vendor, conformity route et documentation client.

Preuves et ownership

Les preuves doivent repondre a quatre questions: ce qui a ete revu, pourquoi la classification a ete retenue, quels controles en decoulent et quand la decision sera rouverte. Conservez inventory, intake, description produit ou vendor, data flow, analyse des personnes affectees, intended purpose, screening, role analysis, conclusion, reviewer, date, sources, launch decision, controles et trigger de review.

Product possede la finalite et la configuration. Engineering possede architecture, donnees, logs et testing. Security possede vendor et cybersecurity. Privacy possede data protection. Legal et compliance possedent interpretation AI Act et evidence standard. Leadership possede risk acceptance pour les lancements sensibles ou ambigus.

Erreurs frequentes

La premiere erreur est de traiter haut risque comme une etiquette marketing. Le meme modele peut soutenir un drafting faible risque ou une revue demploi haut risque. La deuxieme est de dependre seulement des assurances vendor. La troisieme est de croire que human review resout tout. La quatrieme est doublier change management quand changent finalite, donnees, geographie, client, modele ou oversight.

FAQ

Quel est le but pratique?

Identifier les systemes dIA qui exigent un parcours de governance plus strict, des preuves plus fortes et des controles lifecycle avant mise sur le marche, mise en service ou utilisation dans des workflows sensibles.

Quand cela sapplique-t-il aux equipes SaaS?

Quand lequipe construit, vend, integre, configure ou utilise lIA comme composant de securite dun produit reglemente, comme produit reglemente ou pour des usages Annex III tels quemploi, education, services essentiels, biometrics, law enforcement, migration, justice ou processus democratiques.

Que documenter dabord?

AI inventory, intake haut risque, role analysis, intended purpose, personnes affectees, classification decision, owner, emplacement des preuves et launch gate.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission draft guidelines on the classification of high-risk AI systems.
• European Commission AI Act FAQ on high-risk AI systems.
• AI Act Service Desk guidance on high-risk AI in regulated products.