Avant qu'un niveau de risque, une obligation ou une mesure de gouvernance ne prenne son sens, il faut établir quel rôle joue votre organisation. Celui qui met un système d'IA sur le marché a d'autres responsabilités que celui qui déploie un système construit par un autre. Le terme utilisé pour cela est connu : fournisseur face à utilisateur. Mais cette classification elle-même n'est pas fixée dans un organigramme. Elle dépend de ce qu'une organisation fait avec un système spécifique, et cela peut varier par système, par département et par moment.
La question centrale n'est pas de savoir qui a acheté ou installé le système, mais qui l'a mis sur le marché ou le met à disposition sous son propre nom. Une organisation qui achète un logiciel et l'utilise tel qu'il est livré est généralement utilisateur. Une organisation qui développe un système, le fait développer sous son nom, ou modifie un système existant de manière à en changer fonctionnellement la nature, peut ainsi se retrouver dans le rôle de fournisseur. C'est souvent là que les organisations se méprennent : affiner un modèle, construire une couche propre au-dessus d'un système externe, ou entraîner un chatbot sur ses propres données peut faire basculer le rôle sans que personne ne l'ait perçu comme un choix conscient. Ce qui compte précisément comme une adaptation modifiant le rôle est décrit sur ce qui change quand vous adaptez vous-même un modèle.
La plupart des organisations ne sont pas exclusivement fournisseur ou exclusivement utilisateur. Une banque qui déploie un modèle de langage externe pour le service client en est utilisatrice, mais si cette même banque met à disposition d'un autre département ou d'un client un modèle de risque développé en interne, un rôle de fournisseur apparaît pour ce système. Cela signifie que la classification doit être établie par application, et non une seule fois pour l'ensemble de l'organisation. Un inventaire qui consigne, par système, qui l'a construit, qui l'a adapté et qui l'utilise, est donc le seul moyen de répondre à cette question de manière structurelle plutôt qu'occasionnelle.
Le rôle n'est pas une caractéristique fixe d'une organisation mais un statut sujet à changement. Un fournisseur peut modifier son système d'une manière qui affecte le profil de risque. Un développeur interne peut faire évoluer un outil interne vers quelque chose qui est proposé en dehors de l'organisation. Un système entré comme un outil simple peut, après une mise à jour, exécuter des tâches qui le placent dans une autre catégorie de risque. À quels moments ce basculement se produit concrètement et ce que cela signifie pour la question de savoir qui en est alors responsable est expliqué sur quand votre rôle change-t-il. Pour les organisations qui souhaitent comprendre ce qu'implique concrètement un basculement vers un niveau de risque supérieur, ce qu'implique un niveau de risque élevé pour votre organisation offre un développement plus approfondi.
Toute application désignée par le terme d'intelligence artificielle ne relève pas du cadre pour lequel cette répartition des rôles est pertinente. Certains systèmes se situent hors du champ pour lequel cette classification a été conçue, et il est tout aussi important pour une organisation de savoir ce qui se trouve hors champ que de savoir ce qui s'y trouve. Sinon, du temps est consacré à classer quelque chose qui n'avait pas besoin de l'être, ou quelque chose est négligé parce qu'il semblait trop mineur. Les applications qui se situent hors de ce cadre, et pourquoi, sont décrites sur quelles applications sont hors champ.
Établir le rôle est une première étape, non l'aboutissement d'un processus de gouvernance. Après la classification vient la question de ce qui doit effectivement se passer pour chaque rôle et chaque niveau de risque, et cette question se divise en deux catégories : ce qui requiert une attention immédiate et ce qui peut être planifié à plus long terme. Ces deux catégories sont souvent confondues, avec pour conséquence que des affaires urgentes restent en suspens tandis que du temps est consacré à quelque chose qui n'est pas encore urgent. Un aperçu des priorités en la matière figure sur ce qui est urgent et ce qui peut être planifié. Ceux qui souhaitent approfondir davantage la question de la répartition des rôles, avec les critères précis qui déterminent la frontière entre fournisseur et utilisateur, trouveront ce développement sur êtes-vous fournisseur ou utilisateur : de quoi cela dépend.
Cette classification n'a de sens que si elle est appliquée à ce qui fonctionne réellement dans l'organisation, et non à ce qui figure sur une liste approuvée. Les systèmes introduits sans autorisation comptent tout autant, et le rôle qui s'y rattache doit être établi tout aussi rigoureusement. Cela requiert un inventaire qui dépasse l'administration informatique.
Dès qu'il est clair quel rôle une organisation joue par système, l'attention se déplace naturellement vers une autre question : que font réellement ces systèmes, et quelle part du travail reprennent-ils. Cette question se situe en dehors du scan de gouvernance, mais s'y rattache directement. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, offrant ainsi une image de l'impact d'un système en complément de l'image des obligations qui s'y rattachent.
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.