La plupart des organisations ne choisissent pas de mener plusieurs programmes de gouvernance de l’IA. Cela se produit parce que la sécurité, la protection des données, le juridique, l’IA responsable et l’ingénierie abordent chacun l’IA à travers leurs propres obligations, et que chacun voit juste sur sa part du problème. La solution consiste à partager un dossier unique et une porte d’entrée unique, tout en laissant chaque équipe maîtresse de ses décisions, et il n’est pas nécessaire de se réorganiser pour y parvenir.

Pourquoi chaque équipe finit-elle par avoir sa propre revue de l’IA ?

Parce que chaque fonction aborde l’IA à travers une obligation différente.

• La sécurité voit apparaître de nouveaux flux de données, de nouveaux fournisseurs et, de plus en plus, des agents autorisés à appeler des outils. Elle étend donc son évaluation des fournisseurs et sa modélisation des menaces pour les couvrir.

• La protection des données constate de nouveaux usages des données personnelles et les ajoute à son analyse d’impact.

• L’équipe IA responsable s’attache à l’équité, à l’explicabilité et à la supervision humaine, et construit une évaluation par niveaux de risque fondée sur les principes propres à l’organisation.

• L’ingénierie suit les modèles, les versions, les évaluations et les déploiements dans un registre au sein de sa propre plateforme.

• Le juridique et la conformité examinent les nouvelles obligations réglementaires et les clauses contractuelles, et ajoutent des questions sur l’IA aux revues qu’ils mènent déjà.

Chaque équipe crée un formulaire, un tableur ou une file d’attente, et dès que le volume augmente, chacune se met en quête d’un outil. Chacun de ces besoins est légitime. Pris ensemble, ils posent tous la même question : où doit se trouver le dossier de chaque système d’IA ?

Que coûte cette fragmentation ?

Les symptômes sont faciles à repérer :

La situation s’aggrave avec le temps. Les équipes produit comprennent que la gouvernance est lente et commencent à décrire leurs projets de manière à éviter la revue. Les registres divergent de plus en plus, et leur rapprochement incombe à celui à qui l’on pose la prochaine question difficile.

Le retard tient rarement aux revues elles-mêmes. L’essentiel du temps s’écoule entre les étapes, pendant qu’une demande attend que l’équipe suivante s’aperçoive qu’elle peut la prendre en charge. Lorsque quatre ou cinq équipes recueillent séparément les mêmes informations, ces temps morts peuvent totaliser plusieurs mois.

La répétition nuit aussi au dossier. Un responsable métier confronté une nouvelle fois à la même question répond plus brièvement et avec moins de soin, si bien que les questions redondantes dégradent la qualité de ce que chaque équipe finit par examiner.

De quoi chaque équipe a-t-elle besoin dans le dossier ?

Moins que ne le laissent penser leurs formulaires. L’essentiel de ce que demande chaque revue est la même description de base du système. La différence tient à la décision que chaque équipe prend à partir de celle-ci.

Le socle commun (finalité, responsable, données, modèle, personnes concernées et part des décisions que le système prend seul) doit être recueilli une seule fois, et chaque équipe s’y réfère au lieu de reposer les mêmes questions.

Que contient le dossier commun ?

Un dossier exploitable comporte trois couches, chacune renseignée à une étape différente.

1. La description, recueillie une seule fois lors de la demande. Finalité et cas d’usage ; responsables métier et techniques ; qui utilise le système et qui est concerné par celui-ci ; s’il a été développé en interne, acheté ou activé dans un produit existant ; le modèle et son fournisseur ; les données utilisées, y compris les données personnelles et sensibles ; les décisions qu’il prend ou éclaire ; et ce qu’il peut faire sans l’approbation d’une personne.

2. La classification, déduite de la description. Le niveau de risque, les réglementations et politiques internes applicables, et les revues qu’exige ce niveau.

3. Les décisions et les preuves, ajoutées par chaque équipe. Les approbations et leurs conditions, les résultats des évaluations, les constats ouverts, les résultats de tests rattachés à la version du modèle et la date de la prochaine revue.

