Aller au contenu principal
EN

RÉGLEMENTAIRE

Loi 25 et systèmes d'IA : la liste de contrôle de conformité de 12 points

La Loi 25 du Québec impose désormais des obligations précises aux organisations qui traitent des renseignements personnels, y compris lorsqu'un système d'intelligence artificielle prend, soutient ou influence une décision touchant une personne.

Équipe Agentica RiskPratique de gestion des risques IA
8 min de lecture

Pour les conseils d’administration et les équipes de conformité, la question n’est plus de savoir si l’IA est encadrée, mais de prouver que chaque déploiement respecte un cadre documenté. La Loi 25 du Québec (la Loi modernisant des dispositions législatives en matière de protection des renseignements personnels) est la référence pour toute organisation qui traite des renseignements personnels de résidents québécois, et le projet de loi fédéral C-27 / LIAD la suit de près pour les systèmes d’IA à incidence élevée. Cette note synthétise les douze points qui reviennent le plus souvent dans nos engagements clients.

Nommer une personne responsable

La Loi 25 exige qu’une personne responsable de la protection des renseignements personnels soit désignée et rendue publique. Pour les organisations qui déploient de l’IA, cette personne doit comprendre à la fois les exigences légales et les implications techniques d’une décision automatisée. Dans la pratique, nous voyons rarement un seul individu cocher les deux cases — un binôme juridique et technique est souvent plus réaliste.

Tenir un registre des systèmes d’IA

Avant d’écrire la moindre politique, il faut savoir ce qui tourne déjà en production. Le registre doit lister chaque système d’IA, son propriétaire interne, les données qu’il consomme, les décisions qu’il influence, et le fournisseur du modèle sous-jacent. Une cartographie réelle est la fondation sur laquelle reposent les onze autres points.

Évaluer les facteurs relatifs à la vie privée

Pour chaque cas d’usage à incidence élevée, une évaluation des facteurs relatifs à la vie privée (ÉFVP) est obligatoire. La Commission d’accès à l’information s’attend à voir une analyse documentée, pas une déclaration générale. Les ÉFVP doivent être revues à chaque changement matériel du système — un nouveau modèle, une nouvelle source de données, une nouvelle finalité.

Encadrer les fournisseurs tiers

Les modèles fondamentaux proviennent de fournisseurs hors Québec dans la majorité des cas. Les contrats doivent préciser les obligations du fournisseur en matière de traitement des renseignements personnels, de notification d’incident, et de conservation des données. Les clauses standards des fournisseurs sont rarement suffisantes — un addendum négocié est presque toujours nécessaire.

Définir une politique de conservation et destruction

Combien de temps conservez-vous les données d’entraînement ? Les journaux d’inférence ? Les versions de modèles historiques ? La Loi 25 exige une politique explicite et documentée. En l’absence de politique, l’organisation conserve par défaut, ce qui élargit son exposition à chaque incident.

La gouvernance interne couvre la moitié du travail. La transparence et le contrôle couvrent l’autre moitié — et c’est là que la plupart des organisations échouent.

Informer les personnes concernées

Lorsqu’une décision importante est prise ou appuyée par un système automatisé, la personne concernée a le droit d’en être informée. Cette information doit être claire, pas enfouie dans une politique de confidentialité de quarante pages. La rédaction de ces avis est un exercice de précision : trop vague et vous ne respectez pas la loi, trop technique et personne ne comprend.

Permettre l’intervention humaine

La personne concernée peut demander que la décision soit revue par un humain. Cette demande doit être traitable opérationnellement — pas simplement acceptée en théorie. Cela implique un mécanisme de réception, un délai de traitement, et un chemin de révision documenté.

Établir un mécanisme de plainte

Les plaintes internes doivent pouvoir être reçues, documentées et traitées. Le mécanisme doit être distinct du service client général, car les plaintes relatives à la vie privée ont un statut réglementaire particulier. Les régulateurs consultent ce registre lors d’une inspection.

Planifier la réponse aux incidents

Le délai de notification en cas d’incident impliquant un risque sérieux de préjudice est court — il exige une chaîne de responsabilité préétablie, un gabarit de notification et une procédure d’escalade testée au moins une fois par an. Improviser pendant une crise est le moyen le plus rapide de multiplier l’exposition.

Journaliser pour reconstituer les décisions

La journalisation doit être suffisante pour reconstituer une décision spécifique après coup. Cela inclut les entrées du modèle, la version exacte utilisée, les paramètres appliqués, et la sortie. Sans cette traçabilité, aucune contestation n’est possible — ce qui place l’organisation en position défensive face à toute plainte.

Réviser les modèles périodiquement

Les modèles dérivent. Les données changent. Les cas d’usage évoluent. Une révision périodique — au minimum annuelle, idéalement trimestrielle pour les systèmes à incidence élevée — est indispensable. Cette révision doit produire un compte rendu écrit, archivé dans le registre.

Présenter au conseil d’administration

Le douzième point est souvent négligé : les risques IA doivent apparaître dans les rapports présentés au conseil, avec des indicateurs compréhensibles pour des dirigeants non techniques. Sans cette remontée, les onze autres points deviennent de la paperasse déconnectée de la stratégie.

Ce qui distingue les organisations qui réussissent

Les organisations qui réussissent ces évaluations partagent un point commun : elles ont arrêté de traiter la conformité IA comme un projet ponctuel et ont commencé à la traiter comme un programme continu, avec un propriétaire désigné, un calendrier de revue et des indicateurs présentés au conseil. L’audit n’est plus un événement — c’est un état que l’on maintient.

Notre recommandation pratique : commencez par cartographier les systèmes d’IA déjà en production avant d’écrire de nouvelles politiques. Une politique abstraite ne survit pas à un audit. Une cartographie réelle, doublée d’un registre de risques, permet de prioriser les correctifs là où l’exposition est la plus matérielle.

Chacun des douze points mérite une analyse détaillée propre à votre contexte sectoriel et à la maturité de vos systèmes. La note ci-dessus reste générale et n’a pas pour vocation de remplacer une évaluation sur mesure.