La gouvernance de l'IA est un modèle opérationnel, pas une politique.

La plupart des organisations commencent par une politique IA. Elle est nécessaire, mais répond rarement aux questions opérationnelles : l'initiative doit-elle avancer, qui peut l'approuver, quelles preuves suffisent et que faire si le système se comporte autrement en production?

Le meilleur cadre est un modèle opérationnel de gouvernance de l'IA : un système répétable de décisions, de preuves, de contrôles et de rétroaction qui relie les principes à la livraison.

Pourquoi maintenant

Pour les institutions fédérales visées par la Directive sur la prise de décisions automatisée, les systèmes développés ou acquis avant le 24 juin 2025 avaient jusqu'au 24 juin 2026 pour respecter les exigences nouvelles ou mises à jour. La directive couvre les systèmes en production qui prennent ou appuient une décision administrative concernant un client.

Au Québec, l'indication d'application IA-RI-2025-003-OP est entrée en vigueur le 5 décembre 2025. Elle vise les organismes publics assujettis à l'article 2 de la Loi sur la gouvernance et la gestion des ressources informationnelles des organismes publics et des entreprises du gouvernement, permettait d'échelonner la mise en œuvre jusqu'au 5 juin 2026 et abrogeait IA-RI-2025-001-OP.

Pourquoi la distinction compte

Ces échéances créent l'urgence; les référentiels donnent forme au modèle. Le NIST AI Risk Management Framework traite Govern comme une fonction transversale du cycle de vie. La norme ISO/IEC 42001 définit un système de management fondé sur des politiques, des objectifs, des processus et l'amélioration continue, et non sur un document ponctuel.

Sept décisions opérationnelles

1. Définir ce qui entre dans le système

La limite d'inventaire doit suivre le cas d'usage, pas l'équipe qui l'a construit. L'erreur courante consiste à confondre inventaire IA et registre de modèles de science des données. Celui-ci capte les modèles sur mesure, mais oublie les fonctions achetées, les copilotes intégrés, les modèles appelés par API, les automatisations utilisant leurs sorties et les outils parallèles du personnel.

L'unité à gouverner est l'usage en contexte, pas la plateforme. Un même copilote peut reformuler une note interne dans un processus et influencer une décision concernant une personne dans un autre. Une seule entrée de plateforme empêche alors d'attribuer à chaque usage le bon propriétaire, le bon seuil de preuve, le bon suivi et le bon parcours d'approbation.

2. Attribuer les droits de décision

Donnez à chaque initiative un propriétaire d'affaires responsable du résultat et un propriétaire technique responsable du système. Précisez ensuite qui peut accepter le risque résiduel, approuver l'utilisation en production, accorder une exception et arrêter le système. Les comités peuvent conseiller; des rôles nommés doivent décider.

3. Créer une voie unique de prise en charge et de classement du risque

Utilisez un court formulaire qui porte sur la décision soutenue, les personnes touchées, la sensibilité des données, l'autonomie, la réversibilité et le contexte réglementaire. Les réponses doivent placer l'initiative dans un niveau de risque qui modifie la profondeur de l'examen. Un assistant de rédaction et une recommandation automatisée d'admissibilité ne devraient pas franchir la même porte.

4. Établir des seuils de preuve avant la mise en production

Pour chaque niveau, définissez les preuves minimales : usage prévu, filiation des données, examens de confidentialité et de sécurité, résultats d'évaluation, supervision humaine, modes de défaillance, preuves du fournisseur et plan de suivi. Le seuil doit produire une décision consignée : approuver, approuver sous conditions, retourner pour travaux ou arrêter.

5. Gouverner ensemble fournisseurs, données et architecture

L'approvisionnement ne peut être une voie séparée. Les clauses contractuelles, la résidence des données, les changements de modèle, les droits d'audit, la conservation, les sous-traitants et le plan de sortie influencent l'architecture et la décision de risque. Un examen commun permet de confronter les affirmations du fournisseur au contexte opérationnel réel.

6. Continuer après le lancement

L'approbation n'est pas la ligne d'arrivée. Définissez des indicateurs de rendement, de préjudices, de dérive, de contournement, d'incidents et de plaintes. Fixez les seuils qui déclenchent une enquête, un retour arrière ou une nouvelle approbation. Un changement important de modèle, de données, de finalité ou d'utilisateurs doit ramener le système en examen.

7. Inscrire la gouvernance dans la cadence de livraison

Le modèle opérationnel doit s'intégrer à la prise en charge du portefeuille, à la revue d'architecture, à l'assurance de sécurité, à la gestion du changement et à la livraison produit. Réutilisez les forums existants lorsqu'ils peuvent prendre la décision; n'ajoutez un comité que lorsqu'une décision réelle n'a aucun propriétaire. Une gouvernance extérieure à la livraison devient de la paperasse, puis la livraison apprend à la contourner.

Un départ pratique sur 90 jours

1. Jours 0 à 30 : établir la visibilité et la responsabilité. Définissez la portée de l'inventaire, repérez les usages actifs et planifiés, nommez les propriétaires responsables et consignez qui peut approuver, imposer des conditions, arrêter ou accepter le risque.
2. Jours 31 à 60 : concevoir le parcours. Créez la prise en charge, les niveaux de risque, les preuves minimales et le registre de décision. Reliez l'approvisionnement, la confidentialité, la sécurité, l'architecture et le juridique autour d'un même flux.
3. Jours 61 à 90 : mettre à l'essai sur du vrai travail. Faites passer trois initiatives différentes dans le modèle. Observez les délais, les revues en double et les preuves manquantes. Ajustez la conception, publiez un petit tableau de bord et lancez le premier cycle d'amélioration.

N'attendez pas un inventaire d'entreprise parfait ni une taxonomie universelle du risque. Commencez avec assez de structure pour prendre trois vraies décisions de façon cohérente, puis améliorez le modèle à partir des preuves.

Les prochaines questions de la direction

• Pouvons-nous nommer chaque système d'IA qui influence une décision importante ou traite des données sensibles?
• Le propriétaire responsable peut-il expliquer pourquoi la production a été approuvée et montrer les preuves?
• Remarquerions-nous un changement de comportement, de modèle fournisseur ou de données?
• Qui possède l'autorité, et la capacité opérationnelle, de l'arrêter?

Ces questions en disent davantage sur la maturité de la gouvernance que l'existence d'une politique.

Si l'une de ces quatre questions demeure sans réponse claire, le Préparation à la gouvernance et à la conformité IA vise à combler cet écart.

Sources et portée

Références : NIST AI RMF Core; ISO/IEC 42001; Directive sur la prise de décisions automatisée (art. 1.2.1, 5.1 et 8.1); IA-RI-2025-003-OP (art. 2, 23 et 25). Information générale, non avis juridique; application selon le secteur, la juridiction et le cas d'usage.