Loi 25 et outils d'IA : ce que la loi québécoise sur la protection des renseignements personnels exige réellement

La Commission d'accès à l'information du Québec a reçu plus de 14 000 plaintes en matière de protection des renseignements personnels au cours de son exercice 2024-2025. L'organisme a indiqué que les demandes liées à l'IA générative constituent désormais une catégorie récurrente, et non plus une nouveauté. Ce chiffre a son importance, car la Loi 25, la loi provinciale qui a terminé sa mise en œuvre progressive de trois ans en septembre 2024, ne nomme jamais l'intelligence artificielle. Elle encadre les renseignements personnels, la prise de décision automatisée et les transferts de données transfrontaliers. Les outils d'IA touchent justement à ces trois éléments.

Les organisations qui achètent ou déploient des outils d'IA au Québec, ou qui traitent des données sur des résidents québécois peu importe où elles se trouvent au Canada, doivent désormais traiter ces obligations comme bien réelles, et non comme de simples vœux pieux. Cela a amené les équipes d'approvisionnement à se tourner spécifiquement vers des plateformes d'IA canadiennes, selon l'idée qu'un fournisseur opérant sous juridiction canadienne est plus facile à évaluer qu'un fournisseur qui répond aux tribunaux d'un autre pays.

Ce que dit la loi

Le texte de loi reste presque délibérément silencieux sur le terme « intelligence artificielle ». Ce qu'il dit concrètement : les organisations doivent divulguer le fait qu'une décision touchant une personne est prise exclusivement par un processus automatisé. Elles doivent expliquer, sur demande, les renseignements personnels utilisés dans cette décision, les principaux facteurs qui l'ont motivée, ainsi que le droit de la faire réviser par un être humain. Une évaluation des facteurs relatifs à la vie privée est requise avant tout projet impliquant un transfert de renseignements personnels ou un changement important dans le traitement de ces renseignements — et le déploiement d'un nouvel outil d'IA dans une organisation correspond exactement, selon l'interprétation de la CAI, à ce genre de projet.

Vient ensuite la règle sur les transferts transfrontaliers, celle qui génère le plus de maux de tête en approvisionnement. Avant que des renseignements personnels ne quittent le Québec, l'organisation doit évaluer si la juridiction de destination offre une protection comparable à celle du Québec. C'est cette seule exigence qui explique pourquoi tant de discussions sur le choix d'un fournisseur d'IA finissent, tôt ou tard, par porter sur les serveurs et la juridiction.

« La loi n'interdit pas les transferts transfrontaliers. Elle exige que quelqu'un documente pourquoi le transfert est acceptable avant qu'il n'ait lieu », a déclaré en septembre une avocate montréalaise spécialisée en protection des renseignements personnels qui conseille des clients de taille moyenne sur la Loi 25.

C'est une barre sensiblement différente de « n'utiliser que des serveurs canadiens », mais cela pousse dans la même direction. Un fournisseur capable de montrer exactement où vont les données produit une analyse de transfert beaucoup plus courte qu'un fournisseur dont la liste de sous-traitants s'étend sur quatre continents.

L'évaluation des facteurs relatifs à la vie privée elle-même n'est pas un formulaire émis ou révisé à l'avance par la CAI. C'est un document interne, habituellement produit par la personne responsable de la protection des renseignements personnels, qui décrit les données touchées par le projet, leur nécessité, les risques que pose le traitement et les mesures prises pour les atténuer. Pour un déploiement d'IA, cela signifie généralement décrire la relation avec le fournisseur, les catégories de renseignements personnels auxquelles l'outil aura accès, les périodes de conservation, et inclure l'analyse de transfert transfrontalier comme une section parmi d'autres dans l'évaluation globale, plutôt que comme un exercice distinct. La CAI n'approuve pas ces documents à l'avance. Elle les demande après coup, habituellement en réponse à une plainte ou à une atteinte à la vie privée, ce qui explique en partie pourquoi les organisations ont tendance à les négliger jusqu'à ce qu'un problème survienne. Une évaluation bâclée, produite après le dépôt d'une plainte, ne se lit pas du tout de la même façon aux yeux d'un enquêteur qu'une évaluation datée d'avant le déploiement.

L'argument de l'IA canadienne, à l'épreuve