Les informations propres à chaque équipe peuvent rester auprès de l’équipe qui en a besoin. L’analyse d’impact complète de la protection des données, le modèle de menaces de la sécurité et la suite d’évaluation de l’ingénierie peuvent résider dans leurs propres outils, à condition que le résultat et un lien soient reportés dans le dossier.

Approuvez l’usage, pas seulement le logiciel. Beaucoup de processus existants sont adossés aux achats : ils approuvent un logiciel une fois, puis ne voient jamais à quoi il sert. Le même assistant de rédaction est anodin pour mettre au propre un e-mail, mais devient un vrai risque lorsque quelqu’un y colle un contrat confidentiel. Selon l’EU AI Act, le risque dépend de l’usage qui est fait d’un système. Un nouvel usage d’un outil approuvé devrait donc repasser par la porte d’entrée.

Un seul dossier, des décisions distinctes

L’erreur classique consiste à résoudre le chevauchement en choisissant l’outil d’une équipe et en demandant à toutes les autres de l’utiliser. Cette solution tient rarement, car le modèle de données de chaque outil reflète son équipe d’origine. Une plateforme de protection des données est construite autour des activités de traitement, une plateforme de sécurité autour des actifs et des fournisseurs, une plateforme de ML autour des versions de modèles. Aucune n’est construite autour du cas d’usage de l’IA, qui est pourtant ce que chaque équipe examine.

Le modèle qui fonctionne comporte quatre volets :

1. Une porte d’entrée unique. Toute nouvelle demande d’IA, qu’il s’agisse d’un système développé en interne, acheté ou activé dans un produit SaaS existant, passe par un processus de demande unique.

2. Un dossier par système d’IA. Le processus de demande recueille le socle commun et classe le système par niveau de risque. Une fois le système approuvé, ce dossier devient sa fiche dans l’inventaire IA.

3. Des revues en parallèle, des décisions distinctes. Le dossier est orienté vers les équipes qu’exige le niveau. Chaque équipe mène sa propre revue, conserve ses propres approbateurs et reste maîtresse de sa décision.

4. Les constats remontent dans le dossier. Une condition posée par la sécurité, un constat de la protection des données ou un résultat de test est rattaché au même dossier, de sorte que chaque équipe voit l’état actuel. Si une équipe mène sa revue dans son propre outil de gestion des tickets, l’intégration doit fonctionner dans les deux sens. La demande ouvre le ticket, et la décision, les conditions et les commentaires remontent dans le dossier.

Les systèmes existants restent en place. Les tickets continuent d’arriver dans Jira ou ServiceNow, et les risques d’entreprise continuent de remonter dans la suite GRC. Notre guide du processus de demande IA par niveaux détaille la classification par niveaux et les relais vers les processus GRC existants, et notre comparaison des outils de gouvernance de l’IA et des modules GRC précise quels dossiers relèvent de quel outil.

Comment l’orientation des demandes fonctionne-t-elle en pratique ?

Chaque organisation trace les limites un peu différemment. Dans les flux de travail que nous avons vus tenir dans la durée, les niveaux de risque déterminent quelles équipes examinent quoi : les demandes à faible risque avancent vite et celles à haut risque passent par toutes les revues nécessaires. Le niveau découle de quelques questions de présélection posées lors de la demande :

• Le système utilise-t-il des données personnelles ou sensibles ?

• Prend-il ou éclaire-t-il des décisions concernant des personnes, comme le recrutement, le crédit, la tarification ou l’accès à des services ?

• Peut-il agir dans d’autres systèmes sans l’approbation d’une personne ?

• Ses résultats parviennent-ils directement aux clients ?

• A-t-il été développé en interne, acheté ou activé dans un produit que vous utilisez déjà ?

• Où vivent les personnes concernées ?

Un oui à l’une des trois premières questions implique généralement au moins le niveau moyen, et des données personnelles combinées à des décisions concernant des personnes ou à une action autonome impliquent généralement le niveau élevé. Une version simple à trois niveaux se présente ainsi :

