La gouvernance de l’IA commence par une liste qui dit vrai
Le mot gouvernance revient dans ces archives parce que les plateformes changent plus vite que le besoin de savoir qui décide. Pour l’IA, je commencerais par un registre qui décrit les systèmes réellement actifs, pas seulement ceux présentés au comité.
Le registre peut vivre dans une table simple :
usage_id, propriétaire, tâche, état, niveau_risque,
données, fournisseur, modèle, outils, personnes_touchées,
date_début, dernière_révision, date_expiration, plan_retrait
Chaque intégration, assistant intégré, achat sur carte et prototype recevant encore des données obtient un identifiant. Le Playbook du cadre NIST recommande l’inventaire et la fin de vie; le second point évite qu’un essai approuvé une fois devienne permanent par oubli.
Trouver ce que l’inventaire ne connaît pas
Une liste déclarative ne suffit pas. Je croiserais plusieurs sources :
- factures SaaS, cartes de crédit et renouvellements;
- applications autorisées dans l’annuaire et consentements OAuth;
- secrets et destinations d’API dans les environnements;
- journaux du proxy ou de la passerelle d’IA;
- extensions de navigateur et fonctions activées dans les suites;
- dépôts contenant SDK, modèles ou clés;
- sondage court auprès des équipes et propriétaires de processus.
Le rapprochement produit une file d’éléments inconnus. On ne bloque pas tout automatiquement; on identifie la personne, le but et les données, puis on choisit Fermer, Expérience, Production ou Exception temporaire. Un usage sans propriétaire reçoit une date courte et perd l’accès s’il n’est pas réclamé.
Le niveau de contrôle suit l’impact. Reformuler un texte public peut utiliser un environnement limité et une révision légère. Influencer un prix, une embauche, une paie ou l’accès à un service demande évaluation, explication, intervention humaine, sécurité et surveillance plus fortes. Un même formulaire de huit pages pousserait surtout les petits tests à se cacher.
Le chemin d’expérimentation tient en quelques contraintes : données synthétiques ou non sensibles, compte dédié, aucun droit d’écriture, budget borné, 30 jours et responsable nommé. À l’expiration, le système coupe la clé sauf décision explicite. Si l’expérience doit recevoir de vraies données ou agir, elle passe une revue adaptée à ce changement.
Le registre reçoit des événements. Un fournisseur change de conditions, un modèle est remplacé, le volume double ou un propriétaire quitte : l’usage revient en révision. Une tâche périodique signale les entrées sans contact, preuves ou date. Le tableau de bord mesure surtout inventaire orphelin, exceptions expirées, données sensibles et reprises non testées.
Le retrait est une procédure technique : arrêter les appels, vider les files, révoquer clés et consentements, retirer comptes, exporter traces requises, supprimer index et copies, informer les utilisateurs, puis vérifier l’absence de trafic. Le bouton Annuler l’abonnement ne retire pas toujours une application OAuth ni les données dérivées.
En cas d’incident, le registre doit répondre en minutes : propriétaire, données, fournisseur, versions, personnes touchées et moyen de couper. Si l’équipe reconstruit ces faits à partir des factures pendant la panne, la gouvernance était une présentation.
Je préfère six champs honnêtes, une découverte technique et une date d’expiration à un comité énorme. La gouvernance devient crédible lorsqu’elle rend le chemin sûr plus court, trouve les usages cachés et sait fermer aussi proprement qu’elle approuve.