L'épisode 1 vous a donné un registre : la liste des usages IA réels de votre organisation, avec un propriétaire par usage et un triage en trois statuts. Vous voyez maintenant ce qui se passe.
Vient la question qui décide de tout le reste : qui répond de ces usages devant la direction ?
Elle a l'air bureaucratique. Elle ne l'est pas. Tant qu'elle n'a pas de réponse nominative, chaque décision IA est prise par la personne qui se trouve devant l'écran, avec les informations qu'elle a, sans que personne d'autre le sache. C'est exactement ainsi qu'un outil de tri de CV entre en production sans évaluation, et qu'un incident finit par arriver au comité de direction sans qu'aucun cadre n'ait jamais eu l'occasion de dire non.
Le piège du comité de gouvernance de l'IA
Le réflexe habituel est de créer un comité. Douze personnes, une réunion mensuelle, un mandat de trois pages. Six mois plus tard, le comité se réunit encore, les usages IA se déploient toujours sans lui, et personne ne sait dire qui a approuvé quoi.
Ce n'est pas un problème de sérieux, c'est un problème de conception. Un comité arbitre des cas difficiles ; il ne peut pas être le point de passage de chaque usage. Si tout doit passer par lui, il devient un goulot d'étranglement que les équipes contournent, et vous retombez dans le shadow AI que vous veniez d'inventorier.
La gouvernance qui tient repose sur l'inverse : la majorité des décisions se prennent sans réunion, parce que les règles sont écrites et les rôles clairs. Le comité ne voit que ce qui sort du cadre.
Les quatre rôles, et ce qu'ils décident vraiment
Quatre rôles suffisent. Ce sont des responsabilités, pas des postes à créer : dans une organisation de 200 personnes, elles se répartissent souvent sur trois personnes existantes.
Le propriétaire d'usage. Le gestionnaire dont l'équipe utilise l'outil. Il répond des résultats produits par cet usage comme il répond de ceux produits par son équipe. C'est lui qui inscrit l'usage au registre, qui signale un changement de fournisseur ou de finalité, et qui doit pouvoir expliquer une décision assistée par l'IA. Le point à graver : la responsabilité ne se délègue pas au modèle. Si un outil trie mal des candidatures, ce n'est pas le fournisseur qui répondra devant votre conseil.
Le responsable de la protection des renseignements personnels. Sous la Loi 25, il existe déjà chez vous, par défaut la personne ayant la plus haute autorité, souvent délégué par écrit. Pour l'IA, son rôle est précis : décider quelles catégories de données peuvent entrer dans quel type d'outil, et déclencher une évaluation des facteurs relatifs à la vie privée quand un usage traite des renseignements personnels ou communique des données hors du Québec. Ce n'est pas un veto de principe sur l'IA, c'est une frontière de données.
La sécurité. Elle évalue le fournisseur et la manière dont l'outil est branché : authentification, permissions accordées par OAuth, journalisation, hébergement, conditions d'entraînement sur vos données. Sa question n'est pas « l'IA est-elle dangereuse ? », c'est « cette intégration précise crée-t-elle un chemin d'accès que nous ne surveillons pas ? ».
Le sommet exécutif. Une personne, nommée, qui répond de l'ensemble devant le conseil et qui arbitre les cas où les trois rôles précédents ne s'entendent pas. Dans la plupart des organisations, c'est le directeur général ou le directeur financier, rarement le responsable des TI, parce que les arbitrages sont d'abord des décisions d'affaires.
Un test simple pour savoir si vos rôles sont réels : prenez les trois usages les plus sensibles de votre registre, et écrivez à côté de chacun le nom des quatre personnes. Si vous hésitez sur une case, la gouvernance n'existe pas encore pour cet usage.
La politique d'usage en une page
Une politique IA de quarante pages ne sera pas lue. Une page le sera, à condition qu'elle réponde à ce que les gens se demandent réellement à leur poste de travail. Six sections suffisent.
- Ce qui est approuvé. La liste nommée des outils autorisés, avec pour chacun ce qu'on a le droit d'y mettre. Une liste vide ou floue pousse les équipes vers leurs outils personnels ; dire clairement « oui, celui-ci, pour ça » est ce qui crédibilise les interdictions.
- Ce qui ne sort jamais. Les catégories de données interdites dans tout outil non approuvé : renseignements personnels de clients, d'employés ou de candidats, données financières non publiées, code source et secrets, information couverte par un contrat client ou par le secret professionnel.
- Les décisions qui exigent un humain. Embauche, congédiement, crédit, tarification, décision clinique, décision juridique. Formulation utile : l'IA peut préparer, un humain identifié décide et signe.
- La vérification avant réutilisation. Toute production destinée à un client, à un régulateur ou au public est relue par une personne compétente sur le fond. La règle vaut pour le texte comme pour le code.
- Comment faire approuver un nouvel outil. Un formulaire de cinq questions et un délai de réponse annoncé, par exemple cinq jours ouvrables. Sans délai crédible, la politique se contourne.
- Quoi faire en cas d'erreur. Un canal de signalement sans blâme, et l'engagement explicite que déclarer une erreur d'usage n'entraîne pas de sanction. C'est la suite logique de l'amnistie de l'inventaire.
Datez la politique, nommez la personne à contacter, et prévoyez une révision trimestrielle. Le rythme d'évolution des outils rend toute politique statique fausse en six mois.
Les quatre décisions à trancher avant d'écrire
Écrire la politique est facile une fois que ces quatre questions ont une réponse. La plupart des organisations bloquent parce qu'elles rédigent avant de décider.
1. Version gratuite ou version entreprise ? Les conditions diffèrent sur un point qui change tout : l'utilisation de vos saisies pour l'entraînement des modèles. C'est un arbitrage coût contre exposition, et il se tranche à la direction, pas dans une réunion technique.
2. Où vont les données ? Hébergement, juridiction, sous-traitants du fournisseur. Sous la Loi 25, une communication de renseignements personnels hors du Québec exige une évaluation préalable. C'est souvent ce point, et non la nature de l'IA, qui disqualifie un outil.
3. Qu'est-ce qu'on journalise ? Sans journal des invites et des réponses pour les usages sensibles, vous ne pourrez ni enquêter sur un incident ni démontrer qu'une décision a été prise correctement. Avec journal, vous créez une nouvelle base de données à protéger et à conserver selon un calendrier. Ce choix se fait usage par usage.
4. Que fait-on des agents ? Un assistant qui suggère et un agent qui exécute des actions ne posent pas le même problème. Décidez maintenant si les actions autonomes exigent une approbation préalable, et lesquelles. C'est le sujet de l'épisode 7, mais la règle doit exister avant que le premier agent soit branché.
Le lien avec vos autres obligations
Rien de ceci n'est un régime parallèle. La gouvernance de l'IA se raccroche à ce que vous avez déjà : le registre des incidents et le responsable de la protection des renseignements personnels au titre de la Loi 25, l'évaluation des fournisseurs au titre de votre programme de risque tiers, la gestion des accès et la journalisation au titre de vos contrôles de sécurité.
Si vous visez ISO 42001 ou NIST AI RMF plus tard, ce socle est exactement ce qu'ils demandent en premier : des rôles nommés, une politique appliquée, des décisions tracées. On y reviendra à l'épisode 6.
Ce que vous devriez avoir vendredi
Quatre rôles attribués nominativement pour vos usages sensibles, une politique d'une page datée et diffusée, quatre décisions tranchées et écrites, et un point à l'ordre du jour du prochain comité de direction. Ce n'est pas un projet de six mois. C'est une semaine de travail, une fois l'inventaire fait.
Épisode 3, jeudi prochain : les risques propres aux grands modèles de langage. Injection de prompt, fuite de données par le contexte, hallucinations en production, et pourquoi vos contrôles applicatifs habituels ne les voient pas.
D'ici là, notre score de risque cyber gratuit comprend un domaine « données et IA » qui teste précisément ces questions de gouvernance, et le module Risk Engine transforme un registre et une politique en suivi de risque continu.