Prenons une demande courante : une équipe RH souhaite activer, dans son logiciel de recrutement existant, une fonctionnalité d’IA qui classe les candidats. Dans le modèle fragmenté, la sécurité peut approuver la mise à jour du fournisseur en une journée sans que la protection des données ni l’équipe IA responsable n’en soient jamais informées. Dans le modèle consolidé, la demande passe par la porte d’entrée. Le dossier indique que la fonctionnalité utilise des données personnelles pour éclairer des décisions de recrutement, ce qui la place au niveau élevé. La protection des données mène son analyse d’impact, l’équipe IA responsable teste l’équité et fixe les exigences de supervision, et la sécurité examine la façon dont le fournisseur traite les données, le tout sur la base de la même description. Les conditions de chaque équipe sont rattachées au dossier, et la fonctionnalité est mise en production une fois qu’elles sont remplies. Lorsque quelqu’un demande plus tard quels systèmes éclairent des décisions de recrutement, il suffit d’appliquer un filtre à l’inventaire.

Pourquoi un dossier unique est-il important au regard de la réglementation ?

Dans plusieurs pays et territoires, les régulateurs attendent désormais des organisations qu’elles sachent où des systèmes automatisés prennent ou éclairent des décisions concernant des personnes, et qu’elles soient en mesure de le dire. L’EU AI Act impose des obligations aux déployeurs de systèmes d’IA à haut risque, et le RGPD encadre les décisions fondées exclusivement sur un traitement automatisé. Des États américains comme le Colorado et la Californie, ainsi que le Québec et l’Australie, adoptent des règles qui obligent les organisations à faire connaître, et dans certains cas à évaluer, leur recours à la prise de décision automatisée. Chaque loi le formule différemment, mais toutes demandent quels systèmes sont concernés, quelles données ils utilisent, quelles décisions ils influencent et qui les a contrôlés.

Dans le modèle fragmenté, ces réponses sont réparties entre plusieurs équipes. L’ingénierie sait quels systèmes existent, la protection des données sait lesquels utilisent des données personnelles, l’équipe IA responsable sait lesquels éclairent des décisions importantes, et la sécurité sait quels outils tiers ont été approuvés. Avec un dossier unique, la protection des données et le juridique peuvent répondre sur demande au lieu de reconstituer le tableau à partir de listes distinctes.

Sur quoi les équipes butent-elles lors de la consolidation ?

La plupart des consolidations se heurtent à quelques problèmes récurrents.

• Deux portes d’entrée pendant la transition. Si l’ancien formulaire reste en ligne pendant une migration, certains demandeurs l’utiliseront, puis croiront que leur demande s’est perdue. Désactivez l’ancien formulaire le jour où le nouveau est mis en service.

• Des fiches d’inventaire créées trop tôt. Lorsque la soumission d’une demande crée immédiatement une fiche dans l’inventaire, chacun saisit le strict minimum pour faire avancer sa demande, et l’inventaire se remplit de dossiers sommaires sur des systèmes qui ne seront peut-être jamais approuvés. Recueillez la description lors de la demande et ajoutez le système à l’inventaire une fois qu’il est approuvé.

• Une évaluation des risques visible par le demandeur. Les demandeurs qui voient quelles réponses élèvent le niveau peuvent apprendre à adapter leurs réponses pour ne pas le faire monter, et certains voient des alertes de risque qu’ils ne savent pas interpréter. Il vaut généralement mieux ne montrer le résultat qu’aux évaluateurs et aux approbateurs.

• Des scores de risque que personne n’a validés avec le juridique. Un score de risque élevé documenté pour un outil que l’organisation finit par approuver peut faire mauvaise impression en cas de contentieux ultérieur. Il peut être plus prudent de commencer par de simples avis des évaluateurs, allant de l’absence de réserve au blocage, et de n’introduire les scores qu’une fois la taxonomie des risques arrêtée et alignée sur la matrice des risques de l’entreprise. Demandez au juridique comment le risque doit être consigné, et pas seulement ce qui doit être évalué.

• Un contrôle que personne n’a conçu. Le nombre d’agents reste souvent faible pour des raisons que personne n’a choisies, par exemple parce que chaque agent nécessite encore un ticket informatique. Cette limite disparaît dès que chacun peut créer ses propres agents. Si une file d’attente fait discrètement office de contrôle, faites passer les agents par la porte d’entrée avant que cette file ne se résorbe.

