Loi 25, PIPEDA et IA : la checklist 2026 pour déployer ChatGPT, Copilot et des agents sans vous exposer

Temps de lecture : 12 minutes | Publié le 14 avril 2026

Pourquoi cette checklist compte vraiment en 2026

Le problème n'est plus d'accéder à l'IA.

Les modèles sont là.
Les interfaces sont déjà dans les équipes.
Les usages se diffusent souvent plus vite que les politiques internes.

Le vrai risque commence précisément à ce moment-là.

Quand une organisation adopte ChatGPT, Copilot ou des agents sans cadre clair, elle ne déploie pas seulement un outil. Elle ouvre un nouveau périmètre de risque.

Au Québec, les manquements les plus graves à la Loi 25 peuvent exposer une organisation à des sanctions allant jusqu'à 25 M$ ou 4 % du chiffre d'affaires mondial, selon le montant le plus élevé.

PIPEDA ne repose pas sur le même régime de sanctions, mais impose tout de même des obligations réelles en matière de protection, de responsabilité, de gestion des atteintes et de gouvernance.

Autrement dit, le sujet n'est plus "pouvons-nous utiliser l'IA ?".
Le sujet est : pouvons-nous l'utiliser d'une façon que notre organisation peut défendre ?

D'abord, ne mélangez pas ces trois réalités

Beaucoup d'équipes parlent d'"IA" comme s'il s'agissait d'un seul bloc. En pratique, les exigences ne sont pas les mêmes.

Cette distinction est essentielle.

Une organisation peut tolérer certains usages d'assistance simple et interdire, en parallèle, certains usages agentiques tant que l'architecture n'est pas prête.

La checklist Kantia 2026

Voici la checklist minimale que toute organisation canadienne devrait passer avant d'élargir l'usage de ChatGPT, Copilot ou d'agents IA.

1. Cartographier les usages réels, pas seulement les usages autorisés

La première erreur consiste à ne documenter que la politique cible.

Il faut d'abord savoir :

• qui utilise déjà quels outils
• dans quelles équipes
• sur quels types de données
• pour quels cas d'usage réels
• avec quelles contournements informels

Sans cette cartographie, la gouvernance reste théorique.

À obtenir avant toute généralisation
Une vue simple par équipe, outil, type de donnée, criticité et niveau d'autonomie.

2. Classer les données avant de parler d'IA

Toutes les données ne devraient pas entrer dans un système IA de la même façon.

Vous devez distinguer au minimum :

• données publiques
• données internes non sensibles
• renseignements personnels
• données financières, juridiques ou santé
• données protégées par le secret professionnel, le privilège ou des obligations sectorielles

Si cette classification n'existe pas, il devient presque impossible de définir ce qui est permis, toléré ou interdit.

Règle simple
Plus la donnée est sensible, plus l'usage doit être encadré, journalisé et validé.

3. Savoir exactement où vont les données

Une question reste trop souvent sans réponse :

Quand un collaborateur utilise un outil IA, où part l'information et dans quelles conditions ?

Avant de valider un outil, vous devez clarifier :

• la localisation des traitements
• la durée de rétention
• la réutilisation éventuelle pour l'entraînement
• les paramètres de journalisation
• les mécanismes de suppression
• les sous-traitants impliqués

Le mot "enterprise" dans un produit ne remplace jamais une vraie lecture du cadre fournisseur.

4. Définir noir sur blanc les usages interdits

Beaucoup d'organisations écrivent des recommandations. Trop peu écrivent des interdictions claires.

Il faut pourtant rendre explicite ce qui est exclu, par exemple :

• coller des renseignements personnels dans un outil non approuvé
• demander à un modèle de produire une décision finale sur un dossier sensible
• laisser un agent déclencher une action critique sans validation humaine
• exposer des pièces client sans cadre contractuel et technique validé

Une politique utile ne doit pas seulement dire "faites attention".
Elle doit dire ce qui n'est pas acceptable.

5. Séparer assistance, recommandation et décision

Toutes les sorties IA n'ont pas le même poids.

Une organisation sérieuse doit distinguer :

• l'assistance à la rédaction
• la suggestion ou préqualification
• l'analyse préparatoire
• la décision ou action à impact réel

Plus l'impact métier, juridique ou humain est élevé, plus la validation humaine doit être explicite et traçable.

Exemple
Un modèle peut aider à préparer un dossier. Il ne devrait pas, seul, l'approuver, l'envoyer ou l'exécuter dans un flux critique.

6. Rendre la validation humaine visible et non implicite

Beaucoup d'équipes pensent avoir gardé "l'humain dans la boucle" alors qu'en réalité la validation est floue, tacite ou impossible à démontrer.

Vous devez pouvoir répondre clairement à ces questions :

• qui valide
• à quel moment
• sur quels critères
• avec quelle trace
• dans quels cas l'escalade est obligatoire

Une validation non documentée n'est pas une vraie mesure de contrôle.

