IA et confidentialité : comment vos données restent privées quand on branche un LLM sur votre cabinet

La peur légitime (et les mauvaises réponses)

Chaque cabinet qu'on rencontre pose la même question dans les 5 premières minutes : « Si on branche l'IA sur nos dossiers, est-ce que les données de nos clients se retrouvent dans le modèle? »

La réponse courte : non, si c'est architecturé correctement.

La réponse longue : la majorité des incidents de « fuite de données IA » viennent de deux sources — des employés qui copient-collent des données client dans ChatGPT, ou des intégrations mal configurées qui envoient des données brutes à des API publiques. Aucune des deux n'est inévitable.

Ce que la Loi 25 exige (concrètement)

Depuis l'application complète de la Loi 25, la Commission d'accès à l'information du Québec impose trois obligations directes quand un cabinet utilise l'IA :

1. Transparence. Si une décision affecte un individu (conflict check, priorisation de dossier, triage de demande), le cabinet doit pouvoir expliquer comment l'IA a fait cette décision à la personne concernée.
2. Consentement par défaut désactivé. Les outils de suivi et d'analytique sont opt-in, pas opt-out. Pas de cookies de tracking sans consentement explicite.
3. Minimisation des données. Ne passer au LLM que les données strictement nécessaires au traitement. Pas de dump complet de dossier « au cas où ».

Les amendes vont jusqu'à 4 % du chiffre d'affaires mondial. Mais la vraie perte, c'est la confiance du client.

L'architecture qu'on déploie (et pourquoi elle fonctionne)

Voici les quatre couches de protection qu'on met en place dans chaque projet d'intégration IA :

1. Aucun entraînement sur vos données

Les modèles qu'on utilise (Azure OpenAI, Anthropic, modèles open-source hébergés) ne s'entraînent pas sur les données de nos clients. Vos requêtes ne finissent pas dans le prochain modèle public. C'est contractuel, pas juste une promesse — les API d'entreprise offrent des garanties écrites de non-rétention.

2. Contrôle d'accès dans le RAG (le problème que personne ne voit)

La technique standard pour brancher un LLM sur vos données s'appelle RAG (Retrieval-Augmented Generation). Le LLM ne « voit » pas toute votre base — il reçoit seulement les fragments pertinents à la question posée.

Le risque invisible : le data bleed. Un adjoint administratif pose une question au système, et l'IA lui remonte un document confidentiel du comité de direction parce que le filtre de permissions n'existe pas.

La solution : on implémente un contrôle d'accès basé sur les rôles (RBAC) directement dans la base de données vectorielle. Si vous n'avez pas accès à un document dans Clio, vous n'y avez pas accès dans l'IA non plus. Même permissions, même périmètre.

3. Données synthétiques pour le testing

Quand on développe et teste un pilote, on ne travaille jamais avec de vraies données client. On génère des données synthétiques — des jeux de données qui ont les mêmes propriétés statistiques que les vrais, mais ne contiennent aucune personne réelle.

Pour un cabinet d'avocats : des dossiers fictifs avec des noms fictifs, des dates cohérentes, des montants réalistes. Le pilote fonctionne exactement pareil, mais zéro donnée sensible ne touche l'environnement de développement.

4. Hébergement souverain quand c'est nécessaire

Pour les cabinets qui traitent des dossiers à haute sensibilité (immigration, droit familial, criminel), on peut déployer des modèles open-source sur infrastructure privée — Azure Canada (Montréal/Toronto) ou serveur dédié. Les données ne quittent jamais le sol canadien.

Ce n'est pas nécessaire pour tous les cas d'usage. Pour un conflict check ou un triage de courriels, les API d'entreprise avec garantie de non-rétention suffisent. On dimensionne la protection au risque réel.

La question que les associés oublient de poser

La plupart des cabinets se concentrent sur « est-ce que l'IA va fuiter nos données? » alors que le vrai risque est déjà là : vos employés utilisent ChatGPT, Copilot et Claude en Shadow AI, sans aucun cadre, depuis 2023.

Un projet d'intégration IA structuré remplace l'usage sauvage par un usage contrôlé. Au lieu de bloquer l'IA (ce qui ne fonctionne jamais), on la canalise dans un système avec des permissions, des logs, et des garde-fous.

Ce qu'on signe avant de commencer

Chaque projet commence par un NDA mutuel. Voici ce qu'il couvre concrètement :

• Non-rétention des données : les requêtes envoyées au LLM ne sont pas stockées au-delà de la session.
• Pas d'entraînement : vos données ne contribuent à aucun modèle futur.
• Droit d'audit : vous pouvez auditer notre infrastructure et nos logs à tout moment.
• Destruction à la fin du mandat : toutes les données de projet sont purgées selon votre politique de rétention.

Si la confidentialité est ce qui vous retient

Le Projet d'intégration IA commence par un appel découverte de 30 minutes où on adresse la question de la confidentialité en premier. On ne touche à rien avant que vous soyez à l'aise avec l'architecture.

Réservez votre appel découverte (30 min) →

Ou commencez plus léger : téléchargez la checklist de préparation IA pour votre vertical.