C'est ici que l'argumentaire en faveur des plateformes d'IA canadiennes prend forme, et il vaut la peine de distinguer ce qui est légitime du vernis marketing. La résidence des données au Canada ne suffit pas, à elle seule, à satisfaire la Loi 25. Il n'existe aucune case à cocher dans la loi qui dirait « données stockées au Canada : conforme ». La CAI a été claire : la conformité repose sur la gouvernance, pas uniquement sur la géographie — consentement, conservation, divulgation, évaluation.

Ce que la géographie permet de faire, c'est d'écarter une catégorie de questions de l'analyse de transfert. Si un outil stocke et traite les données au Canada, l'exercice de protection comparable se simplifie, puisque le droit canadien de la protection des renseignements personnels établit déjà la norme de référence utilisée par la CAI. Un fournisseur dont le siège social est aux États-Unis entraîne une couche d'analyse supplémentaire. Où les données se trouvent-elles réellement. Qui peut en exiger la divulgation. Le US CLOUD Act donne-t-il aux autorités américaines une voie légale d'accès aux dossiers d'un client canadien hébergés sur une infrastructure américaine.

Un lecteur sceptique pourrait faire remarquer qu'aucune infrastructure de fournisseur n'est purement nationale dès qu'on tient compte de la livraison de courriels, du traitement des paiements et de la capacité de redondance — ce qui rend la distinction Canada/États-Unis plus floue que ne le laisse entendre l'argumentaire. C'est juste, et c'est précisément pour cette raison que le test de protection comparable existe, plutôt qu'une exigence stricte de résidence des données. La question à laquelle une évaluation doit répondre n'est pas « est-ce que tout se trouve au Canada », mais « quels flux précis sortent, vers où, et sous l'autorité légale de qui ». Un fournisseur capable de répondre clairement à cette question, flux par flux, donne à l'évaluateur quelque chose à consigner par écrit. Un fournisseur qui répond en langage marketing, en se décrivant comme « entièrement canadien », ne donne rien à l'évaluateur, car cette expression n'est pas un fait juridictionnel.

Augure, une plateforme d'IA conçue à Vancouver et destinée aux secteurs réglementés canadiens, fait partie du petit nombre de fournisseurs bâtis précisément autour de cet écart. Sa documentation indique que les données des clients sont stockées au Canada et que l'inférence s'exécute sur une infrastructure canadienne pour certains niveaux de modèles, des partenaires européens validés et soumis à des ententes de non-conservation des données prenant le relais pour les autres cas et offrant une capacité de redondance. Aucun des deux chemins ne transite jamais par des fournisseurs établis aux États-Unis. Augure a également attesté, en date d'août 2026, qu'elle n'a ni société mère américaine ni investisseurs américains, ce qui signifie que les conversations et documents des clients ne sont, dès le départ, jamais traités par un fournisseur relevant de la juridiction américaine. C'est particulièrement pertinent pour la question du CLOUD Act, puisque la portée de cette loi dépend du statut américain du fournisseur, et non de l'emplacement physique des serveurs. Cette affirmation s'applique au contenu des clients et à l'inférence de l'IA, pas à l'ensemble de la chaîne de fournisseurs d'Augure.

C'est une affirmation architecturale réelle et vérifiable, mais elle ne couvre pas l'ensemble du portrait de conformité. La livraison de courriels et le traitement des paiements par carte, pour la plupart des fournisseurs SaaS — y compris Augure —, passent encore par des réseaux basés aux États-Unis. L'entreprise le divulgue elle-même dans sa politique de confidentialité plutôt que de le passer sous silence, ce qui est en soi inhabituel sur un marché où l'expression « entièrement canadien » est utilisée à la légère. Pour une évaluation de transfert, la version honnête du document nomme les deux flux : l'inférence basée en Europe pour certains niveaux de modèles et en cas de redondance, et le traitement basé aux États-Unis limité aux réseaux de cartes de paiement et à la livraison de courriels. C'est un document plus court que celui qui couvrirait un fournisseur dont l'inférence est hébergée aux États-Unis, mais ce n'est pas un document à flux nul, et aucun évaluateur ne devrait accepter qu'on le présente comme tel.

Diligence raisonnable, pas magasinage

Les lignes directrices de la CAI, tout comme la majorité des avocats qui conseillent sur la question, présentent le choix d'outils d'IA comme un exercice d'approvisionnement plutôt que comme une simple décision binaire. Quelques éléments reviennent systématiquement :

• La capacité du fournisseur à nommer précisément quelles juridictions traitent quelles parties du flux de données, pas une affirmation générale sur des « serveurs canadiens », mais un tableau des sous-traitants.
• La question de savoir si les données des clients servent à entraîner les modèles du fournisseur, une question distincte de celle de l'endroit où les données sont stockées.
• La question de savoir si l'outil prend une décision automatisée concernant une personne — en matière d'embauche, de crédit ou d'admissibilité à un service — qui déclencherait des obligations de divulgation.
• La question de savoir si l'organisation a réalisé, et peut produire, une évaluation des facteurs relatifs à la vie privée pour le déploiement en cause.

La plupart des outils de clavardage IA utilisés pour la rédaction interne ou la recherche ne prennent pas de décisions automatisées concernant des personnes, ce qui les écarte entièrement de cette problématique. Les outils juridiques et de ressources humaines, c'est une autre histoire. Un outil de révision de contrats qui signale des clauses à risque, ou un outil d'embauche qui note des curriculum vitae, se rapproche beaucoup plus de la ligne de la prise de décision automatisée, et le fardeau documentaire s'alourdit en conséquence.

Il existe un cas plus restreint qui ne cadre pas du tout avec le modèle général d'approvisionnement : les outils destinés aux développeurs qui se connectent par un protocole comme MCP plutôt que par l'interface de clavardage propre d'un fournisseur. Le serveur MCP d'Augure, par exemple, traite le texte qui transite par lui au Canada, l'inférence de ces appels s'exécutant sur la propre capacité canadienne d'Augure plutôt que par l'entremise d'un tiers, les embeddings, le reclassement ou la reconnaissance optique de caractères étant acheminés vers Calgary lorsqu'un outil donné les invoque. Cela semble simplifier la question du transfert, et pour l'appel MCP lui-même, c'est bien le cas — Augure a conçu ces appels pour qu'ils demeurent exclusivement canadiens, échouant carrément plutôt que de les acheminer hors du Canada si la capacité nationale n'est pas disponible. Mais le serveur MCP est une fonctionnalité destinée aux développeurs, invoquée par une application cliente, et Claude Code est le seul client qu'Augure a validé avec ce serveur. Le fait de connecter un autre assistant à un point de terminaison MCP d'Augure ne soumet pas pour autant le propre modèle de cet assistant, ni sa propre gestion de la conversation, aux conditions de résidence d'Augure. Le fournisseur de l'assistant reçoit tout de même la conversation et ce que l'outil retourne, selon ses propres conditions. Pour une évaluation des facteurs relatifs à la vie privée, cette distinction compte : la garantie exclusivement canadienne du serveur MCP couvre le côté d'Augure dans l'échange, pas l'application cliente qui l'invoque.

Ce qui change maintenant

En pratique, pour une organisation qui évalue des outils d'IA ce trimestre, la liste des actions à poser est plus courte que ne le laisse croire le texte réglementaire. Confirmer quelles données l'outil touchera réellement. Vérifier si le fournisseur publie une liste de sous-traitants ou une politique de confidentialité suffisamment précise pour appuyer une analyse de transfert. Demander si les données saisies par les clients servent à entraîner le modèle sous-jacent. Si l'outil prend ou influence de façon importante une décision concernant une personne en particulier, impliquer la personne responsable du processus d'évaluation des facteurs relatifs à la vie privée avant le déploiement, pas après.

Rien de tout cela n'oblige, sur le plan juridique, à choisir un fournisseur canadien plutôt qu'américain. Cela signifie toutefois que le dossier de diligence raisonnable est plus court lorsque les réponses sont plus simples. Pour les équipes de conformité qui doivent traiter un arriéré d'évaluations de fournisseurs, c'est précisément tout l'intérêt.

Le produit juridique d'Augure, qui gère la révision de contrats et le tri des ententes de confidentialité pour les cabinets d'avocats canadiens, intègre les vérifications de conformité à la Loi 25 et à la LPRPDE directement dans le flux de travail, plutôt que de les traiter comme un ajout secondaire. C'est un choix de conception raisonnable étant donné que les cabinets qui l'utilisent sont eux-mêmes liés par des règles de confidentialité professionnelle, en plus de la loi générale sur la protection des renseignements personnels. Augure affirme que les données des clients ne servent jamais à entraîner ses modèles. Reste que c'est toujours au cabinet lui-même de déterminer, et de documenter, si cela satisfait à ses propres obligations en vertu de la Loi 25. L'architecture d'un fournisseur appuie cette analyse. Elle ne la remplace pas.

Plus de détails sur l'architecture de résidence des données d'Augure et sa gamme de modèles sont publiés à augureai.ca.