Conformité à la Loi 25 : comment documenter correctement les systèmes d'IA

Bien faire la conformité à la Loi 25 pour un système d'IA, ça veut dire produire des documents qu'un régulateur peut réellement suivre : une évaluation des facteurs relatifs à la vie privée, une carte des données, des dossiers de consentement, et une piste montrant comment les décisions automatisées ont été prises. La loi québécoise sur la protection des renseignements personnels dans le secteur privé n'a pas de « chapitre IA » bien ficelé — ses exigences sont éparpillées dans des dispositions générales qui frappent le plus fort quand c'est une machine qui décide. C'est ce que la plupart des listes de vérification de conformité ratent, et c'est pour ça que les références précises comptent plus qu'on pourrait le croire.

Ce texte passe en revue ce qu'il faut documenter, en s'appuyant sur les articles qui s'appliquent réellement, pas ceux qui semblent plausibles. Pour un portrait plus large de la façon dont les plateformes de gouvernance de l'IA gèrent ça en pratique, voir notre article sur les plateformes de gouvernance de l'IA et la conformité à la Loi 25 du Québec.

Les évaluations des facteurs relatifs à la vie privée en premier

L'article 3.3 de la Loi sur la protection des renseignements personnels dans le secteur privé est la disposition opérante ici. Elle exige une évaluation des facteurs relatifs à la vie privée avant tout projet d'acquisition, de développement ou de refonte importante d'un système d'information ou de prestation électronique de services impliquant des renseignements personnels. La plupart des déploiements d'IA sont visés. Point final.

L'évaluation doit couvrir l'objectif de l'IA, ses sources de données, la logique de traitement et les mesures de protection contre les résultats discriminatoires. Documentez ce que le modèle fait avec les renseignements sensibles, et soyez précis à ce sujet — des descriptions vagues du « traitement par IA » ne résisteront pas à un examen si la Commission d'accès à l'information du Québec (CAI) demande un jour à voir le dossier.

Une évaluation des facteurs relatifs à la vie privée en vertu de l'article 3.3 doit précéder le déploiement, pas le suivre. Faire une ÉFVP rétroactivement après le lancement va à l'encontre du but recherché et signale au régulateur que la protection de la vie privée n'a pas été intégrée dès le départ.

La soumission à la CAI n'est pas automatiquement obligatoire pour chaque ÉFVP — ce serait exagérer l'exigence réelle. L'obligation consiste à effectuer l'évaluation et à être prêt à la produire sur demande, ce qui est une barre sensiblement différente. Pour les systèmes qui touchent des droits légaux ou produisent des conséquences similairement importantes, documentez aussi vos procédures de supervision humaine, puisque l'article 12.1 donne aux individus le droit de demander une intervention humaine dans les décisions automatisées.

Notre article connexe sur la documentation des ÉFVP comme exercice de collaboration explique comment en faire un processus interéquipes plutôt qu'un exercice de dernière minute pour l'équipe de conformité.

Cartographie des données et flux d'information

Il n'existe pas de section dédiée à la « cartographie des données » dans la Loi — ça vaut la peine de le dire clairement, parce que bien des guides de conformité en inventent une. Ce qui existe plutôt, c'est un ensemble d'obligations qui, prises ensemble, exigent que vous sachiez d'où viennent les renseignements personnels, où ils vont, et pourquoi.

Documentez les sources d'information, les finalités déclarées en vertu de l'article 13, les lieux de stockage, et toute entente de partage avec des tiers. Pour les systèmes d'IA en particulier, ça comprend les données d'entraînement, les entrées en temps réel et les extrants qui pourraient contenir des renseignements personnels par inadvertance. Les systèmes d'apprentissage automatique sont doués pour trouver des renseignements personnels là où on ne s'y attendait pas.

Les transferts transfrontaliers sont régis par l'article 17, qui exige une évaluation de protection comparable avant que des renseignements personnels ne quittent le Québec. C'est une seule disposition, pas une plage d'articles — assurez-vous d'avoir la bonne référence, car c'est celle qui est le plus souvent mal citée. Les organisations qui utilisent des plateformes d'IA hébergées au Canada évitent en grande partie cette analyse. La résidence des données au Canada d'Augure, par exemple, contourne l'évaluation de l'article 17 pour la plupart des flux de travail, puisque les données ne traversent jamais la frontière.

