Comment operationaliser les systemes AI a haut risque sans ralentir la livraison produit

Les systemes AI a haut risque doivent etre traites comme un workflow de livraison produit, pas comme une question juridique tardive. Le but est d'identifier le cas d'usage tot, de determiner si la route haut risque peut s'appliquer, d'attribuer des responsables, de declencher les controles adaptes et de garder les preuves la ou les equipes produit, security, privacy, compliance et clients peuvent les utiliser.

Selon l'EU AI Act, un systeme peut devenir haut risque lorsqu'il est lie a la securite d'un produit reglemente ou lorsqu'il est destine a un cas d'usage sensible de l'Annex III. Les projets de lignes directrices publies par la Commission en mai 2026 aident a interpreter ces routes, mais ne remplacent pas le reglement. Pour une equipe SaaS, la reponse operationnelle est d'integrer la revue avant la vente, la configuration ou le lancement.

Pourquoi cela compte en pratique

Le statut haut risque change ce que l'equipe doit savoir avant le lancement: finalite, personnes affectees, categories de donnees, modele ou fournisseur, role de l'entreprise, supervision humaine, instructions d'utilisation, logs, monitoring, incidents, configuration client et preuves.

Les obligations peuvent couvrir gestion des risques, gouvernance des donnees, documentation technique, enregistrements, transparence, supervision humaine, exactitude, robustesse, cybersecurite, qualite, evaluation de conformite, enregistrement, monitoring et actions correctives. Sans workflow, ces questions arrivent trop tard, souvent lors d'une revue client, d'un audit ou d'une demande reglementaire.

Commencer par un intake haut risque

L'intake doit rester court. Il ne demande pas une conclusion juridique finale, mais les faits necessaires: nom du systeme, owner, objectif business, parcours utilisateur, personnes affectees, geographie, donnees, modele ou fournisseur, role de provider ou deployer, output, utilisation humaine de l'output et configuration client.

Deux questions suivent. Le systeme pourrait-il etre un composant de securite d'un produit reglemente ou un produit reglemente lui-meme? Cela concerne notamment dispositifs medicaux, machines, transport, aviation, radio, jouets, ascenseurs et environnements similaires. Le cas d'usage pourrait-il entrer dans l'Annex III, par exemple emploi, education, services essentiels, credit, assurance, biometrie, infrastructure critique, migration, justice ou processus democratiques?

Si aucune route n'est plausible, l'equipe documente la raison et continue la revue AI, privacy, security et vendor normale. Si une route est plausible, le cas exige une analyse approfondie avant lancement ou activation client.

Definir triggers et lanes

La revue doit etre declenchee par des evenements deja importants pour la livraison: nouvelle fonctionnalite AI, nouveau but, nouveau modele ou fournisseur, donnees client connectees au workflow, output influencant des personnes, reduction de supervision humaine, configuration client sensible, entree sur le marche UE ou questions acheteur sans preuve disponible.

Utilisez trois lanes. Lane un: aucun signal haut risque, avec justification courte et trigger de revue. Lane deux: incertain ou sensible, avec reviewer nomme, echeance et blocage du lancement jusqu'a resolution. Lane trois: probablement haut risque, avec travail approfondi legal, produit, security, privacy et compliance.

Responsables et controles

Le product owner porte finalite, configuration, scope et promesses client. Engineering porte architecture, logs, versioning, fallback et controles techniques. Legal ou compliance porte raisonnement de classification, sources, declarations client et triggers de revue. Security ou risk porte preuves fournisseur, monitoring, escalade incident, acces et resilience.

Les obligations doivent devenir des controles produit. La gestion des risques devient un registre de risque lie a la fonctionnalite. La gouvernance des donnees devient des regles pour donnees d'entrainement, test, input, client et feedback. La documentation technique devient un dossier de preuves maintenu. La transparence devient des instructions internes et client. La supervision humaine devient un vrai processus d'intervention. Le monitoring devient des metriques, owners et cadence.

Garder les preuves proches de la livraison

Les preuves ne doivent pas vivre dans une archive separee. Utilisez tickets produit pour l'intake, dossiers d'architecture pour le design technique, vendor records pour les tiers, privacy reviews pour donnees et personnes affectees, security reviews pour controles et release checklists pour gates.

Gardez au minimum intake, decision de classification, analyse de role, sources, reviewer, date, raisonnement, controles declenches, questions ouvertes, approvals, limites client, owner monitoring, chemin incident et prochain trigger de revue.

FAQ

Que doivent comprendre les equipes?

Qu'un systeme AI a haut risque est une question operationnelle autant qu'une question juridique. Le workflow identifie le cas d'usage, le route, declenche les controles et maintient les preuves.

Toute fonctionnalite AI SaaS est-elle haut risque?

Non. Beaucoup de fonctions assistees par AI ne le seront pas. L'equipe doit quand meme documenter pourquoi la route haut risque ne s'applique pas.

Quand faut-il suspendre un lancement?

Quand le cas d'usage peut affecter des personnes dans un domaine Annex III, etre lie a la securite produit, manquer d'owner, manquer de preuve ou dependre d'une configuration client non revue.

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.
• European Commission May 2026 update on AI Act implementation timing.
• European Commission report on the review of prohibitions and high-risk AI.