Déployeur AI Act : définition, obligations et preuves à conserver.
Le mot déployeur ne désigne pas uniquement l’équipe informatique qui installe un logiciel. Il vise l’organisation qui utilise un système d’IA sous sa propre autorité dans un cadre professionnel. Cette qualification doit être faite usage par usage.
Une organisation est déployeur lorsqu’elle utilise un système d’IA sous sa propre autorité dans un cadre professionnel. Ses obligations dépendent ensuite du système, de son risque, de sa finalité et des personnes concernées.
Cluster éditorial : Acteurs, rôles et responsabilités · Intention : Comprendre la définition et les obligations du déployeur AI Act
En bref
L’essentiel à retenir
01
Le déployeur utilise le système sous sa propre autorité dans un cadre professionnel.
02
Le contrat commercial ne suffit pas à fixer le rôle réglementaire.
03
Les obligations renforcées concernent notamment les systèmes à haut risque.
04
L’usage réel, la supervision, les journaux et les incidents doivent être documentés.
01
Reconnaître un déployeur à partir des faits
La définition se lit à partir de l’usage réel. Une banque qui emploie un système pour aider à instruire des demandes, une entreprise qui utilise un outil de recrutement ou une association qui s’appuie sur un moteur d’éligibilité peuvent être déployeurs. Le fait que l’outil soit hébergé chez un fournisseur, intégré par un prestataire ou payé sous forme d’abonnement ne change pas ce point central. L’organisation utilise le système sous sa propre autorité et en organise les conséquences dans son activité.
Commencez par décrire la finalité, les utilisateurs, les personnes affectées et les décisions influencées. Identifiez ensuite l’entité juridique qui choisit l’usage, fixe les consignes et bénéficie du résultat. Cette méthode évite de confondre le service informatique, l’intégrateur technique et le déployeur au sens du règlement. Elle permet aussi de repérer les cas où plusieurs entités d’un groupe doivent être qualifiées séparément.
Le rôle peut évoluer lorsqu’une organisation appose son nom ou sa marque sur un système, modifie sa destination ou réalise une modification substantielle. Une entreprise qui personnalise un produit ne devient pas automatiquement fournisseur. Elle doit toutefois examiner l’article 25 avant toute extension importante, car certaines décisions déplacent les responsabilités. La documentation du fournisseur et le contrat donnent des indices, mais la qualification découle du règlement et des faits.
Cas concret : une société achète un assistant de rédaction pour ses équipes. Elle reste généralement déployeur lorsqu’elle paramètre des modèles de messages et contrôle les accès. Si elle transforme ensuite le système, le propose à ses clients sous sa marque et change sa destination, une nouvelle analyse devient nécessaire. Conservez la comparaison entre la version d’origine, les changements réalisés et l’usage final. Cette chronologie soutient la décision de rôle.
Distinguer le socle commun des obligations haut risque
Tous les déployeurs doivent examiner les pratiques interdites, soutenir le développement de la maîtrise de l’IA chez les personnes agissant pour leur compte et appliquer les règles de transparence qui correspondent à leurs usages. Les obligations ne forment pourtant pas une checklist identique pour chaque outil. Un chatbot de service client, un générateur d’images et un système de recrutement posent des questions différentes.
Pour un système à haut risque, l’article 26 ajoute un ensemble de mesures concrètes. Le déployeur suit les instructions d’utilisation, organise une supervision humaine effective, contrôle les données d’entrée lorsqu’il les maîtrise, surveille le fonctionnement et conserve les journaux sous son contrôle. Certaines situations imposent aussi une information des travailleurs ou des personnes concernées, une analyse d’impact sur les droits fondamentaux ou un enregistrement. Chaque obligation doit être reliée à un propriétaire et à une preuve.
Nommer un humain dans une procédure ne suffit pas. La personne doit comprendre le système, reconnaître les limites pertinentes, interpréter la sortie avec prudence et pouvoir interrompre ou ignorer la recommandation. Elle doit aussi disposer du temps, des informations et de l’autorité nécessaires. Une validation automatique de centaines de décisions en quelques minutes ne constitue pas une supervision crédible.
Testez la supervision sur des cas réalistes. Présentez une sortie plausible mais fausse, une situation hors périmètre et un conflit entre la recommandation du système et une information métier. Observez si l’utilisateur repère l’écart, consulte les éléments utiles et choisit la bonne voie d’escalade. Conservez le scénario, les résultats et les actions correctives. Cette preuve est plus informative qu’une simple attestation de présence à une formation.
Préparer la surveillance et la réaction aux incidents
Le déployeur doit savoir reconnaître un fonctionnement susceptible de présenter un risque. Il définit donc des indicateurs, des seuils d’alerte, un canal vers le fournisseur et une procédure de suspension. Les journaux disponibles doivent être accessibles aux personnes chargées de l’analyse. Le contrat précise les informations et l’assistance attendues lorsque le système est exploité dans le cloud.
Lorsqu’un incident survient, la première priorité consiste à protéger les personnes et à limiter l’effet. Préservez ensuite la version du système, les paramètres, les données d’entrée pertinentes, les sorties, les décisions humaines et la chronologie. Une cellule commune réunit métier, technique, sécurité, conformité, juridique et communication selon la gravité. La décision de reprise doit être justifiée et assortie de contrôles vérifiés.
Le dossier du déployeur doit permettre à un tiers de comprendre le système, la finalité, le rôle retenu, la qualification de risque et les contrôles réellement appliqués. Il réunit la fiche d’usage, la notice du fournisseur, le contrat, les décisions de qualification, les procédures, les habilitations, les formations, les tests de supervision, les journaux disponibles et les incidents. Chaque document porte une version, un propriétaire et une date de revue.
Le niveau de détail dépend de l’effet possible sur les personnes, de la complexité et de la fréquence des changements. Pour un outil bureautique de faible impact, une fiche courte peut suffire. Pour un système qui influence l’emploi, le crédit ou l’accès à un service essentiel, la preuve doit être plus structurée. Le dossier ne sert pas uniquement au contrôle. Il aide l’équipe à prendre de meilleures décisions lorsque le produit évolue.
Elle peut être déployeur d’un système d’IA utilisé sous sa propre autorité dans un cadre professionnel. Il faut qualifier l’usage précis, l’entité, la finalité et les responsabilités de chaque acteur.
Non. Le déployeur est en principe l’organisation ou l’entité qui utilise le système sous sa propre autorité. Le service informatique peut en assurer l’intégration ou l’administration.
Non. L’article 26 vise les déployeurs de systèmes à haut risque. D’autres obligations, notamment les articles 4, 5 et 50, peuvent concerner des systèmes qui ne sont pas à haut risque.
Le propriétaire métier fournit les faits. La conformité ou le juridique sécurise l’interprétation. La technique décrit le système et les changements. La décision et ses réserves doivent être attribuées et datées.
Après un changement de marque, de finalité, de version, d’intégration, d’entité utilisatrice ou de répartition contractuelle des tâches.