Documentez les pratiques de minimisation des données propres à l'implantation de l'IA. Montrez comment la collecte se limite à ce que la finalité déclarée exige, et comment vous évitez la dérive fonctionnelle à mesure que les capacités du système s'élargissent — parce qu'elles s'élargissent toujours.

Consentement et fondement légal

Les dispositions relatives au consentement dans la Loi 25 sont réparties dans plusieurs articles plutôt que concentrées dans un seul, alors soyez prudents avec les références ici. Quand le consentement constitue le fondement légal du traitement par l'IA, documentez l'information donnée aux individus : la nature automatisée de la décision, la logique utilisée et les conséquences qui en découlent. Un avis de confidentialité générique qui mentionne le « traitement automatisé » en passant ne satisfait pas au seuil de transparence.

Pour les mineurs, le seuil pertinent et les mécanismes de consentement se trouvent à l'article 4.1, qui établit des règles concernant les renseignements relatifs aux mineurs de moins de 14 ans — et non la disposition habituellement citée à cette fin. Assurez-vous d'avoir la bonne référence; c'est une erreur courante et facile à repérer à la révision.

Conservez un registre des mécanismes de retrait, et documentez comment une révocation de consentement affecte le fonctionnement du système d'IA à l'avenir. Les individus conservent le droit de retirer leur consentement même si cela limite les fonctionnalités, et votre documentation devrait démontrer que vous avez prévu ce cas de figure plutôt que de le traiter comme une exception.

Pistes de vérification et journalisation des décisions

L'article 12.1 traite spécifiquement de la prise de décision automatisée — c'est la disposition qui porte réellement sur le profilage et les décisions rendues exclusivement par des moyens automatisés, et elle est fréquemment mal attribuée ailleurs. Assurez-vous d'avoir le bon numéro; ça change la façon dont vous construisez la piste de vérification.

Les journaux de vérification devraient capturer les données d'entrée, les paramètres de traitement, et une justification de la décision rédigée dans un langage qu'une personne peut comprendre. Des journaux techniques à eux seuls ne satisfont pas à l'obligation de transparence. Un score de confiance de type boîte noire non plus.

Documentez vos procédures de supervision humaine pour les décisions contestées. Quand quelqu'un exerce son droit de demander une intervention humaine, vos dossiers doivent démontrer qu'une personne qualifiée a réellement examiné le cas — pas qu'un deuxième algorithme a simplement approuvé le résultat du premier.

Les mesures de sécurité pour cette documentation relèvent de l'article 3.5 de la loi sur le secteur privé — un article 3.5 différent de celui régissant les ÉFVP dans certains résumés, ce qui est exactement le genre de confusion interne qu'il vaut la peine de vérifier deux fois avant publication. Conservez les registres de vérification avec des contrôles d'accès appropriés, puisqu'ils contiennent généralement eux-mêmes des renseignements personnels.

Pour les décisions d'IA à enjeux élevés touchant l'emploi, le crédit ou des conséquences similairement importantes, conservez des pistes de décision détaillées : les facteurs pris en compte, les pondérations appliquées, et les résultats alternatifs que le système n'a pas retenus. Si une décision est un jour contestée, c'est ce qu'on vous demandera de produire.

Ententes avec les fournisseurs et les sous-traitants

Les systèmes d'IA impliquent régulièrement des sous-traitants tiers, et ces relations comportent leur propre fardeau documentaire. Les ententes avec les sous-traitants doivent traiter des risques propres à l'IA, pas seulement des clauses génériques de traitement de données reprises d'un modèle conçu pour des chiffriers.

Documentez les instructions de traitement données à tout fournisseur, couvrant l'entraînement des modèles, l'inférence et le traitement des extrants. Une entente de services infonuagiques standard n'aborde habituellement pas ça de façon adéquate — lisez les petits caractères, ou mieux encore, ne présumez pas qu'ils en tiennent compte.

