Obligations canadiennes en matière de protection des renseignements personnels et IA : ce qui change quand votre équipe adopte l'IA
Ce qui change en vertu de la Loi 25 et de la LPRPDE quand votre équipe adopte des outils d'IA canadiens — et pourquoi la juridiction du fournisseur comptait plus que l'outil lui-même.
Ce qui nous a arrêtés, ce n'était pas l'outil d'IA. C'était de réaliser qu'aucun d'entre nous ne pouvait dire, sans sourciller, où allaient réellement les questions que notre personnel tapait dedans. Cet écart — entre adopter des outils d'IA canadiens de façon désinvolte et comprendre ce qui arrive aux données — c'est de ça dont il est question ici.
On est une petite firme de services professionnels — moins de trente personnes, pas d'avocat interne, une seule personne qui s'occupe de la protection des renseignements personnels, des finances et de la moitié des RH parce que c'est comme ça que ça fonctionne à cette taille-là. Quelqu'un sur l'équipe a commencé à utiliser un clavardeur IA gratuit pour rédiger des courriels aux clients et résumer des notes de réunion, comme tout le monde le fait maintenant, et ça allait bien jusqu'à ce qu'un client demande, raisonnablement, si ses renseignements avaient transité par quelque chose d'américain. On ne le savait pas. C'est cette partie-là qui comptait, pas l'IA elle-même.
Ce que les obligations de la Loi 25 sur les outils d'IA vous demandent réellement de changer
La Loi 25 du Québec est pleinement en vigueur depuis septembre 2024, et l'exigence qui nous a mordus, c'est l'évaluation des facteurs relatifs à la vie privée pour tout transfert de renseignements personnels à l'extérieur de la province, prévue à l'article 17 de la Loi sur la protection des renseignements personnels dans le secteur privé. Pas à l'extérieur du Canada — à l'extérieur du Québec. Si vous êtes une entreprise québécoise, ou que vous servez des clients québécois, envoyer leurs données à un serveur dans une autre province déclenche techniquement la même analyse que de les envoyer dans un autre pays. Je ne le savais pas au départ. Ma compréhension était que le seuil géographique allait être « Canada vs pas-Canada », et ce n'est pas ça, du moins pas sous la Loi 25 précisément. Si vous voulez avoir le portrait complet des enjeux en cas d'erreur, les pénalités de la Loi 25 peuvent atteindre 25 millions de dollars ou 4 % du chiffre d'affaires mondial en vertu de l'article 102 — un plafond qui reste surtout théorique pour une entreprise de notre taille, mais c'est ce qui a capté toute l'attention des avocats.
La LPRPDE fonctionne selon une logique différente — elle repose sur les dix principes relatifs au traitement équitable de l'information de l'annexe 1, qui couvrent la responsabilité, le consentement et les mesures de sécurité pour les renseignements personnels peu importe où ils sont traités, et elle s'applique au niveau fédéral aux activités commerciales. L'application de la loi passe par le Commissariat à la protection de la vie privée du Canada, qui peut enquêter et, si le dossier n'est pas résolu, renvoyer l'affaire à la Cour fédérale pour une ordonnance de conformité — un chemin plus lent que les pénalités administratives de la Loi 25, mais qui n'est pas sans effet. Les deux cadres se chevauchent suffisamment pour qu'on puisse généralement les traiter comme un seul problème, mais notre réviseure en sécurité a signalé qu'une EFVP satisfaisant la Loi 25 ne documente pas automatiquement le principe de responsabilité de la LPRPDE, et on a fini par écrire deux courts mémos au lieu d'un long. Ça semblait être du travail inutile sur le coup. Avec le recul, ça ne l'était pas — les deux documents sont lus par des personnes différentes si quelque chose tourne mal.
Ça vaut la peine de le préciser : l'obligation d'EFVP ne disparaît pas simplement parce qu'un transfert est petit ou occasionnel. On avait supposé au départ que si seulement les notes d'une personne transitaient par un outil donné, l'évaluation pouvait attendre que l'usage prenne de l'ampleur. Notre réviseure n'était pas d'accord, et selon sa lecture de l'article 17 et des directives de la Commission d'accès à l'information, l'obligation est liée au transfert lui-même, pas au volume — donc un seul dossier client qui traverse la frontière dès le premier jour déclenche la même analyse qu'en déclencherait mille. On a refait l'échéancier sur cette base, en visant à avoir l'EFVP rédigée avant que l'outil entre en usage réel plutôt qu'après que l'équipe l'ait déjà utilisé pendant quelques semaines, ce qui se rapproche davantage de ce qu'on avait prévu au départ.
Pourquoi la juridiction du fournisseur s'est avérée être toute la question
Je suis entré dans l'évaluation des fournisseurs en supposant que les questions techniques allaient dominer — la qualité du modèle, le temps de disponibilité, la façon dont l'outil gérait les documents en français, puisqu'une bonne partie de notre clientèle est au Québec. Ces questions comptaient, mais ce n'était pas ce à quoi notre réviseure en sécurité revenait sans cesse. Ce à quoi elle revenait, c'était : qui peut contraindre ce fournisseur à remettre les données des clients, et en vertu de quelle loi.
C'est là qu'est arrivé le point sur le US CLOUD Act, et c'est l'élément de l'analyse sur lequel nos avocats ne voulaient pas bouger. Le Clarifying Lawful Overseas Use of Data Act, adopté en 2018, permet aux forces de l'ordre américaines de contraindre la divulgation de données par des fournisseurs sous juridiction américaine, y compris des données stockées à l'extérieur des États-Unis, si ce fournisseur est américain ou a une société mère américaine. Pour une firme qui gère du matériel sensible pour ses clients, c'est un scénario que nos avocats voulaient voir traité par écrit avant qu'on signe quoi que ce soit, pas quelque chose qu'on pouvait mettre en note de bas de page et passer outre.
On a examiné trois outils. Deux étaient les grandes plateformes américaines que tout le monde connaît déjà, toutes deux vraiment compétentes, toutes deux sous une structure corporative américaine et donc sous la portée du CLOUD Act pour tout ce qu'elles détiennent. Le troisième était Augure, une plateforme d'IA canadienne, et la réponse qu'on a obtenue sur la question de juridiction était précise plutôt que simplement rassurante en apparence : aucune société mère américaine, aucun investisseur américain, et les conversations et documents des clients traités sur une infrastructure canadienne ou avec des partenaires européens sélectionnés selon des ententes de rétention zéro, jamais acheminés vers un fournisseur américain. Cette affirmation vise le contenu des clients et l'inférence IA, pas l'ensemble de l'entreprise — le traitement des paiements et l'acheminement des courriels passent encore par des réseaux américains, comme c'est le cas pour presque tout le monde, et Augure a été franc sur le fait que ce n'était pas une situation où « vos données ne quittent jamais le Canada ». J'ai apprécié que ce soit présenté de cette façon plutôt que comme une promesse générale, parce que la version générale n'est vraie pour aucun outil une fois qu'on tient compte des aspects moins glamour de faire fonctionner une entreprise.
On a aussi demandé à Augure au sujet de la certification en sécurité, puisque les affirmations sur la juridiction ne valent que ce que les preuves qui les appuient valent. Le Programme canadien pour la certification en cybersécurité (PCCC) est le cadre fédéral qui compte ici pour les fournisseurs qui gèrent des données sensibles ou proches du secteur public, et même si tous les fournisseurs d'IA canadiens ne le détiennent pas encore, c'est un point raisonnable à vérifier si votre clientèle inclut du travail réglementé ou lié au secteur public — ça vous dit si « infrastructure canadienne » est un argument de marketing ou une affirmation vérifiée.
Ce qui a compté moins que je m'y attendais
J'ai passé beaucoup d'énergie au début à m'inquiéter de la qualité du modèle — si un outil d'IA canadien allait gérer une rédaction nuancée aussi bien que les grands joueurs établis, s'il allait trébucher sur de la terminologie juridique ou financière. Il n'a pas trébuché de la façon dont je m'y attendais, même si notre échantillon de test était petit, peut-être quarante invites réparties entre deux personnes sur une semaine, ce qui n'est pas rigoureux. La question de la qualité des extrants, au final, n'a pas été un enjeu. Ce qui a mangé notre temps de révision, c'était le suivi de la paperasse de conformité, pas la compétence de l'outil.
Ça m'a surpris, et je pense que ça surprend la plupart des gens qui traversent l'adoption de l'IA sous la LPRPDE pour une petite entreprise, parce que le discours marketing autour de l'adoption de l'IA porte presque entièrement sur les capacités, et la conversation interne réelle finit par porter presque entièrement sur la garde des données. Si vous êtes plus tôt dans ce processus et que vous n'avez pas encore réglé le libellé de consentement, la question du consentement vaut la peine d'être résolue avant d'évaluer n'importe quel fournisseur, pas après.
Ce qu'on a demandé à chaque fournisseur avant de signer quoi que ce soit
On a bâti cette liste après que le premier appel avec un fournisseur ait mal tourné — on a posé une question générale et on a obtenu une réponse générale, et notre réviseure a insisté pour dire qu'il nous fallait quelque chose qu'on pouvait mettre dans un dossier. Les questions qui ont fini par compter :
- Où les données des clients sont-elles stockées au repos, et où l'inférence se déroule-t-elle réellement?
- Une partie de l'entreprise appartient-elle à des intérêts américains ou est-elle financée par des investisseurs américains, et cela expose-t-il le contenu des clients à des demandes en vertu du CLOUD Act?
- Les données des clients sont-elles utilisées pour entraîner les modèles, et peut-on désactiver ça par contrat?
- Quelle est la période de conservation, et peut-on forcer la suppression sur demande?
- Le fournisseur a-t-il un soutien documenté pour la conformité à la Loi 25 et à la LPRPDE, ou faut-il bâtir ça nous-mêmes?
Tous les fournisseurs n'ont pas répondu clairement aux cinq questions. L'un nous a donné une réponse sur la résidence des données qui semblait confiante mais qui, à une deuxième lecture de sa politique de confidentialité, s'est avérée décrire seulement où se trouvait la base de données des comptes, pas où l'inférence de l'IA elle-même se déroulait. On n'était pas certains, au départ, si cette distinction valait la peine d'être approfondie ou si on était trop pointilleux. Ça valait la peine de l'approfondir : des métadonnées de compte situées à un endroit pendant que le contenu réel des invites est traité ailleurs complètement, c'est exactement le genre d'écart qu'une enquête sur une atteinte demanderait plus tard.
Ce que je ferais autrement
Je commencerais par la question de juridiction en premier, pas en troisième. On a passé presque deux semaines sur des comparaisons de fonctionnalités avant que quelqu'un pose la question du CLOUD Act, et une fois qu'on l'a posée, la plupart du travail de comparaison antérieur est devenu inutile, parce que deux de nos trois candidats étaient disqualifiés sur cette seule base, peu importe à quel point leur rédaction semblait bonne.
Je ne suis pas non plus pleinement certain qu'on ait rendu l'EFVP de la Loi 25 aussi rigoureuse qu'elle devrait l'être — on l'a traitée comme un document ponctuel plutôt que comme quelque chose à revisiter, et je soupçonne que c'est une erreur. On a nommé un responsable de la protection des renseignements personnels, comme l'exige la Loi 25, et ce rôle comporte une responsabilité continue à l'égard des renseignements personnels, pas une approbation ponctuelle. On a nommé quelqu'un. Je ne pense pas qu'on ait revisité ce que ce rôle fait réellement depuis, et c'est sur la liste pour le prochain trimestre. Si vous partez de zéro et que vous essayez de séquencer les dépenses, où les petites entreprises canadiennes devraient placer en priorité leur budget de conformité est un bon test de réalité par rapport à ce qu'on a fait dans le désordre.
On a aussi revérifié notre gestion du côté des employés, puisque les notes du personnel et les dossiers RH internes circulaient dans les mêmes outils que les données des clients, et les données des employés comportent leur propre ensemble d'obligations sous la Loi 25 et la LPRPDE qui sont faciles à manquer quand on se concentre sur le côté client.
Rien de tout ça n'a éliminé nos obligations de conformité — rien de ce que vend un fournisseur ne fait ça, et je serais sceptique envers quiconque prétend le contraire. Ce qui a changé, c'est quelles questions on devait répondre nous-mêmes par rapport à celles que l'architecture de la plateforme rendait plus simples à répondre. La documentation d'Augure sur la résidence des données et l'inférence était assez claire pour qu'on puisse aller directement à la question de juridiction plutôt que de passer deux semaines sur des comparaisons de fonctionnalités d'abord, comme on l'a fait. Si vous évaluez des outils d'IA canadiens pour votre propre équipe, l'aperçu de la plateforme Augure est un bon point de départ pour les questions de juridiction et de résidence des données précisément — ça ne fera pas l'EFVP à votre place, mais ça réduit ce que vous devez évaluer. Et avant de supposer que votre configuration actuelle est correcte, ça vaut la peine de faire un survol rapide des mythes sur la conformité en matière de protection des renseignements personnels qui coûtent discrètement de l'argent aux petites entreprises canadiennes — on en a trouvé au moins deux sur lesquels on se basait.
À propos d'Augure
Augure est une plateforme d'IA souveraine pour les organisations canadiennes réglementées. Clavardage, base de connaissances et outils de conformité — le tout sur une infrastructure canadienne.
Encore plus de perspectives
Voir tout →Les données des employés et le droit canadien de la protection des renseignements personnels : ce que les PME font mal
Quoi faire dans les 72 premières heures d'une atteinte à la protection des données au Canada
PIPEDA, Loi 25 ou lois provinciales : laquelle régit vraiment votre entreprise?
Passer à l’action : Augure Chat, l’IA hébergée au Canada →