L’utilisateur veut comprendre le rôle de fournisseur dans le contexte de l’AI Act de l’UE et l’appliquer à des travaux concrets de gouvernance ou de conformité de l’IA.
Un fournisseur est une personne, une organisation, une autorité publique, une agence ou un autre organisme qui développe un système d’IA ou un modèle d’IA à usage général, ou le fait développer, et le met sur le marché ou le met en service sous son propre nom ou sa propre marque.
Au sens de l’AI Act de l’UE, un fournisseur est l’acteur qui développe un système d’IA ou un modèle d’IA à usage général, ou le fait développer, et le met sur le marché ou le met en service sous son propre nom ou sa propre marque. Le rôle ne se limite pas aux entreprises qui écrivent chaque ligne de code. Une entreprise peut devenir fournisseur si elle conditionne, marque, modifie substantiellement ou fournit un système d’IA comme son propre produit ou service réglementé. Les concepts clés d’Atlas sont provider, deployer, downstream-provider et intended-purpose. Le statut de fournisseur est important parce que les obligations les plus exigeantes de l’Acte s’attachent souvent à l’acteur responsable de la conception, de la mise sur le marché ou du contrôle du système. Pour les systèmes d’IA à haut risque, le fournisseur est généralement censé créer les preuves de conformité avant que le système n’atteigne les utilisateurs. Pour les modèles GPAI, des obligations de fournisseur peuvent aussi s’appliquer aux développeurs de modèles dont les modèles sont utilisés par de nombreux systèmes en aval. Le rôle doit donc être évalué à partir des contrats, de la marque, du contrôle sur la destination prévue, des droits de modification et de la responsabilité relative aux preuves de conformité.
Pensez au fournisseur comme à l’entreprise dont le nom figure sur un produit réglementé. Si une société conçoit un dispositif médical, le vend sous sa marque et indique aux clients à quoi il sert, les autorités regarderont généralement d’abord cette société pour la conformité au niveau du produit. L’IA fonctionne de manière similaire. Le fournisseur n’est pas toujours la personne qui appuie sur le bouton dans l’usage quotidien ; c’est l’acteur qui rend le système disponible sous son nom, contrôle la destination prévue ou fait en sorte qu’il soit mis en service. Le déployeur est plus proche de l’organisation qui utilise l’outil dans ses opérations. C’est pourquoi l’étiquette doit suivre le rôle réel du produit, et non simplement le titre commercial prévu dans le contrat.
Analogie
Un fabricant de produit de marque : le nom figurant sur le produit indique souvent qui doit prouver que le produit a été conçu et fourni légalement.
La classification comme fournisseur est importante parce qu’elle détermine qui supporte la charge de conformité la plus lourde. Si votre organisation est fournisseur, elle peut devoir gérer la gestion des risques, les contrôles de conception, la documentation technique, l’évaluation de la conformité, les instructions d’utilisation, la gestion de la qualité, la surveillance, les actions correctives et la coopération réglementaire. Le risque est particulièrement élevé pour les entreprises qui personnalisent des modèles tiers, proposent des outils d’IA en marque blanche ou intègrent l’IA dans des produits vendus sous leur propre marque. Si l’analyse du rôle est repoussée jusqu’à la signature du contrat ou au lancement, l’organisation peut constater que les documents du fournisseur amont sont incomplets et que les preuves internes n’ont jamais été collectées. Une cartographie précoce des rôles aide aussi à décider ce qui doit être demandé aux fournisseurs amont avant que les décisions de développement et d’achat deviennent difficiles à inverser.
Urgence
Une mauvaise hypothèse fournisseur/déployeur peut créer une lacune de conformité tardive juste avant la mise sur le marché ou la due diligence client.
Un fournisseur devrait traiter la classification du rôle comme une décision de gouvernance produit, et non comme une étiquette ajoutée par le service juridique à la fin. Le fournisseur doit définir la destination prévue, comprendre les mauvais usages raisonnablement prévisibles, identifier la catégorie de risque du système et conserver les preuves montrant que les obligations applicables ont été respectées. Pour l’IA à haut risque, cela signifie généralement un processus géré par la qualité pour la conception, les tests, la documentation, la journalisation, la supervision humaine, la cybersécurité, la surveillance après mise sur le marché et le traitement des incidents graves. Si l’organisation s’appuie sur un modèle ou un composant tiers, elle doit tout de même obtenir assez d’informations amont pour soutenir ses propres obligations. Ces preuves devraient être reliées aux jalons de release, à la gestion des fournisseurs et aux procédures de contrôle des changements afin que la responsabilité reste claire dans le temps.
Le rôle de fournisseur est souvent mal compris parce que les équipes l’assimilent à la qualité d’auteur du logiciel. Dans l’AI Act de l’UE, le contrôle, la marque, la mise sur le marché et la destination prévue peuvent compter autant que la personne qui a initialement codé le modèle ou l’interface.
Erreur 1 : supposer qu’un prestataire externe est toujours le fournisseur conduit un revendeur ou intégrateur sous marque propre à manquer ses propres obligations.
Erreur 2 : changer la destination prévue d’un système d’IA sans réévaluer le statut de rôle peut transformer un usage proche du déploiement en responsabilité de niveau fournisseur.
Cette page devrait relier provider à deployer, downstream-provider et intended-purpose. La comparaison provider-vs-deployer est la lecture suivante essentielle, tandis que provider-vs-downstream-provider aide à expliquer les déplacements de responsabilité dans la chaîne d’approvisionnement de l’IA. Ensemble, ces liens aident les lecteurs à passer de la définition juridique à la responsabilité dans la chaîne d’approvisionnement, aux changements de rôle et aux obligations pratiques de documentation. Elle soutient aussi un maillage interne propre entre les définitions et les décisions de mise en œuvre.