Pour les plateformes qui maintiennent la résidence des données au Canada, documentez ce fait explicitement dans le cadre de votre diligence raisonnable envers les fournisseurs. L'infrastructure d'Augure conserve les données au Canada, ce qui élimine une couche d'évaluation transfrontalière qui serait autrement exigée en vertu de l'article 17. C'est une simplification importante pour les équipes de conformité qui traitent le risque lié aux fournisseurs.

Incluez des exigences de sécurité adaptées spécifiquement aux charges de travail d'IA : protection des modèles, sécurité des données d'entraînement, confidentialité des extrants. Suivez aussi les relations avec les sous-traitants ultérieurs, puisque de nombreux services d'IA enchaînent plusieurs fournisseurs pour différentes étapes du traitement, et chaque maillon de cette chaîne a besoin de sa propre entente adéquate. Notre article sur les outils qui répondent à la norme de la Loi 25 du Québec explique comment évaluer les fournisseurs sur cette base.

Procédures de réponse aux droits des personnes concernées

Les individus ont le droit d'accéder à leurs renseignements, de demander une correction, et — quand une prise de décision automatisée est en cause — de demander des renseignements significatifs sur la logique utilisée et un accès à une révision humaine. Documentez la procédure opérationnelle pour chacun, pas seulement l'énoncé de politique qui affirme que le droit existe.

Une politique écrite promettant une « révision humaine sur demande » ne veut rien dire s'il n'y a pas de véritable file d'attente, pas de réviseur désigné, et pas de trace de ce qui s'est passé quand quelqu'un l'a demandée.

Les modèles aident ici. Construisez-en un pour les demandes d'accès, un pour les demandes de correction, et un spécifiquement pour les explications de décisions automatisées, puisque l'information requise diffère sensiblement entre chacune. La coordination entre l'équipe juridique et l'équipe technique compte le plus quand quelqu'un conteste avec succès un résultat automatisé et que le système doit réellement changer son comportement pour cette personne.

Pour un aperçu de la façon dont les délais de notification en cas d'incident interagissent avec ces mêmes procédures de droits, voir les exigences de notification d'incident lié à l'IA au Canada.

Surveillance continue

La documentation n'est pas un livrable unique. Les systèmes d'IA changent — les modèles sont réentraînés, les fonctionnalités s'élargissent, de nouvelles sources de données s'ajoutent — et chaque changement significatif peut justifier une ÉFVP mise à jour et un avis révisé aux personnes concernées.

Conservez des registres de la formation du personnel sur les obligations de confidentialité propres à l'IA. La responsabilisation en vertu de la Loi n'est pas satisfaite par un dossier de documents; elle exige un programme démontrable, avec des gens qui savent ce que les documents disent et pourquoi ils existent.

Prévoyez des révisions périodiques de la documentation liée à l'IA, particulièrement pour les systèmes qui évoluent avec le temps. Une évaluation des facteurs relatifs à la vie privée rédigée pour le système tel qu'il existait il y a un an pourrait ne plus décrire ce que le système fait réellement aujourd'hui.

Lecture complémentaire sur le volet opérationnel de tout ça : les exigences du CPCSC pour les outils d'IA couvre un cadre complémentaire qui vaut la peine de comprendre en parallèle de la Loi 25.

Pour les organisations qui construisent des flux de travail IA avec Augure, la résidence des données au Canada de la plateforme et ses journaux de traitement intégrés appuient directement plusieurs de ces exigences de documentation, réduisant le travail manuel de suivi séparé des transferts transfrontaliers et des journaux d'accès.

Une documentation adéquate transforme la conformité à la Loi 25 d'une course réactive en un système que n'importe qui sur l'équipe peut maintenir. Commencez par l'ÉFVP. Faites bien la carte des données. Tout le reste découle de ces deux éléments. Mais si vos références sont fausses, rien de tout ça ne tient la route — vérifiez-les auprès des directives officielles de la Commission d'accès à l'information du Québec et du texte actuel de la Loi plutôt qu'auprès d'un résumé de résumé.

Prêt à voir comment ça fonctionne en pratique? Augure intègre directement la documentation de conformité à la Loi 25 dans des flux de travail IA hébergés au Canada.