Une grande partie du travail de gouvernance de l'IA ressemble à du travail de politique — principes, fiches de modèle, comités d'éthique. Tout cela est utile, mais rien n'est opérationnel. La question opérationnelle est plus précise et plus familière : à quoi ce système a-t-il le droit de toucher, sous quelles conditions, et qui est responsable lorsqu'il touche à quelque chose qu'il n'aurait pas dû?
C'est exactement la question à laquelle la gestion des identités et des accès répond pour les comptes et les services depuis deux décennies. Un agent d'IA capable d'appeler des outils, d'écrire des fichiers ou d'exécuter du code est, structurellement, un principal privilégié — et il mérite la même rigueur : des permissions circonscrites plutôt qu'un accès global, une élévation limitée dans le temps plutôt qu'une capacité permanente, et un journal qui survit à l'examen de l'incident.
Ce qui le distingue d'un compte de service normal, c'est l'imprévisibilité de l'intention. Un robot de déploiement fait une seule chose. Un modèle qui décide de sa prochaine action ressemble davantage à un employé junior ayant un large accès aux outils et sans gestionnaire surveillant chaque geste — ce qui plaide pour les mêmes contrôles qu'on placerait autour de cet employé : une portée par défaut plus étroite, un point de contrôle humain avant tout geste irréversible, et une piste d'audit qui consigne non seulement ce qui s'est passé, mais pourquoi le système croyait en avoir le droit.
Traitez la gouvernance de l'IA comme un problème de GIA avec un principal inhabituellement affirmé, et la majeure partie de l'outillage et des processus existe déjà. Vous n'inventez pas une nouvelle discipline — vous pointez une discipline existante vers un nouveau type de compte.