7. Journaliser les étapes critiques

Si vous ne pouvez pas reconstituer ce qui s'est passé, vous ne gouvernez pas le système. Vous le subissez.

Sur les flux critiques, il faut pouvoir tracer :

• le déclencheur
• le contexte d'entrée
• les agents ou modèles sollicités
• les transformations majeures
• les validations humaines
• les exceptions et reprises

La traçabilité ne sert pas qu'à auditer.
Elle sert aussi à corriger, expliquer et défendre.

8. Intégrer les risques propres aux agents et à la GenAI

Le débat conformité ne peut pas se limiter à la confidentialité.
Les risques GenAI ont leur propre mécanique.

Il faut traiter explicitement :

• la prompt injection
• les sorties trompeuses ou inexactes
• la fuite de contexte entre systèmes
• les permissions excessives
• les actions automatiques mal bornées
• les chaînes d'agents trop opaques

Une organisation peut être "privacy-aware" et malgré tout rester vulnérable sur l'orchestration.

9. Évaluer le fournisseur comme un vrai partenaire de risque

Avant de brancher un outil IA sur des flux réels, posez au minimum les questions suivantes :

1. Quel est le cadre contractuel exact ?
2. Quelles garanties existent sur la rétention, l'entraînement et la suppression ?
3. Quelles sont les options de journalisation et d'audit ?
4. Quels sous-traitants ou services tiers interviennent ?
5. Quels contrôles de sécurité et de permissions sont réellement disponibles ?

Si ces réponses sont floues, la décision devrait l'être beaucoup moins :
n'élargissez pas l'usage.

10. Prévoir un scénario d'incident avant le déploiement

Beaucoup d'organisations prévoient la valeur. Peu prévoient la dérive.

Avant tout déploiement sérieux, vous devriez savoir :

• comment signaler une mauvaise utilisation
• comment isoler un agent ou un workflow
• comment documenter une atteinte ou un incident
• comment notifier les parties concernées
• comment suspendre un usage sans casser toute l'exploitation

La maturité se voit moins dans la démo que dans la façon dont le système se comporte quand quelque chose tourne mal.

11. Nommer un owner, pas seulement un sponsor

L'IA échoue souvent en gouvernance pour une raison simple : tout le monde est favorable, mais personne n'est réellement responsable.

Il faut un ownership clair sur :

• la politique d'usage
• la validation des cas d'usage
• la revue des exceptions
• la relation fournisseur
• l'évolution du cadre de contrôle

Un sponsor soutient.
Un owner répond.

12. Revoir le dispositif en continu

L'outil change.
Le fournisseur change.
Les permissions changent.
Les usages changent.

Une gouvernance IA n'est pas un document figé. C'est une discipline continue.

La bonne question n'est pas : "Avons-nous une politique IA ?"
La bonne question est : "Notre dispositif reste-t-il à jour alors que les usages évoluent ?"

Ce qu'une organisation mature devrait pouvoir démontrer

À la fin, une organisation sérieuse devrait pouvoir démontrer au minimum :

• quelles données peuvent ou non entrer dans quels outils
• quels usages sont autorisés, limités ou interdits
• comment les décisions critiques sont validées
• comment les flux sont tracés
• comment les risques propres aux agents sont traités
• qui porte la responsabilité opérationnelle du cadre

Si vous ne pouvez pas démontrer cela simplement, votre dispositif n'est probablement pas assez mature.

Où KORA intervient

C'est précisément là que KORA, pour Kantia Orchestrated Reliable Agents, devient utile.

KORA ne sert pas à ajouter une couche technologique de plus.
KORA sert à transformer l'usage de l'IA en système plus gouvernable.

Concrètement, KORA aide à :

• structurer les agents et les étapes d'exécution
• clarifier les rôles et points de validation
• tracer les flux critiques
• mieux gérer les exceptions
• soutenir une exploitation plus défendable dans un contexte canadien et québécois

Autrement dit, KORA répond là où beaucoup d'outils s'arrêtent :
au moment où l'IA doit devenir exploitable sans devenir risquée.

Références officielles utiles

• Commission d'accès à l'information du Québec - Sanctions et poursuites
• Commissariat à la protection de la vie privée du Canada - Intelligence artificielle générative
• Directive sur la prise de décision automatisée - Gouvernement du Canada
• NIST AI RMF - Generative AI Profile

Conclusion

Déployer ChatGPT, Copilot ou des agents n'est plus un sujet expérimental.
C'est désormais un sujet de gouvernance.

La bonne organisation n'est pas celle qui adopte le plus vite.
C'est celle qui sait :

• ce qu'elle autorise
• ce qu'elle interdit
• ce qu'elle trace
• ce qu'elle fait valider
• ce qu'elle peut défendre

Parlez à Kantia pour cadrer votre dispositif IA

Si vous voulez passer d'un usage opportuniste de l'IA à un cadre réellement exploitable au Canada, c'est exactement le type de chantier pour lequel KORA a été conçu.