Quand un agent IA en lit trop : les incidents de confidentialité et la Loi 25

En octobre, le CERT national de l’Inde a signalé que des agents IA en cours d’évaluation avaient atteint des systèmes en production d’organisations indiennes et lu des dossiers d’affaires contenant des renseignements personnels et confidentiels (CIAD-2026-0049). Aucune des organisations touchées ne s’en est rendu compte. Ce sont les fournisseurs d’IA qui les ont prévenues.

Ramenez maintenant le scénario au Québec, et plus près de chez vous. Un agent que vous avez déployé, avec des identifiants que vous lui avez émis, doit résumer les billets de soutien ouverts. En chemin, il ouvre des dossiers de clients qui n’ont rien à voir avec la tâche. Rien ne sort de votre réseau, du moins à votre connaissance.

Est-ce un incident de confidentialité au sens de la Loi 25 ? Si oui, vos obligations courent déjà, et la preuve dont vous avez besoin pour y répondre se trouve dans des journaux que vous ne conservez peut-être pas.

On est des praticiens de la sécurité, pas des avocats. Ce billet explique comment les obligations se traduisent dans l’architecture des agents ; c’est à vos conseillers juridiques de décider comment elles s’appliquent à vous. Les articles cités renvoient à la loi sur la protection des renseignements personnels dans le secteur privé, telle que modifiée par la Loi 25.

Ce que dit la loi

Le régime des incidents repose sur quatre articles.

L’article 3.6 définit l’incident de confidentialité comme l’accès, l’utilisation ou la communication d’un renseignement personnel « non autorisé par la loi », ou sa perte ou toute autre atteinte à sa protection.
L’article 3.5 s’applique dès qu’une entreprise « a des motifs de croire » qu’un incident s’est produit. Elle doit prendre les mesures raisonnables pour diminuer les risques qu’un préjudice soit causé et éviter que de nouveaux incidents de même nature ne se produisent. Si l’incident présente un risque qu’un préjudice sérieux soit causé, elle doit, avec diligence, aviser la Commission d’accès à l’information (CAI) et les personnes concernées.
L’article 3.7 précise comment évaluer ce risque : considérer notamment la sensibilité du renseignement, les conséquences appréhendées de son utilisation et la probabilité qu’il soit utilisé à des fins préjudiciables, et consulter le responsable de la protection des renseignements personnels.
L’article 3.8 exige la tenue d’un registre des incidents de confidentialité. Le Règlement sur les incidents de confidentialité en fixe le contenu et impose de conserver chaque inscription au moins cinq ans après la prise de connaissance de l’incident.

Ne pas déclarer un incident de confidentialité est un des motifs de sanction administrative pécuniaire prévus à l’article 90.1, comme on l’a vu dans notre survol de la Loi 25 et de l’IA générative.

Un agent qui lit hors de sa tâche : accès « non autorisé par la loi » ?

La définition ne dit pas « non autorisé par l’organisation ». Elle dit « non autorisé par la loi ». La vraie question, c’est donc ce que la loi autorise.

L’article 20 donne la réponse la plus proche. Dans l’exploitation d’une entreprise, un renseignement personnel n’est accessible, sans le consentement de la personne concernée, à un préposé ou à un agent qui a qualité pour le connaître qu’à la condition que ce renseignement soit nécessaire à l’exercice de ses fonctions. L’article 12 ajoute qu’un renseignement personnel ne peut être utilisé qu’aux fins pour lesquelles il a été recueilli, sous réserve des exceptions prévues.

Un agent IA n’est pas un préposé, et probablement pas un mandataire au sens juridique. Mais il agit sous une identité que votre entreprise lui a émise ; son accès, c’est donc celui de votre entreprise. Si le renseignement qu’il a ouvert n’était pas nécessaire à la tâche confiée, on peut soutenir de façon crédible que l’accès n’était pas autorisé par la loi, même si vos contrôles d’accès l’ont laissé passer. La permission technique et l’autorisation légale, ce sont deux critères différents.

C’est un argument, pas une décision. À notre connaissance, la CAI n’a publié aucune décision sur l’accès d’un agent IA. La conséquence pratique, elle, est claire : quand un agent lit des renseignements personnels hors de sa tâche, c’est un incident potentiel. Ça s’en va à votre responsable de la protection des renseignements personnels pour évaluation, pas dans un billet de débogage.

« Des motifs de croire » : la barre est basse

L’article 3.5 n’attend pas la certitude. Il s’applique dès que vous avez des motifs de croire qu’un incident s’est produit. Dans un déploiement d’agents, ces motifs arrivent en général sous forme de ligne de journal : un tool call qui a renvoyé des dossiers de clients, une alerte d’un outil de surveillance des accès aux données, un enregistrement leurre qui a été lu.

Ça a deux conséquences. D’abord, le moment où vous en prenez connaissance compte, puisque le registre consigne à la fois la date de l’incident et la date à laquelle vous en avez pris connaissance. Les victimes dans le cas du CERT-In l’ont appris d’un tiers. Ensuite, une entreprise qui ne journalise pas les accès aux données de ses agents au niveau de l’enregistrement risque de ne jamais avoir de motifs de croire quoi que ce soit. Ce n’est pas de la conformité. C’est de l’aveuglement.

Le registre couvre tous les incidents, pas juste les graves

L’avis à la CAI n’est obligatoire qu’en cas de risque de préjudice sérieux. Le registre, lui, couvre tout incident de confidentialité. Selon le règlement, chaque inscription doit notamment contenir :

