Les organisations pensent souvent que leur rôle est fixe : nous sommes utilisateur, le fournisseur est le fournisseur, point final. Cette hypothèse est régulièrement erronée, ou elle est correcte aujourd'hui mais ne le sera plus demain. Le rôle qu'une organisation occupe par rapport à un système d'IA n'est pas une caractéristique fixe de l'organisation. C'est le résultat de ce qui se passe avec le système : qui le crée, qui l'adapte, qui le met sur le marché, et sous quel nom. Si l'un de ces facteurs change, le rôle peut également changer, et avec lui les obligations qui y sont associées.
Cela signifie que la classification n'est pas un instantané. Un rôle correctement établi au moment de l'acquisition peut s'avérer incorrect un an plus tard, sans qu'aucune décision consciente n'ait été prise en interne.
La classification dépend d'un nombre limité de facteurs, mais ces facteurs ne relèvent pas tous de la partie qui utilise le système. Il est notamment pertinent de savoir si un système a été développé en interne ou acheté, si le système acheté est utilisé sans modification ou s'il est adapté, et si l'adaptation affecte le profil de risque du système. Il est également pertinent de savoir sous quel nom un système est présenté au public : un système revendu ou développé davantage sous une marque propre peut entraîner un rôle différent que le fait de laisser fonctionner un produit externe sans modification. Pour la limite précise entre ces deux positions, la page sur ce qui change lorsqu'une organisation adapte elle-même un modèle acheté est pertinente, et pour la question de base de savoir lequel des deux rôles principaux s'applique, il existe la page qui explique de quoi dépend précisément le choix entre fournisseur et utilisateur.
La classification n'est donc pas quelque chose qu'une organisation détermine une seule fois puis archive. C'est une classification qui doit être réévaluée dès que les faits sous-jacents changent.
Si le rôle change, ce qui est attendu d'une organisation change également. Une partie purement utilisatrice a des obligations différentes d'une partie (co)responsable de la création d'un système. Cela ne concerne pas seulement les formalités administratives. Cela concerne aussi l'endroit où, au sein de l'organisation, la responsabilité d'un système devrait se situer, qui en rend compte, et quel niveau de contrôle est approprié.
Ce glissement se répercute sur la question de savoir avec quelle rigueur un système doit être évalué en interne. Un changement de rôle peut conduire à ce qu'un système auparavant considéré comme maîtrisable doive être réévalué en termes de niveau de risque — une question traitée séparément sur la page consacrée à ce que signifie un niveau de risque élevé pour l'organisation qui utilise ou fournit le système. Inversement, un changement de rôle peut également faire qu'un système sorte justement du champ d'application de certaines obligations, ou y entre de peu. Les types d'applications qui se situent précisément hors du champ d'application et ceux qui y entrent de peu sont expliqués sur la page consacrée à quels types d'applications d'IA se situent hors du champ des obligations.
Les facteurs qui provoquent un changement de rôle se produisent généralement à un niveau que la direction, le service juridique ou la gestion des risques ne perçoivent pas automatiquement. Une équipe qui affine un modèle acheté avec ses propres données. Un service qui transmet un produit de chatbot externe aux clients sous son propre nom de produit. Une intégration qui combine un modèle fournisseur avec des règles propres, et propose ensuite cette combinaison à l'extérieur. Aucune de ces étapes ne passe automatiquement par un registre central, et la liste informatique des outils approuvés n'enregistre généralement pas ce type de modification, car celle-ci n'est pas reconnue comme un « nouvel achat » mais comme une adaptation de quelque chose déjà approuvé.
C'est pourquoi les changements de rôle ne deviennent souvent visibles que lorsque quelque chose se passe mal, ou lorsqu'une justification est demandée depuis l'extérieur. La question « quel est notre rôle par rapport à ce système » est alors répondue rétroactivement, à un moment où la marge de manœuvre pour adapter quelque chose est plus réduite que si la question avait été posée plus tôt.
Comme la classification peut évoluer, la distinction entre ce qui nécessite une attention immédiate et ce qui doit être réévalué à terme est pertinente pour la planification du travail de gouvernance. Tout ce qu'un changement de rôle implique ne requiert pas une action immédiate ; une partie peut être planifiée. La page sur ce qui doit être pris en charge maintenant et ce qui peut être planifié pour plus tard traite de la partie concernée, et de celle qui ne peut pas attendre. Pour un résumé compact de la question de classification elle-même, incluant les principaux points de basculement, il existe la page qui approfondit les circonstances précises dans lesquelles un rôle change.
La question de savoir quel rôle une organisation occupe par rapport à un système d'IA est proche d'une autre question qui reçoit rarement la même attention : quelle part du travail effectif au sein de l'organisation est déjà réalisée par l'IA, est prévue pour l'être, ou est déjà reprise sans que personne ne l'ait consigné. Alors que la question du rôle porte sur la responsabilité par rapport à un système, l'analyse du travail de FTE TO AI porte sur la répartition des tâches elle-même : pour chaque tâche, on calcule quelle part peut être reprise par l'IA, indépendamment du rôle que l'organisation occupe formellement à cet égard. Ces deux questions se rejoignent, car un glissement dans la répartition des tâches est souvent à l'origine d'un glissement de rôle.
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.