De nombreuses organisations partent du principe que la classification en fournisseur ou utilisateur est définitive : un système est acheté quelque part, et le rôle de votre organisation est ainsi déterminé. Dans la pratique, les choses sont plus nuancées. Le rôle que vous avez par rapport à un système d'IA dépend de ce que vous en faites, pas de l'origine du système. Une même organisation peut être utilisateur pour un système et, sans que personne ne l'ait désigné comme tel, fournisseur pour un autre.
La question centrale n'est pas de savoir qui a construit le système, mais qui le met sur le marché ou l'exploite sous son propre nom. Une organisation qui achète un système d'IA prêt à l'emploi et l'utilise pour son propre processus est généralement utilisateur. Dès que cette même organisation adapte, développe davantage, relabellise ou propose ce système à d'autres sous son propre nom, cette image change. Le degré de contrôle sur le modèle joue également un rôle : qui décide avec quelles données l'entraînement se fait, qui fixe les paramètres, qui porte la responsabilité du comportement du système en production. Ces questions ne se posent pas une seule fois lors de l'acquisition, mais restent pertinentes tant que le système est en usage.
Le rôle d'une organisation n'est donc pas une étiquette fixe, mais le résultat de l'usage effectif. Cela signifie que des modifications internes — une nouvelle application d'un système existant, une adaptation par le propre service informatique, la fourniture d'une fonction d'IA à un client ou à une filiale — peuvent modifier la classification sans qu'une décision formelle ait été prise au préalable. Ce que cela signifie en pratique, et à quel moment un rôle change réellement, est développé plus en détail sur la page consacrée à le moment où votre rôle par rapport à un système d'IA change. Il est important de noter que ce changement passe souvent inaperçu, car il se produit au niveau des services, loin de l'endroit où la politique est définie.
La question de savoir si vous êtes fournisseur ou utilisateur ne se pose pas de manière isolée. Elle est liée à la question du niveau de risque d'une application, et à celle de savoir si une application relève du champ d'application de la réglementation. Un système utilisé en tant qu'utilisateur avec un faible impact peut nécessiter un traitement différent de celui appliqué lorsque cette même organisation adapte davantage le système et se rapproche ainsi du rôle de fournisseur. Ce qu'un niveau de risque plus élevé signifie concrètement pour l'organisation est décrit sur la page consacrée à ce qu'un niveau de risque élevé signifie pour votre propre organisation. De même, toutes les applications ne relèvent pas du champ d'application des mêmes exigences ; quelles applications en sont exclues et de quoi cela dépend est expliqué sur la page consacrée à quelles applications sont exclues du champ d'application.
La raison pour laquelle cette classification reste floue pour de nombreuses organisations n'est pas l'absence de règles. Le texte actuel et les critères précis se trouvent ailleurs et ne sont pas modifiés par ce texte. Le problème se situe en amont : pour savoir quel rôle s'applique, il faut d'abord savoir quels systèmes d'IA sont réellement utilisés, par qui, et avec quel degré d'adaptation. Cet inventaire manque dans la plupart des organisations. La liste officielle des outils approuvés par l'informatique décrit rarement ce qui est réellement utilisé. Les services adoptent des outils, adaptent des modèles avec leurs propres données, ou intègrent une fonction d'IA dans un processus interne, sans que cela soit consigné de manière centralisée nulle part. Qui veut savoir si l'organisation est fournisseur ou utilisateur doit donc d'abord savoir ce qui fonctionne réellement — et c'est une question à laquelle un document de politique ne répond pas, mais un inventaire qui ose demander aux gens ce qu'ils utilisent, sans que cela soit lié à une sanction.
Comme le rôle d'une organisation peut changer sans décision formelle, il est important pour la direction et les organes de contrôle que les rapports en tiennent compte. Une approche de gouvernance fondée sur une répartition statique des rôles manque le moment où une adaptation interne place effectivement l'organisation dans une autre position. La manière dont une politique d'IA peut être conçue pour rendre visibles ce type de changements plutôt que de les dissimuler, et pour être effectivement lue par les responsables, est abordée sur la page consacrée à une politique d'IA qui correspond à la pratique plutôt qu'au placard.
La question de savoir si votre organisation est fournisseur ou utilisateur porte sur la responsabilité et les obligations. Elle ne dit encore rien de ce que l'IA signifie pour le travail lui-même : quelles tâches sont reprises, modifiées ou soutenues par elle. Cette question s'inscrit dans la continuité de la détermination du rôle, mais demande un regard différent — non pas sur la gouvernance, mais sur le contenu du travail. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, indépendamment du rôle que l'organisation occupe par rapport au système sous-jacent.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.