Une description des renseignements personnels visés, ou les raisons pour lesquelles il est impossible de la fournir
Une brève description des circonstances
La date ou la période de l’incident, et celle de sa prise de connaissance
Le nombre de personnes concernées
Les éléments qui ont permis de conclure qu’il existe ou non un risque de préjudice sérieux
Les mesures prises pour diminuer les risques qu’un préjudice soit causé

La CAI peut en demander une copie en tout temps. Un agent qui a lu 300 dossiers de clients hors de sa tâche, sans indice d’exfiltration, ne justifie peut-être pas d’avis. C’est quand même une inscription, et elle doit expliquer pourquoi vous avez conclu que le risque n’était pas sérieux.

Ne confondez pas ce cas avec un quasi-incident. Si vos contrôles ont bloqué l’agent avant qu’il lise quoi que ce soit, aucun renseignement personnel n’a été consulté et il n’y a pas d’incident de confidentialité. Consignez-le comme quasi-incident dans votre processus de sécurité, comme le recommandent les pratiques clés du NIST, de la NSA et de la CISA. Si l’agent a lu les dossiers et que rien de fâcheux n’a suivi, ce n’est pas un quasi-incident. C’est un incident dont l’évaluation du risque est favorable.

Ce qu’il vous faut pour évaluer le risque

Chaque élément exigé par le règlement correspond à une question sur l’agent. Et chaque question n’a de réponse que si vous l’avez journalisée.

Quels renseignements personnels ont été consultés ? Il vous faut des journaux d’accès aux données au niveau de l’enregistrement pour l’identité de l’agent, pas seulement le tool call qui les enveloppait.
Combien de personnes sont concernées ? Comptez les personnes distinctes dans les dossiers renvoyés, pas le nombre de requêtes.
Quelles sont les circonstances et la cause ? Il vous faut la trajectoire de l’agent : la tâche, les tool calls dans l’ordre et les décisions des contrôles en cours de route. La pratique 5.3 du NIST demande des journaux inviolables suffisants pour reconstituer les trajectoires des agents, leurs tool calls, leurs traces de raisonnement, les interactions avec les utilisateurs, l’état de l’environnement et les décisions des contrôles de sécurité.
Quand est-ce arrivé ? Des horodatages fiables, qui viennent de systèmes que l’agent ne peut pas modifier.
Y a-t-il une probabilité d’utilisation à des fins préjudiciables ? C’est là que l’exfiltration compte. Les données sont-elles sorties dans une requête sortante ? Ont-elles été envoyées à un fournisseur de modèle comme contexte, et qu’est-ce qu’il en conserve ? Les journaux de trafic sortant et les conditions de conservation de votre fournisseur répondent à ça ; une supposition, non.
Quelle était leur sensibilité ? La sensibilité est le premier facteur que nomme l’article 3.7. Votre classification des données doit couvrir les enregistrements auxquels l’agent a accès, sinon vous ne pouvez pas l’évaluer.

Si vos journaux ne répondent pas à ces questions, l’évaluation du risque frappe un mur d’incertitude. Et ne pas savoir ce qu’un agent a lu ni où c’est allé, c’est une bien mauvaise base pour conclure que le risque de préjudice sérieux est faible.

Quand votre agent lit les données de quelqu’un d’autre

Le cas du CERT-In marche aussi dans l’autre sens. Si votre agent atteint le système d’une autre organisation, c’est elle qui détient les renseignements personnels et qui porte les obligations de l’article 3.5. Mais c’est vous qui avez la preuve. La pratique 8.1 du NIST demande aux exploitants d’aviser les parties dont les systèmes ont été compromis, y compris les tiers qui n’étaient pas la cible finale. La pratique 8.2 leur demande de partager chronologies et transcriptions. Écrivez ce chemin d’avis avant d’en avoir besoin.

Besoin d’un deuxième regard ?

Évaluation de la sécurité de l’IA générative. On vérifie si les accès aux données de chaque agent sont journalisés au niveau qu’exigent une évaluation du risque et une inscription au registre au sens de la Loi 25, et on relie chaque constat aux articles 3.5 à 3.8 et aux pratiques du NIST.
Playbooks pour les agents. Un chemin de décision qui mène de « l’agent a lu quelque chose qu’il n’aurait pas dû » à l’évaluation prévue à l’article 3.7 par le responsable de la protection des renseignements personnels, à l’inscription au registre et, au besoin, à l’avis à la CAI.
Exercices tabletop. Un scénario réaliste, joué avec votre équipe de sécurité et votre responsable de la protection des renseignements personnels dans la même pièce.

Cinq questions à poser à votre équipe

Si un agent avait ouvert hier 300 dossiers de clients hors de sa tâche, comment le saurait-on, et en combien de temps ?
Est-ce qu’on peut nommer précisément les dossiers qu’il a lus, à partir de journaux qu’il ne pouvait pas modifier ?
Est-ce qu’on peut prouver si ces données ont quitté notre réseau ou se sont rendues chez un fournisseur de modèle ?
Est-ce que notre playbook envoie les événements d’accès aux données par des agents à notre responsable de la protection des renseignements personnels ?
Notre registre des incidents de confidentialité contient-il des inscriptions liées à des systèmes d’IA ? Si on exploite des agents et qu’il n’en contient aucune, est-ce parce que rien ne s’est produit, ou parce que personne n’a cherché ?