Comment operationnaliser les obligations des deployeurs sans ralentir la livraison produit

Les obligations des deployeurs au titre de l'EU AI Act deviennent gerables lorsqu'elles sont traitees comme un workflow de livraison, et non comme une note juridique tardive. Il faut identifier les usages d'IA sous l'autorite de l'entreprise, determiner si l'usage est a haut risque, transformer les instructions du fournisseur en controles, attribuer une supervision humaine competente, conserver les logs utiles et definir quand suspendre ou escalader l'usage.

Le moyen le plus rapide consiste a integrer cette revue dans les processus existants: produit, fournisseurs, securite, privacy et lancement. Chaque workflow d'IA pertinent doit avoir une fiche: systeme, finalite, analyse de role, supervision humaine, controles des donnees d'entree, monitoring, conservation des logs, route incident, obligations d'information et declencheurs de reevaluation.

L'article 26 du Reglement (UE) 2024/1689 est le point d'ancrage principal pour les deployeurs de systemes d'IA a haut risque. Il impose notamment d'utiliser le systeme conformement aux instructions du fournisseur, d'attribuer une supervision humaine avec competence et autorite, de veiller a la pertinence des donnees d'entree lorsque le deployeur les controle, de surveiller le fonctionnement, de conserver les logs generes automatiquement sous son controle et d'agir en cas de risque ou d'incident grave.

Pourquoi cela compte

Dans beaucoup d'entreprises SaaS, la gouvernance IA est repartie entre produit, engineering, legal, securite, customer trust et achats. Les obligations des deployeurs revelent les zones ou ces activites ne se rejoignent pas. La meme entreprise peut etre fournisseur pour une fonctionnalite client, deployeur pour un workflow interne et cliente d'un autre fournisseur.

L'analyse doit donc se faire workflow par workflow. Le fournisseur apporte des instructions et de la documentation, mais le deployeur decide comment le systeme est utilise, quelles donnees sont saisies, qui depend des sorties, quelles exceptions sont admises et quand un humain peut passer outre.

Inserer la revue dans la delivery

Ajoutez les questions deployeur a l'inventaire IA, a l'intake fournisseurs, aux exigences produit, aux revues privacy et securite, et a la checklist de lancement. Declenchez la revue lorsqu'un nouveau systeme est introduit, que la finalite change, qu'un outil interne devient visible cote client, que de nouvelles donnees sont ajoutees, que la supervision humaine diminue, que le modele change ou que des signaux d'incident apparaissent.

Le processus doit indiquer qui ouvre la fiche, qui fournit les faits, qui valide le role et la classification, qui confirme les preuves techniques, qui approuve le lancement et qui gere les reevaluations.

Creer une fiche deployeur

La fiche doit nommer le systeme, le fournisseur, le owner interne, le domaine produit, le processus, la finalite, les utilisateurs, les personnes affectees, les categories de donnees, les pays et le statut de lancement. Joignez les instructions du fournisseur et traduisez-les en etapes operationnelles.

Documentez ensuite le role et la classification: deployeur, fournisseur ou les deux; haut risque ou non; disposition pertinente; incertitudes restantes. Puis reliez chaque obligation a un controle: owner de supervision, instructions approuvees, controles qualite des donnees, signaux de monitoring, logs, criteres d'incident, notices et route de suspension ou d'escalade.

Supervision, logs et monitoring

"Human in the loop" ne suffit pas si la personne n'a ni temps, ni contexte, ni formation, ni autorite. La fiche doit expliquer qui examine les sorties, ce qu'il doit detecter, quelles informations sont necessaires, ce qui peut etre annule ou suspendu, et quelle preuve montre que la revue a eu lieu.

Les logs peuvent se trouver dans la console fournisseur, la telemetrie produit, les evenements d'audit, les outils securite, le support ou le data warehouse. Avant le lancement, l'equipe doit savoir quels logs elle controle, combien de temps ils sont conserves, qui peut y acceder et comment les exporter.

Risques, incidents et usage au travail

Si l'usage peut presenter un risque meme en suivant les instructions, le deployeur peut devoir informer le fournisseur ou distributeur, escalader a l'autorite de surveillance du marche et suspendre l'usage. Definissez les declencheurs avant le lancement: sorties dommageables, logs absents, changement de modele, usage hors finalite, plaintes ou evenement securite.

Certains deployeurs doivent realiser une evaluation d'impact sur les droits fondamentaux avant certains usages a haut risque. L'usage en contexte de travail merite aussi un controle dedie, car les employeurs deployeurs peuvent devoir informer les representants des travailleurs et les travailleurs affectes avant la mise en service.

FAQ

Quel est l'objectif pratique?

Prouver que l'organisation suit les instructions du fournisseur, attribue une supervision humaine competente, controle les donnees d'entree, surveille l'usage, conserve les logs, gere les incidents et revalue le workflow lorsque les faits changent.

Comment eviter de ralentir la livraison?

Placez la revue dans les workflows existants de produit, fournisseurs, securite, privacy et lancement. Des declencheurs, owners et modeles de preuve evitent de reconstruire les memes reponses.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 26: Obligations of deployers of high-risk AI systems.
• European Commission AI Act Service Desk, Article 27: Fundamental rights impact assessment for high-risk AI systems.
• European Commission AI Act Service Desk, Article 13: Transparency and provision of information to deployers.