PIPEDA et IA : 10 erreurs que font les équipes en télécommunications

Ce qui a vraiment arrêté notre révision, ce n'était pas l'endroit où se trouvaient les serveurs. C'était que personne du côté du fournisseur ne pouvait nous dire, par écrit, pendant combien de temps ils conservaient les journaux de clavardage après la fin d'une session client.

C'est la partie que je n'avais pas vue venir. Je travaille en conformité pour une entreprise de télécommunications de taille moyenne, du genre qui gère assez de données d'abonnés pour que l'article 5 de la PIPEDA soit une préoccupation quotidienne plutôt qu'une ligne d'audit annuelle. On magasinait des outils d'IA pour le tri des demandes de service à la clientèle, les résumés de litiges de facturation, ce genre de chose. Je pensais que la conversation difficile allait porter sur l'endroit où se faisait le traitement des données. Il s'est avéré que c'était plutôt sur combien de temps le fournisseur les conservait par la suite, et presque personne n'avait de réponse claire.

Je pense que les vraies erreurs que les équipes commettent sont plus ternes et plus procédurales que celles qu'on voit dans les présentations de vente des fournisseurs. Voici, en gros, ce qu'on a mal fait, dans l'ordre où on s'en est rendu compte.

On a posé des questions sur les serveurs avant de poser des questions sur la conservation

C'est celle qui nous a coûté le plus de temps. On a passé les deux premières semaines d'appels avec les fournisseurs à demander « où vivent les données », ce qui est une bonne question en soi, mais ça permettait à trois fournisseurs de répondre avec un « Canada » confiant et de passer à autre chose avant qu'on pose la question de suivi : pendant combien de temps, et selon quel calendrier de suppression. Le principe de responsabilité de la PIPEDA (Annexe 1, Principe 4.1) place l'obligation sur nous, l'organisation, pas sur le fournisseur, ce qui veut dire qu'une réponse vague de leur part devient notre exposition à nous, pas la leur.

Est-ce que quelqu'un avait vraiment lu la liste des sous-traitants?

Personne ne l'avait fait, moi inclus, pour le premier fournisseur. J'ai survolé la politique de confidentialité, j'ai vu « nous ne vendons pas vos données », et j'ai continué. Notre réviseure en sécurité est retournée ligne par ligne lors du deuxième passage et a trouvé un sous-traitant pour l'envoi de courriels basé aux États-Unis, ce qui n'était pas un problème en soi, il fallait simplement que ce soit divulgué et pris en compte dans notre évaluation des transferts, et ça n'avait été sur le radar de personne avant qu'elle tire ce fil-là.

Ce que cette divulgation voulait vraiment dire en pratique a pris une autre rencontre à démêler. Qu'un sous-traitant apparaisse sur une liste n'est pas la fin de la question; notre réviseure voulait savoir quelle catégorie de données ce sous-traitant touchait, s'il s'agissait de transcriptions complètes ou seulement de métadonnées d'envoi comme une adresse courriel et un horodatage, et si le contrat du fournisseur avec ce sous-traitant nous donnait un recours si quelque chose tournait mal en aval. Pour le fournisseur de courriels, il s'est avéré que c'était seulement des métadonnées, aucun contenu de transcription, ce qui a rendu l'évaluation des transferts plus courte que prévu. Je n'aurais pas su qu'il fallait faire cette distinction avant cette révision.

La question du CLOUD Act, et celle qui a suivi

C'est là que le service juridique s'est vraiment impliqué. La position de notre conseillère juridique était que si une partie du pipeline d'inférence de l'IA se trouvait sous un fournisseur contrôlé par les États-Unis, on devait documenter l'exposition explicitement, même quand le risque pratique était faible. C'est le point sur lequel le service juridique n'a pas bougé. On a regardé quelques-unes des grandes plateformes de clavardage américaines, et la réponse honnête, même dans leur propre documentation, était que le contenu des clients pouvait en principe être atteint par une procédure légale américaine. La réponse d'Augure sur ce point était plus étroite et plus précise : les conversations des clients et l'inférence de l'IA s'exécutent sur une infrastructure canadienne ou chez des partenaires européens vérifiés sous des ententes de non-conservation, jamais acheminées vers des fournisseurs américains, donc la portée du CLOUD Act sur les fournisseurs sous juridiction américaine ne s'étend pas à ce contenu client. J'apprécie que ça ait été délimité aussi précisément plutôt qu'offert comme une affirmation générale, parce que la version plus large aurait été ce qui aurait fait échouer l'entente pour nous.

Le principe de responsabilité de l'Annexe 1 de la PIPEDA stipule qu'une organisation est responsable des renseignements personnels qu'elle a sous sa garde, y compris les renseignements confiés à un tiers aux fins de traitement.

Cette phrase a fait plus de travail dans notre mémo interne que tout ce qu'un fournisseur nous a dit directement.

Un collègue sceptique sur l'équipe de révision a posé la question de suivi évidente : si l'inférence tourne parfois en Europe, est-ce qu'on ne fait pas juste échanger un problème transfrontalier contre un autre? Ma lecture, c'est non, ce n'est pas le même problème, parce que les partenaires européens fonctionnent sous des ententes de non-conservation, et la comparaison qui comptait vraiment pour le service juridique portait spécifiquement sur l'exposition au CLOUD Act, pas sur les transferts transfrontaliers en général. Les transferts vers l'Europe sont quand même documentés dans notre évaluation. Ils ne portent simplement pas le même risque lié aux procédures légales sur lequel le service juridique se concentrait.

Le langage de consentement que personne ne met à jour

