Quand les obligations des deployeurs s'appliquent et que faire ensuite

Les obligations des deployeurs s'appliquent lorsqu'une entreprise utilise un systeme d'IA a haut risque sous sa propre autorite. Pour une equipe SaaS, la question n'est pas seulement de savoir qui a construit le systeme. Elle est de savoir qui decide de l'usage, de la configuration, de la supervision, du suivi et des preuves dans le workflow concret.

L'etape suivante est operationnelle: identifier le systeme d'IA, confirmer le statut haut risque, evaluer le role de deployeur, nommer un responsable, suivre les instructions du fournisseur, definir la supervision humaine, surveiller le fonctionnement, conserver les logs utiles et documenter l'escalade en cas de risque ou d'incident.

Ce travail rejoint AI governance expectations for SaaS vendors, internal AI-tool review, compliance owner models et le risque des static compliance documents.

Quand le sujet apparait

Le sujet devient important lorsqu'une entreprise utilise l'IA dans des processus produit, client, RH, finance, education, sante, secteur public, services essentiels ou decisions ayant un impact sur des personnes. Une meme entreprise peut etre fournisseur pour une fonctionnalite et deployeur pour une autre.

Les declencheurs typiques incluent le classement de candidats, la gestion des travailleurs, l'evaluation de credit ou d'assurance, les usages educatifs, la biometrie, les infrastructures critiques, les services essentiels et les workflows configurables par les clients pour des decisions sensibles.

Quand cela peut ne pas s'appliquer

Tous les workflows SaaS avec IA ne creent pas des obligations d'article 26. Un assistant de redaction, un resume interne de support, un outil d'aide au code ou une recherche documentaire interne peuvent etre hors haut risque si le contexte ne l'est pas.

Cela ne supprime pas les controles habituels: confidentialite, securite, revue fournisseur, transparence, limites contractuelles ou inventaire IA. L'objectif est le bon routage: evidence legere pour l'IA ordinaire, revue approfondie pour les usages sensibles.

Ce que le deployeur doit maitriser

L'article 26 est tres operationnel. Le deployeur doit utiliser le systeme selon les instructions, prendre des mesures techniques et organisationnelles appropriees et attribuer la supervision humaine a des personnes competentes, formees, autorisees et soutenues.

S'il controle les donnees d'entree, il doit veiller a ce qu'elles soient pertinentes et suffisamment representatives du but prevu. Il doit aussi surveiller le fonctionnement selon les instructions. En cas de risque ou d'incident grave, il faut informer, escalader et parfois suspendre l'usage.

Les logs comptent. Lorsqu'ils sont sous le controle du deployeur, ils doivent etre conserves pendant une duree adaptee et au moins six mois, sauf autre exigence applicable. Pour un usage au travail d'un systeme a haut risque, les representants des travailleurs et les travailleurs concernes doivent etre informes avant usage.

Que faire en premier

Mettez en place une courte fiche d'admission pour les deploiements IA. Elle doit capturer systeme, fournisseur, responsable, finalite, parcours utilisateur, personnes affectees, geographie, donnees, sortie, usage humain, signal haut risque, role de l'entreprise et emplacement des instructions.

Classez ensuite le cas en trois voies: usage IA ordinaire, usage incertain ou sensible, deploiement probablement haut risque. Pour la troisieme voie, creez un decision record avec role, instructions, supervision humaine, donnees d'entree, monitoring, conservation des logs, escalade, information des travailleurs et reevaluation.

Erreurs courantes

La premiere erreur consiste a penser que les obligations des deployeurs concernent seulement les clients. Les fournisseurs SaaS utilisent aussi l'IA en interne, configurent des workflows pour des clients ou operent l'IA dans des services manages.

La deuxieme est de s'appuyer sur la documentation fournisseur sans la relier a l'usage reel. Les instructions sont essentielles, mais elles ne remplacent pas l'analyse de l'exploitation, de la supervision, des donnees d'entree, du monitoring et de l'escalade.

La troisieme est de nommer une supervision humaine sans autorite. Le reviewer doit avoir formation, acces, temps, droit d'escalade et regle d'arret.

FAQ

Quel est le but pratique?

Garantir qu'un systeme d'IA a haut risque est utilise de maniere responsable apres sa mise a disposition, avec responsables, supervision, suivi, logs et escalade.

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

Lorsque l'equipe utilise, configure ou exploite un systeme d'IA a haut risque sous son autorite, en interne, pour des clients ou dans des workflows sensibles.

Que documenter en premier?

Le systeme, la finalite, le responsable, le role, le screening haut risque, les instructions, la supervision humaine, les donnees d'entree, le monitoring, les logs et les incidents.