Checklist systemes AI a haut risque pour fondateurs et compliance leads

Les systemes AI a haut risque ont besoin d'une checklist parce que la difficulte n'est pas seulement de comprendre le terme. Il faut prouver que le bon cas d'usage a ete revu, que les owners sont nommes, que les controles sont declenches et que les preuves sont disponibles pour clients, board, auditeurs ou regulateurs.

Selon l'EU AI Act, la classification haut risque peut venir de produits reglementes ou de cas d'usage listes dans l'Annex III. Les draft guidelines de la Commission de mai 2026 aident a appliquer Article 6, mais le reglement reste la source juridique.

1. Confirmer le cas d'usage AI

Confirmez que le workflow utilise vraiment un systeme AI. Les mots automation, intelligence, insight, scoring, recommendation, assistant ou optimisation ne suffisent pas.

Gardez le nom du systeme, zone produit, finalite, modele ou fournisseur, output, utilisateur de l'output et exposition client, employee, interne ou embarquee. S'il n'y a pas de systeme AI, documentez et fermez la checklist.

2. Identifier le role AI Act

Le role compte car les obligations different entre provider, deployer, importer, distributor, fabricant produit et autres acteurs. Une entreprise SaaS peut avoir des roles differents selon les workflows.

Documentez qui developpe, qui controle la finalite, qui controle la configuration, qui met le systeme sur le marche UE et quelles instructions ou declarations de role le fournisseur fournit.

3. Revoir la route produit reglemente

Demandez si le systeme peut etre composant de securite d'un produit reglemente ou un produit reglemente lui-meme. Cela peut concerner medical devices, machines, transport, aviation, radio, jouets, ascenseurs ou environnements industriels.

Verifiez si l'AI soutient securite, diagnostic, monitoring, controle, alerte ou detection d'echec, et si une evaluation de conformite tierce peut etre requise.

4. Revoir l'Annex III

L'Annex III est souvent plus pertinent pour SaaS. Verifiez biometrie, infrastructure critique, education, recrutement, emploi, worker management, acces a services essentiels, credit, assurance, justice, migration et processus democratiques.

La classification suit la finalite et l'usage concret. Le meme modele peut etre faible risque comme assistant interne et haut risque dans un workflow de recrutement.

5. Evaluer la configuration client

SaaS est souvent configurable. Une fonction ordinaire peut devenir sensible si un client l'utilise pour classer des candidats, evaluer des salaries, noter des etudiants ou influencer l'acces a des services importants.

Verifiez si les clients peuvent choisir champs, criteres, seuils ou labels, si des workflows sensibles sont possibles et s'il existe un gate de revue avant activation.

6. Nommer owners et gates

Nommez product owner, engineering owner, legal ou compliance owner, security ou risk owner et owner customer-facing pour les declarations approuvees.

Une classification manquante doit bloquer le lancement dans les domaines sensibles. Une classification probablement haut risque doit declencher revue approfondie et conditions de lancement.

7. Definir les preuves minimales

Conservez intake, description systeme, analyse de role, screen produit reglemente, screen Annex III, finalite, analyse des personnes affectees, data flow, documents fournisseur, decision de classification, reviewer, date, raisonnement, sources, decision de lancement, controles et prochain trigger.

Pour les systemes probablement haut risque, ajoutez risk records, decisions data governance, owner documentation technique, tests, human oversight, logging, monitoring, chemin incident et route de conformite.

8. Transformer les controles en travail produit

Risk management devient un registre de risque feature. Data governance devient des regles pour donnees training, test, input, client et feedback. Documentation technique devient un dossier de preuves. Transparence devient instructions client. Human oversight devient processus de revue reel. Monitoring devient metriques avec owner et cadence.

9. Reouvrir la decision

Reouvrez la checklist lorsque finalite, modele, fournisseur, version, revue humaine, configuration client, marche, categories de donnees, monitoring, lignes directrices, standards ou appetit au risque changent.

FAQ

Que doivent comprendre les equipes?

Quand les systemes AI a haut risque peuvent s'appliquer, quels changements operationnels ils declenchent et quelles preuves montrent que le travail existe.

Pourquoi cela compte en pratique?

Parce que la classification peut affecter design produit, gates de lancement, documentation client, vendor review, monitoring, incident response et preuves d'audit.

Quelle est la plus grande erreur?

Traiter l'AI haut risque comme une interpretation juridique unique au lieu d'un workflow repetable avec owners, triggers, preuves et escalade.

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.
• European Commission guidance on AI Act standardisation.