On a trouvé une vieille clause de consentement sur nos propres formulaires destinés aux clients qui faisait référence au « traitement automatisé pour l'amélioration du service » sans nommer l'IA spécifiquement. Notre responsable de la protection de la vie privée l'avait signalée deux ans plus tôt et ça n'avait simplement jamais été révisé. C'est une petite chose, je pense, mais c'est le genre de petite chose qu'un régulateur remarque avant de remarquer votre schéma d'infrastructure.

On a assumé que les règles du Québec ne s'appliquaient pas à nous

On n'a pas notre siège social au Québec. Environ 14 % de notre base d'abonnés s'y trouve. L'exigence d'évaluation des transferts de la Loi 25, en vertu de l'article 17, s'applique à toute organisation qui traite des renseignements personnels de résidents du Québec, pas seulement aux entreprises établies au Québec, et on avait traité ça comme le problème de quelqu'un d'autre plus longtemps que je suis à l'aise d'admettre. Faire cette évaluation voulait dire nommer explicitement chaque flux de données sortant du Québec plutôt que de décrire le fournisseur de façon générale : inférence européenne pour certains niveaux de modèle et en cas de basculement, et une courte liste de traitements aux États-Unis limités aux réseaux de cartes de paiement et à l'envoi de courriels, le tout inscrit dans la politique de confidentialité plutôt que quelque chose qu'on devait extraire à force de questions. Divulguer ces flux clairement a fini par rendre l'évaluation plus rapide, pas plus lente, parce qu'il n'y avait rien à aller chercher.

La seule chose qui s'est avérée ne pas avoir d'importance

On a dépensé une quantité d'énergie surprenante, au début, à s'inquiéter de l'entraînement des modèles — est-ce que l'IA d'un fournisseur allait ingérer nos transcriptions client et les intégrer dans une future mise à jour de modèle à laquelle un concurrent pourrait d'une manière ou d'une autre avoir accès. En pratique, chaque fournisseur qu'on a sérieusement considéré avait déjà une clause claire de non-entraînement sur les données clients, et ce n'a jamais été le point d'achoppement dans aucune négociation. Je ne dépenserais plus de temps là-dessus. Ça avait l'air du risque effrayant qui fait les manchettes et ça s'est avéré être la case la plus facile à cocher.

Ce qu'on a vraiment demandé à chaque fournisseur, dans l'ordre

Au troisième appel avec un fournisseur, on avait une liste, et j'aurais aimé qu'on commence avec ça.

• Où se fait l'inférence, précisément, et est-ce qu'un niveau diffère des autres?
• Quel est le calendrier de conservation pour les journaux de clavardage et les documents, et peut-il être raccourci contractuellement?
• Nommez chaque sous-traitant, y compris l'infrastructure de paiement et de courriel.
• Les données client sont-elles jamais utilisées pour l'entraînement de modèles, sous quelque forme que ce soit?
• Que se passe-t-il en cas de basculement, et est-ce que ça change la juridiction?
• Peut-on obtenir ça dans l'addenda sur le traitement des données, pas juste sur la page marketing?

Cette liste a attrapé plus de choses que nos instincts de départ. La question du basculement, en particulier, a fait ressortir quelque chose qu'on n'avait pensé à demander à aucun fournisseur, y compris ceux qu'on a fini par écarter.

Pourquoi on a fini par tester une plateforme d'IA canadienne

Je vais être honnête, j'étais sceptique au départ que « IA canadienne » soit une catégorie significative plutôt qu'une étiquette marketing collée sur une infrastructure fonctionnellement identique aux grandes plateformes américaines. On n'était pas sûrs que ça tiendrait la route sous un examen serré. Ce qui m'a fait changer d'avis, en partie, c'est que lorsqu'on a demandé directement à Augure la question du transfert vers le Québec, la réponse nommait les flux réels : inférence canadienne par défaut pour la plupart des niveaux, inférence européenne et basculement pour d'autres, et une courte liste précise de traitements aux États-Unis limités aux réseaux de cartes de paiement et à l'envoi de courriels, documentée dans la politique de confidentialité plutôt qu'enterrée quelque part. Cette précision comptait plus pour notre service juridique qu'une affirmation générale du genre « on est canadiens » n'aurait compté. Le prix tournait autour de 80 $ CA par mois par utilisateur pour le niveau avec gestion de documents et agents de recherche, ce qui était comparable à ce qu'on payait par siège pour l'outil américain qu'on a remplacé, donc le coût n'a été le facteur décisif dans aucun sens.

Ça n'a pas rendu notre conformité PIPEDA automatique. Je veux être clair là-dessus parce que je pense que les fournisseurs laissent parfois entendre ça, intentionnellement ou non. Ce que ça a fait, c'est rendre les parties de notre propre obligation de responsabilité — savoir où vont les données, documenter les transferts, répondre à la question d'un régulateur sans courir pendant six semaines — considérablement plus faciles à remplir, parce que les réponses étaient précises plutôt que rassurantes.

Ce que je referais autrement

Je ferais mettre le calendrier de conservation par écrit avant la deuxième rencontre avec n'importe quel fournisseur, pas la quatrième. J'arrêterais aussi d'assumer que notre propre langage de consentement était à jour juste parce que personne ne s'en était plaint. Ces deux choses-là nous ont coûté plus de temps que la comparaison des fournisseurs elle-même, ce qui n'était pas ce à quoi je m'attendais quand on a commencé.

Si vous faites cette révision vous-mêmes, les questions comptent plus que le nom du fournisseur sur la diapositive. augureai.ca a la politique de confidentialité et la documentation sur les sous-traitants si vous voulez voir à quoi ressemble une réponse précise à côté d'une réponse vague.