• Tous les membres du comité traités comme des approbateurs. Les comités de revue ont tendance à s’étoffer jusqu’à ce que l’équipe de gouvernance passe ses journées à relancer les évaluateurs par messagerie instantanée et par e-mail, et que les membres du comité ne sachent pas quand une demande requiert réellement leur intervention. Distinguez les personnes qui doivent approuver de celles qui ont seulement besoin d’être informées, et notifiez-les différemment.

Par où commencer

1. Cartographiez les recoupements avant de choisir des outils. Listez les champs que recueille le formulaire actuel de chaque équipe et repérez ceux qui décrivent le système plutôt qu’une décision propre à une équipe. Les recoupements sont généralement nombreux.

2. Convenez du dossier commun et de son responsable. Décidez quels champs figurent dans le dossier du système d’IA et qui le tient à jour. Ce rôle revient souvent à l’équipe IA responsable ou au responsable de l’IA, conjointement avec la protection des données.

3. Formalisez les niveaux par écrit. Publiez les questions de présélection, les revues requises pour chaque niveau et un délai de traitement cible pour chacun, afin que les demandeurs sachent à quoi s’attendre avant de commencer.

4. Commencez par une première version courte. Un formulaire simple est un formulaire utilisé. Couvrez l’essentiel de vos besoins dans la première version et ajoutez le reste une fois qu’elle est adoptée. Si différentes régions utilisent leurs propres questionnaires, fusionnez-les d’abord, puis ajoutez des branches propres à chaque pays ou territoire.

5. Ouvrez une porte d’entrée unique et orientez les demandes en parallèle. Conservez les approbateurs de chaque équipe ; ne changez que le point d’entrée de la demande et l’emplacement du dossier.

6. Intégrez les systèmes déjà en service. Commencez par ceux qui prennent ou éclairent des décisions importantes concernant des personnes, ou qui utilisent des données sensibles, car ce sont eux qui présentent le plus de risques et suscitent le plus de questions.

7. Choisissez l’outillage en dernier. La bonne plateforme est celle dont le modèle de données accueille le dossier du système d’IA et assure un relais fluide vers le flux de travail existant de chaque équipe.

Questions fréquentes

Consolider la gouvernance de l’IA signifie-t-il qu’une équipe reprend les revues des autres ?

Non. La consolidation porte sur le dossier et la porte d’entrée. Chaque équipe conserve sa propre revue et ses approbateurs, et continue de prendre sa propre décision ; les équipes cessent simplement de recueillir séparément les mêmes informations.

Les équipes doivent-elles renoncer aux outils qu’elles utilisent déjà ?

Non. La protection des données peut conserver sa plateforme dédiée, la sécurité son outil de gestion des risques fournisseurs et l’ingénierie son registre de modèles. Le dossier du système d’IA peut renvoyer vers ces outils et contient le résultat de chaque revue, si bien que les outils cessent de se disputer le rôle d’inventaire.

Qui doit avoir la charge du dossier commun du système d’IA ?

En général, l’équipe IA responsable ou le responsable de l’IA, conjointement avec la protection des données, car ensemble, ils couvrent le cas d’usage et les données. L’essentiel est d’avoir un seul dossier, avec des responsables nommément désignés pour la politique d’IA et pour la conduite du processus. Si le responsable de l’IA est aussi chargé de l’adoption, confiez la revue à une personne dédiée. Les programmes s’enlisent souvent pendant qu’un comité de pilotage débat de la répartition des responsabilités, et c’est généralement la désignation de ces deux responsables qui les relance.

Comment amener les équipes produit à passer par la porte d’entrée ?

Faites-en la voie la plus rapide vers une décision. Un formulaire au lieu de trois, des niveaux clairs et des revues en parallèle donnent aux équipes une raison de l’utiliser. Conditionner les achats et l’accès aux plateformes à un dossier approuvé règle l’essentiel du reste.

La place d’Enzai

Enzai est conçu pour être ce dossier commun. Une porte d’entrée pour les demandes attribue à chaque système d’IA un dossier unique, le classe par niveau de risque et l’oriente vers la revue de chaque équipe, avec des relais vers Jira et ServiceNow. L’inventaire IA est constitué de ces dossiers. Chaque équipe garde ainsi ses décisions tout en travaillant à partir des mêmes faits. Si vous consolidez la gouvernance de l’IA entre vos équipes, échangez avec l’équipe Enzai.