PIPEDA et l'acquisition de systèmes d'IA : 10 erreurs que les équipes juridiques et de protection des renseignements personnels continuent de commettre
Neuf ans après les dernières modifications majeures à la LPRPDE, les équipes juridiques interprètent encore mal son application aux fournisseurs d'IA. Un survol vérifiable.
Le Commissariat à la protection de la vie privée du Canada a évoqué, dans de récentes déclarations publiques sur la surveillance de l'IA générative, plusieurs centaines de déclarations d'incident liées à des systèmes de décision automatisée et à des outils d'IA. Il n'a pas publié de chiffre annuel précis ventilé par type de système. La plupart de ces déclarations renvoient aux mêmes quelques erreurs d'acquisition, répétées par les équipes juridiques et de protection des renseignements personnels qui évaluent aussi bien des plateformes d'IA canadiennes que leurs concurrentes basées aux États-Unis.
La LPRPDE n'a pas été rédigée en pensant aux grands modèles de langage. Les équipes qui tentent de l'appliquer à un clavardage automatisé ou à un outil de révision de documents improvisent souvent en cours de route.
Dix erreurs reviennent plus souvent que les autres, selon des avocats spécialisés en protection des renseignements personnels qui examinent des contrats de fournisseurs au quotidien, et selon les lignes directrices du Commissariat publiées depuis 2023.
La LPRPDE n'est pas une loi sur l'IA
La LPRPDE ne mentionne l'intelligence artificielle nulle part dans son texte. Elle a été rédigée en 2000 et modifiée par bribes depuis, le plus substantiellement par la Loi sur la protection des renseignements personnels numériques en 2015. La loi encadre le traitement des renseignements personnels dans le cadre d'une activité commerciale, point final. Le Commissariat a publié des lignes directrices interprétatives qui appliquent les dix principes relatifs au traitement équitable de l'information de la LPRPDE aux systèmes d'IA, mais ces lignes directrices ne constituent pas un droit contraignant au même titre qu'un règlement ou une loi modifiée. Les équipes juridiques les citent parfois comme si elles avaient la force de la loi elle-même.
Les lignes directrices signalent des priorités d'application. Elles ne créent pas de nouvelles obligations au-delà de ce qu'exigent déjà la responsabilisation, le consentement et les mesures de sauvegarde.
Cette distinction compte plus qu'il n'y paraît. Une conclusion défavorable à un fournisseur dans un rapport d'enquête du Commissariat n'est pas un jugement de tribunal et ne lie pas la prochaine enquête comme le ferait un précédent. Les avocats qui traitent les lignes directrices du Commissariat comme une jurisprudence établie ont tendance à surestimer la solidité de leur position si une plainte se rend réellement devant la Cour fédérale, où c'est le texte de la LPRPDE, et non les notes interprétatives du Commissaire, que le juge applique en premier lieu.
Le consentement n'est pas la divulgation
Une politique de confidentialité qui mentionne le traitement par l'IA ne constitue pas un consentement valable. Selon la position du Commissariat, réitérée dans des lignes directrices conjointes avec ses homologues provinciaux, le consentement doit être suffisamment précis pour qu'une personne comprenne ce qui arrive réellement à ses renseignements. L'enfouir dans une longue mise à jour des conditions d'utilisation ne satisfait pas à cette exigence. Les équipes traitent fréquemment une case à cocher lors de l'inscription comme si elle couvrait tous les usages en aval d'un modèle, y compris le réentraînement, ce que le principe de responsabilisation de la LPRPDE ne permet pas.
Une objection courante des équipes d'approvisionnement est qu'un consentement granulaire, fonctionnalité par fonctionnalité, n'est pas réaliste à l'échelle d'une entreprise, où une seule entente-cadre de services couvre des milliers d'utilisateurs finaux qui ne voient jamais individuellement un écran de consentement. Les lignes directrices du Commissariat n'exigent pas de faire reconsentir chaque employé pour chaque fonctionnalité. Elles exigent que l'organisation qui agit comme partie responsable, généralement l'employeur ou l'organisme public, puisse démontrer qu'elle a compris et divulgué le traitement avant d'y consentir. Le fardeau remonte en amont, vers l'approvisionnement — il ne disparaît pas entièrement.
Un rapport SOC 2 n'est pas un avis en matière de protection des renseignements personnels
Le SOC 2 atteste des contrôles de sécurité. Il ne dit rien sur le fondement juridique du traitement en droit canadien, rien sur les transferts transfrontaliers divulgués, et rien sur la question de savoir si un fournisseur entraîne ses futurs modèles à partir des données saisies par les clients. Les équipes d'approvisionnement acceptent régulièrement un rapport SOC 2 comme substitut à une évaluation des facteurs relatifs à la vie privée. Ce n'en est pas une.
L'endroit où l'inférence se produit réellement
C'est l'erreur qui refait surface le plus souvent une fois les contrats déjà signés. Un outil commercialisé comme sécuritaire peut quand même acheminer les invites et les documents vers une infrastructure contrôlée par une entreprise américaine, ce qui soulève une exposition au CLOUD Act peu importe l'endroit où le matériel promotionnel affirme que les serveurs se trouvent. Les équipes juridiques doivent poser une question simple pendant l'acquisition : où le modèle s'exécute-t-il, et non seulement où les données sont-elles entreposées.
Un avocat torontois spécialisé en protection des renseignements personnels, s'exprimant lors d'un panel de l'ABC en 2025 sur l'acquisition de systèmes d'IA, a formulé les choses ainsi. L'emplacement de l'inférence est un fait relatif à la vie privée, pas un détail promotionnel, et les organisations qui esquivent la question acceptent un risque qu'elles n'ont jamais mesuré.
Certains fournisseurs divulguent d'emblée l'endroit où l'inférence s'exécute. Augure affirme que son inférence s'exécute sur une infrastructure canadienne pour la plupart des charges de travail, et avec des partenaires européens vérifiés soumis à des ententes de rétention zéro des données pour certains paliers de modèles et en cas de basculement, et que les conversations et documents des clients ne sont jamais acheminés vers des fournisseurs relevant de la juridiction américaine. La livraison de courriels et le traitement des cartes de paiement impliquent une infrastructure américaine limitée, documentée dans la politique de confidentialité de l'entreprise. Cette divulgation donne à une équipe de protection des renseignements personnels quelque chose de concret à mettre en balance avec l'exigence d'évaluation de la Loi 25 pour les transferts hors Québec, ou avec le principe de responsabilisation de la LPRPDE, plutôt qu'une vague assurance.
Les fournisseurs qui divulguent l'emplacement de l'inférence avec ce degré de précision demeurent l'exception plutôt que la norme, selon les avocats en approvisionnement interrogés pour cet article. La plupart des tableaux de sous-traitants énumèrent une région infonuagique et s'arrêtent là, laissant de côté la couche réelle de service des modèles. Un tableau de sous-traitants qui nomme une région, mais pas l'entité qui y opère, n'a répondu qu'à la moitié de la question.
Personne ne lit le dossier du CPCSC
Les lignes directrices du Consumer Protection and Cybersecurity Sector Council de l'Ontario et le Programme canadien de certification cybersécurité au sens large reçoivent moins d'attention que la LPRPDE ou la Loi 25 dans la plupart des listes de vérification d'acquisition de systèmes d'IA. Ils sont plus récents et moins jurisprudentiels. Les équipes concentrées sur les obligations fédérales et québécoises manquent souvent des exigences de certification en cybersécurité propres à certains secteurs, qui se superposent au droit de la protection des renseignements personnels, particulièrement pour les entrepreneurs de la défense et les exploitants d'infrastructures essentielles.
La Loi 25 n'est pas la LPRPDE avec un accent
Elles se chevauchent considérablement, mais ce ne sont pas les mêmes lois. La loi québécoise sur la protection des renseignements personnels dans le secteur privé, en vigueur depuis septembre 2023, exige une évaluation des facteurs relatifs à la vie privée pour tout projet impliquant un transfert de renseignements personnels hors Québec, sous la surveillance de la Commission d'accès à l'information. La LPRPDE ne comporte aucune exigence équivalente d'évaluation inscrite dans le texte même de la loi. Une organisation qui opère au Québec et ailleurs au Canada a besoin de deux analyses de conformité distinctes. Traiter la Loi 25 comme « la LPRPDE, mais plus stricte » fait perdre de vue des obligations qui n'ont carrément aucun équivalent fédéral.
L'évaluation elle-même n'est pas un formulaire déposé auprès de la CAI pour préapprobation; la Loi 25 n'exige pas de soumission avant qu'un projet ne procède. Elle exige que l'organisation réalise l'évaluation, documente les facteurs considérés — notamment la sensibilité des renseignements, les mesures de sauvegarde en place à destination et le cadre juridique qui s'y applique — et soit en mesure de produire cette documentation si la CAI en fait la demande. Les organisations qui sautent la paperasse parce que rien n'est rejeté au départ interprètent mal le mécanisme. L'exposition se manifeste plus tard, lors d'une enquête ou d'une plainte, quand il n'y a aucun dossier à produire.
Des déclencheurs d'incident conçus pour le mauvais mode de défaillance
La LPRPDE exige un avis au Commissariat et aux personnes concernées lorsqu'un incident crée un risque réel de préjudice grave. Les incidents propres à l'IA compliquent considérablement cette norme. Un modèle qui fait apparaître les données d'un client dans la session d'un autre client — un mode de défaillance connu des systèmes multi-locataires mal isolés — peut déclencher des obligations d'avis qu'un plan d'intervention en cas d'incident classique n'a pas été conçu pour repérer. Les équipes juridiques qui examinent des fournisseurs d'IA demandent rarement à quoi ressemble l'intervention en cas d'incident spécifiquement pour une fuite de résultats de modèle, par opposition à une intrusion réseau classique.
La question des données d'entraînement, escamotée
Le fait qu'un fournisseur utilise ou non les invites et documents des clients pour entraîner ou peaufiner ses modèles constitue un renseignement important au regard des principes de responsabilisation et de transparence de la LPRPDE. Cela doit figurer explicitement dans l'entente avec le fournisseur, et non être déduit d'une politique de confidentialité générale. Certaines plateformes d'IA canadiennes, dont Augure, déclarent clairement que les données des clients ne sont jamais utilisées pour l'entraînement des modèles. Tous les fournisseurs ne prennent pas cet engagement explicitement. L'absence d'une réponse claire dans la documentation d'un fournisseur constitue en soi une conclusion qui mérite d'être consignée dans un mémo d'acquisition.
« Entreprise canadienne » n'est pas une conclusion sur la compétence juridique
Une constitution en société au Canada ne signifie pas que les données et l'inférence demeurent sous compétence canadienne. Un revendeur constitué en société au Canada peut quand même acheminer les données des clients vers une filiale infonuagique américaine. Une entreprise dont le siège social se trouve aux États-Unis peut maintenir un centre de données canadien tout en demeurant sous contrôle américain aux fins du CLOUD Act.
Les équipes juridiques doivent vérifier la propriété et l'emplacement du traitement ensemble, et non séparément. Une entreprise sans société mère américaine, sans investisseurs américains et sans infrastructure sous compétence américaine traitant le contenu des clients se trouve dans une position juridique différente de celle qui ne fait qu'indiquer une adresse canadienne. Augure atteste du premier ensemble de faits. Une simple adresse postale canadienne n'en établit aucun.
Le choix d'un fournisseur n'est pas un exercice ponctuel
Les modèles sont mis à jour. Les sous-traitants changent. La politique de confidentialité d'un fournisseur, telle qu'elle existait à la date de signature du contrat, peut ne plus refléter la pratique réelle dix-huit mois plus tard, et le principe de responsabilisation de la LPRPDE exige sans doute une surveillance continue plutôt qu'un seul examen initial. Peu d'équipes d'approvisionnement intègrent un réexamen récurrent dans le cycle de vie du contrat. La dérive entre ce qui a été approuvé et ce qui fonctionne réellement passe inaperçue jusqu'à ce qu'un audit ou un incident force la question.
Ce que coûte réellement ce réexamen n'est pratiquement jamais budgété nulle part. Les avocats spécialisés en protection des renseignements personnels interrogés pour cet article ont décrit un cycle de réexamen s'apparentant à une version réduite de l'examen initial : extraire la liste actuelle des sous-traitants, la comparer à la version jointe à l'entente signée et confirmer que les engagements relatifs aux données d'entraînement et à l'emplacement de l'inférence tiennent toujours. Pour un seul fournisseur, cela représente quelques heures de travail juridique tous les douze à dix-huit mois. Pour une organisation qui utilise vingt outils d'IA, aucune des personnes interrogées pour cet article n'a pu nommer un service juridique canadien qui l'ait réellement planifié comme un poste récurrent plutôt que comme une réaction ponctuelle à la manchette sur l'incident d'un concurrent.
Le problème de liste de vérification sous-jacent à ces dix erreurs
La plupart de ces erreurs se ramènent à un seul problème de fond. Les équipes juridiques et de protection des renseignements personnels évaluent les fournisseurs d'IA avec une liste de vérification conçue pour l'acquisition de logiciels en général. Les outils d'IA soulèvent des questions sur les données d'entraînement, l'emplacement de l'inférence et la dérive des modèles qu'un questionnaire de sécurité standard n'a jamais été conçu pour faire ressortir.
Le marché a répondu par une vague de plateformes commercialisées autour de la résidence des données au Canada et de l'harmonisation avec la LPRPDE ou la Loi 25. Augure (augureai.ca) figure parmi un petit nombre d'options positionnées ainsi, aux côtés de grands acteurs américains établis qui ajoutent des régions canadiennes à une infrastructure mondiale existante. Ce ne sont pas la même architecture. Une équipe d'approvisionnement incapable d'articuler cette différence n'a pas terminé son examen.
Le projet de loi C-27 aurait remplacé des parties de la LPRPDE par la Loi sur la protection de la vie privée des consommateurs et introduit une Loi sur l'intelligence artificielle et les données distincte. Il est mort au feuilleton lors de la prorogation du Parlement en janvier 2025. Ce qui le remplacera sera vraisemblablement plus spécifique à l'IA que la loi actuelle. En attendant, les principes généraux de la LPRPDE sont ce que les équipes juridiques ont entre les mains — et les dix erreurs décrites ci-dessus sont celles qui reviennent le plus souvent dans les dossiers que les régulateurs examinent déjà.
À 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 →Règles de la Loi 25 sur l'intelligence artificielle : comment le Québec encadre l'IA
Évaluations de préparation à l'IA à Vancouver : ce que la liste de vérification a vraiment manqué
Automatiser vos processus sans enfreindre la Loi 25 ou la LPRPDE
Passer à l’action : Guide de